Ryan Tomayko’s post about Unicorn is one of my favourite pieces of the past year. He’s spot on the money that despite all of the change in the past several decades of systems development, idiomatic use of the Posix APIs will still carry the day. And it got me to thinking about the differences between the (majority of) the Ruby / Python community and how it contrasts to the PHP / Java community in terms of embracing idioms and striking a balance between tools doing too much and too little. I’m christening this concept tooling impedance.

What we do as developers today isn’t any different than how developers worked twenty years ago. We still create text files that get parsed and transmogrified by a compiler (or an interpreter, but that’s immaterial to my point). We still write code and work with relation to a filesystem. While we’ve graduated from linear style to a nearly universal embrace of objects, the way we actualize these concepts is still file-and-compilation-unit-centric.

Despite the seemingly immutable nature of our code, there has been an explosion of IDEs over the past decade or so. As a consequence, the complexity of tooling relative to code has risen far above what it once was. I’m not suggesting that we all need to go back to using ed to get things done, but I think it’s certainly worth taking a step back from the tooling landscape before we suffocate underneath IDEs.

I remember Reg Braithwaite’s excellent talk at RubyFringe a number of years ago, and one of the quotes he offered up therein:

“All problems can be solved by adding another layer of abstraction, except the problem of having too many layers of abstraction.”

I defy anyone out here to try and extend Eclipse without writing any code. As an IDE, it presents so much abstraction between the screen and the filesystem that it’s often not always even clear which file you’re operating on. An IDE that ‘helps you’ by abstracting away the fundamental metaphor of development is doing you a tremendous disservice, all the more so if it’s coddling you into believing that those metaphors are dead. Introducing this kind of impedance mismatch into the development cycle may help you as long as you’re inside the walls of the IDE, but find yourself outside those walls, and you end up having to recreate those abstractions on your own.

Fuck that noise.

Whether or not vi / emacs / TextMate is forever isn’t at all important. What is important is that they all treat code as text, and not some heavyweight abstraction. Whichever one you choose (and just to be clear, it doesn’t matter), they’re all superior to IDE’s because they don’t try to punch above their weight. There’s zero impedance mismatch between your editor as a tool, and your code as text. Understanding comes from clarity, and you can’t have that if you can’t see what it is you’re doing.

I’m sure people will point out that this is regressive, that this is the ranting of a crotchety old man averse to change. Horseshit – I’ve delivered actual, real products in both Eclipse and XCode bigger than anything you’ve done this year, and I’ve spent enough time with both of them to know that they’re both trying to do too much. They’re both trying to keep coders away from code, which is so patently wrong I don’t know where to begin (in fairness, Eclipse is much more guilty of this than XCode).

In the end, I think Ryan’s original post is dead on. In 30 years, smart people will still be solving hard problems using fork(2) and exec(2). I’m just pushing that statement out further, and saying that if Posix calls are still around, then text will still be king. And if text is still king, then the humble editor will still be around, long after your vaunted IDEs and code fashions de jour have passed into antiquity.