Honestly I think the author misunderstood and misused P != NP. They should have said something like "collusion is NP-hard". P = NP doesn't imply NP-hard problem is efficiently solvable in practice, but the author assumes so.
I was expecting some tight convergence analysis that rely exactly on some superpolynomial behavior. No, yet another fallacy about P = NP vs NP can be solved in practice. We have too many of these.
> A small but illustrative example: given a live running clisp program, I can click on a UI element to inspect both the live object and the underlying code in the IDE. I can even copy and paste UI elements!
I agree GUI is awkward in Emacs/SLIME. I think the reason is there isn't a standardized GUI framework across the Lisp world. Otherwise people can make SLIME support it.
> If I wanted to use slime-fancy to inspect a class, what I get is a dead list of raw text that I have to awkwardly interact with.
This part I do not agree. Nowadays "text" in Emacs/SLIME is far from "raw text", there's button that respond to hover, with right click context menu, and can be copy and pasted. I recall some small quirks (like objects in inspector are not presentations) but the only reason they aren't fixed (yet) is nobody get bothered enough. There's rarely any fundamental limitation. After all, it wouldn't be fare to call LispWorks UI "dead pixels".
BTW I once wrote yet another over ambitious project < https://github.com/neomacs-project/neomacs > but it doesn't go anywhere either. People do not care enough, Emacs is good enough.
I don't see any comments on Kernel in the post. I didn't waste my time reading the book, but the post criticizes unhygiene F-expr, which is known to be awful and is exactly what Kernel aims to solve and supersede (via hygiene F-expr).
Not directly. Every "extensions" listed above cannot be implemented as user libraries, that's why these back and forth process between implementation extensions and portability user libraries need to happen to reach a de-facto standard. Otherwise the user libraries become de-facto standard themselves, like ASDF the build system, Trivia the pattern matcher...
But I think the power dynamics is crucial. In the Lisp ecosystem the users have great power, (and there are dozens of implementations,) so it's not like one or two implementation decides what everyone is gonna use and everyone just lives with it.
I think the Common Lisp ecosystem sets a good example of how a dozen of implementations move ahead together. Implementations experiment with extensions, the really useful ones get implemented multiple times, and some portability library emerges as de-facto standard if it's good enough. You can watch the result in https://portability.cl/, the language is evolving like never before even if the standard committee has dissolved nearly 40 years ago!
Why? Many Lisp systems and Common Lisp in particular have great hot reloading capability, from redefining functions to UPDATE-INSTANCE-FOR-REDEFINED-CLASS to update the states.
> As to the actual difference between JIT vs. AOT... it may just come down to accounting. That is, on whether you can always exclude the compilation time/cost from the overall program execution time/cost or not. If so, you're compiling ahead of (execution) time. If not, you're compiling during execution time.
Well, this includes what I refer to as "on-the-fly" AOT, like SBCL, CCL, Chez Scheme... Even ECL can be configured to work this way. As I mentioned in another comment, people in those circles do not refer to these as "JIT" at all, instead saying "I wish my implementation was JIT instead of on-the-fly AOT"!
In that sense almost every compiled Lisp/Scheme implementation, GHC, etc. or any other interactive programming system, count as JIT. But virtually nobody in those circles refer to such implementations as JIT. Instead, people says "I wish our implementation was JIT to benefit from all those optimizations it enables"!
It seems that JIT is overloaded with at least 2 meaning.
The canonical definition of JIT is "compilation during execution of a program". Usually, a program is being interpreted first, then switches to compiled code in the middle of execution. This is not what this article does.
What this article does is sometimes called on-the-fly AOT, or just on-the-fly compilation. I'd prefer not overloading the term "JIT".
I guess this case is workable similar to struct redefintion. There can be a condition and a CONTINUE restart, which makes instances of the removed constructor obsolete.
> 1. The function and variable namespaces have been collapsed into a single namespace.
Lisp-N, package system and homoiconic macro is a local optimum (IMO practically much better than Scheme, but I digress) for variable capture issue in metaprogramming. Now it's saying let's bring back the footguns and also you have to write lst instead of list. Please, no.
> 2. ...adds a layer on top of CLOS
How about a library? Why a new standard?
> 3. Common Lisp 3 supports case-sensitive symbols.
This I can relate.
> 4. Common Lisp 3 supports native threads.
> 5. Common Lisp 3 supports tail recursion elimination.
Practically not a problem for today's CL. There's nothing to fix.
> Meanwhile proper typing should be introduced out of the box, like in Coalton[3], for example.
Are you saying Coalton as an embedded language should be introduced out of the box? I'm afraid it may quickly earn similar reputation as LOOP and FORMAT. Or are you saying the whole language should adopt Coalton-like typed semantics? Then I don't think it's even possible for large part of the language, especially when you take interactivity into account. What happens when a function gets redefined with different type? Worse, how about CHANGE-CLASS and UPDATE-INSTANCE-FOR-REDEFINED-CLASS?
> Also, pattern matching should be the part of the language, not some external library [4].
Why not? Common Lisp as a living and extensible language now evolves by adopting de-facto standard (trivia for pattern matching, bt for native threads, usocket for network, ASDF for build system, etc). Why need a committee or other form of authority to prescribe what everyone gets to use when we have a maximally democratic process?
wookie is built on cl-async, so my hope is that it's more tractable to write proper async SSE handler. But I haven't looked at whether it's possible to keep open connection asyncly.
I was expecting some tight convergence analysis that rely exactly on some superpolynomial behavior. No, yet another fallacy about P = NP vs NP can be solved in practice. We have too many of these.