I think Lisp failed because it had no killer app. Most developers don't pick a language, they pick a project and the select the most appropriate language.
Web frontend -> Javascript
Unix / Linux -> C
Wordpress plugins -> PHP
Windows apps -> .Net
iOS -> Objective C / Swift
Android -> Java
In my entire career (25 years), I've never had a project that directed me towards learning Lisp. This pretty much leaves Lisp to the type of developer that seeks out new languages and is willing to spend the extra effort integrating, and that's a pretty small number of developers.
If Lisp was in the browser instead of Javascript, it would be popular no matter the complaints about the language.
Was Pascal a failure? Lots of programs were written in it. It had killer apps. Lots of programmers learned it. It made its way into the education system.
Lisp might be viewed similarly. It’s not a fad and big companies don’t use it widely, but does that make it a failure?
Google uses Common Lisp. (They even host a style guide!) So does Rigetti Computing making quantum computers. So does/did DWave, another quantum company. There are a handful of companies that have existed between 15–30 years developing Lisp compilers (LispWorks, Franz Inc, etc). Lisp also seems to be making HN front page at least once a week.
I guess, although in the case of Java I'm not too sure. It seems like what you're really pointing out isn't so much a killer app but a captive market. If programmers are forced to use a language, they'll use it, is basically what you're pointing out. But think about C++, or Python or Java(!) or any number of other languages that didn't actually have a captive audience or a killer app and still became popular--- interestingly, in one of the other comments they say that the "killer app" for Java is safety and GC. That doesn't sound like a killer app, that's a language feature.
What I'm getting at here is that it's pretty clear that language features are an integral part of what makes a language successful. In fact, apart from some extreme, extreme outliers like JS which just happen to be the most visible, features are the only deciding factors outside of luck (and marketing). So if you ask why a language isn't successful, saying that it doesn't have a captive audience isn't a very descriptive or helpful metric. Yes, without a captive audience or maybe won't be as successful as JS but that's not the real deciding factor at all.
Aside from a captive audience based killer app, projects don't lead to language choice necessarily. Why did the person who created Numpy choose Python? Python didn't have a killer app for that. They chose it because of language features.
So we're back to the OG question: in the arena where languages normally compete (besides outliers), LISP looks amazing, so why isn't it as successful as we'd expect? I'd honestly suggest it's just bad luck, no marketing, and a fragmented community.
Now, we could talk about why the LISP community is fragmented, and in this case I think it's due to too much of an emphasis on extending the language. DSL-building based programming paradigms are actually really effective, they're essentially what FP and OOP are all about. In OOP you build a custom type system and language to represent the problem. For FP you do the same, just with less internal state. LISP's only difference is it has more powerful abstractions for formalizing the process. The problem is they confused DSL building with language building and so multiple different general purpose dialects proliferated.
Yeah, we geeks like to think the concepts and technical design of a language in itself is what makes or breaks it. But JavaScript could have been similar to BASIC or it could have been similar to Scheme - people would have grumbled but used it regardless. Objective-C was considered a pretty obscure niche language until the iPhone made it mainstream.
The article cites fragmentation as the reason Lisp didn't become mainstream. But consider SQL - a severely fragmented language. Each implementation have major incompatibilities with every other. But it is still ubiquitous and rules its niche.
> I think Lisp failed because it had no killer app.
As a vim user I love to think of all of the emacs peoples' heads exploding when they read lisp has no killer app. However it should be noted that lisp still has strong use cases in education and language design and even if not commonly used in industry its principles and design ideas come through in many modern languages.
Android -> Java? Java dominated well before mobile.
Also JVM languages are surging even though none have a specific killer app.
But Clojure is still niche. And is the most powerful/simple of them all. I think there’s something else going on, too much power & simplicity in a language doesn’t yield to mass appeal - why?
Yeah, that's a great way to look at it. Just to add to your point, why in hell would someone use Emacslisp? Well, it has a killer app (Emacs / org-mode / etc.) and people learned and used it.
I wonder if ClojureScript -> [Node, Web-js] is how lisp will be saved? Or maybe lisp doesn't need to be saved and it'll always be this non-mainstream language. (To be clear: I say non-mainstream but I don't mean it negatively.)
I think you’re on to something, but maybe missing a historical detail: Lisp had a killer app: AI.
Unfortunately, the massive investment of time, money, attention, etc that went into Lisp and AI came too early, faltered, and left both high and dry for a few decades. It’s called “AI Winter”.
Thank You, Which is basically my economic theory of PL that I have been trying to explain across to many people.
An ecosystem forces you to program in a language, as long as the ecosystem grows in market value, it will require more developers, more people learning it and more jobs for it. A positive growing circle, and once it reaches a certain threshold it should become self sustainable, there will be interest from many parties to try and improve on it.
On the other hand, if a languages ecosystem does not reach that threshold, there will be doubt if new project should be built on it, there will be less opening for developers, less in demand means people are not learning it, market wants experience dev but experience dev would have moved on to other ecosystem. Lack of hireable Devs meant PM should choose something else that makes hiring easier. And the ecosystem shrink, what we call a languages is dying. It really isn't dying, it should be accurately described as shrinking. The Negative circle.
And in most cases languages lives on in other form. People call Ruby as Matz's Lisp.
I'd argue that none of those languages are the most appropriate for any problem at all. As long as the language itself is somewhat usable it's mostly the ecosystem (and hype) that counts: Libraries, editor support, build tools, etc.
Either that or people know a language and they get given a new project which is generally not written in that language and they find some compiler/bridge/some other tool that allows them to write what they need to write in the language they are accustomed to writing in.
For what it's worth, the "Android -> Java" part is now obsolete. Especially as you do mention Swift in the context of iOS development. Kotlin is now the default language for Android, officially recommended ahead of Java.
- In the past, it was better at abstraction, but slow and niche and you needed to shell out for hardware.
- In the present it is not better. Common Lisp is about on a par with Python in what it has built in, inferior in its ecosystem, and for some modern stuff (threads, sockets) you will have to go outside the language standard into the wild west of implementation extensions or third party libraries.
Lisp's one big selling point is macros. Macros are magic that lets you reprogram the language. Reprogrammed languages break the ability of a programmer to drop in and read the code. Languages that need reprogramming to get basic shit done are unfinished or academic (Scheme). Languages that can get stuff done, but tempt you to reprogram them are attractive nuisances (Common Lisp, Ruby). In use, they create incompatible tangles that don't mix well with other people's incompatible tangles. I have been bitten by this repeatedly in Ruby. But Ruby is still easier to get work done in than Common Lisp.
Basically it died of being meh with a side of footgun.
Maybe not quite as big of a selling point, but lisp has also always been the best environment for writing programs that need to modify themselves at runtime. Homoiconicity removes the limitation that code must be known and constructed at compile-time.
It is inaccurate to call things like threading a Wild West of implementation-defined stuff. It is true these things aren’t de jure standard, but most important stuff has de facto standard portability libraries in Common Lisp. For threading, use BORDEAUX-THREADS. For filesystem operations, use UIOP. For module definitions, use ASDF.
Most of my day to day work is in python, but I have a number of projects in Racket and have been dabbling with common lisp. I think the author is simply incorrect here. Other algol like languages offer the illusion of understanding, but then you get things like 'patterns' where even though in principle you know what the atomic elements of the language mean you are confronted with an undocumented 'pattern' that you have to puzzle out to understand what the code is actually trying to do. Lisp provides structure for these patterns in the form of DSLs, and if that means someone has to confront that they don't know something, at least it whacks them in the face rather than giving them the illusion of understanding. More importantly lisps provide a way to formalize, specify, check, and document the pattern.
So if lisp failed for some internal reason then I don't think it was for the reason the author specifies. What should worry people more is that a language that is better in 99% of cases can fail for reasons that have nothing to do with its technical merits, but purely by accident of history or as a result of politics unrelated to those technical merits.
Trilobites were the most diverse clade in the history of the earth. Trying to rationalize why they went extinct by studying their anatomy is going to be fruitless. Same with LISP.
This is a really loose definition of “failed”. His definition of failed seems to be “didn’t take over the world”... but most things don’t. It’d be like saying “John Smith failed at life because he wasn’t a billionaire by age 25”. As a language it was (and is) used in a lot of places, had a lot of offspring, and brought a lot of influential ideas into the world. That doesn’t seem like a failure!
Considering the number of people who have bemoaned over the years how Lisp never became mainstream, I think it's fair to say that it failed compared to what its enthusiasts wanted.
Did it? People seem to use Clojure a lot, other dialects are popular with hobbyists, and some of the most enduring computer science books of all time use it. How many other languages from the 50s can claim that kind of wide use?
Aside from that, as the author points out, ideas from Lisp have made their way into almost every widely-used language today. It's fingerprints are everywhere. That doesn't sound like a failure to me.
I often daydream about an alternate universe where the entire Lisp community unified behind Clojure, built other runtimes for it, etc. I wish we could do that, because it would become a force to be reckoned with. Clojure is perfectly designed and positioned for success in the industry, the real problem for lisp is that the community is so fragmented.
Every now and then people write these silly articles about lisp failing, yet it persists as an elegant solution that doesn't need constant new releases and picking up the latest fad.
I have been using Clojure(+Script) full-time for 6 or so years. I hope I never have to use a less elegant or more verbose language. The trick/tradeoff is to work at early stage startups that leave you with enough control to choose your tech stack. If I did have to go back to, say... JS (which thankfully has improved in the past several years), I will at least bring with me a fresh clarity; Clojure certainly made me a better programmer.
> So what is the problem with creating domain-specific languages as a problem solving technique? The results are very efficient. [...] It results in many sub-languages all slightly different. This is the true reason why Lisp code is unreadable to others.
> The reason Lisp failed was because it fragmented, and it fragmented because that was the nature of the language and its domain-specific solution style.
The main points above can be solved with two things:
1. A more opinionated base language with batteries (e.g. Clojure)
2. A package manager shared by users of the language
Ruby is expressive and has the DSL failure modes as lisp (though usually not as low-level), but it starts with a more batteries-included base. If it wasn't for Rails and gems leading the way to normalized usage Ruby would not be as successful as it is today.
This is precisely correct IMHO. Lisp was designed for single programmers managing their entire stack (including the compiler itself) rather than for teams mostly gluing libraries together. Modern software engineering practices are focused on lower-level languages that don't give programmers the power of Lisp.
[Herein I mostly mean Common Lisp when I talk about Lisp. I have no experience with large projects in Clojure or Scheme.]
Most modern software -- Lisp programs included -- is written by multiple programmers in both coordinated and uncoordinated teams. Lisp can easily adapt to team programming but SWE needs to be augmented to handle programming projects that operate at a meta-level, which is natural with Lisp. If you write code at a meta level with ordinary SWE it can lead to disaster.
SWE needs tooling, procedures, and policies to deal with macros, package naming, bootstrapping, multiple-inheritance classes and first-class methods, etc. before it can really support Lisp. Lisp projects that have added such SWE features manually tend to succeed; those that don't tend to have difficulty with Lisp. My point is the team has to do the SWE work; SWE tools operating in default mode tend not to be good enough for Lisp.
LISP doesn't really have a hugely complex conceptual level. It gives you a list, which can be combined to form complex structures, and also a list can be code.
MLs took ideas in LISP much further and imposed powerful type systems on them, so they appeal to a smaller audience than LISP does.
And the multi-paradigm languages simplified ideas from LISP to be usable for a broader audience, and brought in new ideas from elsewhere.
So I don't think SE has failed to reach LISP, if anything, it's surpassed it.
It's difficult to agree with the idea that VB displaced COBOL. Even if this were the case, it certainly wasn't because COBOL compilers were expensive compared to "a cheap interpreter" that came with the machine. COBOL compilers surely were expensive, but they were also intended for mainframes rather than PCs. Also, I don't remember VB ever coming packaged with Windows for free. VB has been a part of Visual Studio for as long as I can remember and I don't believe there was a free version of until around VS2005.
Lisp, it turns out, is a weird and challenging language. It takes a little extra before you start to see the exciting bits. Unfortunately, until you reach that point, it's a matter of struggling with the parts around it - namely the editor. Lisp and Emacs go hand in hand, and while today you can rely on other editors to competently work with Lisp code, 20 years ago I don't think this was the case.
So now a user has to pick up Lisp (challenging when viewed through the lenses of either VB and COBOL) and Emacs (positively baroque if your only experience is within a GUI and IDE). I'd venture to guess that getting a functional Lisp environment running on a 286/386 era PC was probably a challenge in itself for most people.
Now consider VB or Java, significantly more familiar languages that didn't effectively depend (at the time) on the features of their editor or IDE. Both were a mouse-click away as far as installation, and Java didn't cost anything. Both were backed by large organizations that had a lot of incentive to invest and convince people to use their particular thing.
Lisp was this weird, mostly academic, language intended to tackle relatively esoteric rather than business problems, that was Unix only at a time when PCs and Windows were taking off. It doesn't seem unusual to me that it didn't take over the world. Frankly, I'm surprised and thankful that it's still around, actively used, and even sporting a significant community.
> while today you can rely on other editors to competently work with Lisp code, 20 years ago I don't think this was the case.
I've been doing Lisp for just about that many years and have used nothing but Vim. Its Lisp support is built off :set lisp mode which is in the original Unix vi. It does a good job of syntax coloring, indentation and all that.
To reindent a block of code in Vim, I just put the cursor on one of the parentheses, then hit =% . The odd time there is a stylistic disagreement (like Vim wanting to align the arguments of something as if it were a function, rather than let-like).
My Lisp implementation, TXR Lisp, comes with a comprehensive Vim syntax file.
When you browse the sources using CGIT, all the syntax coloring you see is performed by Vim, being used on-the-fly as a back end for HTML generation.
> The reason Lisp failed was that it was too successful at what it was designed for. Lisp, alone amongst the early languages was flexible enough that the language itself could be remade into whatever the user required. [...] However, the process causes Balkanization. It results in many sub-languages all slightly different. This is the true reason why Lisp code is unreadable to others. In most other languages it is relatively simple to work out what a given line of code does. Lisp, with its extreme expressibility, causes problems as a given symbol could be a variable, function or operator, and a large amount of code may need to be read to find out which.
And I perfectly agree. You can see it in tutorials too. You can even see it in any Lisp-lover comments showing you a proud snippet of how "it can be solved better with lisp": it's too clever.
A little bit of clever is fun, it's good for the soul, it can even be productive. But Lisp is just a big pile of cleverness.
Being clever is so appealing to my geek nature. It's so cool. Yet experience (in coding and life) taught me it is not a good property to build a community around. Or a project for that matter.
At best, it's something that can emerge from a battle against long and arduous stream of problems. And then you can rest, you try to factor away the cleverness. But not as a goal. Not as a basic proposition.
I use Common Lisp for most of my development now that I am (mostly) retired, so I admit some bias. Given that:
Common Lisp tooling is very good and there is an active community of users. I argue that Haskell is really a Lisp language, at least it seems so to me. Also, so many good Lisp-y things are in Ruby, Python, modern JavaScript, etc.
I think language selection for a project is a process of making trade offs. I am happy that it is a free world to develop using whatever languages and tools we want. I try very hard to never judge anyone on their politics and I try to do the same in programming language wars.
Are there examples of languages that were not popular for a long while before suddenly going mainstream (the definition of success from the article)? I feel like even a potential killer app is not enough, there were some interesting web frameworks for smalltalk (like seaside) but it wasn't enough to shake in any way the feeling that the language was a dead end for most people (and they can just wait for a reimplementation in a popular or new hyped language if it's really a good idea).
Phoenix/Ecto for example would probably not get the attention it gets (and deserves) if it focused on Erlang instead of a new language with some momentum. And Lisp seems to get it even worse when all of them (old and new, with as many programming paradigms as there can be) get grouped together as one 60 year old language family. Hopefully clojure, racket and other newcomers can turn this around.
1. The more I dig into Lisps, the more I find Lisp is not a language. 'Lisp' is more like the term 'C-like'.
Common Lisp, Scheme, and Emacs Lisp are way too different from each other. It's more like a comparison with C++, JavaScript, and Bash. Common Lisp is hardly a functional programming language. Emacs has no lexical scope (This really made me freak out). Clojure is a more qualified functional programming language.
2. Lisps, for example, Scheme was superior to other languages decades ago. But now, as you can see JavaScript is basically a Lisp without macro (Yeah I know HN guys don't like JavaScript, but I choose JavaScript because it's a footgun language like Common Lisp and Emacs Lisp). Or just Elixir, basically a Lisp without paren syntax.
3. Lisp never dies, there will be more. It will march forward as the industry moves. The Lisp syntax means the ease of parsing and macro design, and people will combine this feature with other features. There are already:
a) Functional Lisps like Clojure
b) Carp, a Lisp without GC, there were also Linear Lisp
c) WASM, an assembly with S-expression
d) I have already seen other prototypes with static types/dependent types/monadic macro systems etc.
Right now I'm using Lisp for a hobby project. I find it actually really enjoyable. Lisp's metaprogramming support is super powerful. I'm the kind of developer who likes to explore different styles of programming. If you're like me, Lisp will not fail you. It really is a "programmable programming language".
For example, Lisp is not purely functional, but if you want to force yourself to program in a bit more of a functional style, you can make a macro that disallows the use of 'setf' (Lisp's assignment operator) in a function body, and it's actually quite easy to do that!
Maybe Lisp 'failed' because it's too flexible. You can solve your problem in a million different ways. Arguably, that is not a good thing in industry where it is preferred to have a language that enforces a single style on your code base for consistency across developers. However, I'd argue that it is very good thing for a creative individual. You want to have the freedom to do things your way.
From what I've experienced so far, Common Lisp offers a unique combination of customize-ability, utility, and interactivity. It's been around long enough for it to have a significant amount of libraries, and it has a multi-threaded REPL (so you can run your main loop and hot-reload your code-updates at the same time, how cool is that?!).
As for the parentheses... yes, I can see why Lisp code would be hard to read. On the other hand, with the right editor extensions (parinfer) it's really easy to edit, and you don't even need to think about the parenthesis when doing it. The documentation is alright I'd say, you can find plenty of stuff online.
Not sure what else I can say. I'm having a good time with CL... I'll try not turning into a 'smug lisp weenie'?
Elephant in the room: the hostility of the LISP community. Is there any language community with quite the reputation for unwelcoming unpleasantness, combined with the opposite - no counterbalancing reputation for welcoming friendliness?
That people feel bad when they try to enter LISP world is much documented[1]. That Python and, say, Julia, managed to get reputations as welcoming communities long after Eternal September says the problem isn't "everyone" invading Usenet.
I'm expecting immediate downvotes for this comment, but what I really hope for is "yes I have that feeling about LISP world compared to other languages" or "no I feel LISP world is represented approximately the same as other languages".
> "And yes, I think it still represents the comp.lang.lisp group, even in the post-Naggum area. Just look up the latest debate of the shortcomings of Common Lisp that was incited by Steve Yegge. Lisp is as close to a perfect programming language as any, and its zealots guard it rabidly. Criticism isn't tolerated. Ignorance isn't tolerated - which drives many newbies away quite quickly. Lisp has been attacked so much before, that any post by a newbie meekly seeking an advice on some arcane feature gets immediately interpreted as criticism and turns into a flame war. True, Erik Naggum was the main cause of such flame wars in the past, but he wasn't the only one. Wake up, Common Lisp gurus - your language is so unpopular because of you - there is no one else to blame. If you ever asked yourself why is CL much less popular than the obviously "brain dead" Perl (paraphrasing Naggum's favorite Perl quote), the answer is the community, that is you."
Typically what ends up in wide use is historical in nature. C became dominant because it closely maps to the hardware that was available when personal computing went mainstream. A whole generation of programmers learned it, and that influenced language design for decades to come. When everybody is used to doing things a certain way, it can take a long time for new ideas to gain popularity. People often get set in their ways and have a hard time adapting to new ideas.
A lot of the popular languages are fungible because they come from the same family. For example, Ruby, Perl and Python are all extremely similar in nature and offer no fundamental advantages over each other. Then we have system languages like C, C++, and Rust which offer better control over resource utilization.
As a long term trend what's going to drive language popularity is how well the language is suited to tackle popular problems. Functional languages are perfect example of this, as they have been around for many years, but they simply didn't fit well with the available hardware.
Back in the 70s you had single core CPUs coupled with very limited memory. Things like GC were simply not an option and you needed languages that were good at squeezing out every bit of performance possible. Imperative languages addresses this problem extremely well.
However, today we have different kinds of problems. In many cases raw performance is not the most important goal. We want to have things like reliability, scalability, and maintainability for large code bases. We want to be able to take advantage of multicore processors and network clusters.
The imperative paradigm is a very bad fit for these problems because it makes it very difficult to localize change. On the other hand, functional paradigm is a great fit for these problem thanks to its focus on immutability and composition. Today we're seeing a resurgence of interest in functional programming, and Clojure is a perfect example of a Lisp that's quite successful.
I learned Lisp in the 80’s and 90’s because AutoCAD used that as it’s internal scripting language. Was fun to play around with and I wrote code for a paying project to do election redistributing after the 1990 census. I’m out of that world now and have no idea what AutoCAD uses these days for scripting.
[+] [-] FigBug|6 years ago|reply
Web frontend -> Javascript
Unix / Linux -> C
Wordpress plugins -> PHP
Windows apps -> .Net
iOS -> Objective C / Swift
Android -> Java
In my entire career (25 years), I've never had a project that directed me towards learning Lisp. This pretty much leaves Lisp to the type of developer that seeks out new languages and is willing to spend the extra effort integrating, and that's a pretty small number of developers.
If Lisp was in the browser instead of Javascript, it would be popular no matter the complaints about the language.
[+] [-] reikonomusha|6 years ago|reply
Lisp might be viewed similarly. It’s not a fad and big companies don’t use it widely, but does that make it a failure?
Google uses Common Lisp. (They even host a style guide!) So does Rigetti Computing making quantum computers. So does/did DWave, another quantum company. There are a handful of companies that have existed between 15–30 years developing Lisp compilers (LispWorks, Franz Inc, etc). Lisp also seems to be making HN front page at least once a week.
[+] [-] logicprog|6 years ago|reply
What I'm getting at here is that it's pretty clear that language features are an integral part of what makes a language successful. In fact, apart from some extreme, extreme outliers like JS which just happen to be the most visible, features are the only deciding factors outside of luck (and marketing). So if you ask why a language isn't successful, saying that it doesn't have a captive audience isn't a very descriptive or helpful metric. Yes, without a captive audience or maybe won't be as successful as JS but that's not the real deciding factor at all.
Aside from a captive audience based killer app, projects don't lead to language choice necessarily. Why did the person who created Numpy choose Python? Python didn't have a killer app for that. They chose it because of language features.
So we're back to the OG question: in the arena where languages normally compete (besides outliers), LISP looks amazing, so why isn't it as successful as we'd expect? I'd honestly suggest it's just bad luck, no marketing, and a fragmented community.
Now, we could talk about why the LISP community is fragmented, and in this case I think it's due to too much of an emphasis on extending the language. DSL-building based programming paradigms are actually really effective, they're essentially what FP and OOP are all about. In OOP you build a custom type system and language to represent the problem. For FP you do the same, just with less internal state. LISP's only difference is it has more powerful abstractions for formalizing the process. The problem is they confused DSL building with language building and so multiple different general purpose dialects proliferated.
[+] [-] goto11|6 years ago|reply
The article cites fragmentation as the reason Lisp didn't become mainstream. But consider SQL - a severely fragmented language. Each implementation have major incompatibilities with every other. But it is still ubiquitous and rules its niche.
[+] [-] melling|6 years ago|reply
https://www.reddit.com/r/programming/comments/b7khq2/i_just_...
[+] [-] duckqlz|6 years ago|reply
As a vim user I love to think of all of the emacs peoples' heads exploding when they read lisp has no killer app. However it should be noted that lisp still has strong use cases in education and language design and even if not commonly used in industry its principles and design ideas come through in many modern languages.
[+] [-] wellpast|6 years ago|reply
Also JVM languages are surging even though none have a specific killer app.
But Clojure is still niche. And is the most powerful/simple of them all. I think there’s something else going on, too much power & simplicity in a language doesn’t yield to mass appeal - why?
[+] [-] grumpy8|6 years ago|reply
I wonder if ClojureScript -> [Node, Web-js] is how lisp will be saved? Or maybe lisp doesn't need to be saved and it'll always be this non-mainstream language. (To be clear: I say non-mainstream but I don't mean it negatively.)
[+] [-] c256|6 years ago|reply
Unfortunately, the massive investment of time, money, attention, etc that went into Lisp and AI came too early, faltered, and left both high and dry for a few decades. It’s called “AI Winter”.
[+] [-] ksec|6 years ago|reply
An ecosystem forces you to program in a language, as long as the ecosystem grows in market value, it will require more developers, more people learning it and more jobs for it. A positive growing circle, and once it reaches a certain threshold it should become self sustainable, there will be interest from many parties to try and improve on it.
On the other hand, if a languages ecosystem does not reach that threshold, there will be doubt if new project should be built on it, there will be less opening for developers, less in demand means people are not learning it, market wants experience dev but experience dev would have moved on to other ecosystem. Lack of hireable Devs meant PM should choose something else that makes hiring easier. And the ecosystem shrink, what we call a languages is dying. It really isn't dying, it should be accurately described as shrinking. The Negative circle.
And in most cases languages lives on in other form. People call Ruby as Matz's Lisp.
[+] [-] tsss|6 years ago|reply
[+] [-] DocTomoe|6 years ago|reply
emacs
[+] [-] bryanrasmussen|6 years ago|reply
So why not choose a Lisp.
[+] [-] hyperpallium|6 years ago|reply
[+] [-] V-2|6 years ago|reply
[+] [-] JulianMorrison|6 years ago|reply
- In the past, it was better at abstraction, but slow and niche and you needed to shell out for hardware.
- In the present it is not better. Common Lisp is about on a par with Python in what it has built in, inferior in its ecosystem, and for some modern stuff (threads, sockets) you will have to go outside the language standard into the wild west of implementation extensions or third party libraries.
Lisp's one big selling point is macros. Macros are magic that lets you reprogram the language. Reprogrammed languages break the ability of a programmer to drop in and read the code. Languages that need reprogramming to get basic shit done are unfinished or academic (Scheme). Languages that can get stuff done, but tempt you to reprogram them are attractive nuisances (Common Lisp, Ruby). In use, they create incompatible tangles that don't mix well with other people's incompatible tangles. I have been bitten by this repeatedly in Ruby. But Ruby is still easier to get work done in than Common Lisp.
Basically it died of being meh with a side of footgun.
[+] [-] flavio81|6 years ago|reply
about 20x+ faster than Python, too; speed in the same order of magnitude than C.
>and for some modern stuff (threads, sockets)
pretty amazing you bring out threads in this comparison, when Python doesn't even support true multithreading.
>Macros are magic that lets you reprogram the language. Reprogrammed languages break the ability of a programmer to drop in and read the code.
It's the other way around. Lisp macros allow to eliminate boilerplate and produce clearer code. This is obvious to any lisper.
[+] [-] voldacar|6 years ago|reply
Maybe not quite as big of a selling point, but lisp has also always been the best environment for writing programs that need to modify themselves at runtime. Homoiconicity removes the limitation that code must be known and constructed at compile-time.
[+] [-] reikonomusha|6 years ago|reply
[+] [-] dual_basis|6 years ago|reply
[+] [-] tgbugs|6 years ago|reply
So if lisp failed for some internal reason then I don't think it was for the reason the author specifies. What should worry people more is that a language that is better in 99% of cases can fail for reasons that have nothing to do with its technical merits, but purely by accident of history or as a result of politics unrelated to those technical merits.
Trilobites were the most diverse clade in the history of the earth. Trying to rationalize why they went extinct by studying their anatomy is going to be fruitless. Same with LISP.
[+] [-] overgard|6 years ago|reply
[+] [-] techslave|6 years ago|reply
You don’t need to guess. paragraph 2:
> Some of the above languages are no longer quite as popular as they once were. This will be the definition of "failure" we will use here.
I think it’s fine to use “failure” as a concise term that way, especially when he explicitly defines it.
I don’t agree with his reasoning but the use of “failure” is fine as a rhetorical point.
[+] [-] ajkjk|6 years ago|reply
[+] [-] caiocaiocaio|6 years ago|reply
Aside from that, as the author points out, ideas from Lisp have made their way into almost every widely-used language today. It's fingerprints are everywhere. That doesn't sound like a failure to me.
[+] [-] logicprog|6 years ago|reply
[+] [-] Veminder|6 years ago|reply
Every now and then people write these silly articles about lisp failing, yet it persists as an elegant solution that doesn't need constant new releases and picking up the latest fad.
[+] [-] elwell|6 years ago|reply
[+] [-] readme|6 years ago|reply
[+] [-] karmakaze|6 years ago|reply
> The reason Lisp failed was because it fragmented, and it fragmented because that was the nature of the language and its domain-specific solution style.
The main points above can be solved with two things:
1. A more opinionated base language with batteries (e.g. Clojure)
2. A package manager shared by users of the language
Ruby is expressive and has the DSL failure modes as lisp (though usually not as low-level), but it starts with a more batteries-included base. If it wasn't for Rails and gems leading the way to normalized usage Ruby would not be as successful as it is today.
[+] [-] abrax3141|6 years ago|reply
[+] [-] dreamcompiler|6 years ago|reply
[Herein I mostly mean Common Lisp when I talk about Lisp. I have no experience with large projects in Clojure or Scheme.]
Most modern software -- Lisp programs included -- is written by multiple programmers in both coordinated and uncoordinated teams. Lisp can easily adapt to team programming but SWE needs to be augmented to handle programming projects that operate at a meta-level, which is natural with Lisp. If you write code at a meta level with ordinary SWE it can lead to disaster.
SWE needs tooling, procedures, and policies to deal with macros, package naming, bootstrapping, multiple-inheritance classes and first-class methods, etc. before it can really support Lisp. Lisp projects that have added such SWE features manually tend to succeed; those that don't tend to have difficulty with Lisp. My point is the team has to do the SWE work; SWE tools operating in default mode tend not to be good enough for Lisp.
[+] [-] agumonkey|6 years ago|reply
and right now most of the world is slowly migrating to a lisp/ml word without knowing...
[+] [-] ben509|6 years ago|reply
MLs took ideas in LISP much further and imposed powerful type systems on them, so they appeal to a smaller audience than LISP does.
And the multi-paradigm languages simplified ideas from LISP to be usable for a broader audience, and brought in new ideas from elsewhere.
So I don't think SE has failed to reach LISP, if anything, it's surpassed it.
[+] [-] garren|6 years ago|reply
Lisp, it turns out, is a weird and challenging language. It takes a little extra before you start to see the exciting bits. Unfortunately, until you reach that point, it's a matter of struggling with the parts around it - namely the editor. Lisp and Emacs go hand in hand, and while today you can rely on other editors to competently work with Lisp code, 20 years ago I don't think this was the case.
So now a user has to pick up Lisp (challenging when viewed through the lenses of either VB and COBOL) and Emacs (positively baroque if your only experience is within a GUI and IDE). I'd venture to guess that getting a functional Lisp environment running on a 286/386 era PC was probably a challenge in itself for most people.
Now consider VB or Java, significantly more familiar languages that didn't effectively depend (at the time) on the features of their editor or IDE. Both were a mouse-click away as far as installation, and Java didn't cost anything. Both were backed by large organizations that had a lot of incentive to invest and convince people to use their particular thing.
Lisp was this weird, mostly academic, language intended to tackle relatively esoteric rather than business problems, that was Unix only at a time when PCs and Windows were taking off. It doesn't seem unusual to me that it didn't take over the world. Frankly, I'm surprised and thankful that it's still around, actively used, and even sporting a significant community.
[+] [-] kazinator|6 years ago|reply
I've been doing Lisp for just about that many years and have used nothing but Vim. Its Lisp support is built off :set lisp mode which is in the original Unix vi. It does a good job of syntax coloring, indentation and all that.
To reindent a block of code in Vim, I just put the cursor on one of the parentheses, then hit =% . The odd time there is a stylistic disagreement (like Vim wanting to align the arguments of something as if it were a function, rather than let-like).
My Lisp implementation, TXR Lisp, comes with a comprehensive Vim syntax file.
When you browse the sources using CGIT, all the syntax coloring you see is performed by Vim, being used on-the-fly as a back end for HTML generation.
E.g.: http://www.kylheku.com/cgit/txr/tree/share/txr/stdlib/defset...
[+] [-] sametmax|6 years ago|reply
> The reason Lisp failed was that it was too successful at what it was designed for. Lisp, alone amongst the early languages was flexible enough that the language itself could be remade into whatever the user required. [...] However, the process causes Balkanization. It results in many sub-languages all slightly different. This is the true reason why Lisp code is unreadable to others. In most other languages it is relatively simple to work out what a given line of code does. Lisp, with its extreme expressibility, causes problems as a given symbol could be a variable, function or operator, and a large amount of code may need to be read to find out which.
And I perfectly agree. You can see it in tutorials too. You can even see it in any Lisp-lover comments showing you a proud snippet of how "it can be solved better with lisp": it's too clever.
A little bit of clever is fun, it's good for the soul, it can even be productive. But Lisp is just a big pile of cleverness.
Being clever is so appealing to my geek nature. It's so cool. Yet experience (in coding and life) taught me it is not a good property to build a community around. Or a project for that matter.
At best, it's something that can emerge from a battle against long and arduous stream of problems. And then you can rest, you try to factor away the cleverness. But not as a goal. Not as a basic proposition.
[+] [-] mark_l_watson|6 years ago|reply
Common Lisp tooling is very good and there is an active community of users. I argue that Haskell is really a Lisp language, at least it seems so to me. Also, so many good Lisp-y things are in Ruby, Python, modern JavaScript, etc.
I think language selection for a project is a process of making trade offs. I am happy that it is a free world to develop using whatever languages and tools we want. I try very hard to never judge anyone on their politics and I try to do the same in programming language wars.
[+] [-] ddragon|6 years ago|reply
Phoenix/Ecto for example would probably not get the attention it gets (and deserves) if it focused on Erlang instead of a new language with some momentum. And Lisp seems to get it even worse when all of them (old and new, with as many programming paradigms as there can be) get grouped together as one 60 year old language family. Hopefully clojure, racket and other newcomers can turn this around.
[+] [-] chicagoscott|6 years ago|reply
http://www.andrewlangman.com/articles/the-missing-lisp-book....
[+] [-] namelosw|6 years ago|reply
Common Lisp, Scheme, and Emacs Lisp are way too different from each other. It's more like a comparison with C++, JavaScript, and Bash. Common Lisp is hardly a functional programming language. Emacs has no lexical scope (This really made me freak out). Clojure is a more qualified functional programming language.
2. Lisps, for example, Scheme was superior to other languages decades ago. But now, as you can see JavaScript is basically a Lisp without macro (Yeah I know HN guys don't like JavaScript, but I choose JavaScript because it's a footgun language like Common Lisp and Emacs Lisp). Or just Elixir, basically a Lisp without paren syntax.
3. Lisp never dies, there will be more. It will march forward as the industry moves. The Lisp syntax means the ease of parsing and macro design, and people will combine this feature with other features. There are already:
a) Functional Lisps like Clojure b) Carp, a Lisp without GC, there were also Linear Lisp c) WASM, an assembly with S-expression d) I have already seen other prototypes with static types/dependent types/monadic macro systems etc.
[+] [-] lispm|6 years ago|reply
it has now
https://www.gnu.org/software/emacs/manual/html_node/elisp/Le...
[+] [-] Quequau|6 years ago|reply
[+] [-] TheOtherHobbes|6 years ago|reply
The original LISP body then went into suspended animation, and may reappear in an evolved form at some point in the future.
[+] [-] runn1ng|6 years ago|reply
https://locklessinc.com/articles/
[+] [-] thsealienbstrds|6 years ago|reply
For example, Lisp is not purely functional, but if you want to force yourself to program in a bit more of a functional style, you can make a macro that disallows the use of 'setf' (Lisp's assignment operator) in a function body, and it's actually quite easy to do that!
Maybe Lisp 'failed' because it's too flexible. You can solve your problem in a million different ways. Arguably, that is not a good thing in industry where it is preferred to have a language that enforces a single style on your code base for consistency across developers. However, I'd argue that it is very good thing for a creative individual. You want to have the freedom to do things your way.
From what I've experienced so far, Common Lisp offers a unique combination of customize-ability, utility, and interactivity. It's been around long enough for it to have a significant amount of libraries, and it has a multi-threaded REPL (so you can run your main loop and hot-reload your code-updates at the same time, how cool is that?!).
As for the parentheses... yes, I can see why Lisp code would be hard to read. On the other hand, with the right editor extensions (parinfer) it's really easy to edit, and you don't even need to think about the parenthesis when doing it. The documentation is alright I'd say, you can find plenty of stuff online.
Not sure what else I can say. I'm having a good time with CL... I'll try not turning into a 'smug lisp weenie'?
[+] [-] jodrellblank|6 years ago|reply
That people feel bad when they try to enter LISP world is much documented[1]. That Python and, say, Julia, managed to get reputations as welcoming communities long after Eternal September says the problem isn't "everyone" invading Usenet.
I'm expecting immediate downvotes for this comment, but what I really hope for is "yes I have that feeling about LISP world compared to other languages" or "no I feel LISP world is represented approximately the same as other languages".
[1] e.g. https://eli.thegreenplace.net/2006/10/27/the-sad-state-of-th... from which comes this
> "And yes, I think it still represents the comp.lang.lisp group, even in the post-Naggum area. Just look up the latest debate of the shortcomings of Common Lisp that was incited by Steve Yegge. Lisp is as close to a perfect programming language as any, and its zealots guard it rabidly. Criticism isn't tolerated. Ignorance isn't tolerated - which drives many newbies away quite quickly. Lisp has been attacked so much before, that any post by a newbie meekly seeking an advice on some arcane feature gets immediately interpreted as criticism and turns into a flame war. True, Erik Naggum was the main cause of such flame wars in the past, but he wasn't the only one. Wake up, Common Lisp gurus - your language is so unpopular because of you - there is no one else to blame. If you ever asked yourself why is CL much less popular than the obviously "brain dead" Perl (paraphrasing Naggum's favorite Perl quote), the answer is the community, that is you."
[+] [-] yogthos|6 years ago|reply
A lot of the popular languages are fungible because they come from the same family. For example, Ruby, Perl and Python are all extremely similar in nature and offer no fundamental advantages over each other. Then we have system languages like C, C++, and Rust which offer better control over resource utilization.
As a long term trend what's going to drive language popularity is how well the language is suited to tackle popular problems. Functional languages are perfect example of this, as they have been around for many years, but they simply didn't fit well with the available hardware.
Back in the 70s you had single core CPUs coupled with very limited memory. Things like GC were simply not an option and you needed languages that were good at squeezing out every bit of performance possible. Imperative languages addresses this problem extremely well.
However, today we have different kinds of problems. In many cases raw performance is not the most important goal. We want to have things like reliability, scalability, and maintainability for large code bases. We want to be able to take advantage of multicore processors and network clusters.
The imperative paradigm is a very bad fit for these problems because it makes it very difficult to localize change. On the other hand, functional paradigm is a great fit for these problem thanks to its focus on immutability and composition. Today we're seeing a resurgence of interest in functional programming, and Clojure is a perfect example of a Lisp that's quite successful.
[+] [-] Tagbert|6 years ago|reply