I had a good beer talk
this week with Merlyn about IDEs and Emacs. Merlyn's been playing
with Clojure, a Lisp for the JVM. And he was looking at the effort it might take to provide support for Clojure in IntelliJ. Our conversation started briefly before the
http://xpdx.org meeting.
"Why not Emacs?", I asked.
Merlyn's face scrunched up a bit in that look that Emacs seems to cause on many programmers' faces.
"Emacs has had great support for Lisp for decades.", I pleaded. "I like that Clojure is bringing a lot of programmers to Lisp these days. You only have to learn a bit of Emacs to use it for Lisp. It's not any harder than learning Lisp itself."
"Yeah. Maybe", Merlyn told me, unconvinced. Then the meeting began.
After the meeting, over at the Side Door, with a good, draft Pilsner in hand, I was asked by Merlyn, "What's the fundamental difference between an IDE like IntelliJ or Eclipse and Emacs?"
The argument I made was this: In Emacs, everything is a buffer. If you edit a program, it is in a buffer. If you edit a directory or even just choose a file in a "dialog", it is in a buffer. Some of the functions in the directory buffer are directory and file-specific. Most are just general editing functions. If you run a shell or any subprocess, that process' input and output is in a buffer.
And across all these buffers the contents are made up of text, but also things analagous to words, sentences, paragraphs, etc. Many functions operate as expected within "text editing" even though the more specific mode is for files, or programs, or email, or whatever.
I compared this to what little I know of the Eclipse-like IDE, especially Eclipse as a framework for building extensions. In Emacs this is easy and many people build small or large extensions. In Eclipse my sense is this is relatively more complex and not as many people, as a percentage of total users, extend Eclipse in any significant way.
Here's what I think the Eclipse framework provides: an "architecture" for an editor. There is an implementation of the text editing area; there is an implementation for those tabs at the bottom where build results and test results go; there is an implementation for those trees to the left where file and class hierarchies are displayed; and there is an implementation for the pop-up dialogs that ask you to choose a file or set a property of some kind.
The problem is these are all big imposing structures with an "A.P.I." - users cannot edit their contents in general ways, and extenders cannot extend them in general ways. They a "CLASSES" which are supposed to be "ABSTRACT" and "MAINTAINABLE".
Horse hockey! The Emacs way wins even if the culture is all for IDEs as a Pascal-ish Pyramid.
Wel, I didn't explain my reasoning with that much enthusiasm, but by the end of our discussion I *think* Merlyn's willing to give Emacs a try.
Some references...
The foreward by Perlis does not address text editing or Emacs at all. It addresses Lisp. The Emacs way *is* the Lisp way. They grew up together. Neither would be as good without the other. Maybe neither could have existed for so long without the other.
From Perlis...
Algol 60, never to be an active language again, lives on in the genes of Scheme and Pascal. It would be difficult to find two languages that are the communicating coin of two more different cultures than those gathered around these two languages.
Pascal is for building pyramids -- imposing, breathtaking, static structures built by armies pushing heavy blocks into place. Lisp is for building organisms -- imposing, breathtaking, dynamic structures built by squads fitting fluctuating myriads of simpler organisms into place.
The organizing principles used are the same in both cases, except for one extraordinarily important difference: The discretionary exportable functionality entrusted to the individual Lisp programmer is more than an order of magnitude greater than that to be found within Pascal enterprises. Lisp programs inflate libraries with functions whose utility transcends the application that produced them.
