LISP Deserves a Fresh Look

Development tools that are programmer-friendly but hardware-intensive, notably LISP, have long been a staple of research domains such as artificial intelligence—but have not been thought suitable for mass-market applications due to difficulties in packaging the executable bits and running them on end-user hardware.

Web-facing applications, whose running code resides on servers, shift those trade-offs and invite "research" languages such as LISP to contend for mainstream roles.

Formal studies of programmer productivity and program performance—with multiple programmers doing side-by-side implementations of multiple tasks—suggest that functions can be performed with fewer lines of code, with less variability in development time and with acceptable memory use and execution speed using LISP and LISP-based systems.

Developers handicap themselves if they play by old rules on the Webs quite different field.

That which was

Resource Library:

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.

Click here to read about the importance of making source code clear.

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 licensees hands, the equilibrium state is far more friendly to developers.

That which is

Imagine the perspective of the proverbial man from Mars, the hypothetical observer with no preconceived ideas about what makes sense.

The man from Mars sees development languages being chosen as if processor cycles are expensive, when a growing fraction of todays computing workload runs on vast farms of cheap boxes whose cost is spread across entire communities of users.

Martian question 1: Cant you use more processor-intensive methods if they deliver more powerful applications more quickly?

The man from Mars sees development languages being chosen for their ability to condense ideas into executable bits today—not for ease of incorporating new ideas tomorrow.

Martian question 2: If the language youre using requires you to be as clever as you can just to get something working in the first place, how will you ever be clever enough to improve it?

Next page: Reintroducing LISP.