Item — HN Reader

Because you need Lisp. That's the actual "power of Emacs". Emacs is a Lisp-interpreter with a built-in text editor. Everything stems from that. Anyone challenging "the choice" of Lisp as the configuration language for an editor, saying things like: "Why? If X is better - faster, more modern, more popular...", etc., have misunderstanding of what makes Lisp so uniquely powerful.

A specific language is not the point - to implement anything similar to Emacs, you'd need a homoiconic language or at least a language that gives you live, reflective, late-bound image with code-as-data. Without that single aspect tons of things simply and inevitably (as history shows) will get complicated.

Why we have not seen such differentiator with VSCode? Because of their design choices - the extension language and the editor internals live in different worlds behind an API boundary. Emacs essentially has no such boundary. That's the power, and also a consequence of the image + homoiconicity combo.

1 comments

> to implement anything similar to Emacs, you'd need a homoiconic language

I've got that. It took 6 years but I developed a comprehensive homoiconic layer for Javascript

How does that work? Homoiconicity is a property of the language, not something you can develop as a layer.

JS was already pretty close. Babel allows a fantastic degree of power in code transformation, it just doesn't preserve blank space.

If I were to use my preferred terminology I would simply call these transform-your-own-code formats "embeddings", and there can be many embeddings for a single language.

> Babel allows a fantastic degree of power in code transformation

That's still not homoiconicity. It reminds me old Stuart Sierra's presentation from Clojure/conj¹. Around 6 minute mark: "Adding eval to a language, even successfully, does not count as homoiconicity"... "and you didn't even succeed at that..."

---

¹ https://www.youtube.com/watch?v=o7zyGMcav3c

I'm sorry, but that's not homoiconicity. I'm not trying to devalue your work (if you're talking about BABLR/CSTML), but you really cannot bolt homoiconicity onto a non-homoiconic language with a layer, because the defining trait is the absence of a layer.

It doesn't look like your real goal was homoiconicity at all, but rather "stay in JS semantics, keep the JS ecosystem, and build structural editing over any language". Homoiconicity is a word you grabbed to borrow from Emacs's fame, but not a requirement you're were ever trying to satisfy. If it was the actual requirement, there are dozens of options that exist already - Squint, cherry, Clojurescript, Scittle, Fennel-to-JS, even Gleam - any of them gives you code-as-data cheaply.