The Integrated Development Environment
In John Carmack's interview with Lex Friedman. The topic of editors and IDEs is brought up. John critiques silicon valley folks for using minimalistic editors where they have to "keep everything in their head". His claim is many of these folks are expecting folks to just read the code and understand it. He also leans into the idea that individuals of this mindset are anti-debugger.
I understand why this is John's perspective. However, regardless of where you stand, I believe the reality is we're all approaching writing software similarly. Namely, most of us are using an IDE to some degree just how we get there has some variance. So, in this post, I'm going to disect the concept of an integrated development environment and attempt to justify why the choice we make doesn't matter...that much.
Integrated Tools
Let's start by defining the term IDE. Wikipedia perfectly states: "The boundary between an IDE and other parts of the broader software development environment is not well-defined". So, for the purpose of this writing, I'll define IDE as:
A program that integrates tools (other programs) in hopes of making developers more productive.
By this definition, an application where you can type characters, get code completion, and run tests would be considered an IDE. Let's take a look at some popular IDEs:
- Intellij (Idea/Goland/Pycharm)
- Visual Studio Code
- (n)vim
These programs have a lot in common. That is, they come with some baseline functionality and provide addons (plugins) that can provide new functionality. Let's consider the above 3 where we add support for Go and a vulnerability scanner.
Considering the above, the differences break down to:
- What features come out of the box.
- The language/packaging format for loading the plugin.
- Default keyboard shortcuts.
- Configuration UI / language.
- The runtime of the app (JVM, Node, etc).
Historically, there has been a lot more differentiation between IDEs. Especially when it came to language features. In this era, there were specific IDEs that were best at Java, C++, etc. While this was OK, it created a lot of fragmentation as you could end up with N implementations to support language features, not to mention each implementation could be limited in the apps that could use it. Today, there are certainly customizations in IDEs to make them flow better for certain lanuages, but the core-language features and their implementations have become table stakes.
LSP: The Equalizer
The language server protocol (LSP) was
LSP is certainly not perfect. For example, there's a valid critique to be had around the architecture of LSP. For many situations, it feels unnecessary to run a server communicating over JSON-RPC just to get details on language features for files sitting on our local file system. But given the requirements around portability and constraints around interoperability, I get it. Also, if you've ever had to work on standards before that stretched across use-cases/organizations, you know how hard decisions like these are.
So...for the vim users in the back, be sure to thank vscode for making your favorite editor better!
My primary IDE is neovim, so poking fun at myself too 🙂.
Case Study: Neovim
Your Choice
The law of triviality (bike shedding) states:
“…people within an organization commonly or typically give disproportionate weight to trivial issues.” [wikipedia].
As software engineers, I can’t think of a better manifestation of this principle than the topic of text editors, IDEs, and generally what tools you should use. Thus, my conclusion is it does not matter.
Especially for newer engineers, using something that is pre-baked with integrations you need to get work done is best. Frankly, if I had a time machine and went back to re-invest all my time spent learning (n)vim into deepening my programming knowledge, I have no doubt I’d be a better programmer. Over time, if you develop interest in digging into new tools, that’s awesome, just don’t let anyone fool you into thinking it’s going to fundamentally change your capabilities as an engineer.
Have fun, use what you like.
- Folks trying to validate their own choices by talking others into it.
- Hot takes around tools.