My Lisp Experiences and the Development of GNU Emacs (2002)

The principle of writing a fast core in C, and choosing a Turing-complete language as the language to build the tool, and further giving the user an interpreter so that (s)he can extend it, is a brilliant design. Whether or not you are a Lisp fan or an Emacs user, this is a great way to build a sophisticated tool. While the unix tool philosophy is to do one thing and do it well, Emacs shows that it is possible…

"They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off." That bit really jumped out at me, because it's something I've felt about computers in general for a long time. People get it into their heads that computers are hard/complicated/etc., and so they get scared of them, and so then they don't do anything with them but a…

Emacs is the first and probably best proof that you can write fast and responsive software without needing to stick close to machine code the whole time. It's a compelling counterexample to those who don't believe you can write "real" software in Python or Ruby.

The interpreter we wrote in that actually wasn't written for Emacs, it was written for TECO. It was our text editor, and was an extremely ugly programming language, as ugly as could possibly be. For proof, see the source code here: http://pdp-10.trailing-edge.com/mit_emacs_170_teco_1220/inde... It is certainly heavily annotated for good reason.