"I have a mind like a steel... uh... thingy." Patrick Logan's weblog.

Search This Blog

Saturday, November 22, 2008

The Emacs Way

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.

9 comments:

Anonymous said...

Emacs is a good IDE, perhaps the best, when it comes to Lisp. SLIME combined with SBCL is awesome. I cannot say enough good things about it.

Emacs as an easily configurable editor just plain stinks. Having spent well over an hour this evening just figuring out how to set the default column-width (for wrapping), and learning that emacs refers to gutters as 'fringes', I can see why anyone might hesitate to use Emacs, even if it is the best of the best IDEs. Setting up Emacs as an IDE is no easy feat, either, and it will take the new user some time and googling to learn how to configure his Emacs, if he's willing to give it that much. And if he can get past setting up his SLIME and SBCL, he'll need more time to learn how to configure his tabs to indent, as well as learn how to set up parens so they automatically close with each new opening (he will need an ".el" file for this.)

No IDE in 2008 should be this difficult to set up. Sure, there's Lisp-in-a-Box and ReadyLisp, but is it saying much for Emacs that anyone has to download these at all? If BBEdit or JEdit had easy access to SLIME and SBCL, I'd bail, no question.

Dominique Boucher said...

For a language like Clojure, which offers a tight integration with the Java platform, I think Eclipse (or IntelliJ, but I have no experience with it) may be a surer bet.

First, the environment gives you access to a complete model of the Java projects in the workspace. This means you can provide lots of useful tools that can take advantage of it.

Also, it may be easier to sell Clojure to Java developers as they won't have to switch to another IDE to try and use it. They will be able to make Java and Clojure code coexist in the exact same environment they use daily.

That was the main reason that led me to the implementation of SchemeScript, and that paid.

That said, I also use Emacs on a regular basis, and I wrote my faire share of Emacs Lisp code. And frankly, I MUCH prefer writing Emacs Lisp modes than Eclipse plugins in Java or Scheme. It's just so painly having to close the IDE and restart it each time you make a change in your code...

Anonymous said...

you don't need a .el file for automatically closing parentheses. All you need to do is set up a "skeleton-pair" for the parentheses:

(global-set-key (kbd "(") 'skeleton-pair-insert-maybe)

add that to your .emacs and you've got automatic pairing, à la TextMate (since that seems to be the reference point these days for talking about lesser-known Emacs features that got re-implemented in TextMate). Just switch the left paranthesis for any other thing that you want to automatically pair "[", "{", etc...

Really, the problem with learning emacs is having the patience to sit down and do two things:

1. Do the tutorial
2. Read the Emacs info ages end to end.

Doing this will take less than a day and will save the sort of heartache that the first poster is talking about. Another day reading the emacs wiki and of Googling around to find nice stuff to put in a .emacs file (keywords ."emacs" and "dotemacs" and what .el packages other people find useful (keywords "emacs tricks" "effective emacs" "favourite emacs packages").

It's not really that hard, it's just a question of putting in the time (2 days). Two days to learn the basics of setting up and using an editor that will save you immense amounts of time whenever editing any type of text throughout your whole life is really a small price to pay.

Anonymous said...

Thanks for the link to Stallman's paper. It answers a few questions I had, but it is a generic overview.

Can anyone recommend other introductory materials? People that love Emacs tend to really love Emacs--is there a path to enlightenment that doesn't make a newbie screw up their nose and walk away? Something like "The Emacs Way" for using Emacs, not writing one?

Patrick Logan said...

As anonymous #2 wrote, a good place to start is with the tutorial. Once you've installed and invoked emacs, type the key sequence "control-h" then just "t". This starts the tutorial.

I've not looked at it, but just glancing at the web site indicates there is a decent book... http://oreilly.com/catalog/9780596006488/

James Abley said...

I take it you're familiar with this? That's what pushed me into getting the O'Reilly Emacs book and really knuckling down with it. I've still got a lot to learn, but every so often I get a glimpse of the streamlined, awesome flow that is possible with Emacs. Then I'm left grinning like an idiot for 5 minutes, marvelling at what I just experienced.

Anonymous said...

Anonymous #1 here.

I applaud anyone who wants to learn Emacs in a thorough manner. More power to them. Emacs makes a fine environment for many things, even editing, if you don't mind the defaults.

I do not want to learn Emacs thoroughly, however. I have no reason to. Most things I write require nothing more than a plain text editor, and for those few things I need something with more oomph, I've found JEdit and other editors do just fine. No real learning curve beyond the basics.

I am not alone, I think. Many people, programmers included, are quite happily working away with no knowledge whatsoever of Emacs. Were it not for my desire to know Common Lisp, I never would have tried Emacs. I can learn Scheme on DrScheme, Java on NetBeans, PHP on vim, HTML on Notepad, and all of the above (excepting Scheme) on any number of easy-to-learn programming editors.

Keep in mind, folks, I'm telling this to you from the perspective of a guy who merely dabbles in programming, who doesn't do it for a living. Emacs is all that and the kitchen sink. It is not, however, easy to learn, and if it takes me, someone who's worked with everything from EDT on a VAX to nano, Eclipse, Dreamweaver, vim and more - if it takes me a lot of time to learn, that's saying a bit.

It could be I'm just stupid. There's always that.

Or it could be, no matter how l33t Emacs is, it will gain little traction among the majority of programmers so long as its attitude is "Screw the programmer! It's my way or the highway!"

Emacs, of course, is not saying this, but its topmost interface is not nearly as user friendly as it could be. I understand if this interface is difficult to address; afterall, Emacs has a long history and a devoted user base. Why should Emacs change? they might ask.

On the other hand, if you wonder why programmers, or anyone else, should cringe at the thought of learning Emacs, I'm giving you the perspective of one Emacs user who would prefer not to use Emacs. Take it as you want, neither Emacs nor I will be affected.

I work with roughly a dozen people who develop code, who administer databases and Linux servers, etc., and not a one, except me, has anything to do with Emacs. They don't miss it, they don't care, and they won't try it because they have no reason to. They are happy with vim or whatever their GUI editor is. They have had to switch editors when they've switched OS, but instead of going from UltraEdit to Emacs, they go for BBEdit or something else.

Something that doesn't require one to two days to learn. *g*

Patrick Logan said...

"but its topmost interface is not nearly as user friendly as it could be"

By "user friendly" I read to mean "familiar". Emacs is very friendly to me, even familiar. But I understand in this day and age it is not familiar to most people. Even though it would be very friendly to them, were they to get to know it.

Anonymous said...

Anonymous #2 here.

@Anonymous #1 — you do have a point in referring to Emacs' user-unfriendliness, it is not a point and click interface. There are two ways to think about that, I think. The first is to say that it is an old interface, something created for the command line and long before software started to benefit from the work of people who devote their work soley to making better user interfaces (more on that, I will come back to it).

The second way to look at it is to see it not as just any user interface, but as a professional's user interface. I hear the howls coming already from vim users, so I will qualify: it is a professional's interface for the professional who wants complete control over their editor, where vim is for the professional that wants an editor that just works out of the box with some small setting-fiddling.

It turns out that there are those who would disagree with both those points and, instead, argue that Emacs has a superior interface. Asa Raskin, the son of Jef Raskin the original head of the Mac team at Apple and the carrier of his father's thinking on good interface design, insists that Emacs is not only a good user interface, but a superior user interface, precisely because of its configurability:

http://humanized.com/weblog/2007/10/05/make_oss_humane/

Rasking admits that Emacs' weakness is the cost of learning it, just as we have been discussing here.

There has been a very successful attempt to point-and-click-ize Emacs and that is TextMate:

www.macromates.com

and its windows imitation:

E-texteditor

I've used TextMate and it is fair to say that it is a simplified Emacs, despite its being complex enough to justify a book being writeen to explain the finer points of using it. TextMate seems to be what the doctor ordered as far as for allowing modification to how text gets edited, but still allowing the new user to get going quickly. It has even "contributed" and idea back to Emacs, the system for managing insertable text snippets. While Emacs had a system for using snippets — 'abbrev', it is ad hoc in nature, and not quite as flexible as TextMate's snippet management system. People who liked the idea have already added it to Emacs, the best version being, in my opinion, yasnippet.

For me, it depends on what you want, if you want an environment for writing text editors, then you choose Emacs, if you want the pro tool, but don't want the massive configurability, you choose Emacs, if you're a newb and just want to get going and will come back to looking at the hoary old tools from the 70's and 80's, trying to guess what the zealots are on about, then maybe you choose TextMate, maybe something else with a little less power.

Blog Archive

About Me

Portland, Oregon, United States
I'm usually writing from my favorite location on the planet, the pacific northwest of the u.s. I write for myself only and unless otherwise specified my posts here should not be taken as representing an official position of my employer. Contact me at my gee mail account, username patrickdlogan.