Tuesday, July 8, 2008

Lisp, Too, Is Mainstream

You’ve seen me talk here before about the fact that I have been lately fascinated with Lisp. Sadly, I haven’t been able to spend the time I’d like with it, but I continue to read and think about it. And I’d really, really like to put in some serious time writing a real app (better: several) in Lisp.

So it was with great interest that I read Lisp, too, is mainstream. I like pretty much everything that Eric has written, and his LispCast screencasts are good, too. This article starts with Greenspun’s Tenth Rule (“Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp”) and extends it to a rather different conclusion:

My point is that it may be too late to start with Lisp so you don't have to reimplement all of its features. Because all of those new languages have already implemented them. At least what most people consider the important ones.

Or put another way:

I guess my point, through all this meandering, is that other languages did borrow a lot from Lisp. About half of it. And now those features are out there, in the world. And in the meantime, while they were borrowing, they got some new features of their own. Features like giant user bases, gazilions of libraries, corporate support, standards bodies. So Lisp has half of the features of Python. Java and Python are far from my ideal language---but so is Common Lisp. The idea that I would have to implement so much of Lisp on my own is a little overblown these days. And speaking of reimplementation: How much of Python's standard library does a complex Lisp program reimplement? How much of Python would you have to reimplement before you regret choosing Common Lisp?

And speaking specifically to macros, which I currently see as the single biggest weakness of C# when compared to Lisp:

Macros let you subsume more code into less code. Macros let you write more functionality with fewer lines. Macros let you abstract away boilerplate into new syntax.

But the corporate manager will say: if everyone writes their own syntax, my programmers can't read each other's code. So instead of having to learn a language once, they will have to learn a new language each time they approach a program for the first time. And the value of macros is lessened.

It’s enough to take the wind out of an aspiring Lisper’s sails. :) However, I haven’t given up yet. I have two questions that I still need to answer for myself before I draw any conclusions of my own.

  1. Is the value proposition of macros (i.e. custom syntax/DSLs) different for small teams? And particularly for stuff I read and write only for myself? Because I’ve got a lot of code that falls into those categories.
  2. Is the library situation really so dire? I find that I don’t actually wind up using third-party libraries all that much in C#, so either the BCL is extremely complete or the types of problems I’m solving are just naturally self-sufficient. Or I’m doing something wrong. :) Besides, when I cruise the Lisp sites, I actually see lots of libraries I could use. But maybe there’s some critical functionality that I’d have to write myself that would take a long time.

Of course, the answers to these questions are inherently highly subjective. Like pretty much any question touching on programming tools. If I can find a way to go write a fair amount of Lisp, I’ll get my answers. They will, however, be my answers. I’ll share them with you if I ever get there, but don’t expect them to help you much. :)


  1. Pingback from Lisp, Too, Is Mainstream at A Better Half

  2. My understanding is that the biggest problem with Lisp libraries is the lack of portability. You really can't take a lisp lib from implementation A and expect it to run on implementation B. So everybody ends up with half-baked libraries.

  3. Use javascript!

    1. Yes. I don't use macros much per se, but I do use a lot of 'dynamic code generation'. I.e. create terse populated data-structures (w/ functions if that's useful) describing your model and then process that to return a more functional model and then operate with that.

    2. No. You need file system and db connectivity. And maybe mail, http and xml. FSO, ADO, CDO, XmlHttp and MSXML. And office automation. Done!


  4. One interesting approach would be to leverage ParenScript, which generates Javascript from Lisp. Particularly useful (I imagine) when writing a web app in Lisp.

    But independent of Lisp, I think it's safe to say that Javascript is the most powerful, widely-deployed language there is, since it's on pretty much every computer and device in existence.

  5. 1. Not really. I've worked on Python in large teams, and had all kinds of problems (when programmers don't run unit tests, or don't even write them). Don't be misled by the fact that macros+functions are more powerful than functions. "Why can't I apply #'AND and #'OR?" is a Lisp FAQ, i.e., even some Lisp programmers don't realize when they're using a macro or a function.

    If your macros are so poorly-conceived that somebody reading your code can't understand anything, then chances are your functions are similarly poorly-designed. (If you're truly lost, just run MACROEXPAND on the sucker! Functions can't even do that.) I guess macros make a convenient scapegoat.

    2. As always, it's not as bad as you fear, but not as great as you hope. Some Common Lisp libraries I've used are so awesome they have no equal in any language on any platform. Others are worse, and all the way down to "awful". It's not really any different than any other language -- there's just a different set of strengths and weaknesses spanned by the set of libraries.

    And I don't think I've ever used a Lisp library that didn't work equally well in CLISP and SBCL, and claim to also work in several others, so I don't know what portability issues Eric is referring to. I'm sure there are concerns around the edges, but it's certainly not common.

  6. Thanks for your comments: as always, the situation as reported by someone who has actually worked with Lisp seems quite different than the perceptions of those who have not. That's not a criticism of anyone: it just seems to be the case that when you actually do it, it turns out differently than preconceived notions suggest.

    Right now the most interesting Lisp to me (indeed, the most interesting language) is Clojure. Since it runs on the JVM, and is a single language rather than a language family, platform issues are essentially nonexistent. Plus it has some pretty amazing features and is super well-thought-out.

  7. It’s the end of the year, and although I skipped 2007, it is my habit to take a look back here on matters