Arguments against IDEs
martinevald.net
martinevald.net
The reality is that rubymine costs 100/year for personal use, and I pay them with a smile because to me it is worth 10x that price. The reality is that ides can help you hide from bad package management. But package management is but such a tiny portion of code organization. And all editors let you find files by name or jump to definition. Some do it far better than others.
Watch someone use the latest jetbrains platform to see type annotation injection into typescript code. I've seen developers abandon vscode and others once they saw how smooth ides can be out of the box with the coolest features.
In any case. Just my take.
This sort of article fall into a fallacy trap which is failing to understand what "integrated" in "IDE" means, and proceeds to fail to address what exactly is integrated.
High level languages hide the underlying machine code being generated, so developers become less familiar with what the CPU is really doing. But in a way that's the whole point.
In the end, newbies will rely on the crutch to develop faster at the expense of not immediately understanding all that is happening behind the scenes, while more experienced developers will leverage the IDE to automate those things which they are tired of doing themselves. Eventually newbies learn what's happening under the hood.
You're not a real developer if you don't write in binary /s
What is an IDE? Personally, I consider IDE an integrated suite of source editor, visual debugger, build system. E.g. I put a breakpoint, push a button, it builds, runs and hits a breakpoint. Other tools (SCM integration, profiler integration, design tools) are an add-on.
So, is Bash an IDE? I think pretty much every modern editor allows setting up macros so it is possible to trigger build/run GDB from within the editor. Does author have an issue with Vim, Emacs and Sublime? What is the difference between Sublime and VSCode?
I started working after the collapse of RAD (rapid application development, think Delphi/VB) and model-driven tools (where you do UML and generate code from model). I am very strongly against those tools, don't think they can be done well. But those are category separate from IDE :) E.g. Rational Rose - could generate code from UML and parse the code to UML, but no code writing inside.
Another thing I take huge offence is people dumping on Eclipse. It was a revolutionary product that disrupted the space. It was blazingly fast compared to Java IDEs of the time (JBuilder, Visual Cafe and such) and had refactoring support comparable to IntelliJ (that was a paid product). It got destuffed at a critical junction (complete rearchitecture from Eclipse3 to E4) and saw crappy plugins (and Java really lost popularity since). But it was an amazing product 24 years ago.
My general takeaway about the dev community is this- stop giving a crap about what other people are doing. If you find a tool that fits your needs and that you like then I'm delighted for you. Ask others if you want to learn but stop telling others they're wrong for having their own preferences.
This is only acceptable for things that don't have a network effect. If svn is the universal standard, then that forces me to use svn.
Eclipse RCP was a pretty cool toolkit for building enterprise desktop apps that could be deployed to both Windows and Linux desktops. You could build complex stuff without much effort. And by 2000s standards it looked pretty slick and sophisticated.
E.g. my former team used to ship "IDE" - that is, use new project wizard to setup your folder, use editor to write the code, press a button to build, debug and profile. We also shipped standalone "visual profiler" - that had custom configuration for window layout/toolbars and stripped down list of included plugins. You open an executable, profile it, see per-line metrics in the read-only editor (that was a complete editor from the IDE, just in read-only mode).
So, does dropping a bunch of plugins (that noremally should not activate unless used) suddenly convert sluggish IDE into fast editor.
I feel like the negative perception of IDEs usually comes from busy UI. Devteam needs to balance discoverability (e.g. adding UI for configuring build and debug) and perceptions of the lightweightness.
They're fast but oh what hell they leave behind.
Yes, obviously the most time consuming part of developing software is thinking. But with an IDE, I can sometimes do some of that thinking out loud in code and rapidly prototype as I go with refactoring helpers, etc. This is not always the best approach, but it's a technique that has its place and is simply impractical without an IDE.
A strong senior engineer in a text editor can likely beat a junior engineer with the best IDE. But a strong senior engineer with the best IDE (and experience with that IDE, this is important!) will absolutely run circles around an equally strong senior engineer with a text editor.
For reference, my daily driver IDE is Rider.
I’m not convinced that people can easily switch though. I’ve met people who never really get the hang of working efficiently in the “Unix is the IDE” style of using text editors, and I can say from personal experience that I’m just never going to be particularly good at IDEs. I suspect that each tool simply appeals to a different personality type- and that’s okay as long as our projects don’t lock us in to something and we let people have the flexibility to use the tool that works for them.
But I swear as an IDE user, when non-IDE users try to describe to me how their toolset is just as good as an IDE ("most of the same capabilities in a different form"), it is like I'm a modern human coming into contact with member of a tribe that has been isolated from civilization, and they're trying to convince me how it's just fine to live in a mud hut without AC or running water, and that they've got all the basic stuff they need. Instead of going to a grocery store or farmer's market, they forage and hunt for food (and they're very proficient at it!). Instead of using bikes/cars/trains/planes to travel, they walk everywhere (but it's great exercise!).
And of course there is nothing inherently wrong with living any way you choose. In fact there are many merits to living more "primitively". But it'll be over 100 degrees today in Texas and I'm really glad I've got AC.
I'm genuinely not trying to be condescending here, so I apologize if that is how this came across. My main point is: I really think you should give IDEs a shot. The good ones are very good!
If we’re doing unkind takes though, I’d say a better analogy isn’t that the non-ide users are ignorant so much as it is that the ide users are, through a lack of ability or motivation, unable to create their own tools to improve their craft, and so take whatever bland uninspiring monument to mediocrity that someone tries to sell them. Like a person who condescendingly eats ramen dry from the package and informs the person cooking a good meal that surely they must be ignorant to not realize you can buy perfectly edible food at the gas station on the corner.
Now, personally, I prefer to think better of people than that- and I assume that people are just choosing to use what works for them, and to not be a jerk about it.
I really didn't mean any offense, so I apologize. I was just trying to find an analogy for a feeling that I've otherwise found difficult to articulate, but I probably did not adequately convey the lighthearted sarcastic tone I intended. My bad.
As I said at the top of my last post, I would never intentionally begrudge or shame anyone for using tools they feel are a better fit for them -- to each their own.
Personally, I've tried IDEs occasionally for decades and they've never stuck. I find that a lot of their integrations are ideal for narrow problem spaces, however, I don't often find myself fitting well into the designed problem space.
> IDEs Can Create Lock-In Effects
Because all the things come before this point are so absurd.
One problem with CS being so male-dominated is the endless focus on turning everything into some sort of d*ck-measuring contest at each turn.
I write code for a large part of my living because I'm good at it and I enjoy it. I personally enjoy plain old Sublime over an IDE. I'm here to maximize my contribution to society and enjoy my time on earth. I'm not here to "beat" somebody in some nonsensical code battle.
> One problem with CS being so male-dominated is the endless focus on turning everything into some sort of d*ck-measuring contest at each turn.
I hope you read what you wrote. Trying to be more effecient at work is "dick-measuring contest"? And somehow it's a gender problem?
It almost sounds like you're assuming women can't be competitive and enjoy writing better code faster.
There are incredibly flexible, concise, low-ceremony languages, with implicit types where placing an IDE between you and code kinda obfuscates them. These are the languages where I think the best representation of code is the code itself.
Then there are elaborate, verbose, high-ceremony languages with explicit types, where looking at code and keeping up with ceremony might be a bit overwhelming. For those languages you probably want a lot more automation and a variety of info representation that goes way beyond code.
I'd go out on a limb to say that everyone here who likes/dislikes IDEs will split almost perfectly among those two language categories.
That said, looks like your history involves .NET -> Python/.NET. I went .NET -> PHP -> Ruby/Elixir/Go. It took me some time to withdraw from .NET before I started preferring not to have an IDE. If you're still split half/half between two worlds, I can understand why you're still hooked.
Not only problems but understanding; as someone who once taught beginning programmers, and assisted someone else before that wherein the students were given step-by-step instructions with an IDE and as a result many had little idea what to do if something didn't work, I started with the "text editor and command line" approach and those little problems mostly disappeared. Another side-effect I noticed is students being more confident in their work, which is likely because they felt like they understood what was happening at a deeper level of detail.
Finally understood what he was talking about in the last few paragraphs, when he mentioned only knowing how to run tests and pipelines through an IDE. He was talking about a GUI! I agree, clicking a button on a GUI that's magically hooked up to GitHub and runs whatever it needs to for testing is "complexity that pretends it's invisible", which was a great phrase. It's always a good idea to learn how to run everything from the terminal, because it's hard to hide complexity behind terminal commands. Not that it's impossible, but it's more of a philosophy from Unix for every command to only do one "action". So to build a project in Go, one runs `go build .`. And to run it, `go run .`. To test it, `go test ./...`. To debug, a set of flags must be passed to build. To build for a different target, a different tag. It's very explicit. In an IDE, relying on whatever buttons are made available means that these commands may be combined, or simply made unavailable
It's similar with PHP via something like PHPStorm, Python via something like PyCharm - there's no real lock-in beyond personal habits in IDEs I've used.
More generally, in this space... using a text editor (with or without plugins) and using an IDE are both valid approaches. I do not believe either are fundamentally better than the other. Try both approaches and choose for yourself - it's all about finding what suits you as an individual and makes you more productive. You may even find that your choice differs depending on what software stack or language you're working with - mine does.
"Hot takes" aiming to belittle or degrade people that choose the opposite to you are unhelpful at best and discourage people from trying both options for themselves. No one is a worse developer because they like working with a simple UI with minimal distractions and separate tools for separate tasks, and no one is a worse developer because they like more integrated tooling with code suggestions, refactoring tools, integrated debuggers, etc.
To the author's statement that it affects adoption of CI/CD, I've seen that, too, where teams didn't know how to run their Junit unit tests outside of an IDE and nobody felt capable of figuring it out. They were wrong, it didn't take too long to figure out, but they honestly believed that running Junit tests was a feature of their IDE, and were not aware that it could be run separately.
These aren't persuasive arguments about using IDEs, because any sensible person can avoid them. I don't want to defend the author's point; I just want to say that I believe him when he says he's seen these things.
They don't care if a method is badly named or misspelled because they barely read names before they ctrl-click them. They don't care that files are haphazardly organized because they navigate by searching. They pick up a ticket and slack somebody to ask where the fix should go. Once they're in the right place, it's click click click and they're on their way.
The best programmers read class names and method names. They look at the directory structure to get a sense for how the codebase is organized. They try to understand the logic behind code they inherit, they try to write code with an evident logic that the next person can follow, through good organization and meaningful, consistent naming.
I've had programmers tell me that they didn't know a word was misspelled because they figured it was a word they didn't know. I told them if they see a word in our codebase they don't know, they shouldn't gloss over it, they should look it up, because somebody thought about that word before they typed it. They roll their eyes. They think everyone is like them and craps out names without thinking about them. They don't realize this has anything to do with why they're still mid-level at their age and people don't trust them with anything important.
In the end, I don't think the author is correct. I don't think that using a poor tool makes a programmer better, even if it forces them to do important things they wouldn't otherwise, like notice how things are named and organized. And I think the best programmers are better and faster with an IDE. But I certainly understand where he is coming from.
The Unix equivalent of a single Visual Studio install and all its functionality is
- clang
- CMake
- gdb (which is pretty lousy compared to VS' debugger)
- valgrind
- perf
- some record-replay tool (maybe perf?)
- system package manager
- language server protocol tool
- clang-format
- clang-tidy
And a whole other host of refactoring tools that just aren't present or possible in the author's tool of choice, Vim.
Sure, one could do complicated editing with indecipherable incantations in Vim, but I spend most of my time thinking, not typing—ironically the same argument that the author uses. I don't need a faster, more to-the-metal tool. I like the abstractions an IDE provides. Working with Git is immensely simpler in an IDE than it is in the command-line. Autocomplete, refactoring, and go-to-definition functionality is superb. All these help me think and write better code.
I don't blame you or anyone else for not understanding vim because it's an obtuse dinosaur of a program that fails to meet the preconceived notions of modern users. Just understand that you don't know what you're talking about. If you get vim, you'd understand that IDEs are nothing but a bundle of cheap gimmicks.
Honestly, I didn't think that these tabs versus spaces equivalence for IDEs versus text editors still existed today, but apparently people tie their personal identities to their tools more often than I would've expected.
Meanwhile, the third camp of people just use the applications that they're comfortable with, preferring to focus on getting the actual work done rather than making sweeping generalizations.
They're not 'third-party tools'. That's what the 'integrated' in 'IDE' stands for, you don't need to maintain and pull a disparate collection of tools; there is one install and everything including the linter, compiler, linker, debugger, runner, profiler, benchmark, package manager, and version control system is part of it.
Ie: This one IDE is worse than this one text editor for this one programming environment. So every IDE is worse than every text editor for everyone.
I am sorry, but there is zero truth in a sweeping generalization like that.
What is an IDE anyway these days? VSCode with plugins is more IDE than some IDEs. The lines are all blurry. Is syntax highlighting considered to be an IDE? Clearly it’s doing more than text editing. It’s understanding the language.
Believe it or not, those days of pure text editors are long gone. Almost every modern iteration of a text editor does a lot of what would have been squarely in the realm of IDEs some years ago.
These are all just tools. Some are better than others in specific situations. Without the specifics, this kind of argument is noise.
It's more like GUI vs the command line. Both can ultimately get the same job done, but the experience is different. And, frankly, I'm not sure there is one winner takes all. Sometimes GUIs allow you to do more, better, and be more efficient, but other times it is the command line excels at those things. There is situational dependence.
Working in a pure text editor works if you have a relatively small piece of code you can focus on while working, but I've seen very experienced engineers become extremely slow or completely fail with their vim setup when they suddenly work on something that's beyond the 20k line mark.
IDEs are sloppy and slow and they make engineers do dumb things.
"Why did you change all the whitespace in this file?"
"I dunno my IDE did it."
And almost every time I've had to retrain someone on git, it's because they were using an IDE and never understood how git works. The same issue pops up with debugging in situations where you only have gdb or ptrace and not your ide.
Kind of like if someone was selling you a super reliable lawn mower, but it took 4 or 5 extra rip cord pulls to start, would have me less inclined to believe his pitch.
Reminder the topic here was we don't need IDEs because people should be smart enough to do it in an editor. I think that with spellcheck it's reasonable to say that if people make mistakes that could be solved with spellcheck, they could also make mistakes that could be solved with an IDE
We are all human, we all make mistakes
The spellchecker is enabled with
set spell
I don't have any problems getting by with shell, sed, grep, and whatever debugger. I've debugged bonkers issues (gdb is super powerful), I've changed the names of things across huge codebases using sed, I've found all instances of things using grep, etc. I've written scripts to do these things and some of them I've reused (ex: I have a script that grep's the output of git status to see what I need to add to a commit to continue a rebase and then runs that git command).
It did take time to learn, but I would argue it didn't take longer than really getting to know an IDE. And now, I have pretty good knowledge of standard tools that's broadly applicable to lots of other problem domains. This has been useful as I've had to dip in and out of data engineering in the last few years, but it's also nice to just be able to whip up utilities to solve random problems that always crop up (does Funko sell some kind of Doug McIlroy talisman?).
As a result, I've always felt that IDEs were vaguely disempowering. I'm good at using *NIX on a variety of problems, and deploying these skills over the years I've gained a pretty deep understanding of how lots of things work (what makes grep fast, forking overhead, file descriptors, buffering on pipes and I/O in general, etc). I can't overstate the degree to which this has made me a better SWE. I'm not a PyCharm user or CLion user, I'm a computer user.
I don't want to veer too far into "IDE users are sheep" or whatever; I definitely don't think that. But for me, digging into *NIX tools essentially taught me about computers and software engineering, and gave me a broadly-applicable skillset that I use to solve bonkers problems all the time, but where I wouldn't even know where to start in something like VS Code. A good example here is I was just rereading tptacek's post on hiring (from also rereading the "Misidentifying Talent" post by luu) [0] [1], and he talks about one of the interview work sample prompts involves reverse-engineering a custom binary protocol. I don't really know how I would do that in PyCharm (or whatever the Ruby equivalent is), but I would make pretty quick work out of it in Wireshark.
I think these arguments just come down to aesthetics. Some people think that IDEs are fun to work with in their GUI magnificence and find a vim/emacs/etc. system extremely opaque and tedious. Others think that it's fun to wire your own system together to suit your own way of thinking and working, and feel suffocated and disempowered by an IDE. Use what you like, have fun, don't yuck my yum.
[0]: https://sockpuppet.org/blog/2015/03/06/the-hiring-post/#work...
But, it can also be very handy. Sometimes I have to search for the name of a function only where autocomplete could have helped me, or I get a PR comment for some minor error that my IDE would easily have spotted. So what I do know is that I only manually invoke syntax checking and completion functions. That way I can use it when I need it and not get constantly distracted by it.
I still turn off all the 'lens' like features, I don't like all kinds of verbose information intermixed with my code.
And I really don't understand your comparison of using a jet brains IDE... to monitor network traffic. It's fairly self evident that if you want to do packet sniffing at a low level that wire shark is your best bet. Maybe you meant comparing fiddler to wire shark? (High level vs low level)
I also think those other disparate tools are actually really good, and reading about and researching why they're good has given me a deeper understanding of software engineering that I can now apply in my own work. I think this is probably also possible with IDEs, but I think they're a little less approachable (and often closed source/proprietary) so it happens a lot less.
You're able to change the name of a variable named 'user' without affecting comments or descriptive text about 'the user'? Props to you if you can do all that with grep/sed across, say, a combined PHP/JS project; I wasn't able to do that as easily as I can in IDE-land.
- grep to see how bad the problem is
- sed what you can
- vim the rest
Oftentimes the compiler or tests will bail you out; like just change the field name and fix the errors clang finds. If I don't have that kind of thing I consider adding it.
Also while it might take a little longer (though I've used IDE refactoring wizards and it's close), I almost never do it. Could be the kind of thing where like, "changing this would take 10 minutes and be really irritating, so let's take 5 minutes here and nail the name, or establish a convention", which I think leads to better codebases and probably trains you better as an engineer.
I've had a few interactions with folks who were staunchly "anti IDE" (not saying you are), but was watching a 'director of engineering' give a walk through of their codebase via vim, and was bashing on IDEs. "If you need an IDE, you probably shouldn't work here. You should always be able to know everything about your code, where stuff is, etc. I wrote most of this and it's not that hard". When I brought up that he had a multi-year 'lead' on people new to the codebase, and that IDEs often make it pretty quick to explore and familiarize oneself with new-to-me code... he just 'pffft'-ed that away as 'sounds like more of a you problem' comment. They were also trying to hire, and having a hard time (this was... 10 years ago... so no idea how they're doing now on hiring front).
I guess my first thought here is that Vim has stuff like "go to definition", and depending on your language has had it for quite some time. I do agree there's a kind of toxic "in my day we wrote programs directly on spinning hard disk platters by being very careful with a magnet and tweezers" attitude in places, but I'll bet that for every one of those there's an equal, "I use actual good IDEs and anyone who doesn't leverage them can't possibly be as productive as me", so I think it probably washes out.
I don't think you should know everything about your code, the opposite actually. I think you should be able to entirely forget everything about your code when the day ends. I think you should be able to walk onto any codebase and quickly understand how things work having no foreknowledge, as though you'd forgotten everything over night. I don't think this has anything to do with IDEs or editors, but has everything to do with coherent mental models and documentation. Without that stuff, you're just Ctrl-P'ing around, just like w/ IDEs. My manager uses VS Code and whizzes around pretty well. I use Vim and whizz around just as well (arguably better as I don't use go to definition so I'm grepping and guessing where stuff is with... idk very good accuracy). I don't really see a point in arguing about it.
> Refactoring entails moving, renaming, consolidating, etc. Personally, I've found most of these activities are usually much simpler to run using tools crafted for that purpose vs crafting my own from a variety of tools.
I hear so much about refactoring and this kind of thing, and it conjures up this image of some sorcerer extracting a pervasive, cancerous hydra from a code's corpus and transmogrifying it into a new, tamed organ. I think a few things about this, but mostly "I frequently have to rename and restructure countless structures/classes and functions/methods across a multi-million line codebase and I need a tool to facilitate that" sounds bonkers to me. It's also hard for me to square that with any kind of testing infrastructure, code review process, or design process. Having to do that kind of thing even once is pretty wild; I can't imagine having to do it so often that I require tooling for it. I can't imagine an engineer dropping a multi-thousand line PR on me with "I refactored billing, but I used IntelliJ so don't worry" in the description. I wouldn't even look at it, honestly.
Which is to say, I actually think it is rare and generally unsuccessful. I've used refactoring tools and wizards in IDEs. They'll rename fields, change types, update type signatures, generate new getters/setters, etc. That's cool (I don't need it though, because I have Vim and macros)! But that's not really refactoring, that's changing names and types. Refactoring is changing the fundamental representation of the problem space, which means you're changing what different classes/modules are responsible for and how they meet those responsibilities. IDEs won't help you with that, but testing can and it's independent of IDEs or editors. I can imagine an engineer dropping a multi-thousand line PR on me with "I refactored billing, took forever to get tests to pass, but now they do" in the description. Not only would I look at it, I would dig in and help refine the approach (or whatever).
So again, I think IDEs are fine. I'm sure there are benefits to either side and I'm not super interested in them. I think it's largely an issue of aesthetics. But, again I think you're right that smart people try to make their aesthetic choices "correct" as though they're above irrational personal preferences, but the best thing I can say about that is it's just no fun haha.
back in its day, eclipse was actually ahead of its time. A usable refactoring tools, incremental compilation, edit/replace method while the program is running, run program with syntax error (as long as you don't hit that line), etc...
To support all these feature, they have written their own java compiler.
Overtime, it get bloated and collapse over its weight.
Full search or replacement has never been easiler after I shifted my workflow to Pycharm. Of course same thing can be done in the terminal, by typing 800 time `cd A/somewhere; vi something`. Why make life harder when tools are accessible?