Irreal

It appears that I’m temporarily at the end of the Internet: I can’t find anything interesting to write about today. Instead, here’s a rant.

I’ve written before that the Lisp Community’s well-known crabbiness with n00bs is probably the result of having the first thing said n00bs do when joining the community is to suggest some scheme or other for doing away with parentheses. If you’re a Lisper, you know how quickly that gets old. If you’re not a Lisper, you can take my word for it.

Sadly, I recently noticed a parallel offense on the part of Emacs n00bs. Many of them come to Emacs, notice that the extension language is Lisp, and suggest that we rewrite Emacs in a “modern” language such as JavaScript, Python, or Ruby. Here’s a recent example that inspired this rant. As you can see, the poster has no idea of the architecture of Emacs or why things are the way they are. That’s alright: he’s a n00b and no one expects him to understand that stuff out of the box. That said, it’s a good idea understand a subject before you start agitating for wholesale changes.

Here’s a bit of truth for all the n00bs out there: Parentheses, Elisp, and plenty of other things you don’t like or understand aren’t going anywhere. You can make whatever suggestions you like but if you want to be received cordially and have your suggestions treated with respect, take some time to understand the community and whatever it is the community was formed to support.

Postscript: I’ve mentioned this before but it bears repeating. Notice how gentle and respectful those responding to the poster were. The Emacs community really is a friendly and welcoming group of people.

Back in 1979, Bernard Greenberg wrote a long document about Emacs on Multics. If you’re interested in the history of Emacs and how it evolved, you’ll probably enjoy reading through the document. It’s fairly long and detailed but all that detail is revealing.

It’s hard today to appreciate how difficult it was to implement Emacs—or any video editor—on a large mainframe like the H6000 system that Multics ran on. The problem was that the hardware didn’t really support per-character input and processing—let alone echoing the characters to the display—so special effort, including patching the OS, was necessary to make it work.

Multics was written in Multics PL/I, which despite being a complete, well designed language was not suited to incremental development. It was, therefore, a poor choice to implement Emacs with its extensibility. Instead, the controversial decision to use Lisp was made—remember that the original ITS Emacs was built as a set of macros on top of the TECO editor. That fateful decision with its profound effect on Emacs extensibility is still with us today. It’s success should give pause to those suggesting alternative languages such as Python, JavaScript, Ruby, or whatever as the Emacs’ implementation/extension language.

By reading Greenberg’s account, you see why Emacs is the way it is today. Although the text representation was different from today’s gap buffer, many of the original implementation details can still be seen in the current versions of GNU Emacs.

As I said, it’s a long document but worth reading if you’re interested in Emacs’ history and beginnings.

UPDATE [2019-01-19 Sat 15:10]: Goldberg –> Greenberg

In my continued atonement for failing to produce a year end Emacs review, here’s an offering from Bozhidar Batsov. Batsov has done a lot of interesting work—including Prelude, CIDER, and Projectile—so his take on things is worth noting.

Oddly, he finds most of the changes introduced by Emacs 26.1 don’t affect him at all. He’s excited by the advances in concurrency but, of course, it’s still early days. He expects that it will become more important as package writers start taking advantage of the capability.

He makes two further points that I agree with. First, he says that MELPA has become the only repository that matters. Sure, there’s a couple of packages in GNU elpa that we all need and, of course, there’s the Org repository but, really, MELPA is the place to go.

The other point involves GNU elpa. He says that he’d like to see more of the packages that are built in to Emacs core—Org, for example—moved to GNU elpa and the core be dedicated to providing the best possible editing experience. That would have the advantage that the packages could be updated more regularly and, of course, make Emacs more configurable.

Batsov’s post is interesting and worth a read.