By itself this doesn't seem like a distinctive advantage of Lisp anymore. Lots of languages have REPLs. But I'm told that Lisp is more advanced in some way. Better debugging, breakloops, everything can be modified in-flight, etc.
You have it exactly right, I think: Lisp's advantage is the interactive repl environment. I do a lot of work with NLP and keeping a (SBLC) Lisp image with all required data loaded saves a lot of time. Even if I am not working in the mode of keeping pre-built images around, starting up an environment and not having to restart it saves a lot of time. I really love to code in Ruby, but the repl experience is better in Lisp.
LISP feels like both an "assembly language" and a "higher level language" at the same time. It's excellent for solving unusual problems, but it carries a lot of baggage when aiming for "usual" problems.
i only said lisp repl is superior. far more superior actually. whether its popular is a different matter. there are people perfectly content with subpar technology and thats ok. however it doesnt hurt to know that there are alternatives
I've built hard realtime systems in Lisp and I did it because it was easier than doing the whole thing in e.g. C. The extra effort for me would have been not using Lisp.
- 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.
The OP lists several features Lisp had decades before they were common to find in more widely used languages, so some of it is for historical reasons. There are two things lisps, including Scheme and Clojure have that are weak or absent in most popular languages:
One is macros. Being able to transform code before it is run using the language's built-in data structures provides a solution when the language just doesn't have the abstraction you need. Used properly, this can be invaluable. Used improperly, of course, it can make a mess.
The other is REPL-driven development. Most languages have a REPL, but they don't really embrace it the way Lisp does. I find this frustrating. Why is my editor on my PC not talking to the app running on my Android phone and letting me see its state and make changes in real time?
I'd say Lisp still has a decided advantage at greenfields programming of new stuff. Especially if the syntax & internal API requirements aren't completely clear yet, then the programming language with minimum commitment to syntax has an advantage. People can experiment more cheaply and in my experience refactoring lisp code is a lot easier than more verbose or inflexible languages. Migrating from lisp to other languages also seems to be a relatively easy path to follow too (I laugh, but I'm serious - this is a useful property when prototyping).
But that isn't very powerful compared to a problem domain expert working in a language they like. If someone doesn't like lisp then they shouldn't use it and they'll probably do well.
True, but one very great advantage of Common Lisp is that it’s a (reasonably) well-designed system, borne of the combined experience of many people. It has many features which seem like hacks (e.g. optional dynamic scoping) or historical baggage (e.g. dynamic scoping) or like over-engineering (e.g. UPDATE-INSTANCE-FOR-REDEFINED-CLASS), but which are actually the product of sound engineering practice, and which lead to solid, well-engineered code.
It does have another big advantage: it's clean. Not having to be compatible with a prior lisp made it possible to have a lot of small things changed. Like the lambda function syntax, or the "def" special form, or the really nice reader syntax for vectors and maps. Both above the hood and below it's based on consistent abstractions. Other lisps would be too, no doubt, but they suffer from having evolved over a very long time.
And it grows, including towards what you it's say it's lacking right now. Recently it got the capability to work with mutable data structures (transients), which makes it less functional, but still without giving up the advantages.
> simple examples comparing Lisp ... that illustrate the benefits of using Lisp over another language
It depends on what you're trying to get out of it. For example, you can grab a simple code of some React components with JSX and ask ChatGPT to write it in Hiccup (Clojure). That would show you how s-expressions can reduce the syntax boilerplate and make it smaller. You can do the same thing with Lua and Fennel - Fennel code would be much shorter and cleaner.
However, without proper understanding and using structural editing and connected REPL, you probably won't see any benefits right away. Lisp code is not the best to be read off the "dead medium" - paper or screen. It's better when you have a connected REPL because it allows you to evaluate every single expression on the fly. Instead of trying to understand what (foo x y z) means, you can evaluate it and immediately see the results. With a connected REPL, you can evaluate them separately (individually), or together. Good talk of relevance: "Stop Writing Dead Programs by Jack Rusher" https://www.youtube.com/watch?v=8Ab3ArE8W3s
Next step in understanding the benefits of Lisp code is learning structural editing. Because everything is a symbolic expression, you can easily move, transpose, change, and replace parts of your program. Instead of rewriting a function of seemingly arbitrary syntax constructs, you'll be dealing with well-structured forms that you can easily move around. No, it not the same, better or worse than using refactoring features of your IDE with other (non-lispy) languages. It's just different.
These two aspects - REPL and structural editing - are really difficult to explain; one has to experience them in person to see if that way of writing software feels appealing to them. And yet, without grokking the basics of these two essential things, IMO, the Lisp experience will not be the same, and you may not get why some people get really excited about Lisps.
And If you're truly looking for a brain-bender, check out https://github.com/hyperfiddle/electric. Dive into the concepts, play with the example demos, and see where it takes you. But be warned: it's an incredibly dense project and definitely not for the uninitiated. If you haven't written in Clojure before, chances are you won't fall in love with its ideas overnight. But it's a good example of "practical applications" that are difficult to achieve unless you're using a Lisp.
The repls you mention are not like lisp repls. You're being downvoted because your comment makes it sound like you've never programmed a lisp but have strong opinions nonetheless.
I would be one of your 10%. I have been using Lisp languages since the late 1970s and Common Lisp since about 1982 so I think it is just familiarity.
Another reason could be developers who like to compose programs from the bottom up would naturally like repl based development, but there are many languages with great repl experiences.
Also, metaprogramming is no longer exclusive to Lisp, other languages are adding advanced features all the time, so there's fewer reasons to move to Lisp.
IMO, the true advantage of lisp nowadays is that of an abstract syntax tree algebra ripped clean of cruft (well, that's scheme, but...). It's much more useful as a way of thinking rather than as a language. "Structure and interpretation of computer programs"is great because if one goes through the entire book and especially implements the scheme interpreter in e.g. C++ or whatever living language it gives you this fantastic general normalized thought model of programming languages which makes it much easier to learn new languages and concepts. That's anyway my experience.
So, to me, Lisp is useful similarly as say, relational theory is useful in software designed (having a relational model is wonderful for complex systems even with a lack of SQL database as a part of the system - if there is more than one 'thing' screw objects and rather use explicit tables and maps).
Lisp was my first real programming language many years ago and the superior environment of Lisp machines (which I had the chance to use from the mid-80s until the mid-90s) is what I still miss today. I dabbled with Fortran IV and Pascal too early on, a bit later with C too, at the same time, but I always found the need to manually manage storage (How long to plan a string? Or how large should an array be?) annoying.
Lisp offered me the freedom to think (and program) in abstract terms. As did (and does), BTW, Perl (especially with regexps, another great abstract tool), where memory management is nothing to care about unless your RAM isn't sufficient ;-0)
When I had to describe the different programming languages to lay people, I used to compare programming in Lisp with using a helicopter and a camera to collect data for map production, while other languages are similar to some earth bound vehicles and a tape measure. Yes, learning to fly a helicopter is more complicated than learning to drive (a bicycle or car) but once you managed the learning curve, you could produce much better results much faster (aka prototyping). And, of course, there are fewer pilots than drivers to chat with.
Here's an interesting (not so recent) talk by Peter Norvig where he summarized the Lisp perspective:
reply