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 eng

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.