Why should I use an IDE? [closed]

It really depends on what language you're using, but in C# and Java I find IDEs beneficial for:

• Quickly navigating to a type without needing to worry about namespace, project etc
• Navigating to members by treating them as hyperlinks
• Autocompletion when you can't remember the names of all members by heart
• Automatic code generation
• Refactoring (massive one)
• Organise imports (automatically adding appropriate imports in Java, using directives in C#)
• Warning-as-you-type (i.e. some errors don't even require a compile cycle)
• Hovering over something to see the docs
• Keeping a view of files, errors/warnings/console/unit tests etc and source code all on the screen at the same time in a useful way
• Ease of running unit tests from the same window
• Integrated debugging
• Integrated source control
• Navigating to where a compile-time error or run-time exception occurred directly from the error details.
• Etc!

All of these save time. They're things I could do manually, but with more pain: I'd rather be coding.

Code completion. It helps a lot with exploring code.

The short answer as to why I use an IDE is laziness.

I'm a lazy soul who doesn't like to do things a difficult way when there is an easy way to do it instead. IDE's make life easy and so appeal to us lazy folk.

As I type code, the IDE automatically checks the validity of the code, I can highlight a method and hit F1 to get help, right click and select "go to to definition" to jump straight to where it is defined. I hit one button and the application, with debugger automatically attached is launched for me. And so the list goes on. All the things that a developer does on a day to day basis is gathered under one roof.

There is no need to use an IDE. It is just much harder work not to.

I don't think it's fair to do the classic "text editor and console window vs IDE" when "text editor" is really emacs. Most features that are typical for IDE:s are also in emacs. Or perhaps they even originated there, and modern IDE:s are mainly interface improvements/simplifications.

This means that for the original question, the answer is not so clear-cut. It depends on how people at the site in question use emacs, if they mainly use it as a text editor, or if they go all out and use custom scripting, learn the commands for the relevant modes, know about code tagging and so on.

I come at this question from the opposite direction. I was brought up in programming with very few pitstops in Makefile+Emacs land. From my very earliest compiler on DOS, Microsoft Quick C, I had an IDE to automate things. I spent many years working in Visual C++ 6.0, and as I graduated into Enterprise Java, I worked with Borland JBuilder and then settled on Eclipse, which has become very productive for me.

Throughout my initial self-teaching, college, and now professional career, I have come to learn that any major software development done solely within the IDE becomes counterproductive. I say this because most IDE's wants you to work in their peculiar I-control-how-the-world-works style. You have to slice and dice your projects along their lines. You have manage your project builds using their odd dialog boxes. Most IDE's manage complex build dependencies between projects poorly, and dependencies can be difficult to get working 100%. I have been in situations where IDE's would not produce a working build of my code unless I did a Clean/Rebuild All. Finally, there's rarely a clean way to move your software out of development and into other environments like QA or Production from an IDE. It's usually a clicky fest to get all your deployment units built, or you've got some awkward tool that the IDE vendor gives you to bundle stuff up. But again, that tool usually demands that your project and build structure absolutely conforms to their rules - and sometimes that just won't work for your projects' requirements.

I have learned that, to do large-scale development with a team, we can be the most productive if we develop our code using an IDE and do all of our builds using manually written command line scripts. (We like Apache Ant for Java development.) We've found that running our scripts out of the IDE is just a click fest or an automation nightmare for complex builds, it's much easier (and less disruptive) to alt+tab out to a shell and run the scripts there.

Manual builds requires us to miss out on some of the niceties in the modern IDE like background compilation, but what we gain is much more critical: clean and easy builds that can live in multiple environments. The "one click build" all those agile guys talk about? We have it. Our build scripts can be directly invoked by continuous integration systems as well. Having builds managed through continuous integration allows us to more formally stage and migrate your code deployments to different environments, and lets us know almost immediately when someone checks in bad code that breaks the build or unit tests.

In truth, my taking the role of build away from the IDE hasn't hurt us too badly. The intellisense and refactoring tools in Eclipse are still completely useful and valid - the background compilation simply serves to support those tools. And, Eclipse's peculiar slicing of projects has served as a very nice way to mentally break down our problem sets in a way everyone can understand (still a tad bit verbose for my tastes though). I think one of the most important things about Eclipse is the excellent SCM integrations, that's what makes team development so enjoyable. We use Subversion+Eclipse, and that has been very productive and very easy to train our people to become experts at.