Comment by roenxi | Hacker News Reader

Comment by roenxi | Hacker News Reader

Parent Full thread

Emacs is my text editor, I love it to bits but I don't have much interest in whether it implements tail call recursion or if lambdas are implemented as a macro. So while the article is a great bit of work, quite praiseworthy and possibly an instant classic of Emacs lore I'm going to be critical of it because I was hoping for something different.

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.

This is one of a number of accepted papers for a conference on History of Programming Language. It does a good job of telling the story of the history of Emacs Lisp. Publicly proclaiming that you are critical of it for doing that is rather unreasonable.

https://hopl4.sigplan.org/track/hopl-4-papers

OP didn't say it was a bad paper. The criticism is that it wasn't something that lived up to its title. It's hardly unreasonable to point that out.

I'm skeptical that the jvm would have allowed anything we haven't had. Just look at the crap show that was eclipse and the module system they came up with.

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.

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

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.

That is my understanding. But I don't know, if that makes sense.

It certainly sounds magical. And the few times I work with bugs in Emacs libraries, it is amazing to jump to source so effectively.

Although I love emacs and use it every day, I'd say the JVM is at least light years ahead. I've been using it in various settings for the past 15 years and although I didn't need to push it far away, what it does is nothing short of impressive. In my use cases (business processing), it's performance are really good, the GC works fine, the profiler is really helpful, it is super predictable.

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

The jvm is light years ahead, but on another problem track.

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. :)

ah, yep, you're right. I understand you better now.

> because I was hoping for something different

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 title is pretty clear.

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.

> I'd rather read up on the JVM which is frankly more powerful and interesting than the Elisp interpretor.

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.

Trivially, but there's enough C code in places you wouldn't expect that you would never get Emacs running doing just that.

I meant that the C code in emacs stays as is. And if it calls to the elisp part then those calls should be replaced of course with calls to the JVM via JNI.

Reply on news.ycombinator.com