Hmm, interesting article. I think I disagree with some arguments though. Eg I think one can make a bit of a lisp curse argument when the alternative is C, but I

Hmm, interesting article. I think I disagree with some arguments though. Eg I think one can make a bit of a lisp curse argument when the alternative is C, but I think that mostly doesn’t apply when comparing with JavaScript. Sure there are janky features but modern JavaScript is a pretty nice language. Indeed, I think there are deficiencies in elisp that make Emacs Emacs. In particular there’s one big namespace, no modules, and not really any hidden state (you could let over defun with lexical scoping turned on but unlike JS where the module system is somewhat modelled on the old immediately-invoked-anonymous-function thing, no one does that). This then means that any extension can mess with any other extension. Elisp has features that make this work better, eg buffer-local variables, dynamic scoping (of globals), and advice. What in Emacs is implemented with buffer local variables is likely in a newly designed system to be some private-to-the-extension object associated to buffers / weak hash table mapping buffers to data. I think Emacs-style extensibility also makes things hard because it is easy for two extensions to interfere unintentionally. I somewhat agree with the idea of ‘barrierless extension’ but not for the reasons given in the OP – that eval exists. I would say some differences are: - many Emacs defaults are old, weird, or wrong. It seems mostly hard for them to be changed. Many packages also require much custom configuration. VS code started with more familiar defaults, no legacy of terminal interfaces, and has product people willing to change and improve defaults and generally set direction. - Emacs is designed to be hacked on. The community around Emacs want things to be hackable, eg a popular way of installing third-party packages, straight, has features to support user-modified versions of packages. Also the language/environment exposes lots of extension points (hooks, parent modes, configuration in accessible global/buffer-local variables, advice). It seems that VSCode doesn’t have this. I suspect that bugs for VSCode are less common than for Emacs setups with a bunch of extensions (giving Emacs more VSCode-like features), but I also suspect that most Emacs bugs may be relatively easily debugged and fixed in a way that isn’t true for VSCode.