Who Knew?


Who knew that Peter Coffee was a closet LISP junky? First he published this piece on "exotic" languages that I commented on at Between the Lines and then yesterday, he put out an article entitled LISP Deserves a Fresh Look. Peter's argument has two prongs. His first point is that old arguments against LISP are largely no longer true.

The current generation of application developers has been imprinted with a business model of mass-market software as frozen bits, packaged as executable binary files, delivered on inexpensive media units--floppy disks or CDs--to run on a PC.

This model is merely an artifact, though, of one brief stage in the evolution of technologies and markets.

The model of "bits in a baggie," as one might call it in homage to the Apple II era, defined its own criteria for programming languages: ease of compilation, minimum code size for ease of distribution and minimum memory footprint for acceptable performance on low-cost PC configurations.

When product-cycle durations are measured in years--or, at a minimum, in quarters--a cumbersome process of turning source code into saleable bits is tolerable; when a mass-market application is delivered as function across a network, not as raw bits in a licensee's hands, the equilibrium state is far more friendly to developers.
From LISP Deserves a Fresh Look
Referenced Wed Feb 08 2006 13:43:02 GMT-0700 (MST)

His second point is that there are real productivity reasons to consider LISP. Peter cites the work of Erann Gat, a researcher at the California Institute of Technology's Jet Propulsion Laboratory:

The trade-offs are clear. In [Gat's study], programmers writing in LISP produced programs with less variability in performance than more experienced programmers writing in C and C++.

The fastest versions of C and C++ programs were faster than most LISP implementations, but the median performance of the LISP implementations was actually twice as good as the median performance of the C and C++ code performing typical tasks.

For real-world teams, such reduction of technical risk and improved worst-case scenarios arguably outweigh best-case results.

The LISP implementations in Gat's study were more memory-intensive than those in C and C++, although LISP's memory use was comparable to that of Java while performance was much better. A key point, though, is that applications are increasingly being delivered to users via the Web, and that developers are therefore freer to use tools that maximize their own flexibility at the supply end.
From LISP Deserves a Fresh Look
Referenced Wed Feb 08 2006 13:45:14 GMT-0700 (MST)

Do I expect any of this to convince you? No, not really. People rarely pick programming languages based on what works best. There are usually a pile of political and social problems that get in the way and muddy the waters. Most programmers don't pick the language they use anyway. It gets picked for them by a pointy-haired boss for whom the political and social factors loom large.