[ Context: Steve Yegge wrote a blog post about why XEmacs should role over and die. While I agree with his main point, I disagree about his vision of the future for Emacs. ]
I know it is controversial point of view, but see it this way: Emacs is really a lousy OS with only cooperative multitasking. And as a platform, Emacs is a joke compared to the Common Lisp environments. However, as a text editor it is brilliant. And the brilliance doesn't mean it is better editor for a specific kind of text (say programming) than any more specialized editor (say a specialized IDE). The brilliance is that it treats everything as text, and gives a uniform interface to editing (or browsing) the various kind of text. When Emacs is best, it conforms to a matrix similar to the major modes (one for each kind of text) and the minor modes (one for each functionality), where the functionality is adapted to each kind of text.
This view of Emacs, as an application rather than as a platform, is why I say: Please don't add multi-language support to Emacs.. Yes, people like to write applications in their preferred language. But people shouldn't write applications in Emacs. They should extend Emacs. To extend something, you have to read and understand the existing code.
Today, if I encounter a bug or "missing feature" in Emacs, I have to know one, or at most two, languages to fix it. Emacs Lisp in most cases, perhaps C if it is something more fundamental.
During the time I have used Emacs the "cool extension language" have switched between APL, Snobol, Icon, Rexx, Awk, Turing, Perl, Tcl, Python, Java, JavaScript, PHP, Ruby, and more. Had Emacs been multi-lingual, there would have been packages contributed in all of these languages. Adding a new row or column to the matrix of functionality would mean knowing how to play nice with code in all of these languages, and likely debug it as well.
In practice, it would likely mean that I'd have the choice between using the Python based LaTeX mode with one set of functionality, or the Perl based LaTeX mode with another set of functionality, because the programmers had different preferences. Yes, there can be multiple packages with similar functionality all written in Emacs Lisp as well. I know, when I maintained AUCTeX, I stole liberally code from Vortex and CMUTeX whenever users suggested features from those packages. All being written in Emacs Lisp and distributed under the GPL made it easy.
Lisp is a good choice for an extension language for a long lived application mostly because of its age and lack of syntax. The lack of syntax means less to learn, and also mean that whatever its popularity elsewhere, it will always have a niche in computer science research.
If you want to make Emacs more OS like, I'd much prefer true multitasking.
2 comments:
Hi Per, and thanks for the thoughtful post.
I believe that an equivalent plea to "Please don't turn Emacs into a multi-lingual environment" would be: "Please learn other languages as appropriate" (aimed at developers in general.)
However, 20 years of experience has shown that this plea falls on deaf ears. :-)
I was at an absolutely mind-bogglingly fascinating discussion at Foo Camp last summer, hosted by the LLVM guy at Apple (I'm sorry, but I've forgotten his name, sigh), and attended by the VM implementors or representatives from pretty much every VM on earth, and the subject was how to get languages to interoperate.
The short summary was: chaos. People were debating ferociously long into the night (seriously). But it's clearly 10 years of work, or more, for our whole industry.
That said, if they can interoperate "seamlessly" (for some definition), including cross-debugging, syntax translation, etc., then the barriers you rightly fear should become much less significant in practice.
In the fullness of time, languages on the same VM should be able to call each other, share a common underlying semantic substrate for things like concurrency, and have a common universal syntax tree. What I'm proposing is a good multilanguage environment. It's going to be a long time in the making, but it will happen eventally.
Might as well do it in Emacs!
And yes, some decent concurrency support would be a necessary first step (and could happen independently.) Some updates to the Lisp interpreter would be nice, too. Read macros, anyone?
I just read your blog, following Stevey's blog, as well as his comment here.
I disagree with your point of view on the whole, and more agree with Stevey. (although understandably the subject matter and what exactly is each's opiniion, is somewhat vague... )
For example, your opinion is that emacs shouldn't become a platform where its extension can written in multiple language... while Stevey thinks it should... even though there is no precise definition on what we mean or want, but I tend to agree with Stevey here in general.
But mostly, few remarks in your blog raized red flags to my eyes. They are:
• «And as a platform, Emacs is a joke compared to the Common Lisp environments.»
This remark i find sufficiently vague and hand waving. I'm not preliged in age to have used Lisp Machines. I have just heard their legacy, and have just read about them over the past 2 decades, i do believe in their quality being a few magnitude better than, say, unix. But such a broad, general claim, above, i find questionable.
• «During the time I have used Emacs the "cool extension language" have switched between APL, Snobol, Icon, Rexx, Awk, Turing, Perl, Tcl, Python, Java, JavaScript, PHP, Ruby, and more.»
Although it is true that computer languages comes and go, and programers follow trends and fashions in a bad sense of those terms. But i find the above remark just too vague. Just about every old programer, flash it out to prove his opinon on XYZ.
I'm 40 years old. My professional programing career started in 1995. So, i have not experienced APL, Snobol, Icon, Rexx. (and have not heard of Turing) However, i personally and intimately witnessed the birth of Java throughout its growth and life. As far as i know, Java has never been considered as a extension language, and is rather is a odd one out among your list.
• «Lisp is a good choice for an extension language for a long lived application mostly because of its age and lack of syntax. The lack of syntax means less to learn, and also mean that whatever its popularity elsewhere, it will always have a niche in computer science research.»
I also have issue with the statement above. In my opinion, it has absolutely no basis, in the claim that lisp's “age” makes it a good extension lang choice, nor is there any basis in its “lack of syntax” making it a good extension lang choice.
Also, the statment “The lack of syntax means less to learn” to me is just all too typical of unsubstantiated claim of hardcore lisp devotees.
... i'm a dedicated fan of functional programing, and am also a fan of lisp in general, however, i'm a ardent critic of lisp and its community. Many of old time lisper's claims, popular in lisp community, i consider patently untrue or unsubstantiated, not unlike the type of beliefs pleasant to hear and popular for XYZ language cliques.
Xah
xah@xahlee.org
∑ http://xahlee.org/
☄
Post a Comment