Ide Instead Of Editor

Some people just can't believe that some other people still use editors and shells. VisualStudio or the various smalltalk browsers/inspectors/diagrammers allow them to move smoothly over the code, learning and changing and debugging as they go.

Other people find they can do all these things with an editor and a shell. For them, an IDE feels like a straight-jacket. Their editors give them the ability to hot-key to declarations and uses of methods, to trigger compiles and debug sessions, to move smoothly over the code, learning and changing and debugging as they go.

Which groups of people are right? Neither of them! Use the tools you know in the way that makes you happiest, and you'll get into the MentalStateCalledFlow. Once you do that, the choice of tool is entirely irrelevant. Anyone who says different is selling something.

Saying "tools" and "editor" in the same sentence is pretty weird if you are talking about Smalltalk. The Smalltalk environment lets you write code in the debugger. If you don't know how to write code, you just put a breakpoint there and when the situation arises, up pops a debugger. You can inspect all the objects, even drawing pictures of them if you have a diagramming inspector from HotDraw or the Object Explorer. You can not only look up the stack to see how you got here, you can look for all senders of a message to see other ways you might have gotten here. You can look for all objects that point to the object you are inspecting. "Editing" is the least of your worries, and the least of what the programming environment gives you. When I am programming, I spend 10% of my time editing code, and the rest reading and learning.

An IDE is merely a linkage between tools. Most of the debate seems to be about how well specific implementations provide this linkage.

I personally find that automatic linkage between a compiler and editor is very helpful. Cross referencing line numbers from compiler errors to line numbers in files was always a problem; one quickly learned to fix problems from the end of the file to the beginning in order not to change line counts.

I personally find that automatic linkage between a debugger and and editor is very helpful. Using link maps and compiler listings to determine where to set a break point and then doing the reverse mapping when a problem area was identified, and quickly left one's desk buried under print outs that one hopes he labeled correctly and is working with the most current version.

I personally find that automatic generation of make files is very helpful. Maintaining dependency lists by hand was always difficult and unreliable; one quickly learned that if a sufficiently strange problem arose, it was better to do a full rebuild than to spend any time on debugging an iterative build. This problem has not been fully eliminated and the reliability of the automatic dependency check system varies greatly with the supplier.

I personally find that automatic linkage between a file search and editor is very helpful. It is simply easier to double click on a find hit and have the editor open the correct file and scroll to the correct location. The problems due to editing changes noted between the compiler and editor also apply. Refactoring tools are even more helpful but seem to have reliability issues at present.

I personally find it frustrating that JUnit is not automatically linked to the editor. The tool provides a nice visual calling tree leading to an error, but I cannot double click on an identified problem, instead I must go to the editor, open the file and count lines. I end up rerunning a failed test when I forget and close the tool and determine the initial location I looked at was not the culprit.

Your wishes have been granted. Just use Eclipse.

And remember, UnixIsAnIde.