Building Working Code
Every so often, I run across a manifesto that captures something I know about programming, but couldn't quite express before I read it. That was true when I first read the Ion Window Manager Manifesto, and struck me again tonight when I read the Sepia Philosophy:
A development environment should support three activities: code spelunking, interaction, and customization. Emacs as an environment for developing Emacs Lisp thoroughly supports all of them: It has commands to visit individual functions' code and documentation, commands to evaluate or step through expressions, and an architecture that encourages customization in Emacs Lisp…Modern IDEs also support these three activities, but do so awkwardly. Rather than having functions to visit definitions (find-function) and search for functions (apropos), they clutter the screen with class and file trees. Rather than supporting interactive evaluation of small pieces of code, they perform background semantic checking on whole projects and highlight errors. Rather than allowing minor customizations to grow organically into features, they support limited configuration files and baroque plug-in APIs. Sepia tries to adhere to the apparent Emacs philosophy that rich semantic information should be unobtrusive, and that the best way to build working code is to start by experimenting with small pieces.
The idea that the best way to build working code is to experiment with small pieces has been a philosophy I have followed for years, but I'd never seen it captured so eloquently. I thought it might be worth sharing, especially for folks that have an interest in the REPL way of programming, but learned using a modern IDE that doesn't support the REPL style.
