[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs Lisp and Guile

From: Noah Friedman
Subject: Re: Emacs Lisp and Guile
Date: Sat, 10 Aug 2002 00:17:49 -0700 (PDT)

>Yes, all such extensions can be done, and there are _several_ different
>incompatible object systems for Scheme, i.e., Scheme is at the stage
>where Common Lisp was 20 years ago, when there were several CL object

I don't expect that the decision is going to be made based on popularity,
but for what it's worth I agree with Sam.  I hate writing Scheme programs
because every implementation is incompatible and usually incomplete.  On
the other hand I've been able to take CL programs and run them on a
dozen systems.  

Every few decades (or less) someone gets it in their head that the large,
complex but feature-complete languages they've been using are too big for
some project, and they start all over again with some toy language that is
more suitably scoped for their project.  And then it starts accreting
features until it's just as big and hairy as the language everyone ran away
from in the first place.  Scheme has had roughly 20 years to catch up and
has not succeeded.  As a research language it seems less compelling to me
than ML and as an applications language it's less compelling than CL or

Emacs is already a big program, but program size is not the biggest concern
in software development anymore.  Lack of code sharing IS.  Too many people
have spent too many years writing libraries and interfaces in one language
or another that cannot be used by other applications that have some other
foundation, and so more people have to waste time reimplementing them.  I
for one am tired of (e.g.) being unable to reuse Perl modules in Python, or
being unable to reuse CL libraries in Emacs or sawfish.

But at this point I am not that keen on replacing Emacs' interpreter if the
idiosyncrasies of maclisp (e.g. dynamic scope) and editor-specific hacks
like buffer and frame local variables are so deeply embedded in it that the
replacement language will have to mimic all of its behavior AND try to
remain faithful to whatever semantics the replacement language
(e.g. Scheme) is supposed to have.  If you use Scheme, the resulting
language is going to be incomprehensible to anyone who knows just R5RS.

What exactly is anyone gaining by this?  Could someone explain to me why
effort should be expended on it at all?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]