Oliver Steele observes a significant division among programmers: the Language Mavens vs. the Tool Mavens. I want to reflect upon this distinction, and use it to make a point about the nature of programming. You see, for a long time I was a Language Maven, but now I am a Tool Maven.
I used to be a control freak and an abstraction junkie. I gloried in constructing perfect and beautiful abstractions. I carved out the deepest and hardest parts of a system as my domain. I was exceedingly proud of these intellectual triumphs.
The last thing I wanted was anyone or anything getting between me and the code. I needed to micro-manage everything to ensure perfection. Programming tools and methodologies were for the weak-minded. IDE’s might be fine for beginners, but they seemed to me like incompetent assistants: hindering more than helping. And there was a bit of pride: accepting help would diminish by accomplishment.
I have slowly come to realize that programming is not an intelligence contest, and that judging code by a mathematical standard of elegance is to misunderstand the essence of programming. The limiting factor in programming is always our mental abilities. That is why some people with the right kind of intelligence are dramatically better at programming than others. But even the smartest of us are still way over our heads most of the time. How else to explain why we constantly make mistakes, and constantly throw away and rewrite code? In retrospect, everything I have ever built could have been done much better if only I had understood it more fully (let he who writes perfect code flame me first). Most software systems are so complex that they exceed the bounds of human comprehension, even if we could freeze them for long enough to study. When it comes to programming, we are all stupid.
This is the Existential Dilemma of programming: how to make rational choices when it is not possible to fully understand the problem. Programming is about learning how to work effectively in the face of overwhelming complexity. This requires humility, and an open mind. We have to listen carefully to what the code is telling us, not beat it into submission with brute intelligence. Strategy is crucial: we have to pick the right problems to attack in the right order, realistically assessing our limited knowledge and capability. Simplicity, flexibility, and usability are more effective than cleverness and elegance. Wherever possible, we need to use tools and tactics that leverage our limited powers.
Nowadays I will take all the help I can get. Modern IDE’s like Eclipse handle some of the inane, repetitive details that I used to obsess over. I love automated refactorings, especially the way they let me treat design decisions as provisional. I am grateful for all the assistance in visualizing the structure and meaning of code. Anything that offloads cycles from my brain is a win. I have put aside my beloved Emacs macros. More and more programmers are likewise crossing over. Here at MIT, Eclipse is now the standard tool in the capstone Software Engineering class 6.170.
I am more interested these days in tools and libraries than the power of a programming language. In fact I find some kinds of power actually counterproductive, as in the excessive mathematical abstraction of languages like Haskell. Abstract thinking is hard, and we should carefully budget it, rather than wallowing in it.
Thus is my transformation into a Tool Maven complete. My research is essentially about seeing what happens when a Tool Maven is allowed to design a programming language.