May 09 2009
What killed Lisp could kill Haskell as well.
This blog post is mainly aimed at the functional programmer readership of this blog. There is a video out there on the web from a recent conference that brings up a number of good points, that I think needs to be more widely disseminated in the functional community.
Now, before I link to the video and have you go watch it, I need to do a little bit of explaining. Because, you see, the conference was RailsConf. And the presenter doesn’t even mention functional programming, and his discussion, well, mention really, of static typing encompasses Java, C#, and C++, and that’s it. In fact, the original title is “What killed Smalltalk could kill Ruby as well”. But as you listen to the video, I want you to do the following: when he says “Smalltalk”, think “Lisp”. When he says “Ruby”, think “Haskell”. And when he says “Test Driven Development/Design”, think “Static Typing”. Some of the details don’t map perfectly, but his main points are, I think spot on.
So, with that in mind, go watch.
That is all.
Podcast: Play in new window | Subscribe | Download
I wasn’t aware that Lisp was dead. And, really, isn’t comparing Haskell to Ruby just a bit of delusions of grandeur?
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.
Added the video to the podcast feed.
@Richard
This post was written by Brian Hurt, the other blogger on this page. See his author page for a list of the posts he wrote, as opposed to my author page and the ones I wrote.
@Everyone
Clojure pretty well shows that Lisp (as a family of languages) isn’t dead. In fact, I doubt it will ever die, because it’s so obnoxiously perfect in its mapping to the theoretical underpinnings of computer science. And because it’s what emacs is programmed in, and God knows (but has little to do with) emacs is immortal.
@Richard
And no, Scala doesn’t provide a “good enough” alternative to functional programmers. If you look at the people flocking to Scala, it’s not made of up those with backgrounds in lisp, haskell, ocaml, or erlang — it’s made up of people whose backgrounds are in Java. Interestingly, you’re even seeing an outflux of attention from the JVM to the CLR, where people are looking into F#. F# is basically a more object-friendly OCaml, so for hints on why people are moving over to F#, see my Why Rubyists Should Learn OCaml, or compare the Scala versions of code to the OCaml versions of code presented in 7 Actually Useful Things You Didn’t know Static Typing Could Do: An Introduction for the Dynamic Language Enthusiast.
Actually, the Lisp v. Clojure difference is exactly what James Robertson was talking about. Clojure doesn’t have the arrogance that Lisp did/does. The smalltalk community had nothing on the Lisp community for arrogance. I mean, come on- we still make jokes about the arrogance of Lisp. But by being on the JVM, and providing a close and easy mapping between Java and Clojure, Clojure is being less arrogant. It’s admitting that it needs to deal with and interoperate with the huge bodies of existing Java code. Lisp is dead, in the same sense that Cobol and Fortran are dead (both of which, I comment, still have people coding in them). But it can find new life if it sheds it’s arrogance (as Clojure).
@Brian
Who is James Robertson?
I’m not sure Clojure is really not arrogant in that sense. Being on the JVM doesn’t solve the underlying arrogance: that comes from the mapping back to CSci ideas, and lisp developers overcompensating for the sheer volume of lay-up parenthesis jokes.
I think I got the name of the guy doing the presentation wrong. Sigh. I’m terrible with names. All you humans look alike to me.
Actually, Clojure uses fewer parens, and more other symbols, than “true” Lisp does. Granted, it has way less syntax than “normal” languages like Java, but it doesn’t take to the extreme.
Whether Clojure can break through the wall that everyone else built around Lisp (as opposed to the wall the Lisp programmers built) remains to be seen. But I comment that in the “Programming Clojure” book (being released by the Pragmatic Programmers) has, as chapter 3, a whole chapter devoted to working with Java. I’m still a Clojure N00b, but it feels to me like Clojure is a whole lot more willing to compromise and deal with ugly problems (like legacy code) than Lisp was.
To be clear, the speaker is Bob Martin of Object Mentor, a.k.a. “Uncle Bob”. He’s on Twitter at @unclebobmartin.
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.
I don’t think the parallels hold at all, sorry.
His point was that Ruby programmers need to be disciplined to avoid making a mess. Well, Haskell programmers have more ways (and more reliable ways) to avoid making messes than Ruby programmers do. And I’m not just thinking static typing here, but also purity, QuickCheck, HPC and so on.
Neil Bartlett: Very good point. One of the advantages of Haskell is that if you start trying to create a mess, it makes your life a living hell. Keep your code clean and it’s a breeze. This is one of the reasons I like the strict static typing languages of the Haskell/Ocaml/F# variety. But note- what was his advice about keeping the code clean? Unit testing. The difference is that in Ruby/Smalltalk, unit testing is optional- in Haskell, static typing is not optional. So there is still a mapping there.
But you are right- I was mainly thinking about the “building a wall, or having a wall built for you” aspects of the talk.
Haskell and Lisp are very different things. Haskell is basically a single language with a standard (in some ways similar to Common Lisp), some implementations and several experimental versions. Lisp is still a larger family of programming languages (Scheme, Common Lisp, Emacs Lisp, Logo, Clojure, …).
As a language, Haskell and Common Lisp are also very different. It is a huge mistake to assume that Haskell is a more modern language making Lisp obsolete. It is not. Haskell is really a different language with different application domains. Lisp has not much lore to offer for the Haskell community. Lisp was invented for experimenting in poorly structured domains. Common Lisp was invented to make the result of that research deployable in the military domain (planners, expert systems, …). Common Lisp still has ten active maintained implementations, four of them commercial (LispWorks, SCL, Corman Lisp, Allegro CL). ITA Software for example currently writes the business logic of a new airline reservation system (for Air Canada) in Common Lisp.
Lisp was not killed by the capability of Lisp programmers to create a huge mess. It was not killed at all. This capability at the same time makes a larger industry adoption (which looks for ‘industrial’ programmers that are easily replaceable and does projects where large amounts of people work in a controlled environment) of Lisp impossible AND secures the survival of Lisp, since it still supports exploratory programming in small to medium sized teams very well. The capability of creating a huge mess is somewhat a consequence of its flexibility. But if we remove that flexibility from Lisp, then we weaken its appeal in its core domains.
Haskell people should really try to get rid of their Lisp complex. Haskell is a very different language. It will have users for a long time – at the same time really large scale adoption is unlikely, since Haskell is too complicated for most of the programmers in industry.
Lisp is not dead, it just smells funny.
[...] by Robert Martin titled “What Killed Smalltalk Could Kill Ruby, Too” as well as a blog post drawing parallels between the aforementioned languages and functional languages, namely Lisp and [...]