What killed Lisp could kill Haskell as well.

Tanner – did you watch the presentation (and read the response from James Robertson)? The argument is simply that Smalltalk is not being used for a statistically significant set of industry problems (much like Lisp isn’t, nor Clojure perhaps its most recent reincarnation) because it was too easy to make a mess in that you didn’t have to clean up before it got unusable. Lisp clearly isn’t “dead”, some people use it, but probably about the same number as Smalltalk – but the concepts are being used and morphed into other languages. I podcast with a friend who is a major Lisp fancier but he said he wouldn’t write a commercial app in it.

My response to Robert’s comment about Haskell is – is Haskell even alive? Didn’t Scala provide a “good enough” alternative for functional programmers? Haskell is more like C++, people who understand it have a superiority complex (which IMHO is well deserved, I simply cannot wrap my head around functional programming).

Finally, my comment about the actual talk is that TDD is all fine and good when sorting out the mess that people make with Ruby in their own applications. But when that mess is so awfully bad and has thus been baked into the API (from experience, I am looking at you ActiveRecord), there is little you can do about it. Where the language and framework require you to monkey patch, nothing will save you from those hell debugging sessions, not even TDD.

Thanks for the link Robert, very interesting presentation.

Norman Ramsey said some things recently that I think are on the money http://stackoverflow.com/questions/822752/should-i-learn-haskell-or-f-if-i-already-know-ocaml/823338#823338 Basically, the investment in Haskell in language researchers means they’ll be Haskell papers for many years to come. When the Haskell papers no longer appear at ICFP, then we can turn off the lights.

The other direction, though, cracking the mainstream, is really hard. People are tied to the JVM. People are tied to .NET. This hurts Python, Erlang, Haskell, Ruby. It gives free “credibility points” to Scala, Clojure, F#, Groovy.

Clojure wont win the battle but may win the war. Is it better than Haskell, Smalltalk, Common Lisp or Scala? No. It’s not better, anymore than they are better than Clojure. What Clojure is, is a well thought-out, well designed language with unique features as well as features that other languages share. That said, the other languages in the list also have their unique features.

Picking a language, as everyone must admit is a very complicated exercise. The language selected most is the one that is mandated by the organizations we work for. In the rare case where one is given the choice to select a language, macro-economics more often than not, play as important a role in selection as anything technically related.

Now back to the first statement. In fact, Clojure may or may not win any given battle. The dynamics of a battle (a language selection) are far too specific to a given environment and problem domain to say whether it should or could win without a much deeper understanding of the particular battle situation. What I do think however, is that Clojure will win the war. In “war” I mean, it will “survive” and prosper unlike so many other languages that have fell by the way side.

Clojure does not attempt to be everything to everyone like Scala or Common Lisp. Clojure is not as academically pure as Haskell. Clojure, if it is anything at all, is pragmatic and delivers on its targeted objectives. It will win the war (survive) because those objectives are clear, concise, achievable and most importantly understandable.

A hammer still survives despite the introduction of the nail gun. Why? Nail guns are clearly more efficient aren’t they?. A hammer survives because, not all problem instances are of the same scale. Clojure is like the hammer. Haskell is great when the problem is purely functional. I would hazard to say that while most problems can benefit from a functional style of programming their solutions are not entirely without side effects. Somewhere in there there is a “sweat spot”. A functional side effect free line in the sand, so to speak. One could argue forever where that line is but the point is; that if your on one side of the line Clojure’s approach is a very efficient one and if your on the other Haskell might be more suitable. My observation of the commercial landscape gives the majority of the space on either side of the line to Clojure.

With respect to Common Lisp and Small talk the battle and the wars are over. They are what they are. They have survived and will continue to do so, no doubt for many years to come, but they will not become more than what they are. This outcome is cast in stone as soon as they were standardized and relegated to the bureaucratic standards heap.

Scala, on the other hand wants to be a better Java. Clearly its goals are to add functional capabilities to a language that was lacking them. Scala may indeed become a successful general purpose language. It is a well designed language. As a general purpose language however, it suffers from the same fate that all general purpose languages face. It is a compromise of an over-abundance of objectives. The greater the list of objectives, the more general it is, the more of a compromise it becomes. This is both a strength and a weakness.

Comparing Scala to Clojure is more straight forward.

Scala is great when you have general problems to solve that would generally be solved with Java but you want to use something cool and new. Scala does many things better than Java but jumping the language gap is always an expensive proposition. Is there enough value choosing Scala over Java? You would have to determine that for yourself. It is a very challenging business case to switch languages. Are the benefits of switching from Java to Scala so great and so provable that it makes conclusive sense to switch? For some perhaps, but for most large enterprises that drive the JVM stack blueprint, not likely.

Clojure on the other hand is great when a STM capable, Dynamically typed, Homoiconic, macro leveragable language is required. While the later seems obscure, it’s not. Some problems are simply very hard, and very expensive to solve without those features. More importantly the number of problems that fit this category is growing like the dickens. These problems are at best solved, with great difficulty, with general purpose languages.

Clojure will survive because all the other languages have made fundamental design decisions that conflict with the holistic set of features that Clojure is built upon. Sure the other languages can “do” whatever needs to be done but they aren’t as elegant as Clojure for these types of problems. The other languages are strong in most general problem domains but not especially strong in this specific problem domain. The other languages cannot simply be extended to create an optimal solution for these types of problems. Because they have fundamentally followed a different design approach they will not be optimized for problems this specific without breaking many of the other design designs that they rely upon.

What is far more likely is that Clojure will loose to a language that has yet to be developed that finds an even better solution to the aforementioned type of problem. Until that time comes however, we have Clojure.

I’m programming clojure as my day job, so trust me- I’m well aware of it’s benefits and drawbacks. It’s biggest benefit is also it’s biggest drawback- dynamic typing.

I’ve decided that object orientation and static typing go together like chocolate and motor oil. The problem is that the true type of an object in an OO program depends upon where it came from, all the way back. Static typing an OO language is basically implementing a dataflow type system, in a situation where “I don’t know” isn’t an acceptable answer. Forget type inference, in this case- just specifying the types requires a complicated type system, handling (at least) both co-variance and contra-variance of types. A type system, in other words, that would be of interest to a PhD-level type theorist, but one that would be nigh onto impossible for a mere mortal (like even me) to understand.

Given this, going pure dynamic typing is an obvious win if you’re dealing with OO at all. Clojure is the least painful way I know of to access all those huge Java libraries.

On the other hand, dynamic typing is throwing away one of the most powerful and useful correctness tools for software we have- static typing, also known as static analysis. Having just spent half an hour of my life tracking down a bug that turned out to be that I was passing a map in where a vector of maps was expected, a bug that a decent (by which I mean Haskell/Ocaml/etc. style) type system would have caught and I would have fixed in 30 seconds.

Having now worked, in a production setting, with both Ocaml and Clojure, given a choice between macros and static typing, I’d take static typing and I wouldn’t look back. The measure of productivity isn’t “how fast is it to write the code?”, it’s “how fast is it to get the code working?” My experience is that both me and every other programmer I’ve ever worked with spends a hell of a lot more time debugging the code than they do writing the code. Especially if you count the time it takes to design, write, and debug unit tests- which I do. Unit tests don’t add features to the product, they’re just there to find and help isolate bugs. Just like static typing.

The big advantage of Clojure is then that it’s on the JVM and has really good integration with Java, giving you access to all those huge Java libraries- Terracotta, Lucene, Restlet, etc. This is an even bigger win in terms of productivity that either macros or static typing- if you can turn a 30K LOC project into a 5K LOC project plus a 100K LOC library that someone else has written and already debugged, that’s a huge win.

As just a side note, Haskell does allow side effects and mutable variables. It’d be a pretty boring language if it didn’t- I/O is a side effect. Haskell just “isolates” the side effects within monads.