Why is lisp still so uncommon today as a practical, business-needs language? Everyone I know who uses it loves it, but it’s virtually nonexistent in today’s enterprise.
Things could change though when you look at the landscape of computer languages today:
- OOP is trending downward, and for good reasons, look at Java and C#, too verbose, too top-down.
- dynamic languages are not efficient enough, especially in the cloud where they require 10 VM to do the work that could be done on a single machine with lower level languages.
- c/c++ are too low-level, hard to master/difficult to maintain.
- Rust is a mess, too verbose, too complex.
- In the FP universe, which is trending up, Haskell is too complex, F# is good but the libraries (.NET) are OOP mainly so the integration sucks. Clojure, not sure, didn't play with it but my guess is it suffers the same problem than F#.
So, personally, and not trying to convince anyone here, lisp, and especially Common Lisp with its large number of available libraries and its good development environments (emacs/slime), is getting more interesting every day.
Just want to throw D into the ring as a candidate here. It's a smashing language. I think it satisfies the very compromise you are seeking from your evaluations of other languages.
Thank you for reading me so well :) It's a very interesting language for sure, checks a lot of boxes. How is the market trending for it job wise? What I'm finding online so far seems pretty mixed.
Java is mediocre (better than it used to be), but Scala and Kotlin benefit from those huge investments in JVM optimization and have a lot of potential if you don't need the minimal footprint of Rust.
Scala is an interesting language, but now, it's back to java ugliness as soon as you need to import some existing java classes. That's my issue with all the JVM languages (and .NET is even worse here).
In theory there's no reason it shouldn't be used. CL has OOP, GC, very mature optimizing compilers. It was used in industry a lot as the faster-to-develop alternative to C, but then Java/Python pretty much took over since the dotcom era.
In Java/Python (and now Go), there's generally only one way to do any given thing. A business can hire people who were trained the same way to stamp out idiomatic code. Lisp hackers create works of art that no one else can figure out after they leave.
If you're working on something on your own, or with a small group of people, then you don't have to dumb yourself down. You can always rewrite it later in Java/Python/Go if the project gets big enough that replaceable cogs need to be hired.
> Lisp hackers create works of art that no one else can figure out after they leave.
It's possible, but it's not necessarily so. There are many Lisp code bases which are 20, 30, 40 or even 50 years old and still maintained, passing on the work to new generations of programmers.
Maxima has bits from the end 60s. Cyc is under continuous development from the early 80s onwards. SBCL is based on Spice Lisp code developed at CMU from 1981. The commercial implementations Allegro CL and LispWorks with their IDEs and libraries are under development since mid/end 80s. Axiom/Fricas computer algebra systems started the code base in the 70s at IBM as Scratchpad 2. The first MIT LOOP macro implementation was written in the 70s and then modified as Lisp dialects changed. The G2 process control system by Gensym started mid/end 80s and is still being sold. The SPIKE telescope scheduling system from NASA is still in use for various large earth and space telescopes - originally development started in the end 80s.
I've seen code bases which I could not understand from looking at them - rare, though. The biggest problems were code bases which were tied to a particular implementation and OS. For example the Sk8 multimedia development environment written by Apple is non-portable, since the Lisp code uses Mac native graphics/multimedia libraries everywhere directly from Lisp and is not abstracted in a layer.
Thanks so much for this comment. I've only scratched the surface of Cyc and SPIKE and half an hour is already gone.
I hope someday to work on something even remotely as challenging and worthy of applying one's brain power to as these honest projects are. In the meantime, I have to bear the "full stack developer" mania and its zombie friends.
Because it's not popular, and managers like popular languages because they imply a large supply of fungible programmers. Whether the language is actually powerful (or even useful) is never as important as popularity.
It's more that a language and its relative expressive power is not nearly as important to project success as the ecosystem around it. Who can I hire? If I lose them who can I replace them with? What frameworks can we use? How can I get support?
this is tangential to your point, but I feel as though I personally use this justification often in technical projects, a wide base of users often means a large base of accessible supporting material and community. while I'm sure of the utilitarian justification I can't help but feel it's also laziness on my part.
It's not used in business because it's not popular.
One of the two factors that hinder its popularity is the friction needed to set-up a proper development environment and the learning curve that one has to take to master it.
- To code effectively one has to learn how to edit at the sexp level rather than at the word level.
- The only free editors that provide proper debugging and repl support are the ones that offer a plugin for Swank. Amongst these the best two are Emacs and Vi(m) with Emacs that has an advantage in terms of additional support for CL.
- Installing and configuring properly all the above requires some work.
- There have been recently attempts to mitigate this (e.g. Portacle) but in any case one has to learn Emacs (or Vim), Swank commands and a Lisp supporting mode such as lispy,paredit,parinfer, etc.
- Windows is a second rate citizen: there is no free Windows implementation that allows to step native code. Emacs is a second rate citizen on Windows as well. (This is mitigated by the fact that SBCL runs on Windows Subsystem for Linux).
- The commercial implementations are very good but expensive.
Now compare all of this with the typical developer that just downloads Visual Studio code and starts to write Javascript on Linux, Windows or Mac.
All of the points above are of course not insurmountable but require some investment in time. One has to take a couple of weeks to start to become proficient in all above. The typical young developer doesn't have this patience.
This is exactly why CL is more common amongst who uses Emacs already: if you master Emacs the jump to CL is almost consequential.
Very little concept of security, privacy and a default paradigm of "lisp assumes it owns the environment".
This may no longer be true, but it's a large barrier against being adopted in many industries.
That and it's kind of hard to do modern graphics with many implementations.... although they can do html serving pretty well.
LISP environments may be the start of GUI, but that code is largely locked up, or in systems that can no longer be used (I think?)
Anyway, all stuff worth putting some attention on!
(note : just a lisp fan, and only an edge one, so likely no longer accurate on many points Most of the above came from reading 50s through 90s texts, and trying lisp environments at the time)
For a long time, the answer was probably performance. Lots of people were trained to use Lisp in their computer science courses, and lots of people admired it. But it was never anywhere near as fast as C, and in the seventies and eighties squeezing every darn bit of speed out of your hardware was what counted.
The language had another chance in the nineties, when it became important to save not just execution time, but the programmer's time also. This is when interpreted languages like Perl and Python started showing up in a big way. I'm less confident why Lisp lost out that time, but its weird syntax is probably at least part of the reason.
Perl was quirky at best, but performed very well on simple string manipulation, so it briefly replaced a lot of "grep | sed | awk" use cases where interpreted Python or Lisp might have been 100x slower.
As an imperative language for novices, Python (based on GvR's earlier ABC) was slow but more approachable than Lisp, and the industry had a huge influx of novices at the time (arguably still does). Now that GC and closures are table stakes, Lisp no longer has major advantages until you're ready to create DSLs.
