Could you clarify what you mean by 'there is nothing new under the sun' when referring to programming with Common Lisp? Are you indicating that Lisp has already introduced many of the concepts and features that are now found in modern programming languages, implying that contemporary languages have largely assimilated Lisp's ideas and paradigms?
Your comment left me with a strange sentiment. I'm somewhat disheartening because it implies that learning Lisp might be redundant given that contemporary languages have already incorporated its best aspects.
> Are you indicating that Lisp has already introduced many of the concepts and features that are now found in modern programming languages, implying that contemporary languages have largely assimilated Lisp's ideas and paradigms?
Yes. See effect handlers for an example, which are making rounds around the programming world as of late. They are equivalent to the Lisp condition system, except formalized to work in strongly statically typed programming environments.
> I'm somewhat disheartening because it implies that learning Lisp might be redundant given that contemporary languages have already incorporated its best aspects.
Sort of, lots of things have thankfully trickled from Lisps to other languages (including whole languages like Julia). The pleasant feeling of conversing with the language and programming bit by bit in it is hard to replicate with things like LSPs, though, since the implementation is always running in the background and programming in it is based on mutating it until it contains the program you seek.
I'm also the kind of weirdo who thinks that the old and new testaments are baseline requirements for a human to be "literate" (along with Ovid and Aristophanes).
Despite these works having been recycled a large number of times, the originals still bear close scrutiny.
You'll never know what modern $proglang authors screwed up until you go back and read the fundamentals. For a concrete example, consider the Python module system, and the pirouettes you have to do to use it programmatically. Until you look at (just for example) how this works in CL and RS5/6S, you'll not have the context to readily apprehend the hack job in question (although if you have a modicum of taste you may wrinkle your nose regardless).
It'll also give you a good feel for what the true inventions have been since the early nineties.
Runtime access to read and redefine namespaces and their contents at whim.
Similarly powerful to having the compiler available at runtime, another thing trickling very slowly into mainstream languages.
"But why would you want this?! That sounds dangerous!"
It's quite dangerous, but so is a 700cc dirt bike.
"Can you give me any practical reason you'd want this?"
Aside from the freedom to redefine other folks' code (see: the derogatory term "monkeypatching"), you can leverage runtime namespace access and manipulation to, when loading a "fasl" into a running Lisp image, identify all classes that you care about and then upgrade them to new definitions without restarting the Lisp process.
Most mainstream languages completely punt on "deployment" (PHP [accidentally] aside, where you can joyfully edit production all day, a paradigm too many folks sneer at in the name of cargo cult professionalism), forcing the system operator to restart the process with new binaries (or pycs, whatever, I'm sure you can generalize the point).
A CL system supports that model, of course, but one can also precompile binaries to be loaded into the running system, redefining system behavior without downtime. Binaries, we should note, that don't include the entire Lisp runtime.
It's not that this provides some sort of day-to-day omg ergonomic bonus over the popular Algol families, but that I feel respected as a software author in a Lisp context in a way that I really don't in many other contexts ("nobody needs generics", to pick on some old low-hanging fruit), and the language providing interfaces to itself in itself is a delightfully low-friction cognitive model.
To return to the dirt bike analogy, I could prattle all day about this, but unless you're the kind of person inclined to spend five hours a week learning to enjoy riding dirtbikes, I don't know that I can spill enough ink to convey the fun of managing a few hundred cc's around the track at speed. Countersteering, inertia management, traction, all of these things are going to go over your head if your idea of a fun time with motive power is a Rivian.
I've always said half-joking, that CL users write more text praising it than actual code in CL. This thread is a fine example, but still fun to read.
But back to your examples - I feel that a lot of ideas CL is built on just aged poorly, I guess? No way I want to see some magical binary where some guru adjusted a parameter in the image or the ugly head of monkeypatching or macros all over the place in production code. CL serves the myth of lonely hacker where the rest of the world has accepted the fact that writing software is mostly a social activity and that code is as much for other people as for the machine.
eyyy you should see the paens I've written to lovers past ;)
Note that I'm not strongly advocating anyone ship CL in hot loops in prod, merely that there are wonders in there worth examining, as perhaps the surviving mainstream descendant implementations missed a nuance or three.
It's really not a great fit for middle-of-the-road software teams with quotidien concerns.
It does have plenty of great food for thought for the thinking programmer.
> I'm somewhat disheartening because it implies that learning Lisp might be redundant given that contemporary languages have already incorporated its best aspects.
Indeed, Lisp is no longer as revelatory as it once was, since many innovations have been adopted, even surpassed in specific cases. Still, no other language gives you the total package. The environment is far more than the sum of its features list. CL just gets out of your way and allows you to think about problems not programming.
Your comment left me with a strange sentiment. I'm somewhat disheartening because it implies that learning Lisp might be redundant given that contemporary languages have already incorporated its best aspects.