- 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.
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.
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.
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.
- 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.
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)
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.
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.