I recall a Microsoft magazine ad from the mid-1980’s, back when Microsoft was best known for the compiler. The ad was four pages long. The first page said that their new development environment had the three things every programmer wanted. I didn’t use Microsoft tools in any case, but when I looked at that page, I immediately thought “I only want one thing from my development environment: I want it to be faster.” The “three things” were on the next three pages of the ad: they were speed (of compiling the program), speed (of debugging the program), and speed (of the generated code). That was an ad writer who really understood what programmers want.
I’m a long-time emacs user and I’ve never used a more integrated development environment. I played around with Eclipse a few years back and at the time it was slow. In emacs I turn off font-lock mode because it is slow. When it comes to writing code I want to be able to just write.
Of course Eclipse, and font-lock mode, bring another advantage: they make it more likely for your code to be correct as you write it, since they can point out typos right away. I typically don’t find typos until I compile the code. So I definitely see an advantage to using an editor which parses your code as you type–as long as you never have to wait for it.
Speed of compilation is still an issue, at least with C/C++. Using a compilation cluster is easy with distcc, as long as you have a few machines to run compiles on. You’re still limited by how long it takes the largest piece of your program to compile, which can easily be 30 seconds. And of course the link time is serialized, although I have ideas on how to speed that up. The ideal compilation time should be no more than a few seconds–short enough that you don’t switch onto another task. I have not used Eclipse for Java development, but I gather that compilation can be very fast. I hope that Tom Tromey’s work on incremental compilation can help with C/C++.
I don’t personally find that speed of debugging is much of an issue for me these days. The debugger is not the first tool I reach for to find problems in code, and when I do, I normally find that gdb is fast enough.
Speed of development is one of the big advantages of the interpreted languages like Python. There have been interpreted environments for C/C++ in the past, trying to provide the same development time benefits while still permitting fast execution. None of them have caught on, and these days a development environment will only catch on if it is near zero-cost. I’ve never used one, so I don’t know what it is like.
In any case, I still fully agree with that old Microsoft ad: the only way to judge a development environment is by how fast it lets you write code, by how fast you can debug the code, and by how fast the program runs. Any bells and whistles which aren’t directly related to making things faster are irrelevant.
Leave a Reply
You must be logged in to post a comment.