Re: Bad news from the module/environment front

[Christian Lynbech <chl@tbit.dk>]

>>>>> "Graham" == Graham Hughes <graham@ccs.ucsb.edu> writes:

Graham> Tcl, for example, is very slow.  Tcl8 is somewhat faster than
Graham> Tcl7 ... But people use it nonetheless because it's Fast
Graham> Enough; all the really important bits of the app are written in
Graham> C anyway and so Tcl's relative slowness isn't an issue.

However, tcl is much closer to C than scheme, so it is also much
easier to convert a piece of tcl code to C than to do the same for
scheme.

Graham> Elisp is *ridiculously* slow for a modern day Lisp, and is
Graham> encumbered with numerous warts like dynamic scoping ...

But there just isn't any competion. Elisp is alone in the field of
emacs extension, and then speed isn't really an issue.

Graham> But thinking that speed speed speed is primary is nonsense.

Of course speed is not the only concern. But for real applications,
one must be able to reach the necessary speed.

There is a number of applications where speed really doesn't matter at
all, and certain number of applications where speed can be obtained be
rewriting smaller isolated pieces of the code in C.

However, converting 200.000+ lines of multithreaded, continuation
using, multiple inherited and multi-dispatched scheme to C/C++/Java,
just isn't my idea of a usefull solution to speed problems. Especially
given that other implementations gives a lot more rope to the
programmer *within* the core language.

---------------------------+--------------------------------------------------
Christian Lynbech          | Telebit Communications A/S                       
Fax:   +45 8628 8186       | Fabrikvej 11, DK-8260 Viby J
Phone: +45 8628 8177 + 28  | email: chl@tbit.dk --- URL: http://www.tbit.dk
---------------------------+--------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - petonic@hal.com (Michael A. Petonic)