The reason Emacs survived 50 years while countless modern IDEs rose and died is architectural: Emacs isn't just a text editor with a plugin API—it's an interactive Lisp runtime that treats text buffers as first-class citizens.

Modern editors build layers upon layers of IPC, JSON-RPC protocols, and sandboxed extensions to keep the user from touching the core. Emacs did the opposite: it gave the user direct access to the live execution state. You don’t "configure" Emacs from the outside; you mold it into the exact operational extension of your own thought process.

In an era where modern developer tools consume gigabytes of memory just to render a UI tree, there is something deeply grounding about a piece of software from 1976 that still offers the most malleable computing medium on earth.

Some of us would say it is a Lisp programming environment, with influences from Lisp Machines (Zmacs), having a text editor as sample application.

It's kind of striking how that joke post about ed (from 1991) presented Emacs as extremely resource-wasteful

https://www.gnu.org/fun/jokes/ed-msg.html

but I guess trends elsewhere were so keen on adding abstractions that now Emacs is an efficient, parsimonious choice by comparison.

GNU Emacs really didn't start until 1984, but I keep thinking it would be interesting to compare Emacs' resource usage to Zed (or Gram). Then I realize I can't be bothered to run either of those long enough to do it.

Compared to VSCode, Eight Meg And Constantly Swapping does sound ridiculously parsimonious in 2026.