Monday, July 10, 2017

Learning Clojure Is a Sunk Cost

Here is a message I wrote to an old colleague of mine after spending time learning Clojure from the "Functional Programming for the Object Oriented Programmer" book, and then beginning to read "The Joy of Clojure".

I might have made a few typos. Please don't judge!

Message body begins here.

***

Yesterday, I bought the Joy of Clojure eBook/liveBook edition at Manning. After reading through the first few chapters, here is my opinion as summarized the upcoming 3 paragraphs. I shall blog and tweet my opinions too very soon.

“One example of incidental complexity is the tendency of modern object-oriented languages to require that every piece of runnable code be packaged in layers of class definitions, inheritance, and type declarations.”

This is not the programming language consumer concern. It is the programming language creator concern. To a consumer, you would not have to know about the many layers of Object inheritance and can avoid inheritance except where it offers value. This is not a problem except to the inexperienced developer, which would have a problem with LISP too and any other language. Last but not least, type declarations are not needed in Python, Ruby, nor Smalltalk. I think the author was only talking about one OO language, Java, and it's the old Java as the new Java 8 has optional typing now. That point is very weak and does not hold up as a valid use case for Clojure. One more note, Clojure programmers would still have those classes in LISP too, albeit in a different form; as structures or maps, and separate functions. Does that remind you of anything? Sure, C and structured programming. In fact, they are less readable than Object Oriented abstractions in a clean language like Ruby or Smalltalk and introduce the very problem of maintainability that Object Oriented Programming solved long ago. Also, Python, Ruby, and Smalltalk all allow functional style of programming and expressibility while retaining Object Oriented Programming paradigms. There is not selling point here. I'd recommend mastering Ruby or Python instead.

“Clojure cuts through all this by championing the pure function, which takes a few arguments and produces a return value based solely on those arguments. ”

Object Oriented Programming languages already support writing functions, such as Ruby, Python, and Smalltalk among many other examples. Even Java now supports that with Java 8 Lambda Expression even if it did not support in the past. This renders this argument moot with regards to "simplicity" even when taking Clojure's unique Purity support into account. Still, "simplicity" is not enough to ensure having readable and maintainable code, and thus Object Orientation was came about to narrow down the difference between the way we "think" and the way "code", taking advantage of the fact that computers are more than fast enough to spend cycles on supporting such abstractions while still serving users on time.

“An enormous amount of Clojure is built from such functions, and most applications can be, too, which means there’s less to think about when you’re trying to solve the problem at hand.”

As mentioned before, Object Oriented Languages already permit writing such functions (Ruby, Python, Smalltalk). But suppose there is less, in an Enterprise production application, there would still be a lot to reason about all at once, breaking the 7±2 rule of how much a developer can hold in their head to stay productive in problem solving. So, the way to surmount that is to rely on an abstraction mechanism that shields one from details, as no amount of simplicity in a health comparison machine learning algorithm for example would render the algorithm simple, even in Clojure. Developers would still have to deal with complexity, and abstraction hides it better. Furthermore, "Functions" only represent verbs, which is not how we naturally think of the world. Data may represent objects, but keeping both separated creates the very problem that spawned Object Oriented Programming in the first place as mentioned before. Yes, sounds like this is a problem of lack of understanding of Object Oriented Programming in the wild due to being in academia (I am talking about Rich Hickey, I don't care how hard he worked if he's doing the wrong kind of work.. that's biblical, you do your work for God and he guides you on the right path for building things for the real world. I doubt his work was for God, I feel it was for his own personal gratification).

I am sorry I am not sold anymore, and feel I wasted my time learning Clojure, and would have better spent my time learning LISP or Haskell instead for educational purposes only, and then apply its learning in Ruby or Java 8. The price I paid for the book is "Sunk Cost" as per Microeconomics theory, so I'd get more value of that money by forgetting Clojure, not wasting more of my time on top of that money.

In the meantime, I'm buying Programming in Scala next by Martin Oderskey. By the way, of course I know Martin Oderskey. He was famous for adding Generics to Java 5, one of my favorite features at the time. I have very high regard and respect for him. He talked for years about adding Scala-like features to Java, and that didn't materialize till 10 years later in Java 8. I am sure I will get value by learning Scala as that would make me a stronger Java 8 developer since it adds most of its features. I look forward to that reading sometime later today.

As a recap about my opinions of Clojure, I think Rich Hickey was hiding under his brilliance in academia from delivering real customer value in teams of programmers with practical experience, so he does not understand Software "Engineering" concerns very well, and spins factually inaccurate information to motivate people to use a LISP in a production setting instead, without mastering languages like Python, Ruby, or Smalltalk first. May the Lord Jesus Christ deal with him fairly for the benefit of humanity. Just to be clear, I come from Academia as well, so I highly respect University Professors and their works so long as it serves the Lord Jesus Christ and humanity practically instead of wasting people's times and masking Academics' fear of working practically in the real world. The Rubber (Academic Theory) must hit the Road (Real World) before it offers real value to people.

To repay the favor of recommended books, may I recommend to you reading "Java 8 Lambdas" by O'Reilley (http://shop.oreilly.com/product/0636920030713.do)? It was a very quick and practical read for me when I worked at Grass Valley a couple of years ago. I'm sure it would go down as easily as a marshmallow for an experienced Scala developer since most of the concepts come from it anyways.

Andy

2 comments:

Tap said...

Disclaimer: I'm a bias Clojure guy and I'm only familiar with Java and Ruby not Python and Smalltalk.

My summary after reading you blog post is you aren't interested in reading/learning more because Clojure uses functions to build system and functions are available in other languages. Why bother I learn yet another language with nothing new?

I would say on the flip side, don't you curious how do people can make it work? Assuming there are some people successfully build a big system with just functions, isn't less number of concepts to be concerned about better?

With these following concepts, you have to hold fewer things in your head than you might have thought. Immutable data structures, pure functions, REPL, Value - State - Identity separation, Clojure way of state management (Atom).

There's also a well-defined set of libraries to help to compose and chaining functions together. Ruby is my most familiar language before Clojure. I won't be as satisfying using Ruby to build a system with just lambda and proc.

Andy Maleh said...

I stopped reading after this line:
"I would say on the flip side, don't you curious how do people can make it work? "

The answer is yes. I did mention that I do believe in the value of learning LISP and Haskell and applying their knowledge in Ruby and Java. That keeps the learning honestly for academic purposes only. As such, it avoids lying to oneself that using them is better for building business apps in the enterprise world. Instead, sticking to enterprise-quality object-oriented/functional hybrid languages, such as Ruby and Java, ensures serving customers in the best and most professional way possible. After all, they support successful software engineering with Agile teams that can rotate members in and out regularly, address architectural concerns, such as productivity and maintainability regardless of software complexity, and keep live communication with customers using their business domain ubiquitous language as recommended by Domain Driven Design and Object-Oriented Design approaches.