Discovery, experience, and interfaces

There was a blog post on StackOverflow published recently about IDEs that was not very good. It has, predictably, with its impoverished quality, generated a lot of response.

Lots of the responses, though, are just as bad. A couple key ones that keep coming up is that GUIs are inferior to text-based interfaces (read: terminals) and that command line interfaces are always faster than anything that requires you use a mouse.

I am a long time Emacs user. I genuinely like it and will happily expound on its ridiculous flaws. I use it remotely on a terminal interface and haven't used the GUI version for some time. I am not attached to the terminal interface; it just so happens to be the most convenient for my current use cases.

With that said, the original article seems to miss the fact that editors like Vim and Emacs can be IDEs as well. I get code navigation, debugging and all that in Emacs without too much effort. It is probably more effort than in an IDE, but it was not too complicated. Should it be easier? Yes, it should. But that discussion is for another day.

Various rebuttals I've seen make the muddled argument that plain text is always better. This is, quite frankly, asinine.

I debug on embedded devices as part of my day job. To do so I use an IDE with a GUI. The ability to view the state of the machine (registers, memory, instructions) while stepping through the code is extremely useful. I'm sure it could be done with an TUI, but I doubt it would be as information dense in the same amount of screen space. I wouldn't object to a TUI, but to my knowledge there isn't one that does the same thing.

I've used GDB to do this before and while it is extremely powerful, it sucks for doing that kind of thing. It can, but that's not the point. The point is that it's worse. Monitoring all the special registers to see what has changed between breakpoints is a pain. The IDE, purpose built for this, is much better.

And claims like "the command line is always faster" are just as dumb. This is pure zealotry. It completely ignores the experiences of others.

In my case, I make this general observation: discovery is better in an integrated environment, focused experience is better in a command line environment. It's not an iron clad rule (making one would be silly), but it holds well with my experience.

By "discovery" I mean a mode where you're not sure what it is you need to do. Debugging is a good example. I know there is a problem, I just don't know where or what it is, exactly. Having high information density and easy navigation while keeping context is of high importance. Exactly how this is done is immaterial. It could use terminals. It could use a GUI with some kind of text command interface. Who cares. As long as it allows for kind of setup that accomplishes the task with minimal friction. For the most part, the more integrated, the better.

Another example is image editing or creation. You probably don't want to do this in an environment that doesn't have timely, visual feedback for the operations you are performing.

File browsing is another. I often idly browse a directory structure or sets of images looking for something without a clear indication of what it is that I need. In this case, icons and pop-up previews are really handy.

Once I know what it is that I'm working with, things are a bit different. After I've learned a code base, navigating on the command line or in Emacs' dired is often superior. I know the paths I need to take from one point to another, so I can jump there. Constantly clicking through folders or menus is adding drag.

Same goes for image transforms. If I know that I need to shrink an image by 50% and rotate it 90 degrees to the right, then it's faster to type the command than fire up most image editors.

Debugging is similar. If I know the code and runtime environment very well, I can fire up GDB, set the breakpoints and run it, looking for whatever it is I need to know. I can even script it.

The key, though, is that I need to know an awful lot before these command line and low information density interfaces become really productive. This is true even when I am proficient with them. The tools alone don't make you fast, it's the knowledge of the environment. Sometimes that environment is unknown, and prodding it with the "fast" tools is actually slower.

The blanket statement nonsense in the IDE article and many of its responses miss this.

-- Geoff (