Why I Don’t Like IDEs

I was recently reminded why I don’t like integrated development environments (IDEs). I was curious about trying out a Smalltalk IDE.

It was packed with features and it was hard to make sense of where I should even start. I had to read some documentation. This is where I got reminded of a problem with learning complex graphical user interfaces.

Reading a description of how to operate a GUI is cumbersome. One typically needs a visual guide. In fact a video proved more effective.

Video’s serve a purpose, but unlike written documentation they are much harder to scan or search for particular topics or interest.

We can contrast this with a text based or terminal based interface. Say I want to add a package of a particular name to my project. Using a text based REPL environment in e.g. Julia I could write:

julia> using Pkg

julia> Pkg.add("Foobar")

In contrast if I was adding a package in a GUI environment I would have to know navigate to the area where dependencies are added. Then click an add button and locate the package I want to add.

Describing this process to people know exactly what to do will typically require quite a lot of text combined with pictures.

Meanwhile the textually oriented solution can be replicated by a simply copy-paste from the blog or documentation document describing it, into the REPL environment.

Not to mention that, if you want to automate this process by say adding multiple packages, that is fairly straightforward.

A GUI does not naturally lend itself to automation.

When to Use a GUI

The whole appeal of a graphical interface is that the operations you can perform at any given time are visible and easily discoverable.

However this advantage crumbles as soon as you make a GUI very complex. At that point it is no longer obvious how you do things. Instead you will need extensive training to operate the GUI.

And the training doesn’t really have a lasting benefit. For a sufficiently complex UI, you will struggle to relocate important functionality later.

That is the reason why I think the benefit of graphical user interfaces primarily exists for low to moderate complexity.

Once complexity grows, a command-line based interface starts to have advantages. Yes, you will need some initial training to get started, but since that is required with a complex GUI as well, that does not count against it.

Inflexible Monoliths

So may issue is not graphics user interfaces, but the usage of complex interfaces, which try to do too much.

Let me give some examples. XCode and its NeXT precursor used to be composed of multiple specialized applications. GUI design was e.g. done with an application called Interface Builder. The fact that it was a stand-alone application mean it was tailored towards communicating with external applications and being launched by external applications.

Other development environments not made by Apple utilized this. They would use Interface Builder as part of their toolchain.

When XCode became fully integrated, this opportunity mostly evaporated.

We see this problem with IDEs if we compare AppCode from JetBrains with XCode. Neither company is trying to provide single purpose specialized tools. Instead they want monoliths which dominate their world.

The problem is that while AppCode is good at code completion and refactoring it is pretty bad at a lot of the other things XCode excel at such as GUI design, debugging and profiling.

If both Apple and JetBrains had offered smaller separate tools developers could have mixed and matched what they liked. Instead they got two monoliths which both wants to be the boss. I cannot speak of the current experience, but last time I ran both, I found it to be a somewhat messy experience.

The problem with integration is that you increase complexity. Instead of say GUI design, code editing and version control being separate tools, you clutter the interface by needing menu entries and buttons to deal with all of them.

It is much easier to orient yourself with separate tools. Once you switch to a GUI designer, you know all the menu entries and buttons you see in the interface is related to GUI design.

Switch to a Git GUI client and you know everything you see is related to version control.

With an IDE all of this functionality is usually woven together increasing complexity.

It also reduces reuse. Say you use XCode to develop an iOS application. You learn to use the XCode code editor and Git client well. But now you switch to a Java project and XCode is no longe usable. Your XCode editor and Git skills don’t carry over.

If instead you had used a generic code editor and a generic Git GUI client, your skills would have carried over, as they would not have been tied specifically to building iOS applications.

Negative IDE Anecdotes

One of the accusations against many of us that don’t like IDEs is that we have never really tried one. We are all just a bunch of unix neckbeards that have been stuck in Vim of Emacs forever. In fact I don’t use either of those editors. I actually like having a proper GUI, so I use TextMate.

I am well aware of the the advantages of IDEs, and it is not like I don’t use them. I would use XCode if I was doing iOS development. Rather this is about my philosophical objection to them, and why I prefer not using them when that is practically feasible.

One of my first IDEs as Borland Builder to make C++ GUI applications for the VCL toolkit. Since none of my later jobs involved VCL that investment in learning the Borland IDE was mostly wasted.

Next came Visual Studio. Again I hardly used it in the next job since I found source code searching on Windows too slow at the time and switched to Linux.

Next came Eclipse. But who uses that today? I spent a fair amount of time with Qt Creator. Pretty decent IDE IMHO since it is pretty quick to learn and normal workflows are well optimized.

Still when switching to iOS development it had no value. I had to use XCode.

So over several years I have kept switching IDEs and had very little reuse of skill invested in them. All too often they act as little islands for particular technologies and languages.

Through most of the period where I went through Visual Studio, Eclipse, Qt Creator and XCode, I used pretty much the same code editor, TextMate. I used TextMate for writing Ruby, Python, Go and Julia code. As well as LaTeX, Markdown and occasionally HTML.

In other words I have gotten far more mileage out of a more generic code editor I have used than any IDE I have ever used.

What About Code Completion and Code Navigation?

It is a common misconception that generic code editors don’t offer code completion or code navigation.

Emacs and Vim have used ctags and similar systems for decades to support code navigation.

Usually there is a great variety of plugins that support command completion. And most editors support completion based on existing words in the source code file. Frequently I prefer this kind of completion.

For languages such as Julia, where REPL development is often a focus, code navigation and code completion would often happen from the REPL.

And this is usually better than code navigation based on static analysis of code. E.g. from the Julia REPL I can jump to definitions of functions which was made through code generation.

Text vs GUI

GUIs make it easy to discover functionality given that complexity is low. However if you need automation or complexity is high then text based interfaces often begin to shine.

Text is malleable in a way a GUI isn’t. Text can be searched and edited with generic tools. GUIs cannot. If I need to change a large number of project settings, then a text editor can help me do this with a regexp substitution.

A GUI will usually force me to manually update one item at a time.

It is not without reason that whenever software offers a GUI interface and a command line interface to similar functionality, then the command line interface is usually much richer with more options.

E.g. the shell will usually offer far more operations on files than a graphical file manager. Likewise the git command line tools are usually much richer in functionality than a Git GUI client.

The reason is simple: Command line tools handle growing complexity better. GUI tools shine while complexity is kept low.

Summary

The alternative to using an IDE is to use a collection of more generic tools. The benefits of this is:

• More flexibility in mixing and matching the tools you prefer.
• Ability to reuse the same tools for more projects.
• You knowledge and skills don’t become obsolete as quickly.