IDEs Are Dangerous

I think I disagreed with just about every point on that post. Most of the issues the author describes can be fixed by using your brain and the tools at your disposal.

Your IDE adds metadata to your directory? SVN and git allow you to ignore files and directories.

It's not in the GUI menu so I can't do it! You're doing it wrong.

I can't pipe from my IDE to another program! What? My IDEs create files and these files and their output can be piped wherever. Maybe I'm in the minority but I've never felt the need to pipe directly from vi to anything else. I don't even know how or if that would work. I've piped the file I edited to something else before...which I can still do whether I use an IDE or not.

The whole blog post was just silly.

I've never understood peoples dislike for IDE's When I started programming my IDE was a "C:\>", thats it, just 4 letters and a crap load of .BAT files that was different on every developers machine.

Today I use VS2010 and can honestly say I am hundreds times more productive.

"This in turns clutters the interface and goes against the simplicity they advertise."

Sure it's a big IDE with lots of options but when you finaly tune it to your tastes, it fits like a glove and stays out of the way.

Every toolbar and menu can be configured with what you want and made to hide and fly out when commanded.

I generally disagree with the author: good IDEs (and, by good, I mean IntelliJ) are a huge productivity win, and are the principle justification for static typing in a language.

However I think that the author is absolutely right about two points:

* IDEs should integrated more tightly with the environment they are in, like VIM. The One-Tool-To-Rule-Them-All thinking ends up handicapping IDEs: something that would be simple to do via some other tool becomes a copy-paste-exec-copy-paste exercise in frustration.

* IDEs are generally too heavyweight. IntelliJ, the best IDE in the history of all possible universes, grinds like hell opening up a significant project the first time, building up the caches that allow its refactoring and lightening fast find-usages to work. And it demands a project file/project dir. It's bad enough that I end up using TextMate (which I hate) simply because it gives me a browsable tree on the side and decent syntax highlighting whenever I just want to look around in a project.

I think there is a middle ground here: an IDE that is designed with an 80/20 mindset: no caches, no project files, no state, instant open. Offer code completion (which shouldn't require a disk cache, just a parse), jump to definition (same) and then offer a find-usages that is really a grep-then-parse. Not as fast as IntelliJ, but still better than just a grep. And, addressing the first point above, very tight integration with the command line.

I think that's going to be my 40's project.

There is a segment of developers that came from the UNIX editors to IDE and we like and prefer the IDE. while I will agree that the editors are fast and configurable they don't totally outweigh the IDE. There is a lot of value in a good IDE and that is why they exist. The article talks about plugins and I would argue that that is a strong point of the IDE, I know some of the UNIX editors have pluggable architectures but a whole lot more effort is going into IDE plugins. For someone in a commercial software shop this can be a good thing, because workflow can be optimized without having to tinker with ones environment there are a lot of people working on workflow type issues in the IDE's and this efficiency is being passed on to others. The trick is finding a good IDE and everyone has their opinions, I personally like Netbeans as it has the workflow that I like and it supports all of the languages that I use. I really think there is some dogma in the anti-IDE arguments and I think it tries to unfairly biases people against good solutions. For some people the UNIX editors are right, for others IDE's are right, to call them dangerous is a little dubious in my opinion as it is rhetorical, the article makes some good arguments for using an editor, and I think it's defense should stand on those merits and not on building the perception that IDE's are a bad choice.

One of the biggest pluses of an IDE is the contextual access to the API. This helps a lot when learning a new language/framework.

I haven't used many IDEs lately by when I was learning Java, netbeans was my best friend.

Aside from that, maybe the easy access to debugging. Although tests have made debugging less necessary for me.

Charles Petzold has elucidated a lot of the same ideas in: http://charlespetzold.com/etc/DoesVisualStudioRotTheMind.htm...

Since that's got a 2005 date, can we agree that there's a trend here?

My biggest problem with IDEs is that they make bad languages and practices (that would otherwise be untenable due to the weight of accidental complexity) just barely work, well enough that they aren't replaced. Most of the Java IDE ecosystem exists to make up for deep deficiencies of the Java language.

Also, Java "best practices" involve shitting all over your directory structure with singleton directories like "com"-- because "no one actually uses the Unix command line anymore"-- and putting tests in a separate directory tree ("src" vs "test").

If you have a Repl, you usually don't need an IDE. If you have no Repl, you're working with stone knives anyway and should just give up. http://michaelochurch.wordpress.com/2012/02/07/repl-or-fail/

What I do like is the idea of a read-only IDE available through the web. Google has something like this (Codesearch) and it's great for large codebases.