Pearls Before Swine

Tim Daly of Axiom artfully debunks Steve Yegge’s infamous “Lisp is Not an Acceptable Lisp”:

“I am currently working in Java to re-implement an algorithm I prototyped in lisp. If I replace all of the required curly-braces and semicolons in Java with parens it turns out that the Java program has more parens than the lisp program. The lisp program is 20 lines, the Java program has crossed 100 lines and is still growing.”

Not that I expect any such arguments to persuade  the popularity-worshiping “modern” programmers, of course.  However, one useful attribute of the Lisp systems with which I solve problems and earn my living is that they continue to work whether or not Yegge and friends are persuaded.

This entry was written by Stanislav , posted on Friday August 06 2010 , filed under Lisp, NonLoper . Bookmark the permalink . Post a comment below or leave a trackback: Trackback URL.

9 Responses to “Pearls Before Swine”

  • justbeast says:

    Ok, what?
    Though I am both a fan of Lisp and of non-mainstream language environments (I do much of my work in Smalltalk), I fail to see how Daly’s “debunking” is artful in any way.

    First of all, he fails to address any of Yegge’s actual problems with Lisp.
    Such as balkanization of the various Lisp flavors and dialects (which is also a problem in the Smalltalk world, but to a smaller extent), the weaknesses of the language specification, the clunkiness of the CLOS add-on system, and so on.

    Also, the claim that Lisp doesn’t have many libraries because it doesn’t /need/ them is utter bullshit. “Why have a graph library when you can just embed the graph naturally in the data?” Seriously? “naturally embed the data”? What does that even mean? And does the naturally embedded data display itself properly on the screen, in many of the ways that a good graph library provides?

    I hate responses like Daly’s, which do not actually address real problems in the language environment or offer suggestions on how to fix them, but dismiss any criticism as ignorant.

    • Stanislav says:

      Dear Justbeast,

      I admit that I may have been overly eager in calling Daly’s article a debunking.
      It is not a debunking. But it is worth reading. Let me explain why.

      Not long ago, I was, much like Yegge, an enthusiastic collector and disseminator of gripes about the supposedly crippling flaws of Common Lisp. Endlessly chewing on said flaws has become a kind of beloved national sport in certain quarters (comp.lang.lisp, for example.) I reveled in this sport privately (and otherwise) until I heard a few quiet voices of reason – the late Erik Naggum among them – who claimed, quite convincingly, to have used this allegedly worthless language to solve otherwise intractable problems, afterwards finding that most of the complaints ring hollow.

      This was the reason why I wanted to share Daly’s piece with my readers. Once you consider the possibility that what he says regarding his accomplishments with Common Lisp may be true, you are also forced to also consider whether the language’s detractors may be mistaken, or, at times, even deliberately misleading. This is how I was “cured” by Naggum, who threw similar suggestions at those who would listen. I still work on my own Lisp dialect and underlying system, but in the meantime I have been productive in Common Lisp in my line of work and have resumed enjoying programming in the way that not long ago was a tattered remnant of a childhood memory.

      Common Lisp is not flawless. It is an engineering compromise, much like others. Yet almost all of the criticisms that are bandied about as proofs of its worthlessness are founded on generous helpings of misunderstanding, herdthink, outdated information, and the occasional bout of willful ignorance.

      For instance, the “balkanization” so often mentioned is simply a consequence of the “paradox of choice” – there is no dictatorship and monoculture a la Python, Perl, etc. This turns into a non-problem once you settle on a particular implementation of the standard. Yes, said standard does not mention, say, TCP/IP. But does the ANSI C standard mention it? The latter is silent even on matters such as whether dividing two signed integers yields the floor or the ceiling of the result. What is the “weakness” of the ANSI Common Lisp specification compared to this marvel of vagueness? C programmers are happy using an underspecified language with its laughable charade of portability, yet offer them one with an actually descriptive standard, and they condemn it for not encompassing the whole universe.

      I can run code written two decades ago without changing a single line. Genuine standards and the resulting stability are nice. Especially when compared with the never-ending hellish treadmill of marketing-driven faux progress one sees elsewhere.

      Just what is so “clunky” about CLOS? Paul Graham once infected many of his readers, myself included, with the idea that CLOS is unwieldy – despite his admission that he had never used it in earnest. Making serious use of CLOS in a project for the first time rapidly cured me of this notion.

      Behind the “library question” you will mostly find decade-old gripes being passed off as fresh fact. Essential functionality like HTTP, threads, graphics, etc. are now available in freely licensed, well-written libraries which run under several implementations of Common Lisp. has pointers if you’re interested. However, it would be a mistake to expect to find a plug-and-go Common Lisp interface to every ephemeral piece of garbage the modern software industry shits out. This will never be the case, and anyone who demands it (as I once did) will walk away disappointed and angry.

      CL is not a “mass” language, and will never become one. Naggum explains some of the reasons for this (see: but I believe that there are others. Namely, a programming language so powerful that it reduces the need for manual drudgery and pyramidal teamwork to nearly-zero threatens to revive the dominance of the craftsman over the organizer/industrialist (see: and will thus be Ur-feared by the managerial type, who will never even consider introducing subordinates to the language, lest he find himself factored out of the economic equation entirely. The delusion that planning the creation of a program is an act which can be entirely distinct from actually writing the program (and can thus be performed by people with no technical education or inclination) is the rot at the core of the US software industry. But I digress.

      I once thought of Common Lisp’s unpopularity and lack of a strong public presence as problems. I no longer do. As Naggum pointed out, one does not see an ocean of “Lisp jobs” because Lisp is not a “job creation language” – as a labor-saving tool of tremendous power, it is in fact a *job elimination language*.

      You will find that Common Lisp is used mainly by people with substantial freedom of choice in problem domain. The down-side of this is that you are unlikely to find the same abundance of “pre-fab” workarounds to help you navigate the foetid sewer of broken-by-design crap (such as “Web 2.0″) as seen in the trendy languages. As a Smalltalk user you are probably keenly aware of this already.

      Forgive me if this reply is somewhat long-winded and meandering. I saw you repeating some of the same misconceptions that I was once very fond of repeating, and wished to correct them. My original intent was simply to explain that I have gained much from listening to satisfied users of Common Lisp, like Naggum and Daly. I took the unloved and decidedly un-trendy language for a spin, and found that much of what the naysayers (including my past self) were saying turned out to be wrong. I could not state this position without attacking some of the more common criticisms head-on.


  • Seumas MacLeod says:

    On the other hand, Pascal Constanza’s reply to the original blog post is really admirable.

  • The exact number of parentheses does not matter. LISP scares 99% of potential functional programmers off because of the nested parentheses. The syntax is just plain scary.

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">