Paul Graham - LISP fanboy extraordinaire
There - that got your attention, didn’t it?
Anyway, I finally managed to finish Paul Graham’s “Hackers and Painters“. After really enjoying the first two or three chapters (see my previous post), I found finishing this book quite a chore and on the whole found it quite a let-down. At the end, I’m not sure what I’ve learned. Except that Paul enjoys LISP. That’s what I found the most painful and booooooringgggg: Advanced LISP fanboy-hood (is that a word? If not, I’ve got copyright).
What totally threw me off was the repeated “Milchmädchenrechnung” (see here for explanation) of developer productivity and the huge gains possible by using LISP. Paul’s argument — condensed in order to make a point — is as follows: Due to syntactic brevity, the average LISP program is five to ten times as short as a Java program solving a similar problem. Hence, LISP programmers are five to ten times times as productive, giving any start-up using LISP an enormous competitive advantage over those using Java. He actually writes: ‘So the more powerful the language, the shorter the program. […] Code size is important, because the time it takes to write a program depends mostly on its length. If your program would be three times as long in another language, it will take three times as long to write […] If [your competitors developing in LISP] spent just three months developing something new, it would be five years before you had it too.’ (p. 192f)
I call bullshit!
This comparison would make some sense if software development was really just slinging out code and if the quality of your results and the speed at which you achieve these results depended merely on the speed at which you type (or the amount that you need to type, asusming your typing speed remains constant). But it doesn’t! There’s conceptual design, actually understanding the problem, coming up with a solution to the problem, and then developing an implementation. The mere effort expended typing your solution into the machine is only a fraction of the total effort in coming up with a working solution. Even more so if you take the application’s life-cycle into account and consider maintainability, robustness, or ability to adapt and grow. I’ve yet to see a project post-mortem which comes to the conclusion “well, we could have finished within the schedule and on budget, but you see there were all these curly braces and ‘public’ keywords in Java which totally slowed us down. So in the end we needed twice as long with twice as many developers. Two additional off-shore teams were needed just for all the semicolons.”
In an appendix titled “Power”, Paul then compares programming languages based on the following “problem”: ‘We want to write a function that generates accumulators - a function that takes a number n, and returns a function that takes another number i and returns n incremented by i.’ (p. 195) He then sets out to compare various implementations of this “problem” in different languages, coming up with solutions of varying lengths (although none so long that it would actually matter). From these different code lengths he deduces that LISP is such a hugely more powerful language.
I’m all for choosing the right tool for the job. As for the “power” argument, there’s no discussion at all of wether the “problem” is actually one that is worth solving in other languages and one that would actually come up in other languages. Using a LISP idiom (macros or closures) which cannot be directly expressed in another programming language in order to prove LISP’s superiority is a very strange argument indeed. Just because I can string together nouns into compound nouns and write “Donaudampfschiffahrtsgesellschaftskapitänsmützenkordel” in German, does that mean that German is inherently a superior language to English? Probably not.
If speed of production were the only issue, stenographers would all be Shakespeare.
Tags:
Hackers and Painters; Paul Graham; Programming Language; LISP
Bookmark on del.icio.us
Add this post to digg.com
Bookmark on reddit.com
February 12th, 2010 at 8:20 pm
I know this was 3 years ago, but there have been studies showing a given programmer writes the same number of lines of productive code a day, on average, regardless of the language. So if you are a super-productive C programmer and can write 200 lines of C code, once you switch to Python and become used to it, you’ll be able to write 200 lines of Python code a day. Since you can do more in 200 lines of Python than in C, you will be more productive. There is merit to this argument.