Sec
Victoria LacroixIs there any evidence that programmers are more productive when using IDEs? Fewer bugs, faster coding, minimal technical debt?
d@nny disc@ mc²@vtrlx they are extremely successful at making build processes magical https://circumstances.run/@hipsterelectron/113680457433333172
d@nny disc@ mc² (@[email protected])
Attached: 1 image @[email protected] the crowd went wild for this one
vriska, thief of light 
@hipsterelectron @vtrlx i couldn't find a paper actually relevant to the OP but i did find this thesis paper with one of the most unhinged abstracts i have seen in my life https://bura.brunel.ac.uk/handle/2438/3286
@leo @hipsterelectron Truly, unhinged.
I do find that mood often has an effect on my ability to program. Specifically, lacking guidance in the face of an unyielding problem often deeply frustrates me, sometimes to the point of needing to pivot to a very different approach. I don't think a patronizing IDE will help solve this issue.
@hipsterelectron Magical (derogatory) indeed.
fog@vtrlx it depends on what you mean by IDE. If you mean "jump to references" + "inline docs" + "auto complete" then, yes, I am much more productive in an IDE than in a simpler editor.
@fog I know you're disagreeing, but I think you've gotten to the core of the point I'm trying to make.
Many IDE features make it easier to write more code in less time. Programmers often want this, but I strongly believe that more code makes programs worse. Faster coding means less time spent designing elegant solutions.
The point of raising this question is less to assert my own opinion (though I've made myself clear) and more to note that evidence in favour of either opinion is lacking.
@vtrlx you are absolutely right. I love to write less code (so that I have more time just to think about it or even to play with alternatives or other projects). But having the IDE show me the docs of a function I am using instead of having to look it up in the docs removes some friction and let me concentrate on the code even more. That's all and I think we're aligned on the basic principles here.
BTW, trying out your "shell" is on my roadmap, just after FOSDEM.
Lucas Dohmen@vtrlx Good question. In my personal experience, the answer to all three questions is „No“
Andreas, DJ3EI, he/him
Jens Peter Grosen@vtrlx having an IDE that allows you to refactor across multiple classes, extract/inline/move/rename methods. Where the IDE guarantees the resulting code is correct. Will make you more productive.
@jpgrosen This is a good point that I want to believe is genuinely in favour of IDEs which also serves to illustrate why I dislike them. Features like this a) suggest a reliance on OOP, and b) suggest that code is broken up into many small files. I shy away from both of these approaches in my own projects because I find that they make code more difficult to reason about from my natural bottom-up approach to solving problems.
Red Rozenglass@[email protected] @[email protected] IDEs are the bandaid that can help you _after_ a codebase becomes full of bugs, slow to code, and drowning in technical debt.
@rozenglass @vtrlx in my experience as soon as a code base reaches a few files and you eg want to rename something across the files an IDE makes you more productive
@rozenglass @vtrlx or even just in a single file selecting a few lines and extracting them to a new method if it made sense. Or inlining a method if than made more sense. IDE can support the natural code flow of you working with and improving your code
@[email protected] @[email protected] none of those things are things I could not do in my text editor. This comes down to the definition of IDE, which is fuzzy, and defined differently by different people. My personal definition is: IDE understands the language being used on an AST-level at least (vim with a language-server is an "IDE" in my view for example), and provides a set of pre-made tools to act over that AST. While an editor works at the level of text, and provides tools that works over textual content in general. Working at the level of text is very powerful (much more powerful than IDEs in my opinion), and much faster performance-wise. For example, I can, in Emacs, grep for a symbol, record a macro that goes to each result, then does a very complex custom ad-hock transformation specific to my code, and run it over all the results, watching the outcome of each automatic execution, while collecting all the modifications into a patch file, then sending it as an email to my colleagues, and announcing it on an IRC chat channel. All of those things are "textual", and thus can be worked productively together within the same paradigm. An IDE cannot provide such power just by "understanding" the code of the specific language I'm currently working on. Jumping to definition, mass-renaming, replacing calls of a method with its content (i.e. inlining) are some of the easiest things that can be done at the text level.
The real positive for the IDEs usually, is low barrier of entry. The constraint of the pre-made operations acting upon structured ASTs and content, ensures that the user doesn't need to learn much before becoming productive, all while pointing out your mistakes and guiding you with hints and suggestions. The textual editing paradigm is a playground for infinite creativity, and requires a lot of learning. Nothing stops you from shooting your foot off, and ultimate mastery is forever a moving goalpost.
The real positive for the IDEs usually, is low barrier of entry. The constraint of the pre-made operations acting upon structured ASTs and content, ensures that the user doesn't need to learn much before becoming productive, all while pointing out your mistakes and guiding you with hints and suggestions. The textual editing paradigm is a playground for infinite creativity, and requires a lot of learning. Nothing stops you from shooting your foot off, and ultimate mastery is forever a moving goalpost.
What is your comparison baseline?
I use emacs for small stuff and switch to IDEs for bigger things. So emacs is my baseline, though you could argue it is an IDE of itself.
I somewhat heavily use IDE features like "rename", "go to declaration", "find all uses", "move to base class". Doing any of these is faster with an IDE than it would be with emacs + grep.
Also, I'll do these more freely when in front of an IDE, resulting in better, cleaner code.
You didn't ask about AI, did you?
@dj3ei You've again touched on what other replies have mentioned—IDEs make it easier to handle a larger amount of code, which means IDEs also make it easier to bloat one's projects with more code and more files. This creates a feedback loop where opting out of an IDE becomes increasingly difficult. Much like offloading your brain to an LLM, is the comparison I want to make.
Expired Token@vtrlx @dj3ei I use vim and plain git, and I'm slow. I edit one file at a time most of the time.
I would not be much faster using an IDE, because what takes me time is to read and understand the code I'm editing, and its surroundings.
I have a fast teammate that uses an IDE but commits strings of "typo/fix".
As long as you can stay focused on your task, it's not that hard to use a plain editor on medium-sized code bases.
What's actually hard is to stay focused in the modern workplace 🙃.
miraculous enbybug@vtrlx @dj3ei
What you’re saying is equivalent to «you should apply patch by hand because otherwise it makes you dependent on Git» or things like that.
Renaming something automatically is just removing tedious, deterministic work, without mistake; it has nothing to do with offloading a cognitive process onto an LLM???
@melunaka @dj3ei Renaming things is one of the things I find the least objectionable about IDEs, but because I don't often rename things I would almost certainly lose more time from the cognitive overload imposed by an IDE than I would save from being able to quickly rename variables/functions/types/etc.
@vtrlx @dj3ei
Depends what you mean by «IDE». Renaming stuff is something vim can do too, it doesn’t really add complexity to the editor itself, tho you might not prefer it or like how it works.
As for cognitive offloading, the features I usually think of are autocomplete and code suggestions.
I don’t know what’s code suggestions, I don’t use them. I don’t really see how autocomplete is different than going through docs manually (well I get some people could just use whatever seems to fit without really thinking, but people also copy-paste stuff from StackOverlow without thinking).
In the future, consider interpreting unusual arguments in good faith instead of making highly questionable comparisons as you have.
Well, I’m not sure how they’re «highly questionable»? I assure you I try to assume good faith, but I am annoyed by your initial comparison to using LLMs. I would argue that what bloats project is a capitalist culture more than features than automate deterministic work.
Alice 🚀@vtrlx Genuinely curious about this too. My suspicion is that IDEs help most with navigation and refactoring in large unfamiliar codebases, but for greenfield work or small projects, the productivity gain might be marginal or even negative (context switching, config fiddling). The "fewer bugs" claim seems especially hard to measure — does autocomplete prevent typos or just let you write buggy code faster?
@alice I'd argue that autocomplete makes it easier to accidentally use the wrong function for a given context, which might give rise to subtle errors if the resulting code compiles. Without autocomplete, you need to be deliberate. That means attentiveness and comprehension of both the problem space and the code you're working with. That's how programming is supposed to work, isn't it?
@vtrlx That's a fair point — autocomplete can absolutely become a crutch where you accept suggestions without fully understanding them. The "deliberate typing = comprehension" argument has merit, especially for learning or unfamiliar codebases.
I think the sweet spot varies by context: autocomplete shines for APIs you know well (reduce RSI, catch typos) but can be harmful when exploring something new. Your simplicity-first approach to development probably benefits more from that deliberate friction.
I think the sweet spot varies by context: autocomplete shines for APIs you know well (reduce RSI, catch typos) but can be harmful when exploring something new. Your simplicity-first approach to development probably benefits more from that deliberate friction.
Mäh W.
Jean Helou ⌨️@vtrlx I use an IDE most of the time. I see 3 kind of benefits
1. reading assistance
Code navigation, navigable call hierarchy analysis, navigable dependency analysis, finding references, syntax coloration, symbol search (variable, function name, class name in oof languages),quick documentation access, quick source code access
2. writing assistance
Auto-completion, method suggestion and api discovery these 2 especially when backed by a strong type system), automatic safe refactorings (symbol rename, function extraction, call signature update, capitalisation, and in OO languages class or interface extraction)
3. Trivial interactive debugging especially for tests.
@vtrlx the codebase I am currently paid to work on is 13 year old, 3M lines of code in various languages (mostly kotlin and typescript) contributed to by about 60 people.
Many open source projects also have medium to large codebases addressing several concepts/domains/things and orchestrating them to surface useful behaviors
In these contexts IDEs are useful
Many open source projects also have medium to large codebases addressing several concepts/domains/things and orchestrating them to surface useful behaviors
In these contexts IDEs are useful