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.
I use vim, because I like simplicity. Anything that moves my hand to the mouse is performance lost. I really have no vim tricks other than copy-and-paste, but it still ends up being far superior to gedit, once I pass a certain threshold of experience.
I admit to not having tried Eclipse, and I agree that better tools would be helpful, especially in content creation. We talk of the glories of XML, but it’s far too verbose for most text editors, and even if it wasn’t, any data structure is best explored in a tree view. Note that I didn’t say “visual” — I might actually like a filesystem-like representation better under most circumstances.
Software systems are too complex? Not really. Most of the time, the actual complexity of a system far exceeds the required complexity. This is why the Open Source community has repeatedly beaten Microsoft in raw speed when doing the same thing. I would rather make abstraction easier, because that is how you avoid too much complexity. For proof, do something on your computer — anything — and reflect on how that abstract thing you just did resulted in a massive amount of complexity behind the scenes, none of which you had to be aware of to do it.
I also would agree that text isn’t really necessary. Yet, throwing it away because it isn’t user-friendly might be a mistake. Remember — vim is harder to pick up, but faster and easier to use, than gedit. I would argue that a programming shell is harder to pick up, and sometimes harder to get started with, but ultimately more efficient to use than a spreadsheet. Same with the /etc of Unix vs. the Windows Registry — it’s faster for me to edit things in /etc, but not just because of how poorly the Registry is organized.
If you want to “liberate” programming (or anything) by making it easier to pick up, don’t alienate those who already know it by making it clumsier to ultimately use.
Since the advent of the World Wide Web, I’ve come to regard programming for desktop computers as kind of boring. I’ve spent the last few years since graduating from college learning (mostly) non-programming skills to keep myself employable. I’ve come back to programming in the last year with a focus on the web, first updating my circa-1998 HTML and CSS knowledge and now moving on to dynamic generation of static pages using PHP. After that I’ll be learning JavaScript to create dynamically interactive pages, then learning to tie JS and PHP together so that interactive pages can have dynamic access to back-end data. I’d be using Ruby on Rails for this if I had my way, but PHP adoption is much higher and adoption == employability.
I say all this as lead-up to this question: When, if ever, do you see your concept of language-as-tool coming to the Web?
I personally can’t see it happening given the Web’s highly heterogeneous nature — a language for document content, a language for document layout and style, a handful of languages for server-side scripting, and SQL for back-end databases. Can you see this ever being cleaned up into a more unified development platform? The wild, constantly-evolving mess of it all can be thrilling, but it’s often frustrating as well.
[Adam – yes, web programming is quite an amazing mess, isn’t it? Ruby on Rails and Zope have gotten some traction, so perhaps progress is still possible. My own research is very long-term, and I hope only to make a difference when the next big thing happens. — Jonathan]
“I use vim, because I like simplicity. Anything that moves my hand to the mouse is performance lost.”
Why do some people think that souped-up IDEs and user interfaces require their users to have a mouse to get things done? I like to have all the features I can get in my IDEs and other tools (programming-related or not), but that doesn’t mean I always have one hand on the mouse.
In fact, when I’m coding I’ve got both hands on the keyboard most of the time. Just because there’s a toolbar button for something doesn’t mean I have to use it. I have all the most important features I use hooked up to keyboard shortcuts to avoid using the mouse, and Windows keystrokes like Alt+Space,N (minimize), Alt+F4 (close), and Alt+Tab are second nature to me.
If you don’t like GUIs because they force you to use the mouse, you are misguided: well-designed GUIs allow you to do your work with the keyboard whenever possible.
Of course, more and more the keyboard is being sidelined, but it doesn’t have to be that way. It IS possible to have a rich GUI and a rich keyboard interface at the same time.
Point taken, that “math-ey” code is not the ideal (.. no pun intended). And yet, what is refactoring other than a mental manipulation of a mathematical mind-construction? A good refactoring has the feel of a Fourier transform, or Stoke’s Theorem. All the lumpy crud magically melts away — to be replaced by a new mental state with much less internal tension and a much more compact surface. I dare say it’s like turning blown tires into volleyballs.
I love vim too, because I also don’t like moving my hands off the keyboard, but you can have your cake and eat it too. Eclipse has vi keybindings for something like 20 bucks. Frankly, I would have a hard time hiring someone that insisted on using vim for java programming – maybe C/C++.
I use Vim because of its powerful comand set and i use ruby on rails so i like vim.