The IDE As a Bad Programming Language Enabler(developers.slashdot.org)
developers.slashdot.org
The IDE As a Bad Programming Language Enabler
http://developers.slashdot.org/story/12/10/30/065244/the-ide-as-a-bad-programming-language-enabler?sdsrc=popbyskid
10 comments
Having IDE support is a feature of a language. You have to design your language so that IDE support is possible [1]. Most dynamically typed languages and functional languages fail in this regard and if you use such a language you always are jumping between API docs and your editor.
[1] http://blog.efftinge.de/2011/04/dear-java-killers.html
[1] http://blog.efftinge.de/2011/04/dear-java-killers.html
Interesting how people without good IDE support rationalize things.
Interesting to note how people without good programming languages rationalize things.
What happens when you have a good IDE and a good programming language?
I say we have both!
I say we have both!
My only question is whether Faler switched to vi or emacs when he ditched Eclipse. If we're going to start flamewars with broad generalizations, perhaps we should do it properly (hmmm ... it appears I can troll effectively on HN without an IDE).
In the mean-time, I'd recommend the use of a good IDE and extensive test suite when you're refactoring. Use whatever you like (or are fastest in) when you're producing new code.
In the mean-time, I'd recommend the use of a good IDE and extensive test suite when you're refactoring. Use whatever you like (or are fastest in) when you're producing new code.
When I jumped from android dev to rails dev I was hesitant to using sublime text instead of a true IDE, but now I hesitate to go back. With a good language you don't have to scroll though an auto complete to find the exact method call you want, good conventions enable me to often guess what method or class I want without ever having encountered it prior.
We are in a world where computational and networking resources are absurdly cheap and abundant, compared to the past. Why shouldn't we design languages and environments that take advantage of this fact?
Designing a language that leans on an IDE, or other forms of tool support, is not bad. Analogously, designing an application that leans on having an internet connection (e.g. put documentation in a wiki, Go's URL imports) is not bad.
You can put together a GUI using only textual code in a text editor, but you'll do it faster and better with the help of live previewing and typo underlining.
Designing a language that leans on an IDE, or other forms of tool support, is not bad. Analogously, designing an application that leans on having an internet connection (e.g. put documentation in a wiki, Go's URL imports) is not bad.
You can put together a GUI using only textual code in a text editor, but you'll do it faster and better with the help of live previewing and typo underlining.
Not just bad languages but also bad processes and, I would argue, bad programmers.
IDEs are a good tool that (a) won't venture into some places that a good engineer needs to go, because to be decent at the job you really do need to understand the command-line interface, and (b) is very often put to bad use. I've developed the reputation of being an inveterate IDE-hater, but even I have to admit: abstractly, they are a good thing. They're an attempt to solve a very hard problem (code comprehension) and the reason why they fail (by which, I mean that they tend to reduce the overall quality of the software environment) is not that they are intrinsically bad, but that managers tend to use them as license to hire weaker programmers and launch larger and more poorly-thought-out software projects, and IDEs can only go so far. It's like idiot-proofing: someone will design a better idiot.
The real problem is the horde of untalented, tasteless programmers and the clueless management that most software organizations hire, not the IDE itself. IDEs have just become, unintentionally, a symbol of How The Other Half Codes. There's nothing wrong with the tools themselves (although it is a bitch to support them if your environment has a lot of wonky in-house plugins).
There's also a Blub-like problem where people use "IDE" to mean "more featured environment than I'm used to", with the tacit assumption that "more featured" is a bad thing, because it's believed (and, sadly, often correctly) to be compensating for tasteless programming. As with Blub, IDE isn't even a well-defined term. Is SLIME an IDE? You could make a strong case for "yes", but you'll get flamed if you call it that because good programmers (rather than "IDE programmers") use it.
What are IDEs good for? Hell is other peoples' code, but reading other peoples' code is still a necessity. In the real world, we can't just throw out millions of lines of software because the code is tasteless. We often have to try to make use of it, and IDEs give us a fighting chance. This also explains the negativity toward IDEs. The one thing they are really good for (reading low-quality code) is something engineers hate doing.
IDE-dependence is evil, and bad code is evil, and IDEs only compensate partially. Having good processes, competent engineers and management, and writing high-quality code are all a lot more important than whether you use an IDE or not. In the real world, you probably want to have the IDE as an option because, even with everything going well, pockets of gnarly code are inevitable. Even Google (which has its faults, but its code quality is superior to most corporate environments) has a read-only IDE, served over the web.
One thing I would love to see is for Github to turn itself into a read-only IDE, with code navigation by link. The truth is that a read-only IDE provides all of the benefits of an IDE (except for interactive debugging, but that can be provided at the command line). While automated refactoring is slowed down in an non-IDE environment, that's actually a good thing. If a change is going to affect a large number of interfaces, there's a discussion that needs to happen. The 30 minutes that it takes to write the script that does this is a trivial cost in comparison to the communication effort that a major, potentially world-breaking, change deserves. So I'm a major fan of the "read-only IDE" concept.
IDEs are a good tool that (a) won't venture into some places that a good engineer needs to go, because to be decent at the job you really do need to understand the command-line interface, and (b) is very often put to bad use. I've developed the reputation of being an inveterate IDE-hater, but even I have to admit: abstractly, they are a good thing. They're an attempt to solve a very hard problem (code comprehension) and the reason why they fail (by which, I mean that they tend to reduce the overall quality of the software environment) is not that they are intrinsically bad, but that managers tend to use them as license to hire weaker programmers and launch larger and more poorly-thought-out software projects, and IDEs can only go so far. It's like idiot-proofing: someone will design a better idiot.
The real problem is the horde of untalented, tasteless programmers and the clueless management that most software organizations hire, not the IDE itself. IDEs have just become, unintentionally, a symbol of How The Other Half Codes. There's nothing wrong with the tools themselves (although it is a bitch to support them if your environment has a lot of wonky in-house plugins).
There's also a Blub-like problem where people use "IDE" to mean "more featured environment than I'm used to", with the tacit assumption that "more featured" is a bad thing, because it's believed (and, sadly, often correctly) to be compensating for tasteless programming. As with Blub, IDE isn't even a well-defined term. Is SLIME an IDE? You could make a strong case for "yes", but you'll get flamed if you call it that because good programmers (rather than "IDE programmers") use it.
What are IDEs good for? Hell is other peoples' code, but reading other peoples' code is still a necessity. In the real world, we can't just throw out millions of lines of software because the code is tasteless. We often have to try to make use of it, and IDEs give us a fighting chance. This also explains the negativity toward IDEs. The one thing they are really good for (reading low-quality code) is something engineers hate doing.
IDE-dependence is evil, and bad code is evil, and IDEs only compensate partially. Having good processes, competent engineers and management, and writing high-quality code are all a lot more important than whether you use an IDE or not. In the real world, you probably want to have the IDE as an option because, even with everything going well, pockets of gnarly code are inevitable. Even Google (which has its faults, but its code quality is superior to most corporate environments) has a read-only IDE, served over the web.
One thing I would love to see is for Github to turn itself into a read-only IDE, with code navigation by link. The truth is that a read-only IDE provides all of the benefits of an IDE (except for interactive debugging, but that can be provided at the command line). While automated refactoring is slowed down in an non-IDE environment, that's actually a good thing. If a change is going to affect a large number of interfaces, there's a discussion that needs to happen. The 30 minutes that it takes to write the script that does this is a trivial cost in comparison to the communication effort that a major, potentially world-breaking, change deserves. So I'm a major fan of the "read-only IDE" concept.
"won't venture into some places that a good engineer needs to go, because to be decent at the job you really do need to understand the command-line interface"
This is only true if the IDE has not kept up with the command line interface. Visual Studio and Xcode do pretty much everything their CLI can do except maybe some tool integration like CI or deployment. But that's operations, not programming.
"IDEs are a good tool that ... is very often put to bad use."
So is every other tool out there. What's your point?
"The one thing they are really good for (reading low-quality code) is something engineers hate doing."
They are also good for:
- Writing good quality code.
- Looking up methods.
- Code completion.
- Code navigation.
- Interactive debugging.
The list goes on.
"IDE-dependence is evil"
No it is not. You might as well say static analysis dependence is evil or compile-time optimization is evil or profilers are evil or any other convenience is evil. Should we all remain puritans and suffer cryptic and unwieldy tools just because making them more powerful and friendly also makes them more powerful and friendly for bad programmers?
Bad programmers will write bad code no matter what tools they use. Blaming the IDE is disingenuous and quite frankly comes off as arrogant and elitist.
This is only true if the IDE has not kept up with the command line interface. Visual Studio and Xcode do pretty much everything their CLI can do except maybe some tool integration like CI or deployment. But that's operations, not programming.
"IDEs are a good tool that ... is very often put to bad use."
So is every other tool out there. What's your point?
"The one thing they are really good for (reading low-quality code) is something engineers hate doing."
They are also good for:
- Writing good quality code.
- Looking up methods.
- Code completion.
- Code navigation.
- Interactive debugging.
The list goes on.
"IDE-dependence is evil"
No it is not. You might as well say static analysis dependence is evil or compile-time optimization is evil or profilers are evil or any other convenience is evil. Should we all remain puritans and suffer cryptic and unwieldy tools just because making them more powerful and friendly also makes them more powerful and friendly for bad programmers?
Bad programmers will write bad code no matter what tools they use. Blaming the IDE is disingenuous and quite frankly comes off as arrogant and elitist.
I agree to some extent but i wont go as far and say that programmers using IDEs are bad.
Notch of Minecraft uses Eclipse, John Carmack uses Visual Studio for 2 decades and still loves it. In large Software projects i think that it helps even the best programmers.
On the other hand there are also alot of bad programmers using textmate etc..so i wouldnt relate the skill of a programmer to their development enviroment of choice!
On the other hand there are also alot of bad programmers using textmate etc..so i wouldnt relate the skill of a programmer to their development enviroment of choice!
HN submission linking to Slashdot submission of a story that has already been discussed on HN ages ago.
What was the name of that movie again?
Oh yeah, Inception.
What was the name of that movie again?
Oh yeah, Inception.
October 28th wasn't exactly "ages ago".
This must be setting a new record for an old article.
- and the Redditization of HN comments...
I like having the ability to refactor quickly, to hop to method definitions with ease, to have a quality integrated debugger, and blah blah blah. A good language might make some of that less required, but it doesn't stop it being useful. And, really, if an IDE is required for a language to be useful, but once that IDE is in place the language is useful, why would you not consider language + IDE an indivisible pair? What real relevance does it have that the language on its own is not that great?
Java + Eclipse is Perl + CPAN, or JS + jquery/dojo. Something you have no business criticising unless you've made the effort to use/understand it in its whole.
Java isn't a great language, but Java + Eclipse is really quite tolerable. The majority of people I've known who really hate it (as opposed to the usual sense of vague frustration that obvious improvements haven't been made...) are people who are unwilling to adapt themselves and their tooling to fit.