This comment is going to get downvoted heavily here, but it's high time every one accepted the fact that the Lisp family is almost dead and move on.
> I see no "enlightment" in learning Lisp
> the Lisp family is almost dead
You're conflating popularity with value, and the two are very different.
Moreover, you're missing the fact that most of the features that were invented in Lisps (like GC, lambdas, first-class functions, and REPLs) are now wildly popular, with every modern language having taken several ideas from Lisp.
Furthermore, you don't seem to understand that a language is not the sum of its parts. Python, Java, C++, and the rest of the languages that have been grafting on Lisp features do not have the unifying design philosophy that Lisp does, which is precisely the "enlightenment" that you don't think exists.
Finally, by the nature of "enlightenment", you can't see or understand it until it hits you. As someone who is stubbornly refusing to learn Lisp, you by definition cannot judge whether or not you might have a galaxy-brain moment if you attempt to learn it. (it's perfectly possible that you'll learn it and have no moments of revelation, but you can't even tell whether or not that will be the case until you try)
and thus because you see no enlightment in learning lisp
> it's high time every one accepted the fact that the Lisp family is almost dead and move on.
Doesn't track for me. I believe there can be value in things that I personally don't perceive value in.
This has some obvious negative consequences, such as high feedback loop time - in Lisp, the compilation delay is usually imperceptible, especially when compared to running javac or python.
The "it's high time every one accepted X" is a meaningless comment because it presents an opinion as if it were a fact. Therefore, please accept my downvote.
*if such toolkits exist, please point me towards them - I've always wanted to see one in practice.
My development style is highly iterative and I tend toward functional paradigms. I build up a Python program by evaluating lots of small pieces, slowly building those into the structure of my program. I don't write code into a saved file without first evaluating it in a linked REPL session.
Python does not support the same style of connecting to a live process, like Lisp does. Nor does it have the same facilities of redefining components in a running system.
The surface level actions look similar between my Lisp development and my Python development.
not sure what you have in mind, but i use 'elpy' regularly within emacs, and typically test/load functions incrementally into a python repl buffer, or interact with the repl directly
This is enabled by the fact that code in Lisp is also written in the form of lists. Code is data, data becomes code if you write a macro to process the data.
For example, is the following data or code?
(book (author "Jonathan swift") (title "A Modest Proposal"))
It definitely looks like data. But it can be made into code using an appropriate macro.
What probably Lisp trails in is type inference and bleeding edge libraries.
SBCL type inference is actually getting better and better over time, giving you pretty effective gradual typing. Additionally, a Common Lisp implementation called SICL is in the works, with an advanced compiler and type inference engine.
to chime in, it also can be made into 2 systems - one which defines 'book' as an in-memory object which can be inspected, and one which, say, defines a remote database object - your 'language spec' is the syntax, and you can implement multiple implementations, or replace subsystems as you build up the bigger thing - e.g. 'now my hashtables are persisted to disk', etc
There are essentially 2 possibilities:
- you need huge or specialized libs not available elsewhere: Python, Java, etc.
- you need extreme speed, binary size or memory control: C, Rust, etc.
For everything else, lisp will be better.
The enlightenment comes from the Zen master understanding why those languages are halfway through Lisp, and grow oneself how to improve them to reach parity with the master copy of the universal God language.
Watch someone like Notch code in Java; it's possible to achieve it without whatever language feature people think is essential. However, if it's easier to achieve in Lisp, then Lisp will always have value. The enlightenment isn't essential for application development, but it points the gun away from your foot surprisingly often.
> much of the things that made Lisp attractive before are already available in Python, Java, etc. and I see no "enlightment" in learning Lisp.