Personal site of a web designer and essayist known for writing on Lisp, mainframe computing cycles, and technology culture.
HN links it mainly for "The Lisp Curse", which commenters cite to explain why Lisp's flexibility fragments communities, and for "The Eternal Mainframe".
I'll cons this onto my list of reasons why Lisp "failed". Other explanations are:
Worse is Better: https://www.jwz.org/doc/worse-is-better.html
The Bipolar Lisp Programmer: https://groups.google.com/forum/#!topic/comp.lang.lisp/eicqvm3GXiE
The Lisp Curse: http://winestockwebdesign.com/Essays/Lisp_Curse.html
Where Lisp Fails: http://www.loper-os.org/?p=69
Lisp is still my language of choice. I'm more productive in it than other languages (C, Java), not because I know the other languages less well, but because they're less expressive. So, for me, Lisp fixes the world.
Why aren't people using it? There are three things often missed.
(1) People's choice of programming languages perhaps isn't as rational as they might like to believe. There's a large amount of personal taste involved. For a personal project, that's no barrier, you can use your favourite language, but if you're working with a dozen other people, Lisp is unlikely to be adopted because more people on the team will prefer Java, C++, or Python. Multiply over all the commercial projects and you can see why you can't build a career around Lisp programming.
(2) There are accidents of history. When DEC decided to discontinue the PDP-10, the days of the hacker community built around it were numbered. Those involved then went on to build Lisp machines, but they were undercut by cheaper, commodity hardware which ran Unix. Then, the AI winter arrived. It was bad for Lisp, but Prolog fared far…
Building a community around lisp is tricky. While there are many criticisms to this article [1], there are some elements of the "Lisp Curse" which is true - each programmer tends to rewrite his/her own libraries and so a collaborative framework seldom emerges even while many programmers may work in the same domain. This can be a disadvantage in a domain like the natural sciences where deep collaborations are necessary.
Furthermore, the disconnect with traditional mathematical syntax has also turned off many users. There was a predecessor to R called Lisp-Stat [2] which never achieved the acceptance that S/R did, and the Lisp-based syntax of Lisp-Stat was cited as one of the reasons.
Following the example of a high-profile Lisp supporter like Peter Norvig who accepted Python as a "Lispy" alternative early on, I think there are a lot of us who have come to accept Python as a necessary compromise. While Python is not homoiconic, functional programming is encouraged through its libraries rather than its core language definition, and the power of macros are missing, the inherent popularity and all the benefits that come with it is tough to beat.
[1] http://winestockwebdesign.com/Essays/Lisp_Curse.html
[2] http://homepage.divms.uiowa.edu/~luke/xls/xlsinfo/xlsinfo.html
Looking for a feel for Shen?
A Strange Loop talk by @deech (40minutes): Shen: A Sufficiently Advanced Lisp. https://www.youtube.com/watch?v=lMcRBdSdO_U
An essay: http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
It's insightful and readable and it links to several articles new Shen users would be interested in[0]. It was written before Shen, so it talks about Shen's predecessor, Qi. This article and the Bipolar Lisp Programmer by Mark Tarver (creator of Shen) made me feel not so weird for not "getting" UNIX, and helped me get excited about lisp.
I'm looking to use Shen or another highly cross-platform functional language for my next project. Application logic in Shen with type-checking. web code using some framework.
[0] Wow I'm re-skimming it now: it has Stanislav, James Gosling, buncha Smalltalk, Rob Pike's "Systems Research is Dead" and a lot more. This is actually a good overview of ways to be disillusioned with programming. IMO disillusionment by knowing our historical failures is an antidote to the hype-machine.
Lisp's macro system is so powerful that it actually turned out to be the 'curse' of Lisp:
http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
However I wouldn't call it "curse" but merely the truth that Lisp programmers need a lot of self discipline to write maintainable code.
Lisp was one of the first languages I learned at university (also Pascal and Ada). Afterwards I learned almost every other new programming language. Lisp and the Scheme dialects are still the most powerful languages of all, to this day.
People who are intimidated by such a raw power should take a look at Nim (nim-lang.org). It takes the best of several modern languages and it also has an amazingly convenient and powerful macro system. For instance:
template repeat * (body: stmt): stmt {.immediate.} =
block:
while (true):
body
template until * (cond: expr): stmt {.immediate.} =
block:
if cond:
break
var i=0
repeat:
echo i
i += 1
until i==7
> The only consistent explanation I've seen that it is about 'easy'. The other languages have tools to make them easy, easy IDE's, the languages 'solve' one 'thing' and using them for that 'one thing' is easier to than building your own in LISP.
I have thought something similar, perhaps with a bit more emphasis on network effects and initial luck of popularity, but the same idea. Then about a week ago, I was one of the lucky 10,000[0] that learned about The Lisp Curse[1]. It's as old as the hills, but I hadn't come across anything like it before. I think it better explains the reason "the best languages don't get adopted" than the above.
The TL;DR is with unconstrained coding power comes dispersion. This dilutes solutions across equally optimal candidates instead of consolidation on a single (arbitrary) optimal solution.
[0] https://xkcd.com/1053/
[1] http://winestockwebdesign.com/Essays/Lisp_Curse.html
Haskell would conquer the world if it had a C-like DSL with C-like semantics. Think do notation with a state monad, on steroids. Thing is, there's already a dozen homespun libraries of various kinds doing just that. As an extreme example (mostly just to prove the point): http://kormacode.blogspot.com/2011/11/c-style-haskell_10.html
Which leads me to perhaps the real thing functional languages need. A standard way of doing things. Standard patterns for standard problems, familiar and normal, which the average programmer can recognize. This is related to the Lisp curse:
> Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp.
http://www.winestockwebdesign.com/Essays/Lisp_Curse.html Most functional languages suffer from this to some degree.