7 ms·

There are both kinds of developers. I always thought Oliver Steele did a good job of explaining this here: http://osteele.com/archives/2004/11/ides http://oste

by sofal 18y ago

There are both kinds of developers. I always thought Oliver Steele did a good job of explaining this here: http://osteele.com/archives/2004/11/ides http://osteele.com/archives/2004/11/ides Here's my take: The ability to write in a language that doesn't require excessive amounts of boilerplate code means I'm much more likely to refactor as the code evolves. Seeing an algorithm on one page, localizing and separating the logic cleanly with higher level constructs, easily translating the intuitions in my head to a coded solution, being able to dive into any part of the code without getting lost in the redundancy and residue of IDE vomit, etc... is all really valuable. Getters and setters that take up more than one very short annotation are eyesores, and the mere act of coughing them up into the code was never a bottleneck to programming speed no matter how bloated they get. The act of automatically renaming classes or variables, along with all the other code-shoveling refactoring support that IDEs provide is a miniscule subset of what refactoring is really about. The real refactoring work is done in your head. You need to look at the code and comprehend it in ways that aren't obvious, so that you can reorganize it to be simpler or maybe extendable. This kind of work cannot be done by an IDE; however, it can be aided by using a nice expressive language that gets to the point and doesn't distract you from the problem. When it comes down to building, deploying, and automation of other menial tasks, I'm not stuck with what the IDE developers give me. A good language is like putty in my hands. An IDE locks me down and cumbers me, giving me little in return other than a graphical debugger and quick syntax help. Once you have mastered the command line, it becomes painfully obvious what the IDE cannot do. An IDE is a static cockpit with lots of cool doodads and buttons. I can make my own doodads and buttons and they will do exactly what I wish and they will do it exactly how I wish. I am a language maven.

matstc 18y ago
> The act of automatically renaming classes or variables, along with all the other code-shoveling refactoring support that IDEs provide is a miniscule subset of what refactoring is really about. I've heard this argument many times and I can't quite understand it. Even if the few supported operations like rename/pull up/inline/extract are only a subset of all possible refactorings, I still do these things multiple times an hour. I want them to be automated. I hate bloated IDEs just as much as the next guy, but I do miss automated refactorings when in vim or emacs.
- sofal 18y ago
  It's about trying to find the best trade-off. Certainly automated rename/pull up/inline/extract operations help, but I've found that the navigation and text-editing power of vim outweighs the benefits coming from those IDE operations. Vim is kind of like an IDE in some respects. I like it because it focuses on text editing and doesn't stick its nose into the actual programming decisions where it doesn't belong. If I wanted my editor to interfere with my programming logic then I'd probably take the jump to emacs, where I know it will obey me rather than forcing me to obey it, the latter accurately describing the experiences I've had with Visual Studio. And, like I said, the act of performing the textual refactoring isn't where I spend most of my time anyway. Most of my programming time is spent thinking about how to proceed, placing those thoughts into the context of my program, and translating those thoughts into whatever language I'm using. The more I can speed up those bottlenecks the better.
azanar 18y ago
>The real refactoring work is done in your head. This has totally been my experience. Moving a method or variable up or down in the inheritance tree, extracting part of a method, inlining method calls: all of this is architectural refactoring. I've found the much of my refactoring time isn't spent in moving methods around and modifying signatures; it is spent in modifying the algorithms and data organization. Not organization in the sense of whether variable belongs in sub- or super-class, but in the sense of whether some subset of data should belong in a particular class, or some new delegate class I construct. That new delegate class might not be a subset of the class I'm splitting apart, so requires more than just some automated extraction process. I can't help but create a mental picture of all of this as a sort of architectural autopilot -- it can handle making minor course and altitude corrections, but still expects you to have thought about things before pressing the 'engage' button.
- modoc 18y ago
  The guts of all application design and redesign (which is what refactoring really is) is always done in your head. That's true no matter what tools you use or don't.
modoc 18y ago
Maybe it's a language difference, or something else. I write J2EE apps. I don't want to start a language war, but personally I really like Java, and people like paying me to build stuff in it, so let's take that as a given. Also, seeing that the big popular IDEs are Eclipse (mostly used for Java) and MS's VisualStudio (C++, C#, etc...) the context of the discussion seems to be those languages where there is a mature, popular, IDE available. The projects I work on are often pretty big (e-commerce websites for Fortune 500 type companies), and while an algorithm may live on one viewable screen of one class, a single business process or requirement will almost always span multiple JSPs and many classes. An add to cart action will need to check inventory, shipping rules based on hazardous flags on the SKU, shipping options and costs based on the customer's zip code, run through a whole pricing pipeline to apply coupons, discounts, BOGO type specials, and so on. Therefore to write that, or later alter or debug it, I will need to navigate through multiple files, to specific methods. And IDE means I can go directly to the source a method I call with one mouse click or key-combo. This is faster than finding the file, opening it, and finding the correct method (even more so when you can't just search by method name due to overloading). I don't know exactly what you mean by "residue of IDE vomit". My IDE doesn't write code (with the exception of getters/setters). I do. Maybe Visual Studio does write lots of code for you, I wouldn't know. Real refactoring always starts in your head, no matter what tool or lack of tool you're using. You always plan it out in your head. It's just a matter of when its time to make the changes, are you searching for names to edit in 20 files by hand or not. Maybe there's a difference in what we're talking about when we say IDE. In my opinion: Dreamweaver = bad HTML IDE: because it lets you create page with dragging and dropping, so you don't actually understand how markup works, or how a dom tree is parsed, and it generates tons of awful HTML code behind the scenes. Eclipse = good Java IDE: I write the Java code myself, but the IDE makes common tasks faster, and provides intelligent auto-complete, which means that I don't have to memorize every method name and parameter order of every class in the J2EE + Framework of choice stack. I guess I feel that most of your complaints about IDEs don't apply to (or at least line up with my experience) writing J2EE apps in Eclipse. I used to use Emacs, bash scripts, and Ant, for years so I know what the alternative is. You say an IDE is like a static cockpit, but in Eclipse at least it's pretty easy to make your own doodads and buttons that do whatever you want, or use the doodads someone else already created. For me, an IDE is like toolchest with a little robot attached. It keeps all my tools in one place, so they aren't scattered all over my garage, I can add whatever custom tools I want to it, and the robot knows that when I pick a 18mm socket up, I'll almost certainly want the 1/2" ratchet next, and hands it to me, instead of me having to go dig through the stack of ratchets to find it. And if I'm using a torque wrench, the robot calls out the correct torques for the bolts/studs I'm working on at the moment. The robot doesn't work on the car, and the toolchest doesn't spit out assembled engine blocks, but they mean I spend less time hunting for tools around my garage, and more time working on the car.

by sofal 18y ago

matstc 18y ago

> The act of automatically renaming classes or variables, along with all the other code-shoveling refactoring support that IDEs provide is a miniscule subset of what refactoring is really about. I've heard this argument many times and I can't quite understand it. Even if the few supported operations like rename/pull up/inline/extract are only a subset of all possible refactorings, I still do these things multiple times an hour. I want them to be automated. I hate bloated IDEs just as much as the next guy, but I do miss automated refactorings when in vim or emacs.

sofal 18y ago
It's about trying to find the best trade-off. Certainly automated rename/pull up/inline/extract operations help, but I've found that the navigation and text-editing power of vim outweighs the benefits coming from those IDE operations. Vim is kind of like an IDE in some respects. I like it because it focuses on text editing and doesn't stick its nose into the actual programming decisions where it doesn't belong. If I wanted my editor to interfere with my programming logic then I'd probably take the jump to emacs, where I know it will obey me rather than forcing me to obey it, the latter accurately describing the experiences I've had with Visual Studio. And, like I said, the act of performing the textual refactoring isn't where I spend most of my time anyway. Most of my programming time is spent thinking about how to proceed, placing those thoughts into the context of my program, and translating those thoughts into whatever language I'm using. The more I can speed up those bottlenecks the better.

azanar 18y ago

>The real refactoring work is done in your head. This has totally been my experience. Moving a method or variable up or down in the inheritance tree, extracting part of a method, inlining method calls: all of this is architectural refactoring. I've found the much of my refactoring time isn't spent in moving methods around and modifying signatures; it is spent in modifying the algorithms and data organization. Not organization in the sense of whether variable belongs in sub- or super-class, but in the sense of whether some subset of data should belong in a particular class, or some new delegate class I construct. That new delegate class might not be a subset of the class I'm splitting apart, so requires more than just some automated extraction process. I can't help but create a mental picture of all of this as a sort of architectural autopilot -- it can handle making minor course and altitude corrections, but still expects you to have thought about things before pressing the 'engage' button.

modoc 18y ago
The guts of all application design and redesign (which is what refactoring really is) is always done in your head. That's true no matter what tools you use or don't.

modoc 18y ago

Maybe it's a language difference, or something else. I write J2EE apps. I don't want to start a language war, but personally I really like Java, and people like paying me to build stuff in it, so let's take that as a given. Also, seeing that the big popular IDEs are Eclipse (mostly used for Java) and MS's VisualStudio (C++, C#, etc...) the context of the discussion seems to be those languages where there is a mature, popular, IDE available. The projects I work on are often pretty big (e-commerce websites for Fortune 500 type companies), and while an algorithm may live on one viewable screen of one class, a single business process or requirement will almost always span multiple JSPs and many classes. An add to cart action will need to check inventory, shipping rules based on hazardous flags on the SKU, shipping options and costs based on the customer's zip code, run through a whole pricing pipeline to apply coupons, discounts, BOGO type specials, and so on. Therefore to write that, or later alter or debug it, I will need to navigate through multiple files, to specific methods. And IDE means I can go directly to the source a method I call with one mouse click or key-combo. This is faster than finding the file, opening it, and finding the correct method (even more so when you can't just search by method name due to overloading). I don't know exactly what you mean by "residue of IDE vomit". My IDE doesn't write code (with the exception of getters/setters). I do. Maybe Visual Studio does write lots of code for you, I wouldn't know. Real refactoring always starts in your head, no matter what tool or lack of tool you're using. You always plan it out in your head. It's just a matter of when its time to make the changes, are you searching for names to edit in 20 files by hand or not. Maybe there's a difference in what we're talking about when we say IDE. In my opinion: Dreamweaver = bad HTML IDE: because it lets you create page with dragging and dropping, so you don't actually understand how markup works, or how a dom tree is parsed, and it generates tons of awful HTML code behind the scenes. Eclipse = good Java IDE: I write the Java code myself, but the IDE makes common tasks faster, and provides intelligent auto-complete, which means that I don't have to memorize every method name and parameter order of every class in the J2EE + Framework of choice stack. I guess I feel that most of your complaints about IDEs don't apply to (or at least line up with my experience) writing J2EE apps in Eclipse. I used to use Emacs, bash scripts, and Ant, for years so I know what the alternative is. You say an IDE is like a static cockpit, but in Eclipse at least it's pretty easy to make your own doodads and buttons that do whatever you want, or use the doodads someone else already created. For me, an IDE is like toolchest with a little robot attached. It keeps all my tools in one place, so they aren't scattered all over my garage, I can add whatever custom tools I want to it, and the robot knows that when I pick a 18mm socket up, I'll almost certainly want the 1/2" ratchet next, and hands it to me, instead of me having to go dig through the stack of ratchets to find it. And if I'm using a torque wrench, the robot calls out the correct torques for the bolts/studs I'm working on at the moment. The robot doesn't work on the car, and the toolchest doesn't spit out assembled engine blocks, but they mean I spend less time hunting for tools around my garage, and more time working on the car.