I used to read these kinds of articles with interest, back in my Common Lisp programming days. They would worry me. Back in the day, I would even sometimes participate in language advocacy discussions.<p>These days, I don't care at all — I just write great apps that work (fast). Some code runs on the JVM, some code runs in the browser, some runs in both places. I get to use an impressive set of libraries from at least three different ecosystems (Clojure/ClojureScript, Java, Javascript). I get to use fantastic languages with impressive concurrency support. I deliver applications which customers pay money for.<p>For me at least, Clojure made this kind of writing totally obsolete, in the span of several years.
Lisp is programmable programming language, especially Common Lisp. It works as programmer amplifier. Better you are, more you benefit from it.<p>I challenge anyone to watch this lecture from Christian Schafmeister and say they are not impressed: <a href="https://www.youtube.com/watch?v=8X69_42Mj-g" rel="nofollow">https://www.youtube.com/watch?v=8X69_42Mj-g</a> and <a href="https://www.youtube.com/watch?v=0rSMt1pAlbE" rel="nofollow">https://www.youtube.com/watch?v=0rSMt1pAlbE</a>
Replicating "pre-AI-winter" success is like trying to replicate "pre-dot-com" success, et cetera. The past is the past. Such things all depend not on technical reality but on what was the predominant belief among some non-technical decision makers. Old Lisp was funded by institutions. There were so many dialects because multiple institutions were actually developing Lisp using local talent. That required funds, and dispensation of funds requires that someone is rationalizing that dispensation based on some beliefs, and those beliefs are very distant from specific technical ideas like "multiple dispatch is a beneficial in OOP".<p>What remains is that the Lisp design contains numerous elements which are great ideas, which, if they are nicely implemented in their proper form, give you a great programming language.<p>That doesn't translate to being able to return to the time when you're showered with institutional money to just go wild hacking on whatever you like.
I don't think there's much explanatory power here at all, actually.<p>Some of the most popular languages today, from a web development perspective at least, are JavaScript, Ruby, and Clojure.<p>One of them is an actual Lisp with full-blown macros and a lot of Emacs users.<p>The others are also extremely expressive, dynamic, and amenable to metaprogramming.<p>I don't think there's a single, simple, beautiful explanation for why Common Lisp isn't more widely used. Mostly it just has an undeserved bad reputation... partly because articles like this show up all the time, reinforcing the stigma of Lisp as a weird language for bipolar geniuses, or whatever.
In 1988 I was an intern at HP Labs and my project was 50% Lisp and 50% C, the latter half dealing with time-critical IO and low-level routines crunching CAD tablet input.<p>At the end of a day working on the Lisp portion, which assembled sketched lines into a CAD model I went home happy and relaxed with a feeling of accomplishment. At the end of the C days I felt tense and slightly worried, thinking about ways of more cleverly detecting what the user was trying to sketch on the tablet.<p>In my 20+ years of programming I never returned to Lisp and I don't quite know why I don't miss it. I have a vague nostalgia for Lisp but I think modern programming languages give us enough tools to get our job done without feeling too much shame about abandoning the purity of Lisp.<p>Also, the proselytizing has not helped. I think the "Blub paradox" article embodies the mindset that was ultimately the nail in Lisp's coffin.
I read the article and thought a lot about it, but I'm not buying it. The acceptance problems for Lisp haven't been because it is "too powerful" or that lone wolf hackers won't work together.<p>The author makes an example of the many Object Oriented (OO) systems, but he performs some bait-and-switch there. Those many OO systems were for _Scheme_, not Common Lisp. And Scheme is intentionally a tiny Lisp. For a long time, Scheme was focused on being the smallest possible Lisp. Common Lisp on the other hand, while it briefly went through an OO experimentation period, really only has one OO system: CLOS.<p>Also, the whole Emacs line is off target too. What has that to do with the expressive power of the language? And why ignore the two extremely powerful commercial Common Lisp IDE's out there? So is the point that Common Lisp isn't successful because there isn't a better free IDE?<p>And the "lone wolf/80%" isn't doing it for me either. The Common Lisp specification was the work of many bright minds and is brilliant. And it stands in complete opposition to the situation the author attempts to describe.<p>I'm not saying that Lisp in general (Scheme, Common Lisp, and Clojure) has been successful, or that Common Lisp in particular has been. If the standard is mindshare and acceptance they have not been successful. There are histories and causes aplenty, but being too powerful is not one of them.
I'm the author of this essay. This must be at least the third time that it has appeared on Hacker News. I'm starting to get sick of it, myself, but I keep it up because so many people like it (at the bottom of the page, you can see the translations; all done gratis by volunteers).<p>I wrote it during a period when I was especially fascinated with Lisp and got caught up in the theorizing to which the Lisp community can be prone. Nowadays, I freelance in front-end web development and doing Lisp hacking is something that I put on the back-burner.
A personal anecdote:<p>I stumbled on LISP and Scheme around the time I graduated from high school in 1991. I became interested in LISP from learning about classic AI research. I found a professor my first year in college who mentored me in an independent study of LISP. I then learned scheme doing a self-study with SICP.<p>Despite all of this, I've never done any paid work in LISP, and I've spent the majority of my career writing C. I can't write a LISP program from scratch from memory any more.<p>However, I've found that the ideas of functional programming and the concept of the read-eval-print loop have colored my understanding of software design in a really positive way. I remember when I learned TCL in the mid 90s it was immediately obvious that TCL is just LISP on strings (read-substitute-print). Lua is also very LISP-like, with tables instead of lists.
This is not the curse of LISP; it's the curse of compile-time macros. Any language extensible at compile time has this problem. C++ has it. (See Boost). Rust seems headed there. You can even do this with C macros.<p>There was, around 1990, a fad for "extensible languages".[1] It died, because the resulting code was so hard to read, with program-specific syntax for each program. Don't go back there.<p>[1] <a href="http://www.cas.mcmaster.ca/sqrl/papers/SQRLreport47.pdf" rel="nofollow">http://www.cas.mcmaster.ca/sqrl/papers/SQRLreport47.pdf</a>
Power is a weakness in a programming language, not a strength - some of the most interesting research languages today are not even Turing-complete. It's easy to add expressiveness to a clunky language; it's much harder to add limits to an expressive language that prevent expressing nonsense.
For those that are interested, here's some livecoding streams of me developing and working in a Lisp I'm developing Sigil:<p><a href="https://www.livecoding.tv/burtonsamograd/videos/" rel="nofollow">https://www.livecoding.tv/burtonsamograd/videos/</a><p>See the 'building a language' parts for actual lisp programming, the rest is JS webdev.<p>Sigil is a minimal lisp with only the basic primitives (cons, car, cdr, cond, null, atom, lambda and a few others) and macros. The project is an experiment in building a lisp from the axioms and seeing how far one can go without having to add to the underlying lisp implementation (which is in javascript).
There are many good points in this article and even the variety of Common Lisp implementations in existence attest to the author's point. It seems that everyone is rolling out their whole new CL implementation.<p>That said, even if it were true that the power of lisp turned out to be it's curse, one should be careful to generalize this way about <i>lisp hackers</i>, <i>80% projects</i> and lack of documentation. The language might tempt you to become the hacker portrayed in this article, but it certainly doesn't fight you should you want to follow best practices.
Reading this I wonder if the everybody rewrites everything is that much of an issue. The benefits of it-crowdsourcing capitalized through libraries isn't obvious to me. Some languages make it necessary to distribute the cost of libraries through groups. Maybe Lisp allows to skip that and go straight at the problem. I remember one article about a guy looking at a Graph library for Java. He found two, generic, typed, object and all that; they were more a problem than a solution. He made its own thing in Lisp and called it a day.
I like it. It's a keeper. Also the argument is a bit overstated.<p><i>"...The moral of this story is that secondary and tertiary effects matter....Employers much prefer that workers be fungible, rather than maximally productive...[in regards to creating a larger framework] The reason why this doesn't happen is because of the Lisp Curse. Large numbers of Lisp hackers would have to cooperate with each other..."</i><p>So here's what I see. I see a lot of frameworks and libraries composed by folks using other languages. Many of these, yes, are much more complete than one, totally-custom-made solution by some Lisp hacker. And yes, large numbers of people participate in creating and maintaining these larger frameworks and systems.<p>I also see large corporations <i>bleeding</i> cash because they wanted silo'ed, fungible programmers. Got seven architectural tiers, each with its own framework? Hell, you're going to need seven extremely specialized programmers, kid. Time to get on the phone with the recruiter.<p>So they purchase these specialists. All the buzzwords match. The specialists sit down at the magic frameworks, the ones all the cool kids over the last two years have decided to support. Life is good. For about ten minutes. Then something is required that's not in the frameworks. Or the framework is broken under this one particular edge case.<p>Suddenly we need somebody who's general purpose again. Except -- and this is especially nice -- that's not the guy we hired. So seven layers of experts sit struggling with seven oddball issues. Googling Stack Overflow. Hacking the crap out of things. Making a total mess.<p>And at the end of the day, if we're lucky, something ships. Something with little problems here and there that requires seven different areas of expertise to figure out. Plan on maintenance being fun.<p>The next day version 2.0 of the framework on layer 5 ships. Now if you want maintenance programmers, for layer 5 they have to know both version 1.0 and 2.0<p>More complexity continues. It's fun for everybody.<p>Compare this to the guy who uses a standard language, decades-old libraries, hacks out a partial solution (but good enough to ship) in a few days and then moves on to something else. Now tell me that the framework guys have a better technology development model. I ain't believing it.<p>I'm not saying become a lone wolf and never work with folks. I'm saying that "working with folks" can completely kill any kind of value you're trying to create. Do it wisely.
I wonder why there is all the anguish around why Lisp hasn't flourished, and seemingly less anguish around APL, or even Smalltalk. Is there a reason it engenders so much loyalty? Is it the idea that macros allow you to extend the language, and that seems like the pinnacle of the programming hierarchy? Could there be insight gleaned from looking at programming languages as a fad or style?
I think that Clojure mitigates these issues quite a bit for a couple reasons:<p>- The core library is has enough built in that many questions are answered using built in solutions (e.g. what is done with objects elsewhere is very frequently done with maps and functions that operate on maps)
- The language designer (Rich Hickey) is very opinionated, and the language tends to attract people who agree.<p>There still are multiple choices when it comes to solving some problems (Om vs Reagent vs Rum vs etc.), but is that really that much different than other languages? Javascript has a million choices for the same domain.
"BBM" == Brilliant Bipolar Mind. The acronym is used in "The Lisp Curse" citation of The Bipolar Lisp Programmer, but defined elsewhere in material not cited.
People who care what other people think about the programming languages they use write essays like this.<p>The rest of us just shut up and hack some Lisp.
The homoiconic thing is not all it is made up to be. That is, you can take (say) Java and parse it to an abstract syntax tree and the manipulate the tree.<p>Assuming you have a good toolbox of operators, working with that kind of AST is not much harder than working with s expressions. Maybe it is easier if you can build a general notation that can be generalized for multiple languages and also represent more ordinary data such as json formatted, relational, rdf, etc.
I think this is not properly accounting for the difference between something that's 90% done, and something that is done. (Nothing is ever finished, of course, but you know what I mean.) As we all know, the difference between the two is not simply a gap of 10 percentage points. Far from it.<p>Teams of people were required to write Haskell and Dr Whatshisname tossed off Qi by himself. OK, but people use Haskell, does anyone use Qi? If not, then it's not a problem for Qi to be 90% done. And that's a lot easier to accomplish by oneself.
A lot of thoughts about lisp; are written by zealots; who like to create the impression that they are playing with some kind of dangerous mind amplifying meta language; and if you start using it; you might accidentally unleash creatures from the id. But then you look at it; and find it is simply a programming language.
<i>"It's so damn hard to do anything with tweezers and glue that anything significant you do will be a real achievement. You want to document it. Also you're liable to need help in any C project of significant size; so you're liable to be social and work with others. You need to, just to get somewhere."</i><p>Oh is it time already for another "C is for idiots" thread from Lisp supremacists again? If Lisp fanboiz were slightly less busy ridiculing the rest of the world over how stupid everyone else is, they might even have had some time to pay attention to silly things like performance and tooling. That might help the adoption a bit more than the supercilious rock throwing that is almost exclusively the tone of every single article/post from Lisp lovers.