The tight Integration of the debugger is a huge benefit over what a text editor would provide.
Sure you possibly can add all the stuff to some text editors too, if you spend enough time / energy.
this post was submitted on 23 Oct 2023
10 points (81.2% liked)
Ask Experienced Devs
1248 readers
1 users here now
Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient
founded 2 years ago
MODERATORS
The thing about an IDE is how tightly integrated all of the tools are.
If you list the features individually, surely there’s a way to add most of them to your text editor of choice - but the downside is that they’re now all fairly independent features, may not work as thoroughly or covertly, and you might end up with a slower editor altogether.
Not to say IDEs are the peak of performance - but they tend to provide more robust tooling than is (easily) available in e.g. VSCode/emacs/neovim/whatever.
It’s like using a specialized power tool - it’s not the right tool for every job, it’s probably a bulkier package, but if you know how to use it an IDE can make your life a lot easier for the right workload.
I'm reluctant to call much "bloat", because even if I don't use something doesn't mean it isn't useful, to other people or future me.
I used to code in vim (plus all sorts of plugins), starting in college where IDEs weren't particularly encouraged or necessary for small projects. I continued to use this setup professionally because it worked well enough and every IDE I tried for the main language I was using wasn't great.
However, I eventually found IDEs that worked for the language(s) I needed and I don't have any interest in going back to a minimalistic (vim or otherwise) setup again. It's not that the IDE does things that can't be done with vim generally, but having a tool that understands the code, environment, and provides useful tooling is invaluable to me. I find being able to do things with some automation (like renaming or refactoring) is so much safer, faster, and enjoyable than doing it by hand.
Features I look for/use most often:
- Go to (both definition and usages)
- Refactor tooling (renaming, inlining, extracting, etc).
- Good warnings, along with suggested solutions. Being able to apply solution is a plus.
- Framework integrations
- User-friendly debugger. Ability to pause, drill in, and interact with data is immensely helpful with the type of applications I work on.
- Configurable breakpoints.
- Build tool integrations. Doing it on the console is... fine... but being able to set up what I need easily in the IDE is preferable.
Features I don't use or care so much about? Is there much left?
- My IDE can hook up to a database. I've tried it a few times, but it never seemed particularly useful for the apps I work on.
- git integration. I have a separate set of tools I normally work with. The ones in my IDE are fine, but I usually use others.
- Profiler. I use it on occasion, but only a few times a year probably.
I do code in non-IDE environments from time to time, but this is almost always because of a lack of tooling than anything else. (Like PICO-8 development)
Isn't PICO-8 an IDE? I guess it doesn't really fit the traditional defitinion, but it includes a code editor, image editor, and music editor.
I would argue that PICO-8 is an IDE for game development on a fictional console, but I could understand why others would disagree. It is not necessarily what you would think of when you think of an IDE, but it is a development environment specially integrated with tools for game development. You can make an entire game without leaving PICO-8, and that sounds like an IDE to me.
I think that's a fair argument. PICO-8 definitely could be called a primitive IDE. I think it's closer to being a primitive game engine with so much of its focus being on graphics and sound tooling.
While you can code simple things within PICO-8, I've found that as I've built bigger things, I work better in an outside editor, even if it only gets me smaller fonts, splitable windows, vim bindings, limited linting, and somewhat broken code completion.
This isn't a criticism of PICO-8 as an environment. I think there are a lot of strengths in its simplicity, especially for beginner coders.
I tend to make a distinction between a customizable editor with some support for a language (like vim+plugins) vs a dedicated all-in-one tool that fully understands the language and environment (IDE). PICO-8 is hard to place on that spectrum given it's an all-in-one tool, but switching to a modified editor gives you more features.
They are not bloatware, IMO.
When I see people inserting printfs into their code just to be able to debug, I can't help but cringe. Proper IDEs make debugging so much more easy.
Also people who manually go-to source by a "Ctrl+Shift+F" (or grep or ripgrep or whatever), have code completion without context (as in suggestions of words that exist in the file, but have nothing to do with what it should be completing), refactor by "Replace All", and then claim they are more efficient than IDEs, ... I'm not sure they have ever bothered learning how to use an IDE instead of cram a bunch of arcane emacs or vim shortcuts into their brain to achieve what a simple button press in an IDE could do.
Good IDEs also have stuff like code coverage indicators (run tests and show which parts of your code are covered), "go to that broken test", "go to the line in the stack trace", "execute the remote debugger on another system", database browsers with stuff like query execution analysis, GUI builders, "show me the documentation of this item", and so much more.
I find it extremely hard to go back to using a dumb editor (be it notepad, sublime, vim/nvim/lunarvim/astrovim/..., emac/spacemacs/..., Kate, etc.) after having experienced the ease of development I get from an IDE.
But back to your question: "what can be considered bloat". Well, all the things you don't use can be considered "bloat". If you don't use a database, well loading the database functionality in an IDE may be considered useless. If you don't use a debugger and like being a printf cave-man, then the debugger is useless. If you want to click on a stack trace and be taken to the source code, then that can be considered bloat. If you use git (or whichever VCS you use) manually, then a commit dialog with rebase support might be useless. And so on an so forth.
Also, if all the development you do is on a remote server with exclusive terminal access, then a GUI IDE might be bloat.
Or if you have a machine with 4GB of RAM and can only open Chromium with a few tabs, then sure, opening an IDE might seem like bloat.
Or if you want to have a startup time of milliseconds, but spend more time hitting K or the down arrow to find that symbol instead of just "go-to source", sure then an IDE is bloat.
But most importantly, if you IDE doesn't support the language you're using and has no syntax highlighting, then it is downgraded to an editor.
IDEs are useful, I always stick with them myself.
I don't care where my imports come from, I just need that reference when I start writing the type. I don't remember exactly the name, it's sufficient to type out a bit and get it in the autocomplete. I don't know the overloads, so it's nice to see what it can do/take. Solution wide rename, go to source/usages (I can't stress this enough, along with a mouse with back/forward buttons) allows quickly going back and forward between places you've been. It's not quite on the VIM bookmark and goto that I've seen a coworker use, but still great.
Running tests with good overview and the code a click away, debug both in tests and in general, global search is extremely useful when half your code base is compiled into a database... And another part is loose references to a property that the IDE isn't aware of
Lest not forget the most important one, auto formatting. I pushed for a format on save across the team, and while there's some larger changes in the first pull requests, it totally removes code that has 4 mile long lines, messy indentation and so much more.
While it requires work, a shared editorconfig goes a long way to align style both across computers and IDEs. Not all those style rules are that important but a common format helps making navigating code easier.
Visual studio is pretty good with hot reload, debugger and a few other things. But it needs ReSharper to properly shine imo, and that makes it so damn slow and buggy. I moved to Rider since I knew Pycharm, and it's a lot snapper with a few less bugs. When I started my job my laptop bluescreened a few times a week until VS2022 came out. It's also somehow randomly forgot my keybind until restart, failed to compile when going from .Net 6 back to a old framework version branch, and even clean solution didn't work. (because that doesn't clean obj folders)
Rider sometimes gets it in for itself that my files are invalid, but still compiles. And on first boot, running my application doesn't actual start it somehow. But outside that, the experience is much more smooth.
Depends. For some languages, you may not need them. They do help. I code in G'MIC (Domain-Specific Language) and there is zero IDE for it, but yet, with terminal and a text editor (KDE Kate), I was able to be more productive than I was with Python using Pycharm.
Yet, with C++, I prefer to use IDE as it gives me clues to what I need to insert.
IDEs are tools and you should use the tool that works best for you.
IDEs have tons of tools to teach, debug, refactor, generate code, etc. I've worked in projects where any one of those tools is valuable. When I was learning, I found IDEs to be great aids that helped me avoid common pitfall.
IDEs also do have overhead. I've worked on projects where that overhead is so high the IDE isn't a viable tool.
The first thing you should learn as a dev is to stop worrying about what buzz words people apply to different technologies and closely examine the pros and cons of a technology as it relates to your problem set. Create solutions to problems, not solutions in search of a problem. If you can do that, you'll be off to a great start.
Disclaimer: I'm not super experienced.
I'd say it heavily depends on your usecase. If you're the type of person to only really code in one language and don't really want to tinker too much then an IDE is perfect.
If you love tinkering with your editor and tweak it to be just perfect you also have stuff like emacs or vim.
As for the feature I can't live without: a good vim mode. Once you're used to editing text in vim, going back to a mouse based workflow is a really big pain.
As a rule, and Integrated Development Environment is less than the sum of its parts. Whether it is worth using depends on:
- how many of the parts you actually need to use
- to what extent you would benefit to use features of a part that are not exposed by the IDE
- whether you find it easier to switch between different windows (involving tools with different UIs) for different tasks, or use the same window for different tasks.
- whether the language you're using is statically or dynamically typed, and whether it's syntactically "simple" or complicated (this affects the difficulty of "manual" refactoring)
What features do you use often And what features are not that useful in an IDE and can be considered bloat?
Being able to build projects and debug them is a given. Why would anyone use an IDE that did not supported building or running a project?
Developers spend most/practically all their time navigating through a project. Therefore, features such as opening files, searching for symbols, going to definitions, navigating back to points you were in, end up being the ones everyone uses the most. Also, code bookmarks are also of critical importance to work on specific tasks.
Support for refactoring primitives is also of critical importance. It's extremely convenient to extract/inline functions, rename symbols across the whole project, automatically generate code such as classes and their unit tests, etc. Nowadays, if an IDE does not support basic refactoring features such as extract/inline function/variable then I'd argue that it's not worth bothering with.
Finally, source code formatting. It's surprising the impact on team dynamics and productivity that we get by having an entire team on the same page with regards to where a space is expected to show and not show up.
I'm sure that there are plenty of spectacular features that should be must-haves but I'm oblivious to. Not using them doesn't mean they are bloat.
I mean, define bloatware?
A piece of software can use a lot of system resources without being bloatware if it provides user value commiserate with the resource demand.
Aside from a browser, my IDE provides everything I need to develop software. Terminal, debugger, http client, linter, test runner, prettier, code assist, db client, ftp client, git ui, search tool with indexes, etc.
Could I install ten smaller pieces of software to accomplish the same things and only run them when I need them? Sure. But why? I'm lucky to have a decent machine that runs fine with Chrome, Zoom, Slack, Docker Desktop, and four IDE instances open.
I made the switch to vim a while back because I had to work on remote servers that weren't running an X server. I found it suited my dev needs as well and haven't looked back. On the rare occasion I need to debug something, gdb works well enough.
That said, I do use VS code for personal projects. It feels lightweight enough to me, since you only have to install extensions for the languages and tools you plan to use.
Honestly, they kind of are. They come with so many tightly integrated features that I've never really had luck getting them to work on projects that weren't made with them to begin with. For a very large project, that you work on for thousands of hours, it might be worth it. Otherwise, a code editor like Kate or VS code can do almost all of the same things with plugins/lsp. I haven't really tried, but I bet they're better at using multiple languages in one project too.
I used to be, as another comment has put, a 'printf caveman', but lately I've been getting into using debuggers more. I do find that the debugger plugins in VS code and Kate leave a bit to desired, whereas KDevelop works a lot better. That's probably circumstantial though. I would much rather use a plugin, if there was just one for kate that would follow pointers.
Is your question "what does an ide do that a text editor doesn't"?
Auto complete is very nice.
Find usages is necessary.
Syntax highlighting. The yellow squiggle for when it thinks you maybe messed up. (Like when you typo = instead of ==)
Refactor: rename. Smarter than find replace
Refactor: move. Also smart
Using an interpreter in docker is nice. It can find all the sources without me installing anything on the host machine. Being able to cmd click to view the library code is huge.
I don't really use the debug tools because I'm fine with the command line pdb, but they're very useful for people who like them.
IDE because the Visual Studio IDE (note: not VSCode) has the best debugger I've ever used. That is the main thing keeping me from nvim with a small handful of extensions. The debugger, profiler, and good application of each, have been invaluable to my success as a programmer.
As for the "Is it bloatware question," I think it has the same answer as Excel. No one needs all of the features found in Excel. Basically anyone who uses Excel only needs a tiny subset of the functions that Excel supports. The problem is that everyone needs a different subset.
IMO pure bloat.
I used to use VSCode and thats how I learned vim bindings. One time I tried running a 20char macro 1000 times. Easy work right? VSCode took a solid 120secs to do the macro. Why? What the hell was so difficult about what I asked for. So I took afew hours out of my day and configured VIM to work like VSCode. VSCode is objectivly superior in every regard, VIM just runs faster and the difference is noticable.
Your criticism about IDEs is centered around an unofficial vim emulator plugin for one code editor. If that's your only experience, you're missing out.
Actually the vim emulator was what broke me. In reality VS code was extremely slow with basic key bindings. It will take a good 10 to 30 seconds to start up, and the worst of it all is that I couldn't open multiple windows, I had to jump between tabs.
GUI softwares try to make your life easier by being opinionated. The belief is that if you know how to use your VS code you can use any VS code. Which is fine if you agree with the opinions. The thing I learned when I tore out my entire Microsoft development stack is that I can have my own opinions about my workflow. And my opinions are faster and more intuitive than Microsoft's.
well vscode isn't an IDE so not sure what that has to do with the question at all. You compared a GUI text editor with a console based text editor. Of course the console based text editor is faster.
Debugging is the killer feature that keeps me using them a lot of the time.
You can set it up in code editors but it's never going to be as good as a language specific ide.
I generally find the features aren't bloat. You may not need a lot of them often but when you do they can be incredibly powerful.
Many ides are incredibly extendable as well.