Emacs the system is a programming environment that is used to create a model of what a text editor should look like (in Elisp), then an implementation of that model with windows and suchlike (in Elisp, C and with a bit more thrown in for good measure). Extensions build on that model to accomplish magic of various forms. I was anticipating an interesting read on competing ideas of what that model should look like, and how extensions customarily interacted with it, and how the culture has changed over time. 1985 was not the high point for string manipulation and I expect there has been a lot of change through the 90s and 00s, let alone the 10s.
This document is a record of the mechanisms behind the Emacs model. Important to record, a great service for the archivists who really will care, but if I'm going to invest an evening learning about mechanism I'd rather read up on the JVM which is frankly more powerful and interesting than the Elisp interpretor. Elisp is a historical curiosity to be sure and probably interesting diversion to anyone implementing a lisp (who really should be looking to Common Lisps or Clojures of the world for most of the inspiration), but it this document isn't selling the interesting points of the story which is how it was being used. If I'm reading about Emacs generators the only reason I can think of that they are relevant to an Emacs user in in 2020 is in context of what the implications of that are for how Emacs models documents and a text editor.
I am actually somewhat convinced that s global namespace is one of the major factors of growth for Emacs. Yes, namespaces can be nice. But there is something about a playground that encourages all cards on the table.
And, notably, what makes elisp great is that that is largely the language that Emacs is implemented in. Even if you moved elisp to be hosted on the jvm, I shudder to think of having to do a ton of jvm inspired boilerplate to get a quick extension in.
Isn't that a point of commonality with Lisp Machines? Not that I've used one, but from what I read, one of their great aspects is that every function of everything running in a Lisp OS was available for impromptu runtime modification. IOW, you could modify anything even while it's running, without the need to rebuild it and restart it like we do now.
Having a global namespace makes the hot-reloading easier by not having to figure out in what namespace the redefinition should be happening.
That feature is pretty much only widely available in Emacs, now.
It certainly sounds magical. And the few times I work with bugs in Emacs libraries, it is amazing to jump to source so effectively.
But nothing beats the fun of writing a few functions to improve my beloved editor. If it was Java I just would not do it...
I am not taking away from it's accomplishments. But, in the domain of editors, it has netbeans, eclipse, and intellij as examples. Which are all impressive in their own ways, but a culture of modifications is not included in that list. :)
Would it be possible to implement Elisp on top of the JVM? I mean in a way, so Emacs can use it instead of its own VM in a backward compatible way, while at the same time allowing programming Emacs in other JVM languages.
What were you hoping for? The title is pretty clear. I mean, why on earth would "Evolution of Emacs Lisp" discuss the JVM?
> I don't have much interest in whether it implements tail call recursion or if lambdas are implemented as a macro
That's perfectly fine. Criticizing the article because it dares to discuss things you're not interested in, isn't.
The complaint is that the title is in fact unclear. If someone comes up to me saying they are going to talk about the evolution of monkeys they have two strategies:
(1) Developed protein complex A, cell mechanism B became vestigial, a sequence XYZ came from a disease which became part of the cell structure, etc.
(2) When they migrated from A to B abundant food sources meant that selective pressure caused C. Then flooding destroyed the habitat and killed off all the monkeys that weren't D and that trait can still be seen today. Etc.
(1) focuses on technical mechanisms and (2) focuses on pressures and adaptions. This article has a mix of both, but it focuses in on the mechanism and a lot less on the adaptions within Emacs. Not the interpretation of 'evolution' that I was hoping for.
Take the section on concurrency - it leaves open the interesting question of "why was there pressure to make a text editor concurrent?" and "what did they want to do with that concurrency?". The article notes that use appears to still be limited - so why did they feel pressure to implement a feature people aren't using? Are there issues with Emacs' document model that make it a royal pain to use the feature even though it is technically implemented? These are very interesting questions that fall well within the scope of the evolution of Elisp that are, sadly, not tackled by the article.
The authors haven't missed their mark, but when discussing a text editor there are more ambitious targets to aim at - like 'how does all this stuff link back to text editing?'. Few of these changes are being made because anyone sees Elisp as the future.