I'm not sure what the point of the article is. We should not develop tools to aid large scale programming? The one and only tool is the raw text editor?
Reading between the lines, it appears the IDEs he's using aren't adding features fast enough to support his favorite language. Perhaps the smell is that his favorite language is too complicated and/or unstable to be suitable for tool development?
Having worked in a large C++/C# project, and with large Java projects, I can say that a good IDE partially makes up for missing documentation. If there isn't documentation for a library, at least the IDE tells me what the parameters are, from which I can deduce how I can use it.
However, I have found that by not having an IDE, I spend more time documenting and understanding the code I write and less time relying on the IDE to tell me what I meant by a function or a class. I think about implementation details more because it's not as easy to just "refactor it later".
This pays off when my boss calls me when I'm on vacation saying there's a huge bug in the production code on our website. Since I understand the code pretty well, I can just SSH in, find the code in question, and hot-fix it, all without needing an IDE. If it's a compiled thing, ssh in, write a unit-test, apply patch, run and test. If it passes, it can't be any worse than before, so I ship him a binary to verify the problem is gone, and push an update. I can do all of this without needing to bring my work laptop on vacation with me, because I can have my customized vim on the server.
Also, I don't feel that I'm any less productive than someone with an IDE. When I switched to VIM, I was very unproductive. I kept making simple mistakes, because I was so used to the IDE fixing things for me. However, once I got used to it, I was able to write code as efficiently (if not more efficiently) than with an IDE. But there is a noticeable learning curve.
If you can show me an IDE I can use when I ssh in from a beach in Hawaii on my wife's personal laptop, then maybe I'll consider switching. But for now, VIM is enough of an IDE for me.
That being said, I have a theory along these lines. I wrote a song about it. Want to hear it? Here it go:
Dynamic languages are so hard to deal with that libraries with complicated external APIs die quickly. This ends up exerting a hell of a darwinian pressure on them, where the libraries that survive are complete-enough-to-be-useful but have very tight external APIs.
The statically typed languages, with their naval-helicopter-whop-whop-whop-ing IDEs armed to the hilt with code completion, navigation, code-gen and thermo-nuclear refactoring tools, do not put nearly as much pressure on the API designer to keep the external interface tight, and thus you get the baroque J2EE-style sh*t shows.
So, while I don't view IDEs as a language smell, I do think that they have, indirectly, contributed to the observable sanity-gap between the libraries for dynamic and static languages.
"Conclusion: A Need For IDE's Is a Language Smell" != "IDE's Are a Language Smell"
I actually agree with that Languages THAT NEED an IDE smell... but that's not the same thing as saying IDEs are a language smell.
My first language was PHP, I can still type out in vim most things with few trips to php.net because when I first learned it I just used a basic text editor that didn't even do syntax highlighting, and so I had to memorize most of the standard functions because it was too annoying/time-consuming to keep referencing php.net. Some years ago I learned Flex and to this day I can still only get things done with the Flash Builder IDE, coding with just a text editor is strenuous and Adobe's docs aren't as good for quick reference as PHP's. Could I do it without Flash Builder if I tried harder? Sure. But the point the author gets at is that for some languages the first suggestion is an IDE, and that says something about the language and its common libraries (and programs written in it). There's also an interesting (to me) difference in the way *nix C programs are written and the way Windows C programs are written; the presence of an IDE can't be the single determinant of a language's complexity.
Among other programmers I know I'm one of the few who doesn't use Visual Studio for C or C++, nor do I use Eclipse or Other for Java. I think this is due to my fortune of learning the languages in similar fashion to PHP, whereas with Flex I learned on-the-job. I use those IDEs only when I have to, i.e. for a school project. I have nothing good to say about Visual Studio after using it some dozens of times, though I hear it's nice from C# people who have embraced Microsoft's offerings completely (which are admittedly nice so long as you don't try to do things differently). The only thing I sort of like about Eclipse is the environment around the Java debugger--oddly I like gdb but not jdb. Though I only use it when judiciously placed print statements aren't helpful enough (such as in projects so complex I can't understand the control flow without stepping through with a debugger).
Anyway, the tradeoffs are known. I wouldn't tell companies to jettison their IDEs, I'd just say let me use vim+Linux if I happen to work there and am already familiar with the language (I bet I'll be more productive than IDE users) or else get me the best IDE money can buy if I'm not.
I see no data based evidence of your coding being faster than IDE coding. In my experience of comparing me with myself, I am an order of magnitude faster in accommodating reviewer comments and changing the code design when using a good refactoring IDE, as opposed to menially updating 10s of code reference points manually.
I'm also significantly faster in identifying problems in unknown code using an IDE, especially if the IDE has tracing support. Tracing being exactly what printf debugging gives you, except that it's faster to setup and easier to cleanup when the debug fest is done.