why.haml

%h1 Why Emacs

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-examples
  #nile<
    :preserve
      CompositeSoftLight : Compositor
          ∀ (A, B)
              C = (1 - B / B.a) × (2 × A - A.a)
              D = B × (A.a - C) + (A ⊕ B)
              E = B × (A.a - C × (3 - 8 × B / B.a)) + (A ⊕ B)
              F = B × A.a + (√(B / B.a) × B.a - B) × (2 × A - A.a) + (A ⊕ B)
              >> {D if 2 × A < A.a, E if B × 8 ≤ B.a, F}
  %p VRI's Nile language for rendering and compositing
  #tcpip-parser<
    :preserve
                                              { structure-diagram }
      +-------------+----------+----------+-------------------+-------------------------------------------------+
      \| 00 01 02 03 | 04 05 06 | 07 08 09 | 10 11 12 13 14 15 | 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
      +-------------+----------+----------+-------------------+-------------------------------------------------+
      \|                       sourcePort                      |                 destinationPort                 |
      +-------------------------------------------------------+-------------------------------------------------+
      \|                                                 sequenceNumber                                          |
      +---------------------------------------------------------------------------------------------------------+
      \|                                              acknowledgementNumber                                      |
      +-------------+----------+----------+-------------------+-------------------------------------------------+
      \|    offset   | reserved |   ecn    |    controlBits    |                    window                       |
      +-------------+----------+----------+-------------------+-------------------------------------------------+
      \|                       checksum                        |                 urgentPointer                   |
      +-------------------------------------------------------+-------------------------------------------------+
                        tcp -- Transmission Control Protocol packet header [RFC 793]
  %p 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.

%h2 Emacs vs. _____

“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.

%h2 Some thoughts on longevity

**...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](
http://www.gnu.org/philosophy/free-sw.html)) 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?


#footnotes
  [[1]]:
  The Nile code snippet was taken from [Gezira](
  https://github.com/damelang/gezira/blob/master/nl/compositor.nl), a 2D
  vector graphics renderer. Nile and Gezira are described in the [Viewpoints
  Research Institute 2009 report](
  http://www.vpri.org/pdf/tr2009016_steps09.pdf).  
  The TCP/IP implementation is described in the [2007 report](
  http://www.vpri.org/pdf/tr2007008_steps.pdf). The source code for [TCP frames
  is here](
  http://piumarta.com/svn2/idst/trunk/function/examples/tcp/net-tcp.k) and the
  [ascii-art parser is here](
  http://piumarta.com/svn2/idst/trunk/function/examples/tcp/structure.k).

  [[2]]:
  For some Lisp evangelism, read [Paul Graham](
  http://www.paulgraham.com/avg.html).

  [[3]]:
  Steve Yegge, [*XEmacs is dead. Long live XEmacs!*](
  http://steve-yegge.blogspot.com/2008/04/xemacs-is-dead-long-live-xemacs.html).
  Read all of Steve's Emacs articles for some equally conflicted (but much
  funnier) Emacs advocacy.