Common Lisp is a curious creature. Ancient in some ways, prescient in others.
It is not perfect by any means, and politics did play a large part in the 10-year ANSI standardization process.
At the end of the day, for me, what makes it my favorite language is the principle that the language should provide the maximum possible power to the programmer, boosting productivity of (most evidently) the individual developer.
It has served me well in my 3D graphics project [0], which is different enough from what is out there that it does feel like a worthwhile endeavor.
Amongst the set of opinions (I like Lisp-2s), this is a common misconception:
> Nitpick: Multiple return values are unnecessary if you have tuples
Alright, it doesn't say they are the same (because they are not, despite what you can read on the internetz). If you use tuples and you use unpacking on the caller site, every time you add an element to the returned tuple, you are doom to refactoring all the caller sites. Not the case with Lisp's multiple return values[0]. If you don't use unpacking/destructuring, you must access the returned values with a list index, which is errr not the best. But, if you write your first iteration without returning a tuple, and later you do, you are doomed to refactoring the callers everywhere. Not so with multiple return values.
> Hooks, hooks everywhere…
ah, really? I didn't see hooks in Common Lisp the language, and very few in CL applications (unlike in Emacs). There are meta-object protocols, but you can trace them, see their hierarchy, etc.
> Legacy stuff … no threads … no unicode … no networking
It speaks of the standard. Every CL implementation has those ;)
A good understanding of the in/conveniences profiles of languages. Beginning to grasp the true nature of commonlisp and the true meaning of `the' in the book title `common lisp the language', feeling there is something deeper about it.
The next step could be: if something is inconvenient, change it, make a dialect that is convenient to you, as you noticed, anything can be changed at runtime; see what happens, what was worth the effort and what not. Also, read about the metaobject protocol.
It is not perfect by any means, and politics did play a large part in the 10-year ANSI standardization process.
At the end of the day, for me, what makes it my favorite language is the principle that the language should provide the maximum possible power to the programmer, boosting productivity of (most evidently) the individual developer.
It has served me well in my 3D graphics project [0], which is different enough from what is out there that it does feel like a worthwhile endeavor.
[0] https://github.com/kaveh808/kons-9