我更喜欢IDE，因为它允许我集成编辑/编译/调试，只需单击一下从错误跳转到生成错误的行。此外，它允许使用操作系统标准接口显示多个信息窗格。简而言之，它为用户提供了一个基于鼠标的输入界面和一个现代的输出界面，而不是依靠上世纪70年代的技术和界面来帮助我。

IDE还有更复杂的用户和用途，我并没有说我使用过他们或了解他们所有人。当我需要的时候，我会学习它们。

我从相反的方向来回答这个问题。我从小就在Makefile+Emacs的环境中编程。从我最早的DOS编译器，微软的Quick C，我有一个IDE自动化的事情。我在Visual c++ 6.0上工作了很多年，当我毕业到Enterprise Java时，我使用Borland JBuilder，然后决定使用Eclipse，这对我来说已经变得非常高效。

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.

我了解到，要与团队一起进行大规模开发，如果我们使用IDE开发代码，并使用手动编写的命令行脚本进行所有构建，那么我们可以获得最高的效率。(我们喜欢用Apache Ant进行Java开发。)我们发现在IDE中运行我们的脚本对于复杂的构建来说只是一个点击或者自动化的噩梦，用alt+tab到一个shell并在那里运行脚本要容易得多(而且破坏性更小)。

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.

当“文本编辑器”实际上是emacs时，我认为做经典的“文本编辑器和控制台窗口vs IDE”是不公平的。IDE:s的大多数典型特性也在emacs中。或者它们甚至起源于那里，现代IDE主要是界面的改进/简化。

这意味着对于最初的问题，答案并不是那么明确。这取决于所讨论站点的用户如何使用emacs，是主要将其用作文本编辑器，还是完全使用自定义脚本，学习相关模式的命令，了解代码标记等等。

I'm not sure there's a clear dividing line between a text editor and an IDE. You have the likes of Notepad at one end of the scale, and the best modern IDEs at the other, but there are a lot of thing in between. Most text editors have syntax highlighting; editors aimed at programmers often have various other features such as easy code navigation and auto complete. Emacs even lets you integrate a debugger. The IDEs of even ten years ago had far less features to help programmers than you'd expect of a serious text editor these days.

对我来说，这肯定会提高我的工作效率。我甚至在Vista上的Visual Studio中编写Linux应用程序，然后使用Linux虚拟机来构建它们。

你不需要记住函数或方法调用的所有参数，一旦你开始输入它，IDE就会告诉你需要什么参数。您可以使用向导来设置项目属性、编译器选项等。您可以在整个项目中搜索内容，而不仅仅是当前文档或文件夹中的文件。如果你得到一个编译器错误，双击它，它会直接把你带到有问题的行。

集成了模型编辑器、连接和浏览外部数据库、管理代码“片段”集合、GUI建模工具等工具。所有这些东西都可以单独使用，但是将它们都放在同一个开发环境中可以节省大量时间，并使开发过程更有效地进行。

作为你在你的问题中强调的回答的作者，并且承认这一点有点晚了，我不得不说，在列出的许多原因中，专业开发人员的生产力是最受重视的技能之一。

我所说的生产力是指高效地完成工作并取得最佳结果的能力。ide在许多级别上都支持这一点。我不是Emacs专家，但我怀疑它缺乏主要ide的任何特性。

设计、文档编制、跟踪、开发、构建、分析、部署和维护，这些企业应用程序中的关键步骤都可以在IDE中完成。

如果你有选择，为什么不用这么强大的东西呢?

作为实验，让自己使用一个IDE 30天，然后看看感觉如何。我很想听听你对这次经历的看法。