Kent M Pitman <······@world.std.com> wrote:
> [...] "languages that restrict what's possible to reason
> about by what's known to be possible to implement" vs "languages that
> offer tools for how people really want to reason and make a commitment
> to find a way to implement it". Most languages fall in the former
> camp. C and (I think) Scheme among them. [...] In Scheme, many
> things are not there just to keep things small, but some are absent
> also because they're hard to implement efficiently.
Perhaps you think so out of communications with influential designers of
Scheme, about whom you know much more than I do, and I'm certainly not
trying to push aside any experiences you may have with them. However, and
this isn't necessarily in contradiction with what you wrote, I'd like to
add another view on Scheme using these categories, where it does end up
in your second group: Many people who like Scheme have the view that a
few simple ways of forming abstractions will be sufficient to create many
abstractions, and that implementations should be (continuously) optimized
to make more and more complex abstractions affordable. For example, instead
of having one object system built into the language - expecting that Scheme
translators and runtime systems will provide special support for it, and then
all users will "naturally" prefer that one over many other systems, merely
because it's "the standard", even when there may be better approaches for
different problems - there is a view that various ways to organize programs,
e.g. using different object oriented principles via procedures and other
data types, should be normal, and that implementations should support such
usage of ordinary Scheme as general abstraction construction kit efficiently,
that Scheme designers shouldn't coerce people into one such system, as long
as there's no clear view that it's _the_ right one. Instead of many control
structures, procedure calls and continuations are used to implement many
common and not so common control structures as needed, and implementations
are simply expected to make that affordable, even if not all implementations
do always succeed for some particular solution. Considerable research went
into these questions, sometimes with surprising general solutions which can
be used for many other purposes, not just for some specific problem due to
which someone wanted the general mechanism to be faster. Is Scheme as it is
due to concerns for efficiency, even where a conceptually satisfying feature
is clearly seen? I don't know, but I know that many people who like Scheme
don't argue a lot based on a fear of inefficiency, but much more based on a
perfectionistic struggle for conceptual purity - whatever some particular
person may understand by that notion (for example, first-class environments
are sometimes rejected due to feared inefficiency, but far more frequently
I've seen it rejected because one doesn't want to mix the static denotation
of identifiers with the dynamic behaviour of environments, which should be
made explicit as mapping/lookup mechanism in their own right).
Now we could probably easily agree that this or that feature is missing in
Scheme if one wants to use it towards such purposes, but then we could as
well find some things in Common Lisp which should be there, but which are
not (yet) there, for various reasons, about which you'll know more than
I do. From a practical viewpoint, for some tasks, Common Lisp as it is now
will surely be a superior tool compared with Scheme as it is now, but I'm
not convinced that the "spirit" of the language Scheme is so clearly on
the side where your above ordering seems to put it. I think the ways many
people who prefer Scheme want to think about problems, solutions and the
abstractions to describe them, are frequently simply different from those
which one is likely to find with people who prefer Common Lisp, but both
can and often do go quite far in using their languages as tool expressing
the concepts which they want to use. The evolution of Scheme to incorperate
some construction tools may be slower, perhaps since for the language (not
necessarily particular implementstions, which frequently experiment beyond
the language standard), many people in the Scheme community tend to value
careful progression of general tools over quick progression for particular
problem areas - among other things, based on the experience that usually
it's much harder to get some feature out of a language and it's established
ways of discourse than to get it in. I don't think there's any clear-cut
"right" for either side, but both approaches to programming language design
have different advantages and disadvantages, and the "best" trade-off can
only be found for a given situation, not as "truth" for all cases. I guess
the history of each of those two languages, with different audiences and
also quite different interests on the side of many implementors and users
(e.g. preserving investments by compatibility with existing practice) have
much more to do with the differences. In my view, the wish for expressive
abstractions isn't really a very clear line of division between them.
-- Marc Wachowitz <··@ipx2.rz.uni-mannheim.de>
From: Kent M Pitman
Subject: Re: Ambiguous Categories (was Re: CL & CORBA)
Date:
Message-ID: <sfwiuj07tnm.fsf@world.std.com>
··@ipx2.rz.uni-mannheim.de (Marc Wachowitz) writes:
> ... I'd like to add another view on Scheme using these categories ...
I enjoyed reading your response. As you might imagine, there is a lot
I could say in response to what you've written--and perhaps one of
these days soon I'll try. I don't have time to today, and partly
because you've made some of the points well and to follow them in a
way that is properly thoughtful will take me some time. And you
shouldn't assume that I just out-and-out disagree with you either.
I just come at some of the issues you mention differently, and my
conclusions are consequently different (though the judgment is
subjective). I think it's good for people not to get too one-sided a
view of the world. Wisdom comes from understanding the world is full
of choices, and dogma from believing the wisdom of a choice is
captured in the choice that was made rather than the thought that was
behind it. Both your comments, and Erik's, give this conversation a
nice neutral overall tone and hopefully leave people with plenty to
think about. So remind me another day and we'll pick up from here.
Or maybe others will chime in with still more points of view.
--Kent