I, too, question the basic assumptions behind RMS' article.
Underlying all of them, including the one you mention here, is the
assumption that the "lessons learned from ... Emacs" are applicable in
the same programming environment that spawned Tcl. I strongly
question that assumption.
RMS> The principal lesson of Emacs is that a language for extensions should
RMS> not be a mere "extension language". It should be a real programming
RMS> language, designed for writing and maintaining substantial programs.
RMS> Because people will want to do that!
Emacs was written for a user interface consisting of one
character-based terminal, and for most of its existence it has seen
use primarily in that same environment. People *did* want to extend
Emacs with all kinds of unexpected functionality, because it was nice
to stay in your editor while {reading news,reading mail,compiling,etc.}.
I was a big fan of Emacs at that time, and I *loved* the trend toward
lumping everything into Emacs --- it made my life a lot easier.
Tcl and Tk, on the other hand, have been born into a windowed world.
Huge, monolithic applications like Emacs which do everything are less
important, and smaller, specialized programs which can cooperate are
needed.
I spend quite a bit of my time these days using mxedit (a Tk-based
editor). I have no desire for anyone to build a newsreader, a
mailreader, a directory browser, a debugger interface, or any of those
other things into mxedit. What I *would* like to see (and it has
happened in the case of the mailreader and debugger interface) is
separate applications which cooperate with my editor using the Tk send
facility. I believe that this is a better approach.
RMS> Extensions are often large, complex programs in their own right, and
RMS> the people who write them deserve the same facilities that other
RMS> programmers rely on.
Emacs was also written when dynamic linking was a rarity. Extending
Emacs at the C level was painful, in part because of the strained
interface between C and elisp, but mostly because an entirely new
Emacs binary would have to be generated. This process was difficult
enough that an Emacs extension distributed as C code stood very little
chance of being widely used.
Now, dynamic linking is quite common, and becoming more so. It's
already ubiquitous in the DOS/Windows world. Tcl is being extended to
take full advantage of dynamic linking, with the added benefit that
Tcl extensions can be shared in a machine's storage. And Tcl's
interface for writing C extensions is a beauty. Many of the pressures
which led to enormous, complicated extensions in Emacs lisp are going
away.
RMS> The first Emacs used a string-processing language, TECO, which was
RMS> inadequate. We made it serve, but it kept getting in our way. It
RMS> made maintenance harder, and it made extensions harder to write.
RMS> Later Emacs implementations have used more powerful languages because
RMS> implementors learned from the problems of the first one.
This silly paragraph relies on yet another assumption: string-processing
languages are all equivalent. I rather strongly suspect, from my
knowledge of TECO, that its string-processing nature was not the
primary reason for abandoning TECO as the Emacs implementation
language. Certainly there were others.
Back to Wayne Throop's comments:
>
> RMS proposes to have two languages, both of which scale all the way from
> simple users to the most complicated cases. Tcl advocates propose to
> have two languages, one of which concentrates on power and
> functionality, the other on being lexically inconspicuous glue with a
> shallow learning curve. I submit to you that RMS's pair of languages
> decompose the domain in the "wrong direction", both being vertical
> monoliths instead of being horizontal layers with modest goals.
Indeed.
Regards,
Glenn Vanderburg
"If you've been pounding nails with your forehead for years, it may feel
strange the first time somebody hands you a hammer. But that doesn't
mean that you should strap the hammer to a headband just to give your
skull that old familiar jolt."
---Wayne Throop