“Literature about Lisp rarely resists that narcissistic pleasure of describing Lisp in Lisp.” — Christian Queinnec, Lisp in Small Pieces
Applying software development tools to themselves has a dark side and a light side.
There’s a danger of becoming obsessed with one’s tools and never getting around to using them. If it’s your job to cut down a tree, there’s some benefit to sharpening your ax, but you can’t only sharpen your ax. At some point you hit diminishing return and it’s time to start chopping.
But there are benefits to self-referential systems, such as macros that use Lisp to generate Lisp, or writing a C compiler in C, or using Emacs to tweak Emacs. There’s a kind of consistency that results, and there can be a compound return on effort. But as with writing a recursive procedure, there has to be a base case, a point at which you stop recursing. Otherwise you go down the black hole of becoming absorbed in your tool and never using it for work.
Even though I’ve used Emacs for a long time, I’ve never understood the recursive fascination some people have with it. For example, part of the elevator pitch for Emacs is that it’s self-documenting. You can pull up help on Emacs from inside Emacs. But you can also type your questions into a search engine without having to learn an arcane help API. What’s the advantage to the former?
For one thing, using Emacs help inside Emacs works without a network connection. For another, you avoid the risk of being distracted by something you see when you’re using your web browser. But the most subtle benefit is the compound effect of self-reference. You can use the same navigation commands in the help system that you can when editing text, you can execute code snippets in place, etc.
When I hear “Isn’t it cool that you can do X in X?” my first thought is “Yeah, that sounds cool” but my second thought is “But why would you want to do that? Sounds like it could be really hard.” I’m starting to appreciate that there are sometimes long-term benefits to these sort of recursive tool uses even if they’re not optimal in the short run.
“Otherwise you go down the black hole of becoming absorbed in your tool and never using it for work.”
This is acceptable in retirement.
An emacs user’s typical day:
9am-1pm configure emacs. 1-3pm lunch. 3-5pm post in emacs chats, forums.. 5-6pm code.
Of course, if your entire world is one long tool chain, you can easily change things at a low level, so you can easily break things at a low level. I think of it like when you shoot yourself in the foot you can also destroy all of your DNA. Or, as James Mickens once cried “I have no tools because I’ve destroyed my tools with my tools”.
EMACS has a built in help system for historical reasons. It started out as a TECO macro on the PDP-10 running ITS. TECO was an obscure language originally for editing paper tape, and all its commands were a single letter, but it rapidly accrued new commands thanks to a rapidly growing set of modifiers. The documentation was the TECO order, a list of all the commands in alphabetical order which was built using a TECO macro. They added “real time” mode to TECO for screen editing, and it wasn’t long after that EMACS was born with TECO underpinnings and TECO as its extension language. At some point, the documentation system was added to help users navigate the byzantine mess. Since it was implemented within the EMACS system, there was a fair bit of flexibility. One could find out about a particular command, look for an appropriate command using a keyword or peruse a keyboard action table.