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.

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.

  (defparameter *a* '(1 2 3))
  (setf (car *a*) 3)

p.s. (I hate to point this out), there seems to be a name collision with https://lisperator.net/slip/

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"!

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".

> 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?

Have you tried wookie? Such extreme case of blocking the event loop... negates any benefit of async processing.

> C++ has method override but it's not the same: you cannot change the behavior of how addition works on two 64-bit integers (such as treating them both as fixed-point numbers).

Wouldn't you just create a 1-field struct/class and override all the arithmetic operators? Or if you're less fixated about using the same operator (like me as a Lisper), invent a method called ADD and use that.

> Changing addition to work on "bignum"s (numbers that have arbitrarily large precision) is a good usecase of overriding the addition operation.

I don't see this as something unique to Forth compared to other languages, even C++.