I believe that the future of software development, if we are to survive ever-increasing complexity, lies in domain-specific languages that can express solutions measured in hundreds of lines of code, not the tens or hundreds of thousands of lines common in today's software systems.
VRI's Nile language for rendering and compositing
VRI's language for defining bit field accessors
On the right are two examples from Alan Kay's Viewpoints Research Institute. The top one is a snippet of code in the Nile language for rendering and compositing. Below it, what looks like documentation is a valid program for encoding and decoding TCP headers: it defines accessors called tcp-sourcePort, tcp-destinationPort and so on. (The complete parser for this, and other ascii-art programs, is 77 lines of code.[1]) This second example may seem a bit gimmicky but I've included it to stimulate your imagination and to show just how different, and data-driven, these languages can be.
What does this have to do with Emacs? Well, if you are frequently using dozens of different languages, perhaps even creating your own, you want an editor that is easily extensible. Programmable. At the core of Emacs is an interpreter for Emacs Lisp, a full-fledged programming language;[2] plus excellent integrated help, code navigation, and a debugger. Because the interpreter is embedded in Emacs itself, you can write your tools and customizations interactively; your changes take effect immediately. (If you are familiar with other interpreted languages you will already know and love the convenience of a Read-Eval-Print Loop.) The many Emacs libraries and APIs can be overwhelming, but Emacs Lisp itself is quite simple.
“Writing an Eclipse or IntelliJ (or God help you, Visual Studio) plugin is a monumental effort, so almost nobody does it. This means there's no community of building and customizing your own tools [...]. Moreover, the effort to create a plugin is high enough that people only do it for really significant applications, whereas in Emacs a “plugin” can be any size at all, from a single line of code up through enormous systems and frameworks.”[3]
Of course, there are many valid, reasonable reasons not to learn Emacs. If you program entirely or mostly in Java, Windows/.NET, or OS X/iOS, there are compelling reasons to use Eclipse/IntelliJ, Visual Studio, or XCode, respectively; you will certainly get a better out-of-the-box experience, with IntelliSense and other IDE features that just work, at the expense of extensibility.
Or maybe you just abhor complexity in your tools: One of my early mentors, who to this day is one of the programmers I most respect, used nothing but dozens of Notepad and terminal windows open at once and an extra-wide taskbar along the left edge of the screen to tell them apart. True story.
...of your language: Even if you don't buy the "dozens of domain-specific languages" idea, think about where you see yourself in 10 years. Will you still be writing programs exclusively in Java? In C++?
...of your editor: GNU Emacs has been around for almost 30 years, and earlier versions for 10 years before that. It is open source (and free) software, still under active development, with a large, talented community writing extensions for every new language imaginable. Can you expect the same longevity from TextMate or Sublime Text or whatever the web crowd is using these days?
[1]:
The Nile code snippet was taken from Gezira, a 2D
vector graphics renderer. Nile and Gezira are described in the Viewpoints
Research Institute 2009 report.
The TCP/IP implementation is described in the 2007 report. The source code for TCP frames
is here and the
ascii-art parser is here.
[2]: For some Lisp evangelism, read Paul Graham.
[3]: Steve Yegge, XEmacs is dead. Long live XEmacs!. Read all of Steve's Emacs articles for some equally conflicted (but much funnier) Emacs advocacy.