[ Go back to normal view ]
BW2 :: the bitwise supplement :: http://www.bitwisemag.com/2
Stone-Age Programming and the Death Of The IDE
Who needs an IDE anyway?28 February 2007
by Huw Collingbourne
IDEs are bloated, they ‘get in the way’, they take the fun out of programming. Real programmers use a text editor and a command prompt. Go into programming forums and newsgroups scattered the length and breath of the Internet and you’ll regularly read these and similar views. It is the new orthodoxy. Just as some people would have you believe that Microsoft Windows is a passing blip on the radar, so too they would have you believe that IDEs are a momentary aberration in programming history.
The bizarre thing is that what is now being championed as though it were a bold ‘new way’ of programming is precisely the way I used to write programs over twenty years ago. Back in those days, my intimate relationship with the command prompt didn’t grow out of a deep sense of affection. I didn’t have any choice in the matter. It was all there was.
This is how it went. First you wrote a program in a text editor (if you were lucky) or in a ‘line editor’ (if you weren’t), then you’d save it to disk, compile it, link it, make a cup of tea, try to make sense of the error messages (the more user-friendly of which might say something like: ‘Error 26456’), load it up into the editor again, fix the errors, save it, compile it, link it, take the dog for a walk, fix the errors, wash the cat, and so on and on and on. It is rumoured that some programmers got married, had kids, got divorced and ran away with the milkman by the time they’d managed to get “Hello world” to work.
Then along came Turbo Pascal. That was a revelation to me. It had a built-in editor, it compiled in the blink of an eye and when it found a syntax error it put the cursor onto the line containing the problem right there in the editor. A couple of keystrokes later my program was fixed, compiled and running. This, I felt, must be the face of the future. No programmer ever again would be forced to do battle with the blasted command prompt.
The cutting-edge IDE, ’80s-style. Turbo Pascal combined an editor, compiler, file manager and syntax-error locator – and all packaged up in a 39K executable! At the time, I couldn’t think of anything more anyone could ever want in an IDE… And then along came Delphi… The Windows-based successor to Turbo Pascal had syntax colouring, a graphical debugger, drag-and-drop widgets and a host of other good stuff. See TurboExplorer
Command And Conquer?
It never for one moment crossed my mind that, one day, people would actively choose the command prompt over an integrated programming environment! But here we are, some way into the 21st Century, and a generation of coders (or ‘hackers’ as some like to call themselves, which is OK I suppose, as long as they don’t call me that too!) embrace the command prompt as though it was the finest labour-saving device yet invented. Not that they have to go through the tedious edit-compile-link-and-run process as we did in the olden days. Oh, no. That’s all been replaced with the far more exciting script-edit-load-and-test process.
Testing is part of the new programming religion. Never mind boring old prosaic stuff like documenting, commenting and debugging. These days, the very modern programmer doesn’t debug as he or she goes along; that’s old hat; the very modern programmer writes tests to try to find the bugs after they’ve already taken over the house and eaten all the cheese. These tests are supposed to check that the program does what it’s supposed to do. If it doesn’t you can either rewrite your program or you can rewrite your tests. I am told that the latter option is often the simpler.
Don’t get me wrong, I have nothing against testing. Far from it. Though, I have yet to be convinced that a running nice, neat ‘test suite’ is any real substitute for letting real live, nasty, messy people loose on your code. You can tell a test suite what to do. People tend to be less cooperative…
Then again, testing – whether it’s done by software or by your Uncle Bert, Aunty Mabel and The Kids - is no substitute for debugging. And in order to do debugging – real, meaningful, easy-to-understand debugging with breakpoints and ‘drill down’ watch variables and step-into and step-over and all the rest, you need an IDE. Oh, sure, debugging at a command prompt can be done – just about. People used to do it that back in the ‘70s and ‘80s. But we grew out of it. It was a horrible phase we were going through and, just like acne, flared trousers and Donny Osmond records, some of us never want to go through it again…
The great granddaddy of IDEs as we know them is Smalltalk. Years before Turbo Pascal, it had a graphical interface, popup mouse menus, bitmapped fonts and multi-window browsers. To say it was ahead of its time would be an understatement. Here is a picture of one of the current-day implementations, Dolphin Smalltalk. In spite of a large number of additions, modern versions of Smalltalk are still building upon solid foundations that were in place over quarter of a century ago…
By now, I’m guessing you should have decided on whether my style of programming is your style of programming. If you’re still not sure, we can sort this out easily. Just answer this simple question: what is your style of programming called, anyhow?
If you came up with a name for it without a moment’s hesitation, I guess you and I can shake hands, agree to differ, and go our separate ways. If you went, “Hmm, well, er, what do you mean exactly by ‘my style of programming’?” then I think you and I can probably be lifelong pals and go to retire in a rose-covered cottage by the sea.
You see, my style of programming doesn’t have any special name. It’s not ‘agile’ or ‘extreme’ or ‘green with blue dots in’. Most of the time it’s just competent. If I’m lucky, every once in the while it might even be the teensiest bit pretty darn’ good. Maybe that sounds dull. Believe me, it isn’t. What’s dull is writing programs that don’t work, delivering them after they are needed and trying to fix bugs that are obscure, ambiguous and undocumented.
In order to write programs that work, get them finished on time and make them maintainable, you don’t have to subscribe to a methodology, buy the right books, use the right buzzwords and wear the right tee-shirts. All you have to do is to work with care and skill. Programming is a craft (you can call it an ‘art’ or a ‘science’ if you insist, though personally I think ‘craft’ is a more accurate description); and any craftsman worth his salt surely wants to use the very best tools available.
Why then, do some people spurn IDEs?
As far as I can see there are two possibilities:
1. Nostalgia
2. IgnoranceI suspect that nostalgia for the good old days of the command prompt is usually felt by those people too young to recall its horrors – the programming equivalent of nostalgia for string vests or carbolic soap. So can an antipathy to an IDE can be explained by ignorance, then? Is it conceivable that the people who most hate IDEs on principle have never tried them in reality? This has to be considered as a possibility. In truth, I find it exceptionally hard to believe that anyone who has developed a C# application in Visual Studio or a Pascal application in Delphi would seriously choose to use a text editor and command line compiler as an alternative. But maybe some of those people who have only ever programmed in so-called ‘scripting’ languages such as Python, Ruby and PHP really haven’t any experience of a good IDE and therefore just don’t know any better?
I suppose I ought to consider a third possibility – though this, I confess, is a contingency so remote that I feel rather foolish giving it any degree of credence. Possibly, just possibly, programmers using ‘lightweight’ editors really are more productive – more ‘agile’ – than those of us who insist on our lumbering behemoth IDEs?
Pah! No, I’m afraid that I really can’t take that proposition seriously. It would be like arguing that a better greenhouse grows worse tomatoes or a better cooker bakes inferior cakes. I’ll agree that good tools are not the sole requirement for good tomatoes, cakes or programs. But, by heck, they certainly help!
Huw Collingbourne is one of the developers of Ruby In Steel – SapphireSteel Software’s Ruby and Rails programming IDE for Visual Studio 2005. As such, he confesses to a strong preference for lots of pretty icons, menus, windows and things that pop up all over the place when you click a mouse button. He does not miss Edlin…
