4 ms·

I strongly agree with this narrative and it matches my own experience. I spent 9 years of college and then grad school using exclusively either vi or emacs beca

by hagy 6y ago

I strongly agree with this narrative and it matches my own experience. I spent 9 years of college and then grad school using exclusively either vi or emacs because I believed IDEs were a crutch that weak engineers relied upon. It wasn't until I got a real job that I found myself forced to learn a proper IDE (IntelliJ). It blew my mind just how powerful the IDE was and how it massively increased my productivity. Putting aside code completion and code generate, I found it much easier to navigate a codebase using a proper IDE that fully understood the language. When I contrast that to my previous solution, a highly customized emacs configuration with lots of packages and my own functions, the two just don't compare.

saurik 6y ago
I think part of this is that the people who use IDEs then prefer the actual code to be dumbed down to the point where the IDE can both understand it and then is required to manipulate it; I hate programming in Java because it is a language kind of designed to make it hard for me to build my own rapid abstractions... which of course would break the ability of the IDE to parse it at all much less refactor it; but, I then argue that the more powerful code abstractions obviate the language flaws that required "refactoring" in the first place. And to me, that is a way in which I feel like IDEs are awkward and harmful, but it is almost more at an ecosystem level than at the scale of a single person.
- avl999 6y ago
  You have it totally backwards, people who use IDEs don't like "dumbed down code" for the sake of the IDE. Nor are languages like Java designed with their IDEs in mind. The IDE is designed with the full language spec in mind, understands the language at the AST level and supports the full set of language features and all their permutations. A developer who is writing code in IDE is utilizing every permutation of what the language provides and it is upto the IDE to understand it. IDEs for the most part are not covering for language flaws, they are helping developers be more productive by removing the need to focus less interesting parts of the process and focus on the the problem being solved. While the need for an IDE is more important in some languages over others, there are a set of common problems that exist in every language that the IDE can help solve (navigating the codebase by jumping around to symbol definition/usages, auto importing packages/modues, intellisense, refactoring). Refactoring does not mean going back and refactoring 6 weeks worth of work that you seem to have in mind. Most people who refer to refactoring are referring to it in the context of multiple small refactors during very short development cycles (every few minutes or hours). My workflow and the workflow of many developers I have worked with goes like this: * Write some code (not more than 200-500 lines) * Write tests * Refactor if needed- potentially rename variables, potentially extract some code into methods, potentially pull stuff up into constants, potentially introduce a new class or interface, potentially change types of certain members, potentially visibility of certain members or methods. * Repeat for the entire workday when you are not in meetings. Refactoring- specifically the kind of small scale refactoring that you do as go through your workday to me is almost as important a part of the development process as anything else and IDEs remove almost all friction from it by removing any cognitive load of the task from the developer.
- nec4b 6y ago
  Which powerful language do you use that can't be understood by the IDEs. Don't you think that if your compiler can understand it, the IDE can too? :)

by hagy 6y ago

saurik 6y ago

I think part of this is that the people who use IDEs then prefer the actual code to be dumbed down to the point where the IDE can both understand it and then is required to manipulate it; I hate programming in Java because it is a language kind of designed to make it hard for me to build my own rapid abstractions... which of course would break the ability of the IDE to parse it at all much less refactor it; but, I then argue that the more powerful code abstractions obviate the language flaws that required "refactoring" in the first place. And to me, that is a way in which I feel like IDEs are awkward and harmful, but it is almost more at an ecosystem level than at the scale of a single person.

avl999 6y ago
You have it totally backwards, people who use IDEs don't like "dumbed down code" for the sake of the IDE. Nor are languages like Java designed with their IDEs in mind. The IDE is designed with the full language spec in mind, understands the language at the AST level and supports the full set of language features and all their permutations. A developer who is writing code in IDE is utilizing every permutation of what the language provides and it is upto the IDE to understand it. IDEs for the most part are not covering for language flaws, they are helping developers be more productive by removing the need to focus less interesting parts of the process and focus on the the problem being solved. While the need for an IDE is more important in some languages over others, there are a set of common problems that exist in every language that the IDE can help solve (navigating the codebase by jumping around to symbol definition/usages, auto importing packages/modues, intellisense, refactoring). Refactoring does not mean going back and refactoring 6 weeks worth of work that you seem to have in mind. Most people who refer to refactoring are referring to it in the context of multiple small refactors during very short development cycles (every few minutes or hours). My workflow and the workflow of many developers I have worked with goes like this: * Write some code (not more than 200-500 lines) * Write tests * Refactor if needed- potentially rename variables, potentially extract some code into methods, potentially pull stuff up into constants, potentially introduce a new class or interface, potentially change types of certain members, potentially visibility of certain members or methods. * Repeat for the entire workday when you are not in meetings. Refactoring- specifically the kind of small scale refactoring that you do as go through your workday to me is almost as important a part of the development process as anything else and IDEs remove almost all friction from it by removing any cognitive load of the task from the developer.
nec4b 6y ago
Which powerful language do you use that can't be understood by the IDEs. Don't you think that if your compiler can understand it, the IDE can too? :)