The words IDE and editor are frequently and mistakenly conflated. The differentiating factor for editors and IDEs is functionality. While an editor, such as Notepad++, Emacs, NEdit or VI, enables you to compile and manipulate plain text, an IDE goes much further.
The code insight alone that an IDE brings to the programming process elevates its functionality above that of a simple editor. Some text editors include basic code intel (such as calltips and autocomplete), but none have the refactoring and profiling depth of an IDE. The ability to interpret and profile the code as it compiles, providing visual cues to identify various classes, functions, and variables on-the-fly is reason enough for many to choose an IDE; however, the rationale for choosing the IDE route goes deeper still.
While your common or garden editor is great for writing code, it does nothing to help you with the bulk of your work, AKA as testing and debugging. IDEs integrate your editor with your compiler and debugger to detect and triage errors and prevent bottlenecks. While this function is not infallible, it is certainly easier and faster than manual debugging, which makes this seemingly never-ending story easier to tackle.
IDEs offer collaboration possibilities that provide the means to share data-flows over encrypted peer-to-peer connections. For developers working in teams or for those occasions when you simply need the advice or reassurance of a trusted colleague or friend (who hasn’t been there!) this is an attractive incentive.
Unclean, Unclean!
While IDE users are a large and loyal group, there are many emphatic detractors, who denounce IDEs and champion a return to more basic manual code development techniques and tools.
Amongst the naysayers are those asserting that IDEs are somehow less than their compiling forebears. Less pure, less real, less attuned to the complexities of the process. These programming puritans advocate wresting control back from the jaws of the IDE. They eschew the luxuries of autocomplete, version control integration, and dependency importing in favor of getting down and dirty to develop your own code and coding processes.
They argue that IDEs are more of a Swiss Army knife than a focussed development tool and that over reliance on visual designers and intellisense features diminish your coding skills and experience. Analyzing and fixing your own syntax and semantic errors, they suggest, strengthen your programming prowess.
Bruce Maxwell, Professor of Computer Science at Colby College, explained his problem with IDE integration:
I’ve watched student after student come to the same conclusion that editing the text file is faster and easier and more precise…It comes down to this: you can create nice, general graphics tools that will let you do a certain set of tasks in a certain design space. But as soon as you have a specific idea or concept or need that falls outside of those tasks or the design space, or you want more detailed control, you fall back to the most general tool of all: a text editor and a programming language.
Conversely, you could argue that only the more confident and adept programmer should use IDE’s. Much like the young mathematics student who must learn to go it alone without the aid of a calculator, the less-experienced programmer should learn to execute their own code and navigate the perils of scripting errors without any buffer — the ‘if you don’t make mistakes, you don’t make anything’ argument. Perhaps it is only then that they should consider using an IDE.
Others point to the problem of bloat. IDEs are typically big brutes. They hog memory, are slow to load, and can be so packed with features that they are difficult to navigate. Those who leave their systems in perpetual sleep mode to avoid wait times often complain that their operating systems become slower over time.
Crashes is not uncommon when dealing with complex and powerful IDEs. Minor exceptions in your own code can cause a program to hang and exit, requiring a scrub of metadata and starting from scratch.
There is also a cost element to IDE commitment. Depending on your choice of language, you may have to buy expensive packages that present a steep learning curve, demanding large quantities of your time.
Zen and the Art of Compiler Maintenance
So, are IDEs dumbing down our code? Are we too reliant? Should we return to nature?
Ultimately, whatever your background, level or perceived level, or expertise, IDEs are a personal choice. If you prefer to manipulate your binary and hexadecimal numbers manually, then good for you.
If, on the other hand, you choose to use an IDE because it makes you more productive, gives you peace of mind, frees your creative impulses so you can focus on the bigger picture, then fantastic! No shame in that!
In an industry where change occurs by the zeptosecond (yeah, that’s a thing!), it’s impossible to compete at every level and get in front of every trend. The person next to you may hit on the means to reach your intended goal more quickly and with greater ease. That’s how the cookie crumbles. In the end, It’s all about momentum, whatever keeps us driving forward and gives us the confidence to stay in the game, whether that be IDE, VIM, or going back to nature, make your peace with your choice and push on!
