Twenty Years (at least!) of integrated development environments

Back in 1987 or so, a small company put together an interesting development tool on the Macintosh called “LightspeedC”, which was later renamed “Think C” for legal reasons. What made this tool exciting is that rather than using a series of ‘makefiles’ and command-line tools for building your application, the development environment was integrated into two tools: a development environment which contained a text editor and a compiler, and a separate debugging tool which was automatically launched when you started debugging your code.

What made all this really exciting was that it was an “all-in-one” environment: while it was not as flexible as Unix ‘make’, if you played within the restrictions imposed by the IDE, you got one-button compilation, one keystroke compile and debug, and the ability to double-click on an error message and have the program automatically put the cursor at the point where the error occurred.

This was revolutionary and influential–though there were earlier IDEs, including an old tool called “Hippo C” on the Macintosh which boasted a similar (though less powerful) integrated environment for developing code.

The key to developing code is the “edit/compile/debug” cycle: the faster and more transparently you can go from ‘edit’ to ‘debug’, the faster you can make changes to your code, and the less code you feel like you have to write between testing your changes. If it takes less than half a second or so from changing some code to seeing if that code works, you can damned near debug code at the same time you write it.

And an integrated development environment allows this to happen: with the old method of a separate editor (vi, say), you would make your code changes, escape out of vi, go to the command line and type ‘ant’ or ‘make’ or whatever, wait for the code to compile–write down the line number (or open up a separate window) where the error occurred, open up vi, change the mistake, exit vi, run make again, start up the debugger tool (assuming you even have one!), run your program–it’s a mess.

In Eclipse, the compile error is shown as you type–so you fix your errors as you make them. And to debug, you press the ‘debug’ button.

I note this because for some strange reason I cannot figure out, even though we have the most powerful development tools on the planet today–tools which even make the goodness of ‘Think C’ look like primitive flint knives and crudely crafted clubs, for some fucking reason I cannot fathom, the code I’m working on is still built using command-line tools and editors first invented in the 1970’s!

There is nothing about our project that cannot be handled in Eclipse or NetBeans or the JetBrains IDEs–yet co-workers who are younger than ‘vi’ insist upon using build methods that are older than they.

Next think you’ll know, they’ll insist upon giving up their cars and commuting to work by horse-drawn wagons.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s