There is much, both positive and negative, to be said about IDEs. Over the years, this page will likely grow considerably, but for now it only deals with one sub-issue—that IDEs segregate more than they integrate.
Since writing the first version of this page, in 2012, I have had less and less contact with IDEs. (In part, because of a switch from Java to PL/SQL; in part, because of a lengthy sabbatical from IT.) As a result, the prediction about growth has been put on hold. What the future will bring is yet to see.
While I strongly suspect that the main claims continue to hold in (now) 2023, or that the situation has grown outright worse, I do not rule out that things have improved “in my absence”. (And, certainly, some of the more detailed claims might be outdated.)
A particular potential issue is that what can be done in (more or less) real time without e.g. holding a pre-compiled code tree in memory does change over time, through faster processors, SSDs, and whatever new technologies arrive. This could, in due time, render parts of the discussion moot.
IDEs promise to integrate various tools and capabilities into one tool, making it unnecessary to work with several-to-many individual and incompatible tools. For someone knowing only heavily GUI-centric environments and the usual “isolateed application” philosophy that accompany them, this might even be an improvement.
However, for someone used to traditional Unix and Unix-like environments, where interaction between tools (preferably, tools written according to principles like “small is beautiful” and “do one thing and do it well”) is a main concern during development, the opposite is the case:
He already has an IDE—the command line. Here more-or-less any tool could be combined with more-or-less any other tool to do more-or-less anything that one might conceivably want to do. The traditional command line is an environment of extreme cooperation, which integrates the capabilities of all tools in a highly user-friendly manner (once a certain conceptual threshold has been overcome).
Why “traditional” and “could” instead of “can”? Sadly, the mentality demonstrated by e.g. Microsoft has grown increasingly common even within the Unix-verse and even with many FOSS tools—and the more so with FOSS tools that originated outside the Unix-verse or that cater mostly to users outside it.
The typical IDE, however, builds barriers: There is the inside and there is the outside. Tools from the outside are given little or no heed, and their abilities are lost. Eclipse (the IDE with which I have the most experience) is positively hostile to external applications, and assumes that each and every file of a project is actually loaded into memory within Eclipse at any given time. Integration of other tools is made over internal plugins (which are often limiting and error-prone) and a restricted ability to start external tools from within Eclipse. The latter alternative is very limited in its possibilities of interaction—and interacting with an external tool not started from within Eclipse is a big no-no (which is not to say that the prescribed way automatically leads to success).
For that matter, to just start a typical IDE on a random file and do work on it, as is standard with any even remotely typical text editor, is often impossible. Instead, the files must be part of a “project” (or the same concept under some other name), which increases overhead and puts great limits on where in the file system a file may reside before work is possible.
The effect is that most of the existing Unix environment (and its possible future extensions) is lost, blocked out by the segregating walls of the IDE. Similarly, new functionality of various kinds brought by the IDE is lost to the outside—other tools cannot use it.
Indeed, within the paradigm of extensible IDEs (like Eclipse), it is not possible to just take a nifty new tool and provide it to the world—allowing anyone to interact with it. In particular, it is not the IDE (the prospective benefactor of the tool) that adapts to the tool. Instead, the toolmaker is forced to provide separate plug-ins for each and every IDE that he wants to support—a reversal of both responsibility and workload. Often, the toolmaker does not even bother to provide a detached tool + plug-in, but simply writes a single plug-in for a specific IDE, relying entirely on the IDE and locking the tool to that IDE.
There are interesting parallels to e.g. Facebook: Instead of building constructively to expand the Web (or, more generally, the Internet), a part of the Web is walled off to form its own universe—partially in an inferior manner, partially while re-inventing the wheel, partially while providing “local” functionality that, with another approach, could have been made globally available. Indeed, like many IDEs, Facebook brings the additional issue of being tied to a proprietary product.
Ditto e.g. KDE: Instead of writing a tool and giving it an optional KDE-based interface, tools are written to be part of KDE—period. (Particularly negative, and particularly against the Unix philosophy, as it also shows a great lack of separation between GUI-concerns and functionality-concerns. From a 2023 perspective, the issue can be extended to the XDG/“freedesktop” bullshit, which infects and limits applications everywhere.)
It might seem tempting to see a commercial explanation, that the makers of an IDE deliberately want to block out others in order to maximize profit (or similar). For commercial makers, there might well be something to this, and it does match a behavioral pattern of many commercial businesses elsewhere (and not restricted to software). IDEs are not necessarily commercial, however, and Eclipse is (at least nominally) not.
On the other hand, it is by no means inconceivable that even a non-commercial software maker is obsessed with e.g. market share, and I would not rule out that such thinking is present in some corners.
Note that this attitude is worse for non-commercial software: With the commercial makers, it is user-hostile and arguably an unethical business practice; however, it is at least compatible with the natural goal of making money. Non-commercial makers, on the other hand, should be set on creating the greatest value possible—and this attitude is in direct opposition to that goal.
Another idea could be to remain as platform-agnostic as possible, e.g. in that a particular IDE should behave virtually identically under different operating systems and other environments. While this might or might not be a good thing for the IDE-specific functionality, it is a bad thing when extended further. Good software should enable, not disable, and it is not legitimate to restrict the user in things that he might legitimately want to do. For instance, that an IDE-internal debugger behaves the same, to a high degree of approximation, under Linux and Windows can be a good thing, but if work with external tools is limited because “This Linux call would not work under Windows!!!”, then something is very wrong.
The “might or might not” largely goes back to a conflict of philosophy: Should a certain software behave the same on all platforms or should all softwares on one platform behave the same? (Consider e.g. “look and feel”, conventional keyboard shortcuts, conventional menu construction.)
I have no settled opinion on the matter, but would tend to favor the former, especially when software is involved where users are likely to rely on certain behaviors. The latter applies strongly to e.g. Vim, where users could be entirely thrown and require extensive re-learning, should the behavior change in a non-trivial manner with a change of OS—and extremely strongly to most non-interactive tools and scripting languages. It need not apply to e.g. IDEs and browsers, however. When it comes to Unix-verse tools, an additional argument is that the main reason to install them on Windows is to partially recreate the Unix-verse experience, and a change of behavior from OS to OS would be highly counter-productive in this regard.
Nevertheless, my two main suspicions go elsewhere:
Firstly, sheer convenience, in that it is easier for the IDE developers if they do not have to bother with issues like synchronisation, communication, and whatnot, but can simply pretend that the rest of the world does not exists.
Secondly, good old-fashioned incompetence—especially, through a lack of experience with more flexible, cooperative, and/or truly integrative approaches.
The informed reader will likely ask how to do it better—in particular, considering that many of the functionalities introduced by IDEs are new, not necessarily compatible with exchange through text-based pipes, and that many of the things done can be incompatible with existing functionality in text editors. (Text editors, obviously, forming the most central tool category to a programmer—be they separate applications or internal components of an IDE.)
I will not attempt to answer this question conclusively. This, partly, because a great amount of research and experimentation might be needed; partly, because it is not clear that IDEs or their new capabilities bring that much benefit (see excursion). However, a few preliminary thoughts (to be taken in addition to the general philosophy implied above and provided that a “better IDE” is wanted):
An in-memory database with a well-defined and publicly known (preferably, standardized and language independent) interface runs as a stand-alone application and provides any asker with information about the state of the code, including its compiled state, connections between various pieces of code, etc. Such askers can be IDEs, text editors, refactoring tools, and countless others
(Here and elsewhere, I gloss over many details that a practical implementation must resolve, e.g. what access controls might need to be present for such a database. Ditto, whether access is direct or indirect, e.g. through the application from the next item or some other intermediary.)
A second stand-alone application receives information from other components about code-changes, compiles these (possibly in interaction with the database), and then updates the database. This, maybe, in combination with continuous integration or in cooperation with a CI tool.
Editors are sufficiently flexible and general that they can interact with the database to the degree necessary to allow e.g. for code completion, re-factoring, automatic display of errors, and use of various navigational tools and displays (e.g. outlines of methods, caller hierarchies). This either directly or through some unifying/abstracting interface (depending on how standardized the “raw” interfaces to the other components are).
The exact functionality supported need not be the same everywhere: different users have different needs and priorities. The point, however, is that the developers of the editor and/or associated plug-ins now have the ability to add whatever functionality they like. With powerful editors, e.g. Vim, this will apply to the power-users too.
They would also likely be responsible for (automatically or at the user’s prompt) informing the compiler instance of code changes; however, this prompt could also validly be moved to the command line.
Debuggers could conceivably run entirely stand-alone, without even interacting with the above components; however, with some added complexity, they could be integrated with either.
Server processes (e.g. JBoss instances) definitely run stand-alone, being attached to the debugger through “remote debugging”.
My experiences so far are clear: Attempting to run servers within or through an IDE brings very little benefit—but a load of complications, hard-to-find errors, and arbitrary behavior. Should this situation improve very considerably, I might re-open the issue. As is, I strongly recommend even those using conventional IDEs to go with remote debugging.
This with the reservation that not all languages and whatnots necessarily have the same support for remote debugging that Java and the JVM have.
Version-control tools work directly with the same text files as the editors. They can be used from the command line or activated through a user prompt to the editor.
Other tools will work according to similar ideas (a full listing of all conceivable functionality would be far beyond the scope of this page). I note, in particular, that many tools are already (or could easily be made) able to work on the code over both the editor and the command line—when liberated from the walls of the IDE. (Consider e.g. code formatters.)
It would be quite easy to build an IDE that behaves in a conventional manner (from the users’ POV) once such components and infrastructure exist. This is a core part of my take on software: It is not about forcing users to use/do/whatnot something different than today—it is about building software in way that allows users to do what suits them best. (As opposed to what a narrow minded product manager “knows” will uniformly suit all users.)
Cf. also the most important rule of UI design.
I have often found that IDEs bring comparatively little to outweigh their disadvantages. For instance, the built-in editors tend to be weaker or much weaker than strong dedicated editors—but the editor is the single most important component/tool from a programmer’s perspective. (Also note the common anti-Emacs jibe that “It is a nice little OS. A shame that it does not have a good editor.”, and that the Emacs approach made it a border-line IDE long before there were IDEs. In all fairness, this problem is not unavoidable and an IDE with a truly worthwhile editor is not an impossibility.)
For many languages, tasks, contexts, whatnot, an IDE might even be a net-negative, as with e.g. the writing or editing of a single bash script, where a strong editor (often even a weak editor) is the better choice over an IDE. As a PL/SQL developer, in the time since the original writing, I worked with a mixture of Vim, a command-line SQL*Plus (augmented with rlwrap for better history and whatnot handling), command-line Perforce, and only rarely needed to even start anything graphical, let alone an IDE.
Rare excursions into the graphical included some few Perforce tasks that were poorly supported on the, or inherently hard to do with a, command line.
This limited to core development tasks where an IDE would often be used. Tasks like e.g. reading MS-Word documents from product management are a different matter. (Notwithstanding that some IDEs engage in absurd overreach and that some might well try to handle MS-Word too.)
Even for languages like Java, however, there are limits to the benefits of IDEs, and a contributing reason for their popularity is likely that naive users compare the capabilities of crap like Notepad with e.g. Eclipse, and fail to realize that good editors, like Vim, have many of the core capabilities on their own, most notably syntax highlighting and the ability to invoke external programs to, e.g., call version control tools—as well as many capabilities that, say, Eclipse does not have. Indeed, I would go as far as to claim that Vim could do virtually anything that an IDE could, and in a more user-friendly and more user-adapted manner, if the user invested enough time. (The problem, of course, is that this investment would be unlikely to pay off relative a ready-made, if user-limiting, IDE, which is what gives IDEs a justification.)
The single greatest advantage with IDEs, and the one that I have truly missed during times when dealing with Java in a more editor-centric context, is the ability to do refactoring or, more specifically, refactoring that affects more than one file. Even tasks like code completion and code navigation, however, can be done reasonably well with e.g. Vim, using pre-existing mechanisms. (Implying that the need for the user to invest time is much smaller than for the “virtually anything” above. The “reasonably well” arises from weaknesses like poor context sensitivity that, barring changes since my last look at the issue, would require more time to work around.)
The following is an automatically generated list of other pages linking to this one. These may or may not contain further content relevant to this topic.