6 ms·

No. They (can) make us more productive. When you're working with a large number of source files, the ability to have auto-complete, parameter guessing, getter

by modoc 18y ago

No. They (can) make us more productive. When you're working with a large number of source files, the ability to have auto-complete, parameter guessing, getter/setter creation, auto-builders, and real-time code syntax/quality/checkstyle/pmd/findbugs/etc... validation means you can write working code more quickly. The ability to refactor/rename across an entire project with a click of a mouse means I'm much more likely to refactor as the code evolves, leading to higher quality, more readable, more extendable code. Seeing class hierarchy trees with one click, jumping to view the source of a method I'm using, remote debugging totally integrated with my source code, etc... is all really valuable. Sure, drag-and-dropping everything in some IDEs means you're missing a lot of the core stuff in programming, but at least for me, I am more productive using Eclipse than I was using Emacs and the shell.

jwilliams 18y ago
> When you're working with a large number of source files, the ability to have auto-complete, parameter guessing, getter/setter creation, auto-builders, and real-time code syntax/quality/checkstyle/pmd/findbugs/etc... validation means you can write working code more quickly. I think his point is broader than that - he's arguing that IDEs encourage/are symptomatic of/cause bloat of the APIs and encourage bloat in other areas (e.g. generated code). However, I think this article misses a trick by not mentioning functional programming. FP reduces the surface area of many APIs considerably. It also "fixes" all the code generation issues with a much more elegant solution (i.e. macros).
- newsycaccount 18y ago
  Funny, most programers who make heavy use of macros heavily rely on IDE-like features such as macro-expansion.
maxwell 18y ago
IDEs appear to compensate for language design flaws which decrease productivity in the first place.
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.
azanar 18y ago
Productivity is a difficult thing to measure, because the units people use aren't consistent. I'm going to try to respond using the metric of productivity I've become most comfortable with, which is quanta of robust functionality per unit time. By robust, I mean it is not fragile or rigid to future changes within both itself and dependencies. In this sense of productive, IDEs can be quite detrimental in careless hands. IDE can make developers more prolific, generating very quickly blocks of code that perform particular tasks, but I've also found that it can cultivate a more manufacturing method of coding, where developers just bounce on the '.' and tab keys and glue bits of 'sensed' method calls together. It makes development fast, and that means any productivity metric based on providing code meeting specified requirements is satisfied swiftly. It also means that the developer spends far less time thinking about individual blocks of code; this can have very deleterious effects. A single line might consist of 12 method calls strung together, because the developer didn't take the time to go back and assess things like readability. A particular method might calculate the incorrect result when passed data it wasn't originally designed for, rather that throwing an exception or gracefully degrading its functionality. A method or class definition might likewise make unreasonable assumptions about dependencies, requiring a large amount of rewriting; rewriting which could have been avoided if the developer had taken a few minutes to step back and examine the implications of their work, and how the design could change to make the code clearer and simpler. To be clear, I am not blaming IDEs for careless, fragile code. What I am saying is that IDEs can be a magnifier for carelessness, allowing a developer with a proclivity for banging out code as fast as possible without regard for quality to do so much faster. What time they spend reaching for the documentation for a particular class or framework would give their mind a chance to think about what they are working on, and possibly come up with a more long-term workable solution to what they are building. I'm not saying it's a panacea; I guess what I'm saying is that I'm not totally opposed to artificially slowing down developers who would otherwise write code faster than they can reason about it. I suppose the other solution is just to identify them as careless, and remove them from the project. I also worry about your dismissive stance toward the “core stuff of programming.” I’ve found it is this core stuff that makes for the simpliest, future-proof code, because the core stuff allows for reasoning about design, not just about functionality.
kingkongrevenge 18y ago
> have auto-complete, parameter guessing, getter/setter creation, auto-builders, and real-time code syntax/quality/checkstyle/pmd/findbugs/etc... validation You can do all this from Vim.

by modoc 18y ago

jwilliams 18y ago

> When you're working with a large number of source files, the ability to have auto-complete, parameter guessing, getter/setter creation, auto-builders, and real-time code syntax/quality/checkstyle/pmd/findbugs/etc... validation means you can write working code more quickly. I think his point is broader than that - he's arguing that IDEs encourage/are symptomatic of/cause bloat of the APIs and encourage bloat in other areas (e.g. generated code). However, I think this article misses a trick by not mentioning functional programming. FP reduces the surface area of many APIs considerably. It also "fixes" all the code generation issues with a much more elegant solution (i.e. macros).

newsycaccount 18y ago
Funny, most programers who make heavy use of macros heavily rely on IDE-like features such as macro-expansion.

maxwell 18y ago

IDEs appear to compensate for language design flaws which decrease productivity in the first place.

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.

azanar 18y ago

Productivity is a difficult thing to measure, because the units people use aren't consistent. I'm going to try to respond using the metric of productivity I've become most comfortable with, which is quanta of robust functionality per unit time. By robust, I mean it is not fragile or rigid to future changes within both itself and dependencies. In this sense of productive, IDEs can be quite detrimental in careless hands. IDE can make developers more prolific, generating very quickly blocks of code that perform particular tasks, but I've also found that it can cultivate a more manufacturing method of coding, where developers just bounce on the '.' and tab keys and glue bits of 'sensed' method calls together. It makes development fast, and that means any productivity metric based on providing code meeting specified requirements is satisfied swiftly. It also means that the developer spends far less time thinking about individual blocks of code; this can have very deleterious effects. A single line might consist of 12 method calls strung together, because the developer didn't take the time to go back and assess things like readability. A particular method might calculate the incorrect result when passed data it wasn't originally designed for, rather that throwing an exception or gracefully degrading its functionality. A method or class definition might likewise make unreasonable assumptions about dependencies, requiring a large amount of rewriting; rewriting which could have been avoided if the developer had taken a few minutes to step back and examine the implications of their work, and how the design could change to make the code clearer and simpler. To be clear, I am not blaming IDEs for careless, fragile code. What I am saying is that IDEs can be a magnifier for carelessness, allowing a developer with a proclivity for banging out code as fast as possible without regard for quality to do so much faster. What time they spend reaching for the documentation for a particular class or framework would give their mind a chance to think about what they are working on, and possibly come up with a more long-term workable solution to what they are building. I'm not saying it's a panacea; I guess what I'm saying is that I'm not totally opposed to artificially slowing down developers who would otherwise write code faster than they can reason about it. I suppose the other solution is just to identify them as careless, and remove them from the project. I also worry about your dismissive stance toward the “core stuff of programming.” I’ve found it is this core stuff that makes for the simpliest, future-proof code, because the core stuff allows for reasoning about design, not just about functionality.

kingkongrevenge 18y ago

> have auto-complete, parameter guessing, getter/setter creation, auto-builders, and real-time code syntax/quality/checkstyle/pmd/findbugs/etc... validation You can do all this from Vim.