Victoria LacroixIs there any evidence that programmers are more productive when using IDEs? Fewer bugs, faster coding, minimal technical debt?
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.