The Universe Known as LISP

Next:   [Contents][Index]

The Universe Known as LISP

Version 0.0.142 2022-01-18 08:49

Copyright © 2021 by LOLH

From the Creators of Lisp and Scheme

No amount of language design can force a programmer to write clear programs. — Guy Steele & Gerald Sussman

And now to Lisp

Lisp is the language of loveliness.

— Richard P. Gabriel, The Art of Lisp & Writing, 2003
../resources/images/lisp-universe

What has been, for me, the most mind-expanding programming language? LISP.

To quote Eric Steven Raymond from his manifesto “How To Become A Hacker”:

"LISP is worth learning for a different reason — the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot."

He’s not wrong! I’ve had that exact type of experience with LISP.

— Chris Crawford

"There’s also a special place in my heart for Emacs Lisp, a venerable goofball language that’s so much fun to discuss."

"Lisp programmers are of the opinion that ‘[]’ and ‘{}’ are just ‘()’ with delusions of grandeur."

"47. The first Lisp interpreter was a result of a programmer ignoring his boss’s advice." Peter Norvig, A Retrospective on Paradigms of AI Programming

"48. Abelson and Sussman (1985) is probably the best introduction to computer science ever written. Id.

"CommonLisp, the mud ball of strength, [is] the acting patriarch of the Lisp family." (https://wiki.c2.com/?CommonLisp)

../resources/images/MfcSJ3gl

(https://wiki.c2.com/?SmugLispWeenie)

Creator of Organisms

"Pascal is for building pyramids – imposing, breathtaking structures built by armies pushing heavy blocks into place. Lisp is for building organisms…"

— Alan Perlis

Alan Jay Perlis (April 1, 1922 – February 7, 1990) was an American computer scientist and professor at Purdue University, Carnegie Mellon University and Yale University. He is best known for his pioneering work in programming languages and was the first recipient of the Turing Award. 1

Local Optimum

"LISP has survived for 21 years [61 years as of 2020!] because it is an approximate local optimum in the space of programming languages."

— John McCarthy, 1980

LISP: A Point of High Ground

"It seems to me that there have been two really clean, consistent models of programming so far: the C model and the Lisp model. These two seem points of high ground, with swampy lowlands between them. As computers have grown more powerful, the new languages being developed have been moving steadily toward the Lisp model. A popular recipe for new programming languages in the past 20 years has been to take the C model of computing and add to it, piecemeal, parts taken from the Lisp model, like runtime typing and garbage collection."

— Paul Graham in "The Roots of Lisp", May 2001

Why Common Lisp for Scientific Programming?

I’ve programmed in many languages and Common Lisp is the best at expressing ideas. Every language gets translated into an abstract syntax tree on its way to native code, Lisp code is an abstract syntax tree. There is no programming concept that can’t be expressed compactly in Lisp, this is not true in other languages. You cannot yet express multiple dispatch functions, dynamic variables or Common Lisp style macros (a few CL features) compactly in R, Fortran, C++, or Python.

Why are R, Fortran, C++, or Python considered suitable for scientific computing?

It is the wrong question – those languages are just the languages that people started using and so they keep using them. It is not a choice most people make – it is inertia.

I choose Common Lisp.

— Christian Schafmeister, 2015-11-23, creator of CLASP

About Christian Schafmeister

I’m a chemistry professor who writes software to design molecules that I hope will make the world a better place. I’ve been programming since I was 12, I have written code in a lot of programming languages including Basic, X86 assembler, Pascal, Prolog, Fortran, Smalltalk, TCL, PHP, Python, C, C++ and Common Lisp….

I run a research group in the Chemistry Department at Temple University in Philadelphia, PA. We have developed a way to make the largest, most complex and most “programmable” molecules outside of biology. We call them “spiroligomers”, they are large, shape-programmable and functional group programmable molecules that let us construct molecules that bind proteins as therapeutics and accelerate chemical reactions the way that enzymes do. The goal is to create molecules that can do everything that proteins can do in nature but be designable and evolvable by human beings.

The Power of Runtime Compilation

While there are projects to implement CL on top of a C compiler (see ECL), that behaviour is the exception, not the rule. There are, however, very good CL compilers (see CMUCL for a free one) which will compile CL to Assembly Language, generally within a factor of 2 of a good optimizing C compiler. This is pretty amazing, considering how much more power you get in CL compared to C. To put it another way: a lot of people like languages such as tcl/perl/python, because it’s abstractions let them code much faster than they would in C. However, the "abstraction penalty", if you want to call it that, is sometimes quite high, often a couple or even three of orders of magnitude. So often people optimize by going back and writing critical bits in C or C++, which is a bit of a mess. With CL, you get more power and abstraction than these languages, and with appropriately written code you can have very little penalty. Why this hasn’t sunk it for more people I am not sure (actually, that’s a fib - I have some ideas). (Why Not Lisp?)

— https://wiki.c2.com/?RuntimeCompilation (2005)

In 1991 Lisp offered a combination of features that could not be found in any other language. This combination made Lisp almost a necessity for certain kinds of work (in AI and other applications) and made Lisp the language of choice for a large community of users. Since then Lisp has maintained and added to features, but other languages have caught up. …

One more important feature that didn’t make this list is efficiency. Lisp is about 1.5 to 4 times faster than Java, and about 10 to 50 times faster than Python. Lisp is probably within 20% to 60% of C/C++ in efficiency on most tasks, which is close enough that the differences depend more on the programmers involved than the language, and close enough that for most applications that speed is not an issue for Lisp. Python is a different story: there is a large class of problems for which Python is too slow. …

New Lisp Books

The best, in my opinion, are Paul Graham’s On Lisp and ANSI Common Lisp. Probably the best book ever on how to write Lisp compilers and interpreters is Christian Queinnec’s Lisp in Small Pieces.

— Peter Norvig, Retrospective

The Demise of Lisp

The demise of Lisp at JPL is a tragedy. The language is particularly well suited for the kind of software development that is often done here: one-of-a-kind, highly dynamic applications that must be developed on extremely tight budgets and schedules. The efficacy of the language in that kind of environment is amply documented by a long record of unmatched technical achievements.

The situation is particularly ironic because the argument that has been advanced for discarding Lisp in favor of C++ (and now for Java) is that JPL should use "industry best practice." The problem with this argument is twofold: first, we’re confusing best practice with standard practice. The two are not the same. And second, we’re assuming that best (or even standard) practice is an invariant with respect to the task, that the best way to write a word processor is also the best way to write a spacecacraft control system. It isn’t.

My job today (I am now working on software verification and validation) is to solve problems that can be traced directly back to the use of purely imperative langauges with poorly defined semantics like C and C++. (The situation is a little better with Java, but not much.) But, of course, the obvious solution – to use non-imperative languages with well defined semantics like Lisp – is not an option. I can’t even say the word Lisp without cementing my reputation as a crazy lunatic who thinks Lisp is the Answer to Everything. So I keep my mouth shut (mostly) and watch helplessly as millions of tax dollars get wasted.

— Ron Garret, f/k/a Erann Gat

The Power of Macros

Java added a similar kind of loop construct [i.e., Common Lisp’s DOLIST ] with the "enhanced" for loop in Java 1.5, as part of JSR-201. Notice what a difference macros make. A Lisp programmer who notices a common pattern in their code can write a macro to give themselves a source-level abstraction of that pattern. A Java programmer who notices the same pattern has to convince Sun that this particular abstraction is worth adding to the language. Then Sun has to publish a JSR and convene an industry-wide "expert group" to hash everything out. That process–according to Sun–takes an average of 18 months. After that, the compiler writers all have to go upgrade their compilers to support the new feature. And even once the Java programmer’s favorite compiler supports the new version of Java, they probably still can’t use the new feature until they’re allowed to break source compatibility with older versions of Java. So an annoyance that Common Lisp programmers can resolve for themselves within five minutes plagues Java programmers for years.

— Peter Seibel, author of /Practical Common Lisp/

Interactive Programming

Interactive programming boosts your productivity so much that I believe it should always be part of the decision process when it comes to choosing a language to work with. Hopefully this advance in the practice of programming will be remembered when we design the language of the future.

I believe that for this reason alone Common Lisp is worth learning (and using).

The Bipolar Lisp Programmer

Now one of the things about Lisp, and I’ve seen it before, is that Lisp is a real magnet for this kind of mind [brilliant failure]. Once you understand that, and see that it is this kind of mind that has contributed a lot to the culture of Lisp, you begin to see why Lisp is, like many of its proponents, a brilliant failure. It shares the peculiar strengths and weaknesses of the brilliant bipolar mind (BBM).

Why is this? Well, its partly to do with vision. The ’vision thing’ as George Bush Snr. once described it, is really one of the strengths of the BBM. He can see far; further than in fact his strength allows him to travel. He conceives of brilliant ambitious projects requiring great resources, and he embarks on them only to run out of steam. It’s not that he’s lazy; its just that his resources are insufficient.

And this is where Lisp comes in. Because Lisp, as a tool, is to the mind as the lever is to the arm. It amplifies your power and enables you to embark on projects beyond the scope of lesser languages like C. Writing in C is like building a mosaic out of lentils using a tweezer and glue. Lisp is like wielding an air gun with power and precision. It opens out whole kingdoms shut to other programmers.

So BBMs love Lisp. And the stunning originality of Lisp is reflective of the creativity of the BBM; so we have a long list of ideas that originated with Lispers - garbage collection, list handling, personal computing, windowing and areas in which Lisp people were amongst the earliest pioneers. So we would think, off the cuff, that Lisp should be well established, the premiere programming language because hey - its great and we were the first guys to do this stuff.

But it isn’t and the reasons why not are not in the language, but in the community itself, which contains not just the strengths but also the weaknesses of the BBM.

One of these is the inability to finish things off properly. The phrase ’throw-away design’ is absolutely made for the BBM and it comes from the Lisp community. Lisp allows you to just chuck things off so easily, and it is easy to take this for granted. I saw this 10 years ago when looking for a GUI to my Lisp (Garnet had just gone West then). No problem, there were 9 different offerings. The trouble was that none of the 9 were properly documented and none were bug free. Basically each person had implemented his own solution and it worked for him so that was fine. This is a BBM attitude; it works for me and I understand it. It is also the product of not needing or wanting anybody else’s help to do something.

— Dr. Mark Tarver, 2007

Table of Contents

Footnotes

(1)

https://amturing.acm.org/award_winners/perlis_0132439.cfm

Next:   [Contents][Index]