Quite the contrary, I believe that the world of programming is constantly evolving and not revolving solely around whether Lisp is the best. There is a plethora of new languages being generated that are designed to solve problems in unique, innovative ways. For example, languages like Rust, Elixir, Go, and Haskell are much younger than Lisp and are great in their respective fields.
You know, in some ways, the situation often seems reversed. Some Lisp enthusiasts treat non-Lispers as if they are yet to grasp 'the truth', implying that with enough effort and enlightenment, they too will understand and embrace Lisp. While I recognize the merits of Lisp and the passion of its community, it's important to remember that the technological world isn't static; it continues to evolve and innovate.
The reality is this: The world has moved on. A multitude of new languages, paradigms, and methodologies have emerged, each excelling in its unique way and suited to specific problems or contexts.
When talking about programming languages, these type of comments are equivalent to those you describe being made by some lispers claiming to know "the truth". Plenty of languages have their evangelists and their detractors. Common Lisp is no different. Use the tool that suits you. Religious attitude toward anything is likely to be counter productive
The points you make sound like you're assuming that newer == better, and 'moving on' is innovation. I'm not sure our current batch of fast fashion languages are significant improvements, they would need to provide a feature that lisp does not, and if so, what is it ?
From where, to where? You're saying nothing really.
Most movement I've seen in the last 25 years has been because of price, ease of use for beginners, learning materials, marketing and tooling. Intrinsic qualities of the language matters only to a handful of enthusiastic early adopters that I would put in the marketing category.
IMHO Lisp lacks ease of use for beginners and tooling, it's not about the language at all.
We have come a long way from a time when dynamic languages like Perl, Python, and others were not yet prevalent. Back then, Lisp stood out as a unique problem-solving tool compared to languages like Pascal or C. However, today we live in a world where we have highly capable lisps and dynamic languages that allow us to explore problems quickly and with less verbosity. In this newer world, it seems that younger generations are not inclined to deal with s-expressions. I don't believe it's solely the marketing of other tools that has made them the go-to choices.
Common lisp is flexible enough that it's reasonable for projects to stay within the immutable standard, so only library progress happens.
Scheme has given up on the minimal side to the design and become over-obsessed with complicated macros and static compilation. I suppose that's change, if not progress.
Clojure I can't say much about. I like the hashed trie and do not consider the JVM connection a feature. Maybe that is still changing over time.
Racket is still doing its thing, but the current push (Rhombus) seems to mostly be about removing S expressions.
Kernel is a different lisp. Tragically we lost the author too young. Kernel deletes most of the limitations and cruft of _scheme_. It would benefit from a sbcl-level of development effort which doesn't seem to be happening.
I'm interested anything else strange from the lisp world if people have references.
Innovating in the C derivatives continues at pace of course.
The latter one I point to often is the problem of efficiently compiling a dynamic language, where (for example) the offsets of slots in objects can be changed at run time, or (another example) where the set of methods for a generic function can change at run time.
See Robert Strandh's paper in https://european-lisp-symposium.org/static/proceedings/2021.... (page 72)
https://clasp-developers.github.io
"Clasp is a new Common Lisp implementation that seamlessly interoperates with C++ libraries and programs using LLVM for compilation to native code. This allows Clasp to take advantage of a vast array of preexisting libraries and programs, such as out of the scientific computing ecosystem. Embedding them in a Common Lisp environment allows you to make use of rapid prototyping, incremental development, and other capabilities that make it a powerful language."
There doesn't seem to be any way to feed C++ headers into clasp and get out template instantiations accessible to lisp. It looks like SWIG or pybind but you write the shims yourself, and it's function pointer based so templates are wrapped one instantiation at a time.
Garbage collection in the docs is a one paragraph stub which suggests you're on your own for lifetime management across the languages.
Cool thing to exist. Seamless interoperation is either overselling it or the docs are out of date.
Hissp just released version 0.4.0. It compiles Python tuples to Python expressions and has multiple readers with different characteristics, not all of which are based on S-expressions.
It's hard to argue with that, but I'm not sure what point you're trying to make. Should we stop striving for better programming languages, because the status quo is good enough? Or just stop for lisp languages but try to innovate in C-like languages?