Lisp and the anti-Lisp

Doug Hoyte’s book Let Over Lambda is refreshingly opinionated. I don’t share the author’s opinions, but I appreciate his conviction. Hoyte is a zealous advocate for Lisp, and yet he admires Perl as a sort of anti-Lisp. He even calls Perl “beautiful” as far as non-Lisp languages go.

Hoyte argues that Lisp is the greatest programming language because its minimal (i.e. practically non-existent) syntax makes Lisp macro programming powerful. But if you’re going to have language syntax that prevents this style of programming, you might as well go for broke and have lots and lots of syntax.

If we have to have [non-Lisp] syntax — eliminating the possibility of macros — we may as well extend it as far as possible. Let’s throw in all the possible conveniences and power-user tricks we can think of. If Lisp is the result of taking syntax away, Perl is the result of taking syntax all the way.

I understand that Lisp’s lack of syntax opens interesting possibilities. I also understand the advantages of a rich syntax — provided you (and everyone you work with) have mastered the language and use it frequently enough to keep it loaded in your head. However, I prefer a moderate amount of syntax, somewhere between Lisp and Perl, though I admit this may simply be because that’s what I am accustomed to.

Related post:

Periodic table of Perl operators

10 thoughts on “Lisp and the anti-Lisp

  1. Common Lisp has a lot more syntax than most people realize. It uses mostly parentheses, which misleads people. But there are many syntactic forms with their own complexity to learn and master. (See the loop macro.) Scheme has less but still has some.

  2. IMHO readability is more important than amount of syntax. Lisp may have elegant simplicity from stand-point of interpreter, but Lisp programs can be hard to read, and that makes it harder to debug. Well-crafted pseudo-code is unambiguous, yet readable and very compact. And it looks nothing like typical Lisp or Perl programs. Why don’t we have interpreters that accept pseudo-code?

  3. I like Python, but I miss the ability to use mathematical notation in my programs. Mathematica lets you do that, but it’s encumbered by some 20 year old design decisions. The time is ripe for Mathpythica

  4. Lisp is nice for describing a computation starting from first principles, but how many papers from [math|cs|physics] on the arxiv start with, “We define addition as …”

    Do you want your solution to be plastic or elastic? How much support structure do you need to express your particular solution. One might say that Lisp is woefully inadequate to solve any problem because you will spend so much time reinventing that you have to defer the hard stuff at the edge of the problem space. Language choice, to me, is a design decision like any other, and the [quality|value] of a language is not a perspective-free measure.

  5. Perl is often categorized as a language where syntax has run away with the language, or there’s no structure to the design. In most ways, this is actually quite wrong. Perl is actually a highly architected language, but with different goals than most. Supporting the TIMTOWTDI motto doesn’t mean throw in any and every time saving syntax feature, it means looking a the common ways methods people use to express themselves in easily intuitive ways, and determining the equivalent way to express that in syntax. Many of Perl’s main architects were and are linguists, and this heritage shows in the language.

    It is an interesting comparison though. Lisp seems to reduce the included syntax to a level that allows great customization, and Perl provides a large syntax to allow many programming styles, while still allowing quite a bit of language customization at a very low level. I imagine (my lack of experience with Lisp is obvious here) that there are many libraries in Lisp to provide differing levels of helper utilities, in essence extending the syntax of the language when included.

    P.S. I don’t mean to imply the author has any of these opinions about Perl, just that there was very little analysis given to Hoyte’s possible underlying meaning for his opinion. Common perception of Perl being what it is currently, readers may interpret the quote differently than I did, and I thought a little exposition on a possibly different interpretation might be useful.

Comments are closed.