[jack9]

When saying he works with a bunch of different languages and projects, but then prefers Vim...It's great that Vim is better for older practiced vi programmers (or opinionated middle aged), but the A/B testing is definitive for new developers. IDEs are more efficient for most languages (especially multi-language projects). Reducing the argument to "it shouldn't be this way" is luddite.

[gravypod]

Not to mention the millions of features that I can't even begin to enumerate that I use on a day-to-day that I wouldn't have the time in my life to master without an integrated uniform method of interaction. Two of the best examples are Eclipse's build system and hot code patching in debug mode.

The build system lets me forget entierly about "how am I going to write my tup/make/cmake/anything file" as it just works when I click go.

The hotpatching debugger support is astounding. Nothing comes close to such a seamless integration as being able to change my code and click "go" and have my new method ready for action to see if it works on the next run.

You also get free autocompletion for everything. Oh god the ease of life autocompletion gives you. I miss it every time I need to tough another language.

[charrondev]

As someone that bounced between Android development and webdev, who now does webdev full time, I can say the my biggest 2 complaints were always the build system and tooling surrounding the ecosystem. Luckily things have changed a lot in the web development world in the last two years. TypeScript and Visual Studio code deliver the autocomplete that I've wanted in web development for a long time and bring static typing to javascript, as well as handling the transpiling of new javascript features to older syntax all directly in the editor.

Webpack's hot module reloading is also incredibly useful if you take the time to set it up. You don't even need to hit 'go'. When you save a file, it incrementally compiles that module, and swaps it out on the client. This process is normally faster than me tabbing over the other window, and if you have you're project set up correctly, preserves the app state if it can.

[kayman]

I also love IDEs. Java without IDE - forget it.

But let me point you to the classic article by Steve Yeggie who inspired my commitment to emacs.

https://sites.google.com/site/steveyegge2/effective-emacs

[crpatino]

> The build system lets me forget entierly about "how am I going to write my tup/make/cmake/anything file" as it just works when I click go.

This is a bug, not a feature. Or rather, it is extremely easy for this to result in subtle "works on my machine" scenarios.

1. If you just "click & go", you are foresaking the ability to have automated builds.

2. If you implement the automated build independently from the IDE, you will end up in a setting where the developer makes changes to the IDE settings that are not reflected in the automated build. In a good day, this will result in broken builds. On a bad day, you will have bugs that are imposible to reproduce because the build QA uses is not the same as the build Development uses, even if they both come from the same SVCS. On an ugly day, you ship to your customers a binary version of the product that neither QA nor Development have ever tested before.

3. Not to mention that if you have no version control of the IDE settings, every developer has a slightly different build of the project, one that mostly works, until it does not. See the problems in #2 and extrapolate.

[gravypod]

> 1. If you just "click & go", you are foresaking the ability to have automated builds.

This is incorrect. Eclipse will generate ANT files that are usable via TeamCity.

> 2. If you implement the automated build independently from the IDE, you will end up in a setting where the developer makes changes to the IDE settings that are not reflected in the automated build. In a good day, this will result in broken builds. On a bad day, you will have bugs that are imposible to reproduce because the build QA uses is not the same as the build Development uses, even if they both come from the same SVCS. On an ugly day, you ship to your customers a binary version of the product that neither QA nor Development have ever tested before.

Again, just keep your ANT file in your source tree and export it after every change. This require far less maintenance then Make or cmake.

> 3. Not to mention that if you have no version control of the IDE settings, every developer has a slightly different build of the project, one that mostly works, until it does not. See the problems in #2 and extrapolate.

The build settings are stored in the project files. When you download the project and import it into Eclipse your build enviroment is kept in line.

In larger projects I use a CompanyLibraries project and inside it I have 1) all libraries, sources, and documents neatly organized along with all binaries involved with that library (so if it needs to import a .so or .dll it's there) and the IDE-Bootstrap process:

   1. Go into your settings and import *.userlibraries
   2. Go to your settings and import cleanup.xml
   3. Go to your settings and import codetemplates.xml 
   4. Go to your settings and import format.xml 

You don't need to import the generated ant build system. You can right click it and run the build & tests from there.

After you do this you have complete autocompletion for every library we use. If needed you can cntrl-click to view source of a library, and it will work on your system even if you have windows or linux (because of the way I setup my .userlibraries). These are some from what I've seen the "little known" Eclipse goodies for collaboration.

Could it be better? Yes I'd like to eventually write an eclipse plugin that will automatically import these on a project by project basis then just make a git submodule in each of my projects that includes the global configs to make sure I still only have one.

[jgardner1]

I'm not a luddite.

I just prefer the best tools for the job, tools that can be used with any software project. The Unix IDE is the best in the world.