Post B2tleu1VBJkOXcmyga by jpgrosen@mastodon.social
(DIR) More posts by jpgrosen@mastodon.social
(DIR) Post #B2pDNz4Gzx5ABs0Sps by vtrlx@mastodon.social
2026-01-30T03:14:05Z
0 likes, 1 repeats
Is there any evidence that programmers are more productive when using IDEs? Fewer bugs, faster coding, minimal technical debt?
(DIR) Post #B2pDO0aDMgE6tDxUGG by jpgrosen@mastodon.social
2026-01-30T14:07:17Z
0 likes, 0 repeats
@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.
(DIR) Post #B2pDO25Rm2ntYNZwa8 by vtrlx@mastodon.social
2026-01-30T14:42:53Z
0 likes, 0 repeats
@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.
(DIR) Post #B2pDO3Mr0oK1WejMLw by rozenglass@fedi.dreamscape.link
2026-01-30T22:56:08Z
0 likes, 0 repeats
@jpgrosen@mastodon.social @vtrlx@mastodon.social IDEs are the bandaid that can help you _after_ a codebase becomes full of bugs, slow to code, and drowning in technical debt.
(DIR) Post #B2tleu1VBJkOXcmyga by jpgrosen@mastodon.social
2026-01-31T06:48:38Z
0 likes, 0 repeats
@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
(DIR) Post #B2tlevcPFarTUN3xqa by jpgrosen@mastodon.social
2026-01-31T07:19:03Z
0 likes, 0 repeats
@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
(DIR) Post #B2tlewkF3wiuyxjjhQ by rozenglass@fedi.dreamscape.link
2026-02-02T03:39:10Z
0 likes, 0 repeats
@vtrlx@mastodon.social @jpgrosen@mastodon.social 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.