I suspect there's an opportunity/lesson lurking here somewhere.
One of the biggest complaints devs have about tools is responsiveness. The more responsive a tool is, the higher time-density of information available to a developer.
IDEs tend to suck in this regard, but Vim positively shines. Many people advocate Vim because it tends to shine in this department, even though they may not consciously realize it. Responsiveness seems to be the one vital attribute for developer tools in general. (Mosh is another example of a dev tool that capitalizes on responsiveness.)
So at first glance, it's quite odd that many IDEs suck re: responsiveness. After all, this is measurable. However, the tools to measure this on desktop apps tend to be proprietary and quite involved to use. As a result, FOSS developer tools don't do this kind of measurement, and the Tragedy of the Commons results in bloated IDEs. So the environments that avoid poor responsiveness tend to be ones that matured in a world with far fewer resources.
The takeaway: if your plans for world domination also involve a dev environment to rule them all, you'd best be measuring UI responsiveness as a part of your continuous integration/testing -- and set standards and make the devs stick by them.
I have Eclipse, Netbeans, Monodevelop, and Geany right now on 12.04. And besides having some ridiculous start up times (like, ~10 seconds, then again I have this test 12.04 partition on an old IDE hard drive from 2001. "shades" I must just be a daredevil...) they are pretty snappy, and I imagine any responsiveness shortfalls are JVM disk IO, so an old IDE drive with 60 mb sequential read / write is about as bad as it gets, and I don't lose productivity to slow software with them.
One of the biggest complaints devs have about tools is responsiveness. The more responsive a tool is, the higher time-density of information available to a developer.
IDEs tend to suck in this regard, but Vim positively shines. Many people advocate Vim because it tends to shine in this department, even though they may not consciously realize it. Responsiveness seems to be the one vital attribute for developer tools in general. (Mosh is another example of a dev tool that capitalizes on responsiveness.)
So at first glance, it's quite odd that many IDEs suck re: responsiveness. After all, this is measurable. However, the tools to measure this on desktop apps tend to be proprietary and quite involved to use. As a result, FOSS developer tools don't do this kind of measurement, and the Tragedy of the Commons results in bloated IDEs. So the environments that avoid poor responsiveness tend to be ones that matured in a world with far fewer resources.
The takeaway: if your plans for world domination also involve a dev environment to rule them all, you'd best be measuring UI responsiveness as a part of your continuous integration/testing -- and set standards and make the devs stick by them.