newbie asks: why CL rather than scheme?
Edward Piman
on comp.lang.scheme I fail to see this same scorn for CL. Why is that? As
an outsider, I am puzzled by this bad feeling between groups who would seem
to have much in common.
I am interested in learning more about one or both languages. Scheme has
the advantage of books such as SICP and EOPL. Presumably CL has its
advantages too; anyone care to fill me in? Why (or for what purposes) is
CL better?
Christopher Stacy
Edward> Browsing posts to this group I frequently see real scorn for scheme. Over
Edward> on comp.lang.scheme I fail to see this same scorn for CL. Why is that?
Perhaps it's because Scheme fans inhabit this newsgroup, but not vice versa.
Whatever the reason, I don't think it says anything about the technical merits
of the two languages. The seeming animosity does reflect the fact that the
constituencies of the two languages have different adgendas.
Edward> I am interested in learning more about one or both languages. Scheme has
Edward> the advantage of books such as SICP and EOPL. Presumably CL has its
Edward> advantages too; anyone care to fill me in? Why (or for what purposes) is
Edward> CL better?
Except for the fact that they both use parenthesis and have one or two
functions in common, they are very different languages. For example,
the functions that are used to define a program ("define" and "defun")
do two totally different things.
Scheme was designed to teach certain concepts in computer science classes.
Common Lisp was desiged to facilitate the maintenance and new development
of a large body of existing industrial Lisp code.
Michael Hudson
> Scheme was designed to teach certain concepts in computer science
> classes.
Are you sure about this?
Cheers,
M.
--
Slim Shady is fed up with your shit, and he's going to kill you.
-- Eminem, "Public Service Announcement 2000"
Barry Margolin
>Christopher Stacy <cst...@spacy.Boston.MA.US> writes:
>
>> Scheme was designed to teach certain concepts in computer science
>> classes.
>
>Are you sure about this?
Not just teaching, but for pedagogical purposes in general: teaching and
research. Similar to the original purpose of Algol.
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Kent M Pitman
> Christopher Stacy <cst...@spacy.Boston.MA.US> writes:
>
> > Scheme was designed to teach certain concepts in computer science
> > classes.
>
> Are you sure about this?
I have been in the room of the Scheme authors (check the front page of
the Revised^n Report on Scheme to see my name in the credits) and have
repeatedly seen decisions made in favor of teaching and in opposition to
proposals that would make it easier for industry. I once endured a discussion
where it was openly stated and a fair number of people present agreed that
we needed not to make Scheme too useful too fast because the committee would
take hold. I have seen them decide (that is, I have participated in votes
where my side failed) not to clarify the behavior in places that it could be
clarified and to cite the fact that it would make the spec too long (as if
the spec as in any danger of this).
No one speaks for the authors' committee as a whole except for the
spec that is its output. We have no spokesperson. We simply get together
in person or online or (as lately) not at all, and a spec either does or
does not come out.
All impressions about the actions of any committee are complex. No
one ever really knows the minds of the other people they are with,
other than that they hear stuff they say and they form impressions.
Such impressions can be wrong and such memories fade. But as a direct
participant for many years, I am as entitled to my impressions and my
memories as any whose vote was on the prevailing side of numerous
issues.
It's often hard to tell in a newsgroup whose opinion is direct and
whose is just a subjective rant based on loose information. Chris is
a good friend and a long time colleague of mine at several places
we've worked. He also knows a number of the other major participants
personally. He may even have other sources besides me, but he's
ceratinly heard me say that very statement you quote a million times
when we've been out to dinner or battling some programming bug over a
terminal somewhere. And I, in turn, allege I have every personal
reason to believe, that Scheme's primary focus has been to unify the
academic community. (That doesn't make it a "truth" because there is
no such thing in subjective/political domains. It does, though, I
think, make it a "valid belief". Capable of standing even if someone
also present has a conflicting "valid belief".)
Scheme people not present will likely rally in opposition to this
remark because they want their language for more, and their unelected
representatives on the committee may not always represent them as well
as they wish. And that's fair. Even with elected representatives, some of
us routinely deny we are getting good representation. Heck, in effect,
because my vote did not carry in some of these issues, I am for each such
vote one of those in the audience, like you, who would have aspired for
Scheme to be more or different, but who just didn't get his way.
Scheme people who were there may like to deny that they made certain
statements, or might want to diminish the importance of these things
I've seen, or might spin what they said a different way. But those
events I cite did happen. I think partly they contribute
to why the Scheme spec is now pretty much moribund and all useful work
is done by very dedicated implementors and, perhaps, through the SRFI
(Scheme Request for Implementation) process (see schemers.org).
Some people laud the Scheme spec for its minimalism. That's a valid
position. But it's not mine. I asked for tons of "unspecifies" to be
clarified. I asked for continuation semantics to be fixed so that
a unwind-protect would be reliably possible to define, but I didn't get
that. I asked forever for a condition system and worked hard with various
people to hammer out several plausible definitions, but these things
always get snagged somewhere because "clarity" and "aesthetic" and "spec
size" always dominate practical needs like "predictability" and
"portability" in my experience. (Before you get up in arms about
predictability, I don't mean the stuff Scheme does define a semantics for,
I only mean the stuff it leaves ill-specified. Just as an example,
CL has class precedence lists specified as partial orders. This leaves some
ambiguity the CL language could have left undefined. But we felt
"predictable" behavior was more important, so we defined the total order
reliably even though we didn't have to. There are numerous places CL
does this. Left-to-right order of evaluation is another thing we could have
left vague in a lot of places, but we wanted programs to predictably do
a certain thing. It's one thing to leave things vague when you worry
efficiency considerations might get in the way--it's quite another to just
leave things vague because it takes fewer words in the spec. And I am
*oh-so-tired* of hearing people on that committee talk about what would
make the spec bigger as a design criterion.)
They are entitled to their happy little world over there. I do not begrudge
them their followers, and I wish them much success. I particular am amazed
by the resilience of certain vendors, some of whom, like me, would have liked
more specificity and more featurism because they had a closer bond to
customers rather than just students. Those implementors have hung in there
and done some great things with the spec. But less "because" it was an
element of the design and more "in spite of it". IMO. (Clearly this is a
subjective opinion, so take it for what it's worth.) The reason I post this
hear rather than there is not to bash them in a place they don't respond, but
rather to defend my right to find a safe place where I can differ in opinion
and not get flamed for it. There is a reason I use CL, and that's because
it suits my personal needs and Scheme doesn't. There is a reason others
use Scheme and that's because it suits their needs and CL doesn't. These
statements don't contradict each other. They just emphasize the importance
of settling in a political constituency you're happy with.
Martin Cracauer
>I am interested in learning more about one or both languages. Scheme has
>the advantage of books such as SICP and EOPL. Presumably CL has its
>advantages too; anyone care to fill me in? Why (or for what purposes) is
>CL better?
Existing practical CL implementations allow execution speed realistic
for non-trivial (i.e. not glue-only) applications.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <crac...@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
David Golden
> Browsing posts to this group I frequently see real scorn for scheme. Over
> on comp.lang.scheme I fail to see this same scorn for CL. Why is that? As
> an outsider, I am puzzled by this bad feeling between groups who would
> seem to have much in common.
>
Well, Scheme stole a lot of CL's thunder, just when CL looked ready to
take on the world, a lot of the academic and open source community started
concentrating on Scheme. Scheme is "purer" than CL (e.g. differentiation
between boolean false, symbols called "nil" and the empty list), but it's
also a lot "smaller". This has good and bad points.
CL has the equivalent of much of Java's standard library, scheme is just
a "core", there's only just begun to be a semi-standard library (in the
form of the RFC-like SRFIs). There's also still no standard package system
for Scheme that's as powerful as CL's, though individual implementations of
Scheme often have similarly powerful ones, there's no standard object
system, etc. - Thus, CL is better if you want to do do "industrial" or
"real world" coding, big projects to Get Things Done, etc.
On the other hand, Scheme has become a "better" (warning: subjective!)
playground vehicle for research into _new_ features for Lisp-family
languages, thanks to its smallness and purity, sometimes for
experimentation on new + different variations of features which CL _already
has_ - lately, some scheme implementations have included the aforementioned
very fun package management, some implementations have
wierd typing and object systems, some implementations have extended
scheme's already powerful macro system, etc. These might one day lead to
improvements in CL.
And, while it's not _really_ true, people look at the relative sizes of
the Scheme and CL specifications, and decide to go for Scheme, since
it's perceived to be shorter and therefore "easier". (Not that people
should be trying to learn languages from specification documents, of course
- but it's a matter of perception).
All that said, people who _really_ understand Lisp, know that the different
lisp dialects have different strengths and weaknesses, and can be used
appropriately. I don't think you'll get real scorn for Scheme from many
CL people who really know their stuff - they're complementary - knowing
one will give you a few new insights into the other, and any innovations in
one can lead to innovations in the other... <cough>lexical scoping<cough>
And Scheme people are unlikely to criticize CL beyond, perhaps,
the occasional lighthearted accusation of "standard bloat".
There's always room for more lisp dialects - the forthcoming "arc" will
probably be worth looking out for, and "rep", which is perched somewhere
between a traditional lisp and scheme, is very popular as an extension
language for open-source projects. "Sugared" scheme and lisp (with
pythonesque indentation-sensitive syntax), is also helping increase
acceptance of Lisp among the I-hate-parentheses crowd.
Let's not even mention Emacs Lisp. ;-)
--
Don't eat yellow snow.
David Golden
> Scheme was designed to teach certain concepts in computer science classes.
I'd have to say it also serves/served as a basis for _research_ in computer
science - and a lot of that research directly benefitted the lisp community
as a whole. CL and Scheme aren't rivals, as such, they're best-suited to
somewhat different problem spaces.
Also, scheme's designed-in suitability for teaching core computer science
concepts means that there's a supply of young compscis with a firm
grounding in the "essence" of lisp, who can, and often do, become involved
in the wider lisp and common lisp community.
Christopher Stacy
Michael> Christopher Stacy <cst...@spacy.Boston.MA.US> writes:
>> Scheme was designed to teach certain concepts in computer science classes.
Michael> Are you sure about this?
That seemed to be its primary application when SICP was being
written down the hall from me.
Marco Antoniotti
CL-Scheme Flame WAR!
David Golden <qnivq....@bprnaserr.arg> writes:
> Edward Piman wrote:
>
> > Browsing posts to this group I frequently see real scorn for scheme. Over
> > on comp.lang.scheme I fail to see this same scorn for CL. Why is that? As
> > an outsider, I am puzzled by this bad feeling between groups who would
> > seem to have much in common.
> >
>
....
>
> On the other hand, Scheme has become a "better" (warning: subjective!)
> playground vehicle for research into _new_ features for Lisp-family
> languages, thanks to its smallness and purity, sometimes for
> experimentation on new + different variations of features which CL _already
> has_ - lately, some scheme implementations have included the aforementioned
> very fun package management, some implementations have
> wierd typing and object systems, some implementations have extended
> scheme's already powerful macro system, etc. These might one day lead to
> improvements in CL.
And why in the world didn't all these people improve directly on CL?
(Or maybe they were enjoying re-inventing the wheel?).
Seriously, without mentioning "hygienic macros" (a dubious concept to
start with), what is going on in Scheme that is not already in CL? Or
more easily reprogrammed in CL instead of in the C/C++ guts of your
godzillionth Scheme interpreter sans compiler? I'd like to know.
...
> All that said, people who _really_ understand Lisp, know that the different
> lisp dialects have different strengths and weaknesses, and can be used
> appropriately. I don't think you'll get real scorn for Scheme from many
> CL people who really know their stuff - they're complementary - knowing
> one will give you a few new insights into the other, and any innovations in
> one can lead to innovations in the other... <cough>lexical scoping<cough>
> And Scheme people are unlikely to criticize CL beyond, perhaps,
> the occasional lighthearted accusation of "standard bloat".
My feeling is that a lot of Scheme people do not know CL enough.
> There's always room for more lisp dialects - the forthcoming "arc" will
> probably be worth looking out for, and "rep", which is perched somewhere
> between a traditional lisp and scheme, is very popular as an extension
> language for open-source projects. "Sugared" scheme and lisp (with
> pythonesque indentation-sensitive syntax), is also helping increase
> acceptance of Lisp among the I-hate-parentheses crowd.
> Let's not even mention Emacs Lisp. ;-)
I do not share this opinion. IMHO there room only for a thougtful
re-implementation of Common Lisp in a better packaged way and with a
compiler as good as the commercial ones or Python.
Good extensions should be built portably on top of CL.
All the rest is an application of Greespun's Tenth Rule.... :)
... and a lost occasion.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Kent M Pitman
> On the other hand, Scheme has become a "better" (warning: subjective!)
> playground vehicle for research into _new_ features for Lisp-family
> languages, thanks to its smallness and purity
No. Scheme has become a good testbed for Scheme features. It is a bad
testbed for CL features. (As to the middle ground of Lisp in general, I'm
less sure because I don't know that it's worth talking about an "average"
Lisp when that points to a position in the vacuum of space between the
mass gravities of the various extant implementations. It is probably
needlessly divisive to even attempt to make this statement about an abstract
like Lisp per se. But overall, I think the same reasons that it's a
bad testbed for CL make it a bad testbed for all other Lisps, except Scheme,
if you think Scheme a Lisp, which I don't. If Scheme were a Lisp, though,
I'd think the same thing. My opinion on this is based on fact-of-differentness
as a boolean matter, not degree-of-differentness as a multi-dimensional
distance matter.)
Features cannot tested in one context and assumed productworthy in another.
Testing the tiger in a jungle does not tell you that it will function well
in a desert. Languages are ecologies.
To the extent that Scheme claims to be a place where any purported
"science of design" is best tested, I allege that such is an indefensible
claim.
Further, issues of mere ecology aside, just because you can best measure
something in one context doesn't make it the place to do the measurement.
I can read my thermometer indoors better without frost and snow all over it,
but that doesn't mean it's best to position it there if I want to know the
temperature outside.
And, finally, the Scheme "science" I have seen done often presumes a very
limited and falsely-canonical notion of aesthetic. Scheme is defined around
a particular set of aesthetics, but does not by any means have a unique lock
on the notion of aesthetics. And to that extent, it misses important research
that it could and should be doing.
One might allege that one can learn all they need to know about human
language from Esperanto or Loglan, for example, and can claim such
languages are better languages for doing linguistics research because
they are small and pure. But the day we start thinking that the
science that comes out of the study of such languages is good enough
to substitute for the real science needed to understand all languages
is a sad, sad day for science.
Kaz Kylheku
>Edward Piman wrote:
>
>> Browsing posts to this group I frequently see real scorn for scheme. Over
>> on comp.lang.scheme I fail to see this same scorn for CL. Why is that? As
>> an outsider, I am puzzled by this bad feeling between groups who would
>> seem to have much in common.
>>
>
>Well, Scheme stole a lot of CL's thunder, just when CL looked ready to
>take on the world, a lot of the academic and open source community started
>concentrating on Scheme. Scheme is "purer" than CL (e.g. differentiation
>between boolean false, symbols called "nil" and the empty list), but it's
>also a lot "smaller". This has good and bad points.
Why is it that alleged purity invariably seems to make programs ``dirtier''?
Earlier today someone detailed in this newsgroup a few problems with
the application of the language Clean to real work.
Perhaps there is a hidden ``conservation of dirt'' law, similar to
the principle of the conservation of complexity. Cleaning the language
simply means pushing dirt into programs.
But what is dirt cannot be easily identified as complexity or simplicity;
it's rather a subjective lack of elegance. Elegance often arises from
imposing a framework of artificial constraints. Artists sometimes find
it helpful to adhere to some rigid frameworks which give their work an
identifiable form; the result can be elegant, because it makes use of
the built in elegance-generating properties of the form, which amplify
the artist's contribution. But some forms are simply not applicable to
some kinds of expression. There is a mistake of viewing those expressions
which don't fit into a given subjectively preferred form as inelegant,
giving rise to orthodoxies.
Some people view elegance in programming languages similarly; that there
is some true way of doing things, and everyone must program to that. This
works fine up to the point that programming is merely a form of artistic
self-expression. If one expression doesn't work, the artist-programmer
can self-censor and seek another. When programming is driven by actual
externally-imposed requirements, this approach is no longer adequate.
Carrying the analogy further, suppose you are a music composer, and all
you ever compose is very elegant baroque counterpoint in the style of
J. S. Bach and company. You are happy within these forms making beautiful
magic. But what if someone wants to commission you to prepare a suite of
20th century music? Well, you can say ``Bah, that stuff is cacophonic
humbug, I only write elegant music.'' So the job goes to someone else.
>Don't eat yellow snow.
Aha, Zappa! How pertinent. ;)
David Golden
>
> And why in the world didn't all these people improve directly on CL?
> (Or maybe they were enjoying re-inventing the wheel?).
>
yes, maybe they were enjoying re-inventing the wheel. After all,
it's one thing to *use* a machine, and another to *understand it*. Wheel
reinvention can be a way for people to learn. Maybe they'll accidentaly
invent caterpillar tracks instead.
> Seriously, without mentioning "hygienic macros" (a dubious concept to
> start with), what is going on in Scheme that is not already in CL? Or
> more easily reprogrammed in CL instead of in the C/C++ guts of your
> godzillionth Scheme interpreter sans compiler?
Wel,, (a) lots of people like hygienic macros, particularly the more
powerful variants, and (b) If the feature is most easily prototyped by
adjustment of the guts of the interpreter, then perhaps it _is_ easier to
butcher a simply-written, non-optimised, interpreted scheme implementation
than a finely-tuned, multi-layered,
in-all-respects-wonderful-except-for-ease-of-comprehension-of-internals CL
implementation. People learn by doing, so even if the feature is
completely useless pants that's been discarded years ago by the
establishment, they might discover that faster by hacking on a naive
interpreter.
> My feeling is that a lot of Scheme people do not know CL enough.
>
Yes, definitely - but the majority are open to learning. After all, if
they're a "scheme person", chances are they're at the _start_ of their
computing career, and receptive to learning CL.
David Golden
> David Golden <qnivq....@bprnaserr.arg> writes:
>
>> On the other hand, Scheme has become a "better" (warning: subjective!)
>> playground vehicle for research into _new_ features for Lisp-family
>> languages, thanks to its smallness and purity
>
> No. Scheme has become a good testbed for Scheme features. It is a bad
> testbed for CL features.
I was more thnking of it as an an "invention ground" than a testbed.
> Features cannot tested in one context and assumed productworthy in
> another.
No, but they can be invented/discovered in one context, and tested
in another. Some things my be tried and found good, others unsuitable.
>
> Testing the tiger in a jungle does not tell you that it will function well
> in a desert. Languages are ecologies.
I agree completely - but would a tiger arise in a desert?
Strained analogy: Humans probably couldn't have evolved in the arctic - but
we can now live there. Now, that's due to a human's ability to adapt. and
to alter the environment - but a human can bring to the arctic features it
didn't previously have, like toasters, or big square holes in the
landscape. Yes, these features may or may not be useful to the natural
inhabitants of the arctic, but they *may* make the arctic more widely
useful to both things that were always there, and things that weren't
there before. (I suppose there's a programming-language-feature analogue of
the environmental poisoning and destruction that humans sometimes cause -
perhaps perl's automatic obfuscation by extensive use of implicit
arguments, but that serves to make perl more useful for short scripts -
just as a road may make an environment more useful for human purposes, and
cause hedgehogs and other wildlife to meet their splattery doom.)
Diversity and cross-fertilisation of ideas has played an important part in
the evolution of Common Lisp (as, you, of course, know very well :-) )
Wade Humeniuk
different
> lisp dialects have different strengths and weaknesses, and can be used
> appropriately. I don't think you'll get real scorn for Scheme from many
> CL people who really know their stuff - they're complementary - knowing
> one will give you a few new insights into the other, and any innovations
in
> one can lead to innovations in the other... <cough>lexical scoping<cough>
> And Scheme people are unlikely to criticize CL beyond, perhaps,
> the occasional lighthearted accusation of "standard bloat".
I started using Scheme and I now use Common Lisp. From what I know there is
no strength that Scheme has that CL does not. Perhaps you can name a few?
Here I will try to name some for you:
1) Scheme is easier to learn. If one just used the subset of CL that Scheme
implements then CL would be as small and just as easy to learn. It is just
that academia has chosen Scheme as there model programming language to
teach.
2) Hygenic macros. Gag!!!!!
3) Continuations, Double Gag!!!!
4) Scheme is so small its embeddable. Yes I need a toaster that runs
Scheme.
5) Scheme is so small it can be embedded as an extension language in an app.
See 1.
6) Scheme can be used for research purposes. Got me there. I would assume a
lot of academics would like to advance computer science without actually
doing a lot of programming.
7) Scheme is easier to compile. Oh...., I forgot, what compiler?
8) Scheme has proper tail recursion. It seems to be a case of the dog
chasing its tail.
Most of the bigger Scheme implementations seem to be striving for CL
functionality (object systems, et. al.) and in fact implement CL
functionality (usually a limited subset) without giving credit where credit
is due. Scheme is progressing with piecemeal timidity, afraid to somehow
damage its "purity". With sufficient time Scheme will just become CL.
As for lexical scoping, its no longer an innovation. When was the last time
a computing innovation occured? There seems to be a view that if we can
just find the next innovation (and god knows people use the excuse all the
time) that our grundgy programming problems will go away. Most of the
necessary work is just grundge and I have found that CL has dealt with it
the best.
Wade
Aaron J Reichow
> language for open-source projects. "Sugared" scheme and lisp (with
> pythonesque indentation-sensitive syntax), is also helping increase
> acceptance of Lisp among the I-hate-parentheses crowd.
> Let's not even mention Emacs Lisp. ;-)
Example of a language that uses this? I'm aware of a C syntax package for
guile, but I wouldn't say that it's used by much of anyone, and especially
not helping in making the lisps more accepted. Dylan never really took
off, either.
Regards,
Aaron
Aaron Reichow :: UMD ACM Pres :: http://www.d.umn.edu/~reic0024/
"civilization is a limitless multiplication of
unnecessary necessities." :: mark twain
Kent M Pitman
> > Features cannot tested in one context and assumed productworthy in
> > another.
>
> No, but they can be invented/discovered in one context, and tested
> in another. Some things my be tried and found good, others unsuitable.
But my point is that there exist features that can only be discovered
and tested here and not there. For example, Scheme does not believe
in declarations. CL has done very good research in declarations.
Just look at the CMU CL compiler to see how much can be done with the
declaration facility we have.
> > Testing the tiger in a jungle does not tell you that it will function well
> > in a desert. Languages are ecologies.
>
> I agree completely - but would a tiger arise in a desert?
Would desert creatures arise in a jungle? I miss your point, or you miss mine.
> Strained analogy: Humans probably couldn't have evolved in the arctic - but
> we can now live there.
Very strained analogy because you're now focusing on the life/lifelessness
aspect that was only vaguely incidental to my other example. I could just as
well have focused on rainforest vs the wheat/corn belt of central US/canada.
Things grow both places, but very different things. No buffalo in the
jungle. No anacondas in the hills of Kansas.
People often look to Scheme as somehow "better". It is not. It is simply
different.
> Diversity and cross-fertilisation of ideas has played an important part in
> the evolution of Common Lisp (as, you, of course, know very well :-) )
Mostly with us being open-minded enough to embrace Scheme ideas.
Scheme thinks it has nothing to learn from us. If there's one thing
I'd like new Scheme people never to learn, it is the all-to-prevalant
attitude that there can be a significant field of human endeavor from
which nothing can be learned. Many core Scheme people seem to want
to wish that by ignoring CL, it will become true that there was nothing
to learn from us.
I saw this effect even in work on ISO ISLISP. I remember one day
coming in with one page of the CL spec that exemplified something
useful. Some committee members, from a faction I'll subjectively
describe as "more favorable to Scheme/Eulisp than CL" refused to look
at the page of text. They said it was enough to know it came from
CL. They wanted not to be dirtied by CL. I said, taking one idea or
reading one page of text from CL will not make this a dirty language
and that it was idiotic to say otherwise, but they persisted in an
utterly emotional response, refusing to allow the matter to come to
the table for discussion. They did not want ISLISP polluted by CL thoughts.
Later, ISLISP was at risk of failure as a project because of the
non-cooperation and attitudes changed. I think by the time we
finished that spec, there was a lot more respect all around among the
participants, maybe in part because there had been some changeover in
WHO was participating, but partly also because people had mellowed.
The ISLISP spec worked out as a kind of compromise of sorts and is
small like Scheme but CL-like in other ways. I sort of wish if
someone were going to go make a new dialect they'd at least build from
something existing like this rather than from scratch.... Sigh.
Kent M Pitman
> Perhaps there is a hidden ``conservation of dirt'' law, similar to
> the principle of the conservation of complexity. Cleaning the language
> simply means pushing dirt into programs.
[These remarks not addressed to Kaz, just triggered by his remark here.]
I often feel that small languages make big programs. You aren't starting
with as much, and you have to spend more "building up" work.
Further, it's not clear CL is that much bigger than Scheme. A tiny bit.
Much of what is CL is library. Scheme doesn't call library part of the
language. That's just a marketing trick, like saying that a system dll
not being part of your program means your program is tiny. It doesn't
fundamentally change reality.
Of what is not library, CL has more examples, which take a lot of space.
The Scheme people have avoided the kinds of worked examples the CL spec
has. Does this make their language qualitatively better? I'm skeptical.
CL contains more discussion of portability concerns, branch cuts, handling
of error situations, etc. Does leaving this kind of verbiage out of Scheme
make it a better language? Again, I'm skeptical.
But suppose we removed the library stuff that Scheme just omits. And
suppose we remove examples and explanatory text and we change the typography
and we let someone who uses more concise language than I do write the book.
How different is Scheme from CL ultimately? At the core? Not a lot, I think.
They are issues of substance I wouldn't handwave away. But all this fuss
over size per se is just smoke and mirrors.
CL _does_ require implementors do to lots more than does Scheme.
Scheme leaves things vague, making it easier on implementors. But every
thing left easy for implementors is an increased burden on programmers.
Does making an increased burden on programmers make Scheme better? I'll even
give you that there might be some who think it might. But I hope others
on the other side of the debate will give me that it doesn't NECESSARILY
make the language better. Certainly the increased burden on me as a
programmer is a primary motivating factor for me using CL. Would I want to
IMPLEMENT a CL? No way. Too much work. But it doesn't matter to me that
there is an entry barrier AS LONG AS some are willing to cross it--enough
to give me a reasonable set of choices. And there are such choices. So
I'm happy with the trade-offs we've made.
Kent M Pitman
> > My feeling is that a lot of Scheme people do not know CL enough.
> >
> Yes, definitely - but the majority are open to learning. After all, if
> they're a "scheme person", chances are they're at the _start_ of their
> computing career, and receptive to learning CL.
Though also dangerously open to religious dogma, too.
And for all that Scheme teaches some powerful ways, its courses often
carefully omit training in alternatives. It's not uncommon to have
these "open-minded" people come out of these courses in a daze willing
to say that
(loop for i = 1 to 10
do (print i))
is an unclear program that would be more clear as
(let loop ((i 1))
(if (<= i 10)
(print i)
(loop (1+ i))))
is more clear. I have no problem with people coming out knowing that these
are equivalent programs, nor even with them having a personal preference,
but I've _too often_ been in arguments with them over where the former program
is _clear at all_ to believe they're getting a fair treatment in these
"mind-expanding" courses.
I've even seen this argument over
(do ((i 1 (1+ i)))
((> i 10))
(print i))
which doesn't even have LOOP involved and which has a straightforward
transliteration and/or trivial macroexpansion to a recursive proram for
those who worry it's hard to implement.
David Golden
> On Mon, 17 Dec 2001, David Golden wrote:
>
> Example of a language that uses this?
Uhm... Scheme+Sugar ? "Sugar" is the name of an
_implementation_ of indentation-sensitive syntax, that hangs around
as an add-on package for most schemes... Unlike other attempts at syntax
"improvement", it doesn't try to do anything fancy like infix notation, it
just uses ordinary indentation conventions to "fill in" the parentheses.
The original source is at http://Sugar.mini.dhs.org/
it's about 100 lines.
> Dylan never really took off, either.
>
Dylan tried to do too much, I think. Sugar source is pretty much ordinary
scheme, just with the information that parantheses usually convey to the
reader conveyed by the indentation instead - since pretty much everyone
indents anyway (or the editor does it for them), and Sugar still _allows_
the normal parentheses, it's quite popular for just banging out code - one
problem you have with estimating it's usage is that people may write the
code in sugar syntax, but release the code in normal parens.
Anyway, if you think that's wierd and pointless, wait till you see cugar,
which makes C++ into an indentation-sensitive python-lookalike...
David Golden
>
> Though also dangerously open to religious dogma, too.
>
I suppose so. One must try to look on the bright side :-). Get 'em while
they're young, and all that - I still think knowing Scheme is better than
not knowing any lisp-like languages at all, and that people who know scheme
are more likely to look at Common Lisp than the frightening amounts of
programmers who know little but Java and/or C++ these days...
Kent M Pitman
Only if they are not, as I believe them to frequently be, indoctrinated
with "Lisp is evil" as part of their Scheme training.
David Golden
> Only if they are not, as I believe them to frequently be, indoctrinated
> with "Lisp is evil" as part of their Scheme training.
>
Well, if there's one way to get young people interested in finding out more
about something, it's to tell them not to do it... a certain proportion of
students, usually the better ones, will spot, and question, dogmas they're
presented with - so, you might well end up with the best scheme students...
Gareth McCaughan
> Browsing posts to this group I frequently see real scorn for scheme. Over
> on comp.lang.scheme I fail to see this same scorn for CL. Why is that? As
> an outsider, I am puzzled by this bad feeling between groups who would seem
> to have much in common.
I have a few conjectures.
- Scheme gets, I think, rather more "mindshare" than CL does
on account of its use in university courses. So
- maybe some CLers get a little jealous;
- certainly some CLers are concerned that students
are being told "This is what Lisp is like" when the
language they're being taught is very different from
(and in the opinion of most CL users, much less
useful than) CL. So people get inoculated against
Common Lisp, and that's a shame.
- Although there isn't active scorn for CL among Schemers,
I think there is often an assumption of superiority.
(Look at our lovely elegant language and compare it
with that behemoth over there. I mean, they even let
a symbol mean different things according to whether
it's at the start of a form or not! ... etc.) That can
rankle.
> I am interested in learning more about one or both languages. Scheme has
> the advantage of books such as SICP and EOPL. Presumably CL has its
> advantages too; anyone care to fill me in? Why (or for what purposes) is
> CL better?
That may be an unnecessarily inflammatory way to ask the question :-).
However:
- CL also has some great books. My favourite is Peter Norvig's
"Paradigms of artificial intelligence programming: case
studies in Common Lisp", which in the opinion of many Lispers
is one of the finest programming books on any subject. It's
worth reading even if you have no interest in AI, and it's
worth reading even if you have very little interest in CL.
Also often recommended (but more controversial) is Paul
Graham's "On Lisp", which is mostly about macros and
higher-order functions. And "The art of the metaobject
protocol", which is all about opening up the workings
of your object system to user inspection and manipulation
without making it impossible to be efficient. Very cool
stuff.
The language itself is very different from Scheme. It will
not surprise you to learn that many of the differences are
regarded by most CLers as advantages. For instance:
- CL has a big standard library. (Scheme has a tiny standard
library and a number of different implementations each with
its own fairly big library. The SRFI process helps to
ameliorate this.)
- CL was designed with efficient implementation in mind.
Even though CL is a much bigger language than Scheme,
it's probably about as hard to make a really effective
Scheme compiler as it is to make a really effective CL
compiler. So CL is much more usable in practice for numerical
work than Scheme is, for instance. (Some features that make
it easier to write a good CL compiler: optional type
declarations, immutability of builtins, absence of call/cc.)
- CL is a big language. (This isn't quite the same thing
as having a big library, though the boundaries are blurry,
especially in a language as flexible as CL or Scheme.)
Although this makes it harder to learn all of it, it
means that you can do more, more easily, once you've
got the hang of a decent chunk of it.
- For instance, CLOS (the Common Lisp Object System)
is an amazing thing. I don't think any of the
seventeen million object systems for Scheme has
anything like the same power.
- CL's macros are strictly more powerful than Scheme's
(though I think in practice Scheme implementations
provide procedural macro facilities as well as the
"high-level" ones in the standard).
- CL's richer selection of standard data types means
you don't have to implement so much stuff from
scratch. Hash tables, multidimensional arrays,
structures.
- Some of the things that appear ugly and ad hoc to many
Schemers appear practical and friendly to many CLers.
For instance, the many-namespace-versus-single-namespace
thing: Schemers like not having to think "Is that using
the function binding or the value binding?" and not
having to write FUNCALL and #'... ; CLers like not
having to call variables LST instead of LIST or SYM
instead of SYMBOL to avoid inadvertent capture, and
find that the variety of bindings is no more troublesome
than that in any natural language.
- The community of CL users and implementors has a
rather different focus from that of Scheme users
and implementors: "industrial" rather than "academic",
I suppose. (Of course those terms are meant to be
vague and woolly; there are academic CLers and
industrial Schemers.) Some people prefer one or
the other of those communities.
--
Gareth McCaughan Gareth.M...@pobox.com
.sig under construc
David Golden
> Would desert creatures arise in a jungle? I miss your point, or you miss
> mine.
I don't think I missed your point - I'm just saying, that, sometimes,
"alien" features can arise that might take a lot longer to appear in one
language if they are not "borrowed" from the language in which they evolved
> Things grow both places, but very different things. No buffalo in the
> jungle. No anacondas in the hills of Kansas.
>
Ah... but how would an anaconda fare in the hills of Kansas, or buffalo
in the Jungle, if they suddenly were transported there? (Pretty badly,
probably, at least for the buffalo, and the anaconda come winter), but -
one can envision situations in which the alien introduction does quite
well - alien zebra mussels in european waterways, or certain non-native
seaweeds in the mediterranean, if we're going to stick with wildlife...
That was my point - features which may arise easily in one language
may be snarfed by another language, in which they haven't as yet arisen -
and the various lisp variants play off eachother in such a manner, to an
extent. Then again, maybe I've spent too much time in perl-land (perl
seems to accumulate features from any language that happens to be passing
at the time)...
> I sort of wish if
> someone were going to go make a new dialect they'd at least build from
> something existing like this rather than from scratch.... Sigh.
Well, last I heard, ISLISP was catching on a little bit in Japan...
(At least, there's a couple of implementations being actively developed in
Japan...)
Bruce Hoult
<pit...@world.std.com> wrote:
> (loop for i = 1 to 10
> do (print i))
>
> is an unclear program that would be more clear as
>
> (let loop ((i 1))
> (if (<= i 10)
> (print i)
> (loop (1+ i))))
>
> is more clear.
The first certainly looks clearer to me, except that I'm unclear what
language it is written in -- it's not CL. Or at least not the CL
implemented by CMUCL or (as far as I can make out) described in the
Hyperspec.
Scheme has macros now. Are they powerful enough to build a "loop"
macro? Dylan's macros are only template replacement, but are powerful
enough to build a CL-like "loop" macro that expands to a tail-recursive
local function, and in fact that's a standard part of the language.
-- Bruce
Daniel Barlow
> David Golden <qnivq....@bprnaserr.arg> writes:
> > Yes, definitely - but the majority are open to learning. After all, if
> > they're a "scheme person", chances are they're at the _start_ of their
> > computing career, and receptive to learning CL.
>
> Though also dangerously open to religious dogma, too.
>
> And for all that Scheme teaches some powerful ways, its courses often
> carefully omit training in alternatives. It's not uncommon to have
> these "open-minded" people come out of these courses in a daze willing
> to say
[ ... that loop is unclear and named let is better ]
I started out arguing against that point, but the more I edit this
post the closer I think I'm coming to agreeing with you.
My ad-hoc research (which basically consists of telling people at
Linux events that I write Common Lisp, and getting funny looks for it)
suggests that most people who learnt anything Lispish at university
were (a) told it was Lisp (or LISP, more likely), and (b) convinced
that it was perhaps kind of neat in a twisted way but too slow and
impractical to ever be of any practical use.
OK, some of the students will be keen, and, yes, probably end up as
single-namespace Scheme bigots. The majority, though, I don't think
are coming out of these courses with any kind of revolutionary fervour
against the evil LOOP, because for the most part I don't think they
even have much incentive to learn that the evil LOOP exists. The only
problem with these courses from an evangelising-CL point of view is a
namespace one. Common Lisp is LISP, right? Therefore they already
know it and know it's not actually very good at anything.
So my instinct says not to worry about it, aside from the namespace
angle. The languages on the syllabus have _never_ been the ones that
students usually want to learn - we should be talking in the places
that C, Perl, Python, Ruby etc are talking, not the places where ML,
Miranda, Scheme and Modula 2 are. There's nothing to rebel against in
learning Modula 2 ...
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Jochen Schmidt
> Edward Piman wrote:
>
>> Browsing posts to this group I frequently see real scorn for scheme. Over
>> on comp.lang.scheme I fail to see this same scorn for CL. Why is that? As
>> an outsider, I am puzzled by this bad feeling between groups who would
>> seem to have much in common.
>>
>
> Well, Scheme stole a lot of CL's thunder, just when CL looked ready to
> take on the world, a lot of the academic and open source community started
> concentrating on Scheme. Scheme is "purer" than CL (e.g. differentiation
> between boolean false, symbols called "nil" and the empty list), but it's
> also a lot "smaller". This has good and bad points.
As I hear this word very often called with some languages - what exactly do
you mean by "pure" (or "purer")? We are not talking about diamonds or gold
we talk about languages and it is not absolutely obvious to me why being
"pure" is unconditionally a good thing for a language. (many more important
things like water or air are useless if they are pure...) I don't really
think that distinguishing nil,(),false has anything to do with purity. You
may have seen an extensive discussion over this topic lately and AFAIR
there was _no_ consensus that the distinction is the unconditionally right
thing to do - so _how_ can that increase "purity" in a language?
As I already mentioned elsewhere I'm always careful if someone calls a
language "pure" as this means most of the time that the designers have
chosen to omit a vast amount of things because of more or less subjective
stylistic reasons. CL is a rather impure language in this sense and that is
what I actually think is better in CL - nobody omits some nice or important
feature from you only based on personal stylistic feelings. The default
mode in CL seems to be allowing something if it does not has an negative
effect on others.
ciao
Jochen
Kaz Kylheku
>David Golden wrote:
>
>> Edward Piman wrote:
>>
>>> Browsing posts to this group I frequently see real scorn for scheme. Over
>>> on comp.lang.scheme I fail to see this same scorn for CL. Why is that? As
>>> an outsider, I am puzzled by this bad feeling between groups who would
>>> seem to have much in common.
>>>
>>
>> Well, Scheme stole a lot of CL's thunder, just when CL looked ready to
>> take on the world, a lot of the academic and open source community started
>> concentrating on Scheme. Scheme is "purer" than CL (e.g. differentiation
>> between boolean false, symbols called "nil" and the empty list), but it's
>> also a lot "smaller". This has good and bad points.
>
>As I hear this word very often called with some languages - what exactly do
>you mean by "pure" (or "purer")? We are not talking about diamonds or gold
>we talk about languages and it is not absolutely obvious to me why being
>"pure" is unconditionally a good thing for a language.
``Pure'' means: ``Based on my experiences, I have a world view about what
is necessary in a programming language, and what is not. Those languages
which have exactly what is necessary---nothing more or less---are pure.''
How's that?
(many more important
>things like water or air are useless if they are pure...) I don't really
>think that distinguishing nil,(),false has anything to do with purity.
Unless your world view is that having distinct boolean symbols is somehow
necessary.
According to a certain kind of purist, being able to invoke CAR on an
empty list is a superfluous feature that isn't logical; after all, if
the list is empty, it has no first element, so the function appears to
be lying if it produces NIL; it's covering up for what should be
signaled as a programmer error. You get the effect that
(CAR '())
and
(CAR '(() 1 2 3))
produce the same result. This rubs a purist the wrong way. One must
test the list for emptiness to obtain a boolean value (and by golly,
a boolean true and false must exist for this purpose); then only if
that value is true can one access the first element of that list.
If the result of that is (), we then know that the first element is an
empty list.
The problem is that this makes common programming tasks inconvenient.
Being able to CAR an empty list is convenient, yet you can still
explicitly test for an empty list if you need to. So by having a little
superfluous robustness in the standard function, you eliminate annoying
tests from the vast amount of code written to use it.
There is another kind of view which clashes with the above one and
that is: make the language do the gruntwork whenever possible, and put
frequently-needed idioms into the implementation. This view can equally
be the basis of purism, centered on the purity of work, rather than
the purity of the language.
What is more precious, the programming language or every programmer's
time? Which should serve the other? Language purists hold the language
to be important, and programmers to be unimportant.
Friedrich Dominicus
> David Golden <qnivq....@bprnaserr.arg> writes:
>
> > On the other hand, Scheme has become a "better" (warning: subjective!)
> > playground vehicle for research into _new_ features for Lisp-family
> > languages, thanks to its smallness and purity
>
> No. Scheme has become a good testbed for Scheme features. It is a bad
> testbed for CL features. (As to the middle ground of Lisp in general, I'm
> less sure because
Well I obviously disagree here (otherwise I hardly would answer
;-). Schemes are very diverse and have incorporated extensions which I
do not have seen for Common Lisp. Well at first SCSH comes to my
mind. Than Kawa or Silk. Maybe STk and probably a bunch of others if I
think about it for a while.
Well I do not know of anythink done for Common Lisp which could
compare with the Shell-Scripting facilities of SCSH. I can't see why
that would be worse for Common Lisp. I know of no Common Lisp which is
to tighlty integrated with Java. (Not that I'm a fan of it, just I see
it as an experiment.
Teh regex stuff form SCSH was done in Scheme not in Common Lisp!. Why?
Well I'm sure if one digs a bit deeper into different Schemes one will
find other examples which suggest (at least for me) that Scheme is not
just a good testbed for Scheme features but for very different
"things".
Well I do think that the Common Lispers have put much more effort in
the "programming language" Common Lisp as you pointed out. In that
area I would think that Schemes are very much behind.
Regards
Friedrich
Christopher Stacy
Wade> As for lexical scoping, its no longer an innovation.
That particular innovation adopted by Scheme actually came from
(at least) an earlier Lisp language called MDL, by the way.
Thomas F. Burdick
Yes, people will certainly question a lot of the dogma typically
associated with learning Scheme. And they'll express it by rejecting
Lisp, because this is what they think Lisp is about, and they want no
part of it. GCC optimizes tail calls? Great, who needs Lisp!
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick
> - CL also has some great books. My favourite is Peter Norvig's
> "Paradigms of artificial intelligence programming: case
> studies in Common Lisp", which in the opinion of many Lispers
> is one of the finest programming books on any subject. It's
> worth reading even if you have no interest in AI, and it's
> worth reading even if you have very little interest in CL.
>
> Also often recommended (but more controversial) is Paul
> Graham's "On Lisp", which is mostly about macros and
> higher-order functions. And "The art of the metaobject
> protocol", which is all about opening up the workings
> of your object system to user inspection and manipulation
> without making it impossible to be efficient. Very cool
> stuff.
I'd say that AMOP is as much about implementing the innards of an
object system as PAIP is about AI. It _is_ about that subject, yes,
but is also a wonderful example of OO design for a non-trivial system.
Most pedantic texts on OO design use uselessly small examples. Most
working OO systems, like most working systems, "should" (in a world
with an infinite number of man-hours) be torn down, and redesigned and
re-implemented. I'd say it's useful reading for anyone who is
interested in learning about designing object-oriented systems in
general.
Michael Hudson
> Michael Hudson <m...@python.net> writes:
>
> > Christopher Stacy <cst...@spacy.Boston.MA.US> writes:
> >
> > > Scheme was designed to teach certain concepts in computer science
> > > classes.
> >
> > Are you sure about this?
>
> I have been in the room of the Scheme authors (check the front page
> of the Revised^n Report on Scheme to see my name in the credits) and
> have repeatedly seen decisions made in favor of teaching and in
> opposition to proposals that would make it easier for industry.
Hmm. I think I sort-of misread Christopher's remark, and asked the
wrong question. I was more-or-less aware of scheme's development (and
knew your name was on the front of R^5RS) -- though thanks for the
long and as-ever informative post.
What I meant to ask was more about the purpose of scheme's creation
way back when. Was scheme actually *created* for the purpose of
teaching? I was under the impression that it was not, though I can't
for the life of me remember where I get that impression from, and am
now suspecting that it was erroneous.
Cheers,
M.
(Hmm, good sigmonster)
--
Famous remarks are very seldom quoted correctly.
-- Simeon Strunsky
Kent M Pitman
> David Golden wrote:
>
> > Edward Piman wrote:
> >
> >> Browsing posts to this group I frequently see real scorn for scheme. Over
> >> on comp.lang.scheme I fail to see this same scorn for CL. Why is that? As
> >> an outsider, I am puzzled by this bad feeling between groups who would
> >> seem to have much in common.
> >>
> >
> > Well, Scheme stole a lot of CL's thunder, just when CL looked ready to
> > take on the world, a lot of the academic and open source community started
> > concentrating on Scheme. Scheme is "purer" than CL (e.g. differentiation
> > between boolean false, symbols called "nil" and the empty list), but it's
> > also a lot "smaller". This has good and bad points.
>
> As I hear this word very often called with some languages - what exactly do
> you mean by "pure" (or "purer")? We are not talking about diamonds or gold
> we talk about languages and it is not absolutely obvious to me why being
> "pure" is unconditionally a good thing for a language. (many more important
> things like water or air are useless if they are pure...) I don't really
> think that distinguishing nil,(),false has anything to do with purity. You
> may have seen an extensive discussion over this topic lately and AFAIR
> there was _no_ consensus that the distinction is the unconditionally right
> thing to do - so _how_ can that increase "purity" in a language?
I'm guessing he means purity as in "failing to deviate from a social
goal" and the bug is not per se with the sense of "purity" but with
his failure to identify and defend explicitly the social goal. Often
people assume that social goals are "obvious", "uniquely determined",
and "universally accepted". Such is rarely the case, but often the
more passionate someone believes in the the goal, the more surprised
and confused they are that it's possible for others not to.
For example, Scheme has an implicit assumption in it that fewer
"cases" in a language is undesirable. And they observe that a
statement of the general form "if x is in a functional position, then
... else if x is in a variable position, then ..." is notationally
more complex than "if x is in an evaluable position then ...".
They're right. Two namespaces are more complex than one. But then
they promote this to a social goal: complexity is to be always
avoided. This is the point they usually overlook--that others might
say "some complexity is ok and even desirable". If they fail to see
this, they miss the point. They look at "some" as being an operator
on domain data that introduces impurity. But I don't agree. The onl
kind of impurity that's interesting to me is the kind that happens
after the initial goals are laid down. If my goal is to use my
brain's ability to accomodate limited complexity, then my goal is not
achieved by dumbing down a problem down to where part of my brain that
could be active is left idle by an attempt to apply some sort of
meta-purity that wishes my brain were not constructed as it is.
Within the context of the problem as I want to state it, purity
addresses the question of how to most straightforwardly I can keep my
whole "somewhat complex" brain from either confronting problems that
are either too complex OR too simpleminded. I don't like the verb purity
because it judges at a funny level that seems irrelevant, like trying to
judge a straight line drawn by a person without a straight-edge with a crayon
against a mathematical line. You can do that judgment, but it won't tell
you much about whether the line was of suitable engineering quality since
the result will always be "it's impure" and will miss the point that some lines
will be "just what was needed" while others not. Moreover, there are times
that a mathematically straight line, however elegant, will be the wrong thing.
It might be too thin, too rigid, too lacking in "character", or whatever.
Consider how much art in a museum would be judged impure by gauging its
lines this way, and how much less pretty a museum's art would be if that
kind of purity were the canonical metric of goodness.
> As I already mentioned elsewhere I'm always careful if someone calls a
> language "pure" as this means most of the time that the designers have
> chosen to omit a vast amount of things because of more or less subjective
> stylistic reasons. CL is a rather impure language in this sense and that is
> what I actually think is better in CL - nobody omits some nice or important
> feature from you only based on personal stylistic feelings. The default
> mode in CL seems to be allowing something if it does not has an negative
> effect on others.
Nearly all things that are not uniquely determined are outside the reach of
the Scheme designers to offer to their users since their consensus process
couldn't allow them to choose. Like the donkey left to starve to death
when put at midpoint between two carrots at opposite ends of the room, and
no hint as to which would be the better way to go, sometimes Scheme's design
criteria has overlooked the value of the simply arbitrary.
It also overlooks the value of the blunt. I have often summed up that
virtue in this way:
You are to be locked in a closet. You may choose to be locked in the
one marked Scheme or the one marked Lisp. In the Scheme closet is a
drawer filled with thousands of tiny keys, each of which neatly fits
just one lock. One will get you out, but the others are irrelevant
to your task. Whoever put them there didn't like master keys--too
impure. So you'll have to find the one you need. In the Lisp
closet, you will find a hammer, a screwdriver, and an adjustable
wrench, but no key. (Neither is Lisp this blunt, nor Scheme this
unforgiving, but indulge me some exaggeration to make a simple point
here.) Dinner is not the table while you're locked in there--will you
get out before it's stone cold?
Kent M Pitman
Actually, it came from Algol.
If you study the original Algol 60 report and the Scheme report
(especially versions before R5RS, which has started to drift slightly
IMO), you'll see a HUGE amount of work was done to match the "book
design" (text layout, typography, formatting, chapter organization,
and even certain key phrases) from the Algol 60 report. This was VERY
deliberate, since Algol 60 is what inspired Scheme. The Algol 60
report had, under its list of authors, a dedication to someone who had
died; one of the Scheme reports at least has a similar remark about the
passing of one that had been cared about, but it was Algol itself...
For people who think Algol means Algol 68, this detail probably went right
past them, since I'd imagine the Algol 68 spec is laid out differently, and
since maybe people don't even learn Algol from the spec.
I probably have a copy of the Algol 60 report somewhere in my files
laying around and could maybe could try to scan in the cover for
people to see the similarity if there are those out there who don't
have access... But it may already be online somewhere. I would hope so.
Kent M Pitman
> What I meant to ask was more about the purpose of scheme's creation
> way back when. Was scheme actually *created* for the purpose of
> teaching?
Probably not per se, but I'll check. I _think_ it was created by
Steele/Sussman as a paper as part of some research but I'm not sure it
was intended really to be used at all at that point except for fun.
Sussman was teaching Lisp then, though. (Not sure if Abelson was back
then. My memory says he came onboard slightly later, but I might be
misremembering...) Sussman was using a really ad hoc silly lisp for
the class, probably not of his chosing. I first saw that lisp on the
pdp-11/45 we were using under the Delphi operating system and later
they moved to Unix. (It had some very odd features, like you could
invoke it with a -t or -s option from the command line to tell it to
use a "tree interpreter" or "stack interpreter", which I think
affected whether you got sphaghetti stacks or not...) But the system
it ran on was way too loaded and they wanted to use it on other
machines besides the delphi computer (which was called that even after
it didn't run the delphi operating system). I wrote, in Maclisp on
the pdp10, a simulator of the lisp, which people I know all called
delphi lisp (though I'm not sure that was its name) so my friends
could do homework on another machine. Then I played around with the
simulator and wrote something I liked better called "ulisp" (I believe
the "u" had to so with its origin on the unix). Anyway, ulisp was
used in sussman's class for one semester. It was pretty in some ways
but it didn't have tail call elimination and I for the life of me
didn't know what Sussman was ranting about when he said he wanted
that. (I don't know if he wasn't explaining himself well or if I
wasn't listening.) But he ended up taking original-Scheme (which I
*think* he'd already done as a kind of research project with Steele)
and revised it heavily for his class. I'm not sure if this was going
on already or if it was catalyzed by his frustration with my lisp and
the lisp mine had replaced.
[I still have the ulisp spec at least in hardcopy and will try to put
it online, btw. It had some curious properties that were not what
sussman wanted to be teaching, but it was quite elegant and cute in
its own very different way... it would make a good scripting
language. it was hard to compile, i realized later, becuase of some
oddball decisions i'd made. (The TeX macros I worked out for Ulisp's
manual, though, turned out to be usable for documenting Maclisp and
probably had a coincidental effect on my willingness to start
accumulating maclisp trivia, ultimately resulting in the maclisp
manual, and my interest in documenting lisps. So the weird potential
side effects of stray projects one happens into even just by chance
are not to be understated.)]
> I was under the impression that it was not, though I can't
> for the life of me remember where I get that impression from, and am
> now suspecting that it was erroneous.
I think originally not, but I think Sussman had these ideas rolling around
in his head and was frustrated that he didn't have a language for his class
that allowed him to use them. So I think he co-opted Scheme's design and
development for the purposes of the class for a while, and I think it's
probably at least fair to characterize it as having been productized for
teaching, if not designed for it. Also, original-Scheme is different in
a lot of ways than the Revised Report scheme was. It has changed over time.
I'll see if I can get someone to fill in some gaps here. I was an
undergrad at the time, and though I shared an office at the lab with
Steele during that general timeframe, and I hung out a lot downstairs
with Sussman, I didn't really have a total understanding of what
"drove" the lab's activity at that point. I'm not even sure I then
knew the right questions to ask. I just kind of pushed my way into
things blindly/bluntly and learned by the seat of my pants... not that
most others around me didn't seem to be doing the same, but it doesn't
lead to the most objective retellings. It won't surprise me if Steele
and/or Sussman tells an utterly different version of this. I'll see
what I can coax out of them and post any results I get here.
Aaron J Reichow
> The original source is at http://Sugar.mini.dhs.org/
> it's about 100 lines.
Thanks for the pointer.
> > Dylan never really took off, either.
> >
> Dylan tried to do too much, I think. Sugar source is pretty much ordinary
> scheme, just with the information that parantheses usually convey to the
> reader conveyed by the indentation instead - since pretty much everyone
> indents anyway (or the editor does it for them), and Sugar still _allows_
> the normal parentheses, it's quite popular for just banging out code - one
> problem you have with estimating it's usage is that people may write the
> code in sugar syntax, but release the code in normal parens.
Do a fair amount of people actually use this in your estimation? What
kinds of people? Algol-head CS students forced to use Scheme in school?
> Anyway, if you think that's wierd and pointless, wait till you see cugar,
> which makes C++ into an indentation-sensitive python-lookalike...
Actually, I've used that before on CS assignments. Didn't last through the
semester unfortunately- evenually we were paired for later assignments,
and cugar couldn't change my partner's source back in to cugar. :)
Regards,
Aaron
Aaron Reichow :: UMD ACM Pres :: http://www.d.umn.edu/~reic0024/
"life, probably the biggest word i've ever said, that says a lot,
because there's a whole lot of words inside my head.." :: atmosphere
David Golden
> Do a fair amount of people actually use this in your estimation?
I'd say only a minority of schemers, and it seems to be more popular/known
in france/germany than in america, but the facility tends to be there for
programmers who like it - actually, a similar package for common lisp might
be nice, if it doesn't already exist...
> What kinds of people?
Lazy people, and people who think all the parens in lisp are as ugly as
all the $ signs in Perl. :-)
Actually, as all lisp people know, the current XML fad is rather silly,
given that XML IS basically a tree structure, like one might compose in
lisp with conventional () sexps, but with really annoying syntax -
one of the fun things you can do in theory is munge Sugar and the SSAX
functional xml parser[1] together, so you can write xml/xhtml thusly:
html
head
title
"My Document"
body
h1
"this is my document"
p
"And this is a paragraph. Woop-de-do"
Personally, in conjunction with an autoindenting editor, I think I'd find
this a lot less annoying than the myriad <> of XML...
[1] See http://ssax.sourceforge.net - no doubt, a CL port or
reimplementation of this framework would be relatively painless... it'd
be nice if it still used the same SXML data format...
Janos Blazi
"Edward Piman" <eip...@yahoo.com> schrieb im Newsbeitrag
news:Xns917A7B05D1EF...@65.82.44.7...
> Browsing posts to this group I frequently see real scorn for scheme. Over
> on comp.lang.scheme I fail to see this same scorn for CL. Why is that? As
> an outsider, I am puzzled by this bad feeling between groups who would
seem
> to have much in common.
>
> the advantage of books such as SICP and EOPL. Presumably CL has its
> advantages too; anyone care to fill me in? Why (or for what purposes) is
> CL better?
Scheme has no Erik Naggum.
J.B.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
Check out our new Unlimited Server. No Download or Time Limits!
-----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
Ray Blaak
> dirtied by CL. I said, taking one idea or reading one page of text from CL
> will not make this a dirty language and that it was idiotic to say
> otherwise, but they persisted in an utterly emotional response, refusing to
> allow the matter to come to the table for discussion. They did not want
> ISLISP polluted by CL thoughts.
This "heads in the sand" mentality is the scourge of organizations.
My trick for dealing with this kind of thing is to present the technical idea
one its own, without indicating the controversial origins.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
bl...@telus.net The Rhythm has my soul.
Wade Humeniuk
do
> you mean by "pure" (or "purer")? We are not talking about diamonds or gold
> we talk about languages and it is not absolutely obvious to me why being
> "pure" is unconditionally a good thing for a language. (many more
important
> things like water or air are useless if they are pure...) I don't really
> think that distinguishing nil,(),false has anything to do with purity. You
> may have seen an extensive discussion over this topic lately and AFAIR
> there was _no_ consensus that the distinction is the unconditionally right
> thing to do - so _how_ can that increase "purity" in a language?
When people are talking about a pure language I think they are really
referring personally to themselves. That "they" are "pure". That their
thoughts are not contaminated by complexity. They have fresh ideas, new
approaches, innovative constructs and uncluttered vision. For these people
they confuse the programming languages they use with who they are.
The idea that advances are made by naive (but gifted) youth, is a mythology
deeply ingrained into modern thought. Unencumbered by the past and all its
untidiness (pureness) they have the pliability to see new things. It is
half true. Having a limited number of paints (the three primary, white and
black) with which to paint a picture is not a virtue even though one can
theoretically mix all possible colours (in practice this is impossible).
The advancements of computer science (and programming) in the 60's and 70's
was done largely by the young though the groundwork was laid people with
great experience and insight. There were lots of new ideas and approaches to
come out then. The point however is that these have come out, the work has
been done and its time to move ahead. The work with Scheme, Dylan and Java
is just re-implementing the wheel. Maybe it is because programming can
create the illusion that you are accomplishing something when you are really
not.
Wade
Christopher Stacy
Kent> Christopher Stacy <cst...@spacy.Boston.MA.US> writes:
>> >>>>> On Mon, 17 Dec 2001 14:12:16 -0700, Wade Humeniuk ("Wade") writes:
Wade> As for lexical scoping, its no longer an innovation.
>>
>> That particular innovation adopted by Scheme actually came from
>> (at least) an earlier Lisp language called MDL, by the way.
Kent> Actually, it came from Algol.
I also thought that it originally came from Algol (which is why I said
"at least"), but I think MDL was the first Lisp to have lexical scoping.
Actually, in MDL, symbols were self-evaluating (like keywords in CL),
and for a symbol value you had to specify whether you wanted the
"global" or "local" value. The reader macros "," and "." called
the symbol-value functions GVAL and LVAL, respectively.
MDL was the preferred Lisp programming language of the Project MAC people
on the 2d floor of the lab (people on most other floors liked MACLISP).
Christopher Stacy
Janos> "Edward Piman" <eip...@yahoo.com> schrieb im Newsbeitrag
Janos> news:Xns917A7B05D1EF...@65.82.44.7...
>> Browsing posts to this group I frequently see real scorn for scheme. Over
>> on comp.lang.scheme I fail to see this same scorn for CL. Why is that? As
>> an outsider, I am puzzled by this bad feeling between groups who would
Janos> seem
>> to have much in common.
>>
>> I am interested in learning more about one or both languages. Scheme has
>> the advantage of books such as SICP and EOPL. Presumably CL has its
>> advantages too; anyone care to fill me in? Why (or for what purposes) is
>> CL better?
Janos> Scheme has no Erik Naggum.
Janos> J.B.
That's a bug, not a feature.
Kent M Pitman
> >>>>> On Tue, 18 Dec 2001 15:33:35 GMT, Kent M Pitman ("Kent") writes:
>
> Kent> Christopher Stacy <cst...@spacy.Boston.MA.US> writes:
> >> >>>>> On Mon, 17 Dec 2001 14:12:16 -0700, Wade Humeniuk ("Wade") writes:
> Wade> As for lexical scoping, its no longer an innovation.
> >>
> >> That particular innovation adopted by Scheme actually came from
> >> (at least) an earlier Lisp language called MDL, by the way.
>
> Kent> Actually, it came from Algol.
>
> I also thought that it originally came from Algol (which is why I said
> "at least"), but I think MDL was the first Lisp to have lexical scoping.
That may well be (never thought to check) but, being a statement about
timelines rather than influence, is not in contradiction with my
stated belief. (I sent my post to Sussman and Steele to see if they
have any comments to make. We'll see.) Of course, the influence could
have followed in lockstep with timeline, but it's a mistake in general
to assume that everyone at point X in time was either cognizant of all
things before point X or willing to open their mind to the implications
of such things even if cognizant.
> MDL was the preferred Lisp programming language of the Project MAC people
> on the 2d floor of the lab (people on most other floors liked MACLISP).
You speak about the lab like a unified thing. I always felt the AI Lab
and the Lab for Computer Science were worlds apart. ESPECIALLY the
dynamic modeling (DM) people, who didn't share much of any software with
the other three computers in the building...
Kent M Pitman
> The idea that advances are made by naive (but gifted) youth, is a mythology
> deeply ingrained into modern thought. Unencumbered by the past and all its
> untidiness (pureness) they have the pliability to see new things.
From the "AI Koans" (perplexing little fables used for "teaching"
occasional lessons at MIT's AI Lab, I think generally attributed
to Danny Hillis as author):
+--------------------
|
| In the days when Sussman was a novice, Minsky once came to him as he
| sat hacking at the PDP-6.
|
| "What are you doing?", asked Minsky.
|
| "I am training a randomly wired neural net to play Tic-Tac-Toe"
| Sussman replied.
|
| "Why is the net wired randomly?", asked Minsky.
|
| "I do not want it to have any preconceptions of how to play", Sussman said.
|
| Minsky then shut his eyes.
|
| "Why do you close your eyes?", Sussman asked his teacher.
|
| "So that the room will be empty."
|
| At that moment, Sussman was enlightened.
|
+--------------------
Barry Margolin
>This "heads in the sand" mentality is the scourge of organizations.
>
>My trick for dealing with this kind of thing is to present the technical idea
>one its own, without indicating the controversial origins.
If their priorities are political issues over technical one, they're bound
to ask or find out. The whole reason ISLISP was created was because
several influential members of the ISO Lisp committee were extremely biased
against CL, and that bias influenced the process.
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Kent M Pitman
> In article <ur8psq...@telus.net>, Ray Blaak <bl...@telus.net> wrote:
>
> >This "heads in the sand" mentality is the scourge of organizations.
> >
> >My trick for dealing with this kind of thing is to present the
> >technical idea one its own, without indicating the controversial
> >origins.
>
> If their priorities are political issues over technical one, they're
> bound to ask or find out. The whole reason ISLISP was created was
> because several influential members of the ISO Lisp committee were
> extremely biased against CL, and that bias influenced the process.
I wouldn't say this was the WHOLE reason. It was probably a strong
influence in the start and perhaps an influence all along. If this had
been the only driving force, I don't think it would have been completed
because completing it required considerable accomodation to CL's needs.
It is not a CL subset, but I think we (the US, and by implication the
global CL community) got all of the important concessions we needed in
order to assure that an ISLISP compatibility package can be constructed
within a conforming CL without a conflict with the CL type system, the
CL package system, etc.
Another reason, though, that ISLISP was there and continued to be
important was that there were specific Lisp projects afoot
internationally in various countries and regions that for various
reasons needed some thing that CL wasn't. (I vaguely recall touching
on this in my paper about Lambda, the ultimate political party.
http://world.std.com/~pitman/PS/Lambda.html ) Either smaller text size
or an international stamp of approval or the mere fact of still being
an ongoing design and not a finished project. As someone (not sure
who) once rightly said about standards: The nice thing about standards
is that there are so many of them.
Btw, I have made some very negative remarks about the Scheme
community's disdain for bloat not because I don't think the size issue
is ever real, just because the passion there was extreme. I remember
once they were concerned about the fact that their community was so
size-obsessed that, like an anorexic, they were both too small to be
printed in a bound edition (and had to include another related paper
with the spec to give it more bulk) and yet at the same time didn't
want to grow the spec for "fear" it would change over to where it
needed a different kind of binding that they couldn't brag about in
the same way. When we're talking "keeping Scheme small", we're
talking really obsessively extreme here. HOWEVER, by contrast, the
international concern about size was much more reasaoned. Japan, for
example, cited a specific desire of 100 pages or less, because it was
expensive to do a translation and because they feared various
universities would not use it bigger than a certain size. Yet they
still did not make irrational requests that we not fix bugs or clarify
issues and when the ultimate document was something like 130 pages or
so (can't quite recall, but I recall it as an order of magnitude
smaller than ANSI CL), they voted yes. This kind of concern about
size I have no problem with.
Lieven Marchand
> You are to be locked in a closet. You may choose to be locked in the
> one marked Scheme or the one marked Lisp. In the Scheme closet is a
> drawer filled with thousands of tiny keys, each of which neatly fits
> just one lock. One will get you out, but the others are irrelevant
> to your task. Whoever put them there didn't like master keys--too
> impure. So you'll have to find the one you need. In the Lisp
> closet, you will find a hammer, a screwdriver, and an adjustable
> wrench, but no key. (Neither is Lisp this blunt, nor Scheme this
> unforgiving, but indulge me some exaggeration to make a simple point
> here.) Dinner is not the table while you're locked in there--will you
> get out before it's stone cold?
A nice contrapunt to Guy Steele's woodworking toolshop metaphor in his
foreword to Scheme and the Art of Programming.
I'm beginning to detect a theme ;-)
--
Lieven Marchand <m...@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words
Aaron J Reichow
> Personally, in conjunction with an autoindenting editor, I think I'd find
> this a lot less annoying than the myriad <> of XML...
>
> [1] See http://ssax.sourceforge.net - no doubt, a CL port or
> reimplementation of this framework would be relatively painless... it'd
> be nice if it still used the same SXML data format...
I do the same thing, but using the parens, with le-sursis and clisp. A
collapsing-tree editor would make this even better.
Regards,
Aaron
Aaron Reichow :: UMD ACM Pres :: http://www.d.umn.edu/~reic0024/
"the question is no longer between violence and non-violence; It is
between non-violence and non-existence." :: martin luther king junior
Christopher Stacy
Michael> Kent M Pitman <pit...@world.std.com> writes:
>> Michael Hudson <m...@python.net> writes:
>>
>> > Christopher Stacy <cst...@spacy.Boston.MA.US> writes:
>> >
>> > > Scheme was designed to teach certain concepts in computer science
>> > > classes.
>> >
>> > Are you sure about this?
>>
>> I have been in the room of the Scheme authors (check the front page
>> of the Revised^n Report on Scheme to see my name in the credits) and
>> have repeatedly seen decisions made in favor of teaching and in
>> opposition to proposals that would make it easier for industry.
Michael> Hmm. I think I sort-of misread Christopher's remark, and asked the
Michael> wrong question. I was more-or-less aware of scheme's development (and
Michael> knew your name was on the front of R^5RS) -- though thanks for the
Michael> long and as-ever informative post.
Michael> What I meant to ask was more about the purpose of scheme's creation
Michael> way back when. Was scheme actually *created* for the purpose of
Michael> teaching? I was under the impression that it was not, though I can't
Michael> for the life of me remember where I get that impression from, and am
Michael> now suspecting that it was erroneous.
Michael,
At least by R^3, Scheme was described by the authors thus:
"As might be expected of a language used primarily
for education and research..."
That certainly doesn't mean that Scheme is entirely unsuitable for
industrial applications! However, it does hint at the constituency,
and the underlying goals of the language.
Originally, SCHEME was created as research into programming, especially
recursion techniques: to "have a simple and concrete experimental domain
for certain issues of programming semantics and style". It grew out
experience with Hewitt's ACTORS language, and Micro-PLANNER and CONNIVER.
The original SCHEME Report does not mention ALGOL at all, but does go out
of its way to mention those other languages; there is no cite of ALGOL,
but there is of MDL (which Sussman was also peripherally involved in),
and a couple of CACM cites (Dijkstra; Knuth; Lamport) on "Dijkstra's
Concurrent Programming Problem". Certainly the authors knew ALGOL, though.
As to whether they originally thought they were making a Lisp: they did and
they didn't. That is, it's in the Lisp family, but significantly different.
"SCHEME is essentially a full-funarg LISP...
All LISP functions are primitive operators in SCHEME,
and have the same meaning as they have in LISP."
Later, in the first Revised Report, SCHEME is described as "a dialect
of LISP" and "a LISP-like language".
At that time, people were busy figuring out "the funarg problem" and
related issues; evaluation, quoting, and call-by-name vs. call-by-value,
and basic Lisp implementation techniques were also still research areas.
The were creating a language to *study* *certain* programming issues,
not trying to create a language for application programming. One of
the very first things mentioned was the elimination of features that
were useful for applications such as database manipulation and pattern
matching (which were present in those other research languages that
they were involved with). Over and over, the whole point and emphasis
is on simplicity, lambda calculus (Sussman was teaching 6.031 at the
time), and the cool idea of continuation passing recursion.
That was all back before 1975.
I think ALGOL is first mentioned about 3 years later in the first
Revised Report on SCHEME, which is when the BNF was introduced.
At that point, however, the description was still: "SCHEME programs
are represented by LISP s-expressions. The evaluator interprets
S-expressions in a specified way. This specification constitutes
the definition of the language..."
By that time, they had also gotten rid of some of the Lisp terminology.
(Originally, what CL calls "special forms" and MACLISP called "FEXPRs"
were called "AINTs" in SCHEME.)
I personally didn't encounter SCHEME until 1981 (when I was mostly
programming in MACLISP, MDL, and Lisp Machine Lisp, and of course,
PDP-10 assembler). At that time, SICP was being written from the
course notes for 6.001, and the primary application of Scheme was
for teaching that course. Scheme was also the target of a set of
new Lisp processor chips (the ASSQ chip, etc.).
(Not related to the Lisp Machine project, incidentally.)
Those courses (taught now in many more schools) remain the primary
application of Scheme. The language is still useful for exploring ideas
in programming, except to the extent that its clientele perceive that
this takes it away from being Scheme. Some object systems, and hygenic
macros, are examples of more recent (ca 1983) language research in Scheme.
Common Lisp, of course, includes significant lessons learned from Scheme.
Of course Scheme *can* also be used for writing "real" applications,
but that was not its intended purpose. (Contrast this with Common Lisp,
which eschewed anything smacking of experimental, maybe overly so, and
was designed explicitly for writing and porting industrial applications.)
For some applications, for example tiny machines running small embedded
programs, Scheme might be a much better choice than Common Lisp.
In recent years, Sussman has promoted using Scheme in several
science and engineering domains, and as a vehicle of calculus for
teaching formal concepts in various domains.
When some people get all excited about Scheme being "pure" (by which I
suppose they mean "regularized to the point of simplicity, simple to
trivially implement, underspecified, and lacking many features"),
that just doesn't really enthuse Common Lisp programmers, who are
interested in a different set of aesthetics and features, and who
seem to resent an implication that Common Lisp is "dirty".
But if the real world is not pure, and Lisp is happily a ball of mud,
why should we be offended that Common Lisp is not "pure", anyway?
Chris
cbbr...@acm.org
> On Tue, 18 Dec 2001, David Golden wrote:
>
> > Personally, in conjunction with an autoindenting editor, I think I'd find
> > this a lot less annoying than the myriad <> of XML...
> >
> > [1] See http://ssax.sourceforge.net - no doubt, a CL port or
> > reimplementation of this framework would be relatively painless... it'd
> > be nice if it still used the same SXML data format...
>
> I do the same thing, but using the parens, with le-sursis and clisp. A
> collapsing-tree editor would make this even better.
I'd love to see a port of something like this.
There are getting to be quite enough different sorts of documents out
there that use XML that would be _really_ nice to walk through using
CL.
I'm _slightly_ undecided as to whether I'd rather see:
a) Something like SSAX, where you have to write code to parse bits of
the document, so that essentially the parser walks across the
document, running your code as it goes, or
b) Something that transforms the whole document into a tree,
basically like the Franz "xmlutils," but a bit more portable :-).
I _think_ I'd generally prefer the latter; the fact that you get no
results before reading the whole document arguably means that it's
less efficient, and (arguably) "less elegant." On the other hand,
brute force can work quite well, and if the document fits nicely into
memory, I think that's what I'd rather have.
There are a bunch of XML libraries out there; none are quite
completely working...
--
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
http://www.ntlug.org/~cbbrowne/xml.html
Rules of the Evil Overlord #15. "I will never employ any device with a
digital countdown. If I find that such a device is absolutely
unavoidable, I will set it to activate when the counter reaches 117
and the hero is just putting his plan into operation."
<http://www.eviloverlord.com/>
David Golden
> I _think_ I'd generally prefer the latter; the fact that you get no
> results before reading the whole document arguably means that it's
> less efficient, and (arguably) "less elegant." On the other hand,
> brute force can work quite well, and if the document fits nicely into
> memory, I think that's what I'd rather have.
>
I dunno about that - a lot of XML (or pseudo-XML) usage, particularly
coming out of the microsoft camp, involves streaming it to clients over
sockets - then it's a definite advantage to have interim access to the
parts, particularly for "progressive display" of partial data (users like
to see the web pages or whatever building, and like to "click ahead" on a
part-rendered page, particularly if the network's slow.) and it's not as if
with SSAX (as opposed to the evil, evil SAX) you can't subsequently end up
with a complete DOM-style tree...
cbbr...@acm.org
In that I'm not presently looking at streamed usage, interim access
falls into the "don't care" category...
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/oses.html
Zaphod's just zis guy, you know?
David Golden
> There are a bunch of XML libraries out there; none are quite
> completely working...
how's the xml.lisp one in the clocc?
http://clocc.sourceforge.net/dist/cllib.html
(I've never used it, just asking.)
Harald Hanche-Olsen
| As someone (not sure who) once rightly said about standards: The
| nice thing about standards is that there are so many of them.
That was Tannenbaum, I think. He may not have been the first, though.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Yes it works in practice - but does it work in theory?
Bijan Parsia
[snip]
> When people are talking about a pure language I think they are really
> referring personally to themselves.
I don't think that's a wise thought to hold uncritically. When I encouter
"pure" it's usually "pure with respect to something" and the contrary is
"hybrid". So, Java isn't a pure object oriented language because of
primitive types. Purity of OOness isn't a virtue on its own, or, at least,
it's perfectly possible to have a completely wretched pure OO language (or
"more or less" pure :)).
This is only one, primary use. It's perhaps unfortuneate that the word
"pure" tends to get read *uncritically* as "better", or, at least, more
valuable. But purity even of gold isn't an uniform virtue (as pure gold is
very very soft, too soft for many purposes). Hybridity can bring about
more vigor, disease resistence, or interesting colors (I tend to think of
Common Lisp as a hybrid langauge in this sense; it *unites* various
paradigms/styles in a way that produces strengths beyond merely having the
array of styles available; in this way, "multi-paradigm" doesn't seem
right to me).
[snip]
> The advancements of computer science (and programming) in the 60's and 70's
> was done largely by the young though the groundwork was laid people with
> great experience and insight. There were lots of new ideas and approaches to
> come out then. The point however is that these have come out, the work has
> been done and its time to move ahead. The work with Scheme, Dylan and Java
> is just re-implementing the wheel.
[snip]
Java and Dylan are both explicilty derivative projects, indeed, projects
motivated in part by the goal of making certain things "palatable" to
"mainstream" programmers. That is, they both more or less explicitly
sought to move the state of the general *practice* more in line with the
state of the *art*.
(I tend to think of Common Lisp as an attempt to *codify* the minimum
level of the state of the art and general practice. That is, to settle
*some* stuff as settled so as to focus energy on new things. CL would fail
in one way if it was a base to restrictive to support new things. Clearly,
it's not *yet* failed in that respect.)
Scheme, OTOH, has a rather different history. It may have *ended up* as a
place where wheels are reinvented, but I don't think it started there (as
subsequent posts in this forum have documented).
Cheers,
Bijan Parsia.
Seth Gordon
sparse, almost every Scheme *implementation* worth using has features
not included in the standard. There are a lot of free Scheme
implementations floating around out there, with various feature sets.
So rather than simply ask "what are the advantages of CL over Scheme or
vice versa?", it might be better to start with some goal, find out
*which* Scheme implementations are best for achieving that goal, and
then find out whether there are CL implementations that do better for
that purpose than their Scheme competitors.
--
"Any fool can write code that a computer can understand.
Good programmers write code that humans can understand."
--Martin Fowler
// seth gordon // wi/mit ctr for genome research //
// se...@genome.wi.mit.edu // standard disclaimer //
Nils Goesche
> Elegance often arises from imposing a framework of artificial
> constraints. Artists sometimes find it helpful to adhere to some
> rigid frameworks which give their work an identifiable form; the
> result can be elegant, because it makes use of the built in
> elegance-generating properties of the form, which amplify the
> artist's contribution. But some forms are simply not applicable to
> some kinds of expression. There is a mistake of viewing those
> expressions which don't fit into a given subjectively preferred form
> as inelegant, giving rise to orthodoxies.
> Some people view elegance in programming languages similarly; that
> there is some true way of doing things, and everyone must program to
> that. This works fine up to the point that programming is merely a
> form of artistic self-expression. If one expression doesn't work,
> the artist-programmer can self-censor and seek another. When
> programming is driven by actual externally-imposed requirements,
> this approach is no longer adequate.
Hear, hear. I wish somebody would take the time and explain this to
the folks over in comp.lang.functional ;-)
> Carrying the analogy further, suppose you are a music composer, and all
> you ever compose is very elegant baroque counterpoint in the style of
> J. S. Bach and company. You are happy within these forms making beautiful
> magic. But what if someone wants to commission you to prepare a suite of
> 20th century music? Well, you can say ``Bah, that stuff is cacophonic
> humbug, I only write elegant music.'' So the job goes to someone else.
Interesting analogy. I wonder if it fails if taken very far. For,
there is no music whatsoever without ``form'', that is, rules of any
kind. Bach had certain rules and forms, sometimes very strict like
the ``contrapunkt'' rules, but in other fields was more free than the
people who came after him, like with harmonics. People who don't
understand 20th century composers often think that those compose
without any rules, but that isn't true. Schoenberg /hated/ the term
``atonal music'', and he never wrote a single piece of music that
wasn't ruled by a very rigid framework (that changed over time,
though; sometimes from piece to piece). Similarly, those people who
can tell good free jazz from bad free jazz know that the Godfather
himself, John Coltrane, never played a single note that didn't fit
into the particular framework he was working in (at the time he played
it). In fact, the very reason people don't play any ``free jazz''
anymore is rather that its somewhat hidden frameworks proved to be
rather too restrictive, so the name ``free jazz'' is actually a
misnomer.
There has never been any kind of music that didn't work within some
kind of a ``rigid framework'', nor could there be any. The possible
frameworks differ very much, though. Now, is there some other
framework Lisp people work in? I think there is no Lisp analogy for
stuff like
(*(int *) p)++;
so maybe there is...
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Kent M Pitman
> You should keep in mind that while the Scheme *standard* is deliberately
> sparse, almost every Scheme *implementation* worth using has features
> not included in the standard. There are a lot of free Scheme
> implementations floating around out there, with various feature sets.
>
> So rather than simply ask "what are the advantages of CL over Scheme or
> vice versa?", it might be better to start with some goal, find out
> *which* Scheme implementations are best for achieving that goal, and
> then find out whether there are CL implementations that do better for
> that purpose than their Scheme competitors.
But then what meaning does it have to say "Scheme" has any particular
property if every Scheme is different.
If you criticize CL, you have said something because there is a lot of
commonality there. But criticizing Scheme is as slippery as criticizing
Lisp.
Why don't we just say when people say Lisp is too big, "no, it's small"
because of ISLISP. Or when they say it has no users we'll say "Emacs has
lots of users". I have no problem saying there are useful Scheme
implementations but what makes them useful is, to a large degree, the
part invested by the vendors. Had those same vendors invested the same
amount in CL or some Lisp dialect, I don't think they'd be any worse off.
When we do comparison, let me know if we're talking implementations to
implementations or languages to languages. Because if we compare
implementations, I may pick something like Symbolics Genera as my
implementation to compare to. Or I may pick Allegro. Or I may pick
LispWorks. It just depends on what I think you're going to debate me
about, as I'm sure it does in reverse when people pick a particular
Scheme implementation to debate about... I'm jus tnot sure I see the
point.
Raffael Cavallaro
> Janos> Scheme has no Erik Naggum.
> Janos> J.B.
>
> That's a bug, not a feature.
Did you mean that not having Erik was a bug in Scheme, or that having
Erik is a bug in Common Lisp?
Erik Naggum
| I think there is no Lisp analogy for stuff like
|
| (*(int *) p)++;
|
| so maybe there is...
Well, instead of using the pointer itself, use an index to obtain the
equivalent result in Allegro CL:
(sys:memref p <offset> <index> :signed-long32)
But you have to know the size of the object you have retrieved to
increment the index enough. (incf <index> 4) would work here. <offset>
is somewhat magic.
:signed-long32 is a fairly non-CL way of saying (signed-byte 32).
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
Erik Naggum
| Did you mean that not having Erik was a bug in Scheme, or that having
| Erik is a bug in Common Lisp?
Having Janos Blazi and Raffael Cavallaro going hostile and personal in
_any_ forum is bug in their particular wetware, but fortunately does not
actually affect anyone, only annoy everyone while they breathe in our
corner of the world. Unfortunately, removing morons from the Net is not
considered useful by the morons. If they were smarter, they would figure
out the value to all of going away, but not being smarter, they do not.
And why is that these particular morons do not have anything to say
except to post yet more of their idiotic attacks at me? What other proof
that someone has _nothing_ useful whatsoever to say can there be?
Now, watch them thinking that they were attacked first and deserve a
chance to "retaliate", when everybody else knows that they attacked me
and has no right to "retaliate" at all. So just go away, will you?
Siegfried Gonzi
Nils Goesche wrote:
> Hear, hear. I wish somebody would take the time and explain this to
> the folks over in comp.lang.functional ;-)
Explaining is not appropiate, I would assume. I think people should (and will
only) learn from their failures. I have learned my lessons from programming in
Clean. It is programming with tied hands...
I really wanted to help making a better world. When one always reads that
C,C++,...sucks and the software-crisis, and the silver-bullets...and God and
Devil. I thought the only way to change this is actually listen what computer
scientists have to say. And my first guess has been: why should I beg differ
when they claim that functional programming (Clean in this case) assits you in
writing clean, reusable and robust programs. Now I feel a little bit cheated
when I think on Clean and their claims...maybe I am too naive, because I am
from academia too.
S. Gonzi
Janos Blazi
My mail was in no way hostile. You will not deny that you are a phenomenon
and I that was all I referred to.
By the way: One of the great national poets of Hungary (Babits for the
Hungarian readers) once wrote that in masterpieces even bugs become
features.
Janos Blazi
> property if every Scheme is different.
In my opinion it is interesting that in SICP they usually say "Lisp" and not
Scheme. In one of the other books on Scheme the authors say that Scheme is
Lisp's little brother. I think the CL community should excourage everybody
to learn and eventually start with Scheme as once somebody saw the power of
a Lisp like language he is a potential CL user.
Erik Naggum
| Thank you for sending a response.
Yes, now you exist one more day.
| My mail was in no way hostile.
Yes, it was, you are just much too Janos Blazi to figure it out.
| You will not deny that you are a phenomenon and I that was all I referred
| to.
_Please_ make an effort to understand what you are saying, will you?
Janos Blazi
feature but a bug. This remark I should interpret as a joke but you could
interpret is as hostile. In my original mailing there was no judgement
whatsoever. If you claim that I was hostile then you must have an idea what
I had in mind (but did not put into my mail).
I also admit that you did not start this (though sometimes you do).
Erik Naggum
| I also admit that you did not start this (though sometimes you do).
You will not deny that I never start any attacks at all. It is people
like you who believe that any requirement on your part to _think_,
expressed indirectly, directly, or as exasperation, is a personal
affront. It is not. Just start to think, and you will understand.
Janos Blazi
I do deny it. Let us take two recent examples.
(1) Anette Stegmann posted some trange views here and then you told her
that she was an idiot. (Now I do not like her too much: after having
some dispute about LaTeX in another NG she looked up the NGs where I posted
and posted that I was a troll. She did this in this NG too.) But
objectively it was you who started the first personal attack on her.
(Sometimes I have the impression that if somebody posts something that is
not correct you take it as a personal affront.)
(2) There was another case more recently where somebody said something you
did not like and then you started attacking him immediately (I forgot the
name but I remember that he responded by something like "You do not know me
well enough to talk to me this way".
Finally (now an attack follows) I just wonder if the late Mr Stevenson had
known an ancestor os you before he (Stevenson) started writing one of his
major works.
I tried to analyze the way you are and myself: The reason that I still talk
to you after all that (think of my grandparents!!): It seems to me that
while you are *extremely rude*, you are not mean and you are not vindictive
either.
> It is people
> like you who believe that any requirement on your part to _think_,
> expressed indirectly, directly, or as exasperation, is a personal
> affront. It is not. Just start to think, and you will understand.
I think: as well as I can.
Johan Kullstam
> > But then what meaning does it have to say "Scheme" has any particular
> > property if every Scheme is different.
>
> In my opinion it is interesting that in SICP they usually say "Lisp" and not
> Scheme. In one of the other books on Scheme the authors say that Scheme is
> Lisp's little brother. I think the CL community should excourage everybody
> to learn and eventually start with Scheme as once somebody saw the power of
> a Lisp like language he is a potential CL user.
this seems to be a roundabout way to win CL adherents. bait and
switch is insulting the students and doesn't strike me a terribly
effective method to get people to look at common-lisp.
why not start people with common-lisp and let them see? everybody who
sees the power of common-lisp is a potential common-lisp user.
for any X, if you want them to learn X, why not teach X? teaching Y
is the wrong thing.
--
J o h a n K u l l s t a m
[kull...@mediaone.net]
Janos Blazi
> switch is insulting the students and doesn't strike me a terribly
> effective method to get people to look at common-lisp.
>
> why not start people with common-lisp and let them see? everybody who
> sees the power of common-lisp is a potential common-lisp user.
>
> for any X, if you want them to learn X, why not teach X? teaching Y
> is the wrong thing.
You are right but you have to take into account the university lecturers who
are not willing to give up their familiar Scheme.
Nicolas Neuss
> > You will not deny that I never start any attacks at all.
>
> I do deny it. Let us take two recent examples.
> ...
In the last 1-2 years I followed this newsgroup quite intently, but I
never saw Eric attacking without a reason. Mostly, the reason was
that people didn't think enough before posting to an audience of
probably several thousand people (like your personal attack this
time).
Up to now, I have not really seen him succeed in driving people like
you away, but I dare not imagine which stupidities we would have had
to endure from you if you would _not_ have been disciplined for your
stuff.
> I think: as well as I can.
That's sad news. Please use the tenfold time on your messages then.
The group deserves it.
Bye,
Nicolas.
Immanuel Litzroth
Erik> You will not deny that I never start any attacks at all.
I would never not deny that you never start any attacks at all.
Immanuel
Dorai Sitaram
It isn't absolutely so. Learning is not
downloading or carbon-copying. It is a complicated
process of ministeps and sidesteps and missteps and
unlearnings.
Bait-and-switch! What an interesting image! Scheme
teachers as wily Common Lisp salesmen in
disguise! -- it sounds so bizarre. This reminds
me of a Leo Rosten vitz about a young Korean immigrant
working in a Jewish store who speaks to the customers
in perfect Yiddish. A patron marvels at his linguistic
felicity and asks the owner how come, to which the
latter responds, "Quiet, Shmuel! He thinks he's
learning English!" (Ethnicities may be alpha-renamed.)
Well, you must have meant something else, but
your message is too brief for me to see its
elucidation.
Anyhow, people who learn Scheme may voluntarily, with
their new-found grasp of things, move on to Common Lisp
-- and love it "oh so much" that they stay with it --,
as many have attested here. _They_ switch. As
this is in addition to people who learn Common Lisp
from the get-go, it looks like it's a nett gain for
Common Lisp. Why complain? The bride is too
beautiful?
--d
Florian Hars
> > That particular innovation adopted by Scheme actually came from
> > (at least) an earlier Lisp language called MDL, by the way.
> Actually, it came from Algol.
There is a nice spaghetti graph of the influences on Scheme on page 10
of the "Detailed history of the Lisp family" linked to from
http://lambda.weblogs.com/diagrams
But ther is no MDL, only something called "Muddle", is this the same
thing?
Yours, Florian.
Thomas F. Burdick
> > But then what meaning does it have to say "Scheme" has any particular
> > property if every Scheme is different.
>
> In my opinion it is interesting that in SICP they usually say "Lisp"
> and not Scheme. In one of the other books on Scheme the authors say
> that Scheme is Lisp's little brother.
It might be nice if more Schemers described their language that way,
but somehow I don't think it's gonna happen :-). A more likely
description would be "slim cousin" or some such.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Janos Blazi
> but somehow I don't think it's gonna happen :-). A more likely
> description would be "slim cousin" or some such.
But then maybe the members of this group should take a patronizing attitude:
"Of course lad, start with Scheme it is excellent and after you have learnt
it and if you wanna do serious work you can still change to CL." Or: "Scheme
is excellent for learning, it is a very nice language. Of course it has
never been intended for doing serious work with it but for that we CL." Or
something like that.
I think these mesages would not be very far from truth anyway.
Christopher Stacy
Florian> Kent M Pitman <pit...@world.std.com> writes:
>> Christopher Stacy <cst...@spacy.Boston.MA.US> writes:
>> > That particular innovation adopted by Scheme actually came from
>> > (at least) an earlier Lisp language called MDL, by the way.
>> Actually, it came from Algol.
Florian> There is a nice spaghetti graph of the influences on Scheme on page 10
Florian> of the "Detailed history of the Lisp family" linked to from
Florian> http://lambda.weblogs.com/diagrams
Florian> But ther is no MDL, only something called "Muddle",
Florian> is this the same thing?
Yes.
Christopher Stacy
Florian> Kent M Pitman <pit...@world.std.com> writes:
>> Christopher Stacy <cst...@spacy.Boston.MA.US> writes:
>> > That particular innovation adopted by Scheme actually came from
>> > (at least) an earlier Lisp language called MDL, by the way.
>> Actually, it came from Algol.
Florian> There is a nice spaghetti graph of the influences on Scheme on page 10
Florian> of the "Detailed history of the Lisp family" linked to from
Florian> http://lambda.weblogs.com/diagrams
Florian> But ther is no MDL, only something called "Muddle",
Florian> is this the same thing?
Yes, Muddle is how you pronounce MDL.
That graph has some things that are correct, and some that are not.
For example, it shows Algol relating to the original version of Scheme
but that didn't happen until later (it should be Revised Scheme).
It also fails to show MACLISP being related to Planner,
and also fails to show it for Scheme.
Kent M Pitman
> > It might be nice if more Schemers described their language that way,
> > but somehow I don't think it's gonna happen :-). A more likely
> > description would be "slim cousin" or some such.
>
> But then maybe the members of this group should take a patronizing attitude:
> "Of course lad, start with Scheme it is excellent and after you have learnt
> it and if you wanna do serious work you can still change to CL." Or: "Scheme
> is excellent for learning, it is a very nice language. Of course it has
> never been intended for doing serious work with it but for that we CL." Or
> something like that.
>
> I think these mesages would not be very far from truth anyway.
It has nothing to do with patronizing. I don't regard Scheme as the
same skill. Just as it might broaden your knowledge of languages to
learn German, it still won't help you much in a job involving
translating from Spanish to English and back. I don't think it's at
all like learning Portuguese or Italian which have some overlap. The
amount of overlap between Scheme thought and Common Lisp thought is,
in many ways, arguably broader than the gap between Common Lisp and Java.
The words may look the same between Scheme and CL, but the way you think
about them is so different that it's mostly "false cognates". And I was
taught in my study of human languages to be very wary of such.
Christopher Stacy
>>>>> On 20 Dec 2001 18:45:07 +0100, Florian Hars ("Florian") writes:
Florian> Kent M Pitman <pit...@world.std.com> writes:
>>> Christopher Stacy <cst...@spacy.Boston.MA.US> writes:
>>> > That particular innovation adopted by Scheme actually came from
>>> > (at least) an earlier Lisp language called MDL, by the way.
>>> Actually, it came from Algol.
Florian> There is a nice spaghetti graph of the influences on Scheme on page 10
Florian> of the "Detailed history of the Lisp family" linked to from
Florian> http://lambda.weblogs.com/diagrams
Florian> But ther is no MDL, only something called "Muddle",
Florian> is this the same thing?
Christopher> Yes, Muddle is how you pronounce MDL.
Christopher> That graph has some things that are correct, and some that are not.
Christopher> For example, it shows Algol relating to the original version of Scheme
Christopher> but that didn't happen until later (it should be Revised Scheme).
Christopher> It also fails to show MACLISP being related to Planner,
Christopher> and also fails to show it for Scheme.
Clarifying: those "related" arrows in my paragraph mean "influenced".
Janos Blazi
> same skill. Just as it might broaden your knowledge of languages to
> learn German, it still won't help you much in a job involving
> translating from Spanish to English and back. I don't think it's at
> all like learning Portuguese or Italian which have some overlap. The
> amount of overlap between Scheme thought and Common Lisp thought is,
> in many ways, arguably broader than the gap between Common Lisp and Java.
> The words may look the same between Scheme and CL, but the way you think
> about them is so different that it's mostly "false cognates". And I was
> taught in my study of human languages to be very wary of such.
You are taking me aback. I do not see such a big difference and this
probably indicates that I still think in C. And switching your way of
thinking is very diffcult (especially in my age). But then: There are a some
eexcellent books on teaching using Scheme (SICP, Concret Abstraction, etc.)
but there is *none* on teaching using CL.
There is a third, personal point: As I am not an expert I must trust
somebody. I know that you are an expert but then Mr. Abelson and the others
who say they are using Lisp are experts too. Do you think that their claim
of using Lisp is not justified?
Kent M Pitman
> > It has nothing to do with patronizing. I don't regard Scheme as the
> > same skill. Just as it might broaden your knowledge of languages to
> > learn German, it still won't help you much in a job involving
> > translating from Spanish to English and back. I don't think it's at
> > all like learning Portuguese or Italian which have some overlap. The
> > amount of overlap between Scheme thought and Common Lisp thought is,
> > in many ways, arguably broader than the gap between Common Lisp and Java.
> > The words may look the same between Scheme and CL, but the way you think
> > about them is so different that it's mostly "false cognates". And I was
> > taught in my study of human languages to be very wary of such.
>
> You are taking me aback. I do not see such a big difference and this
> probably indicates that I still think in C. And switching your way of
> thinking is very diffcult (especially in my age). But then: There are a some
> eexcellent books on teaching using Scheme (SICP, Concret Abstraction, etc.)
> but there is *none* on teaching using CL.
It's been a while since I looked, but S&ICP is a course more in algorithms and
ways of thinking than languages. The use of Scheme is intended to be
incidental, or was historically...
Here's what I find people learn in a Scheme course:
- how to cdr down a list
- lisp is 1 namespace
- it's ok to nest defines inside each other
- tail recursion won't get you in trouble
- declarations are unimportant
- class systems are unnecessary
- error systems are unnecessary
- languages without a written formal semantics are bad
- the goal of a language is to trivially implement itself metacircularly
Of those, only the first item is also true of CL.
Here's what I find people learn in Java:
- how to use a variety of datatypes
- class systems are good
- the namespace issue is not the main thing in life
- iteration using conventional operators is ok
- declarations are useful
- class systems are useful
- error systems are useful
- getting real work done is important
- dynamic type discovery is cool
Of those, most of them are also true of CL.
> There is a third, personal point: As I am not an expert I must trust
> somebody. I know that you are an expert but then Mr. Abelson and the others
> who say they are using Lisp are experts too. Do you think that their claim
> of using Lisp is not justified?
They are experts in what they do. The question of who is entitled to
call something Lisp is not an expertise isssue, though. It's just a
subjective issue. I'm not challenging their expertise. I don't see
them now as much as I used to when I was at MIT, but I consider them
to be among the many friends I made while there. I'm not trying to
disparage them. But these are guys that do not shy from a healthy debate,
and they would expect no less from me.
Erik Naggum
> You will not deny that I never start any attacks at all.
* "Janos Blazi" <jbl...@hotmail.com>
| I do deny it.
Grow a brain, Janos Blazi. It was a deliberate spoof of your idiotic
line. Too subtle for you, obviously. Sigh, what a cretin you are. Of
course, I also actually mean it. I criticize people's behavior harshly
some times, but I do not _attack_ them.
| (1) Anette Stegmann posted some trange views here and then you told her
| that she was an idiot.
Find the quote. You will find that not only are you an unintelligent and
despicably stupid person, you are also unable to remember well enough to
avoid being exposed as a liar. I kind of appreciate that you go to these
lengths to prove what kind of character you are.
| (Now I do not like her too much [...])
How amazing that you still do not understand that this newsgroup is not a
forum to talk about what you like or not about other people. This is the
only topic of such a staggering amount of your posts that I doubt that
you can even think in other terms than your feelings for people.
| (2) There was another case more recently where somebody said something you
| did not like and then you started attacking him immediately [...]
This is an _example_? Can you _be_ more vague? You do not even want to
do the legwork of finding the goddamn articles that are your examples!
Could you _try_ to relate to the sheer exasperation that every reader of
your inane babbling must experience?
But since I remember it, let me tell you what it was: It was an example
of an _intelligent_ response to criticism considered unfair. How unusual
that is! He also took care to avoid the things he was criticized for. I
am sure you missed that. Of course, you did not understand this, and
failed to get the point completely. How amazing that you do not even
grasp this.
| Finally (now an attack follows) [...]
What the hell is the _point_ with your annoying behavior?
| I tried to analyze the way you are and myself: [...]
It is because you are a dog who needs a master who can tug your leash.
The despicability of your servility is only matched by a behavior that
only invites harsh responses.
| I think: as well as I can.
No, you do not. It would be a tragedy of biblical proportions of what
you do is the best you can do. A human being cannot actually _be_ so
retarded and still find his way to Lisp. That means there was once a
glimmer of something that caused your miserably underutilized brain to
work long enough to find Lisp. That kind of random spark betrays a
potential that you have chosen not to realize at all. Idiot savants
aside, really unintelligent people simply do not display the amount of
sustained concentration necessary for them to discover something as out
of the way and complex to learn (for them) as Lisp. So you _must_ be
playing the despicable, annoying moron. Quit playing, and THINK!
Tim Wilson
On 20 Dec 2001, Dorai Sitaram wrote:
> Anyhow, people who learn Scheme may voluntarily, with
> their new-found grasp of things, move on to Common Lisp
> -- and love it "oh so much" that they stay with it --,
> as many have attested here. _They_ switch. As
> this is in addition to people who learn Common Lisp
> from the get-go, it looks like it's a nett gain for
> Common Lisp. Why complain? The bride is too
> beautiful?
This is why I am currently looking at CL. I began with Scheme around
February and learned more than is probably healthy about the R5RS
standard. Before learning Scheme I did know what Lisp was generally
about. I did not know about CL, though. The impression I received, that
Scheme is a Lisp, plays a _large_ part in me being here (comp.lang.lisp)
and discovering CL. The reason I began with Scheme was because I had the
impression that it was a good _Lisp_ language to learn (there are quite
many Scheme advocates around who tout Scheme as a Lisp). I was already
set to learn Lisp, but deciding _which_ Lisp was the harder part. Before
finding Scheme, I had found a number of Lisp-related documents via Google
and Yahoo, but for every how-to or tutorial found it seemed a new Lisp
dialect was presented. Needless to say, I never really took up learning a
Lisp-like language until persuaded by a Scheme advocate.
On a side note, I am starting to see the many differences between Scheme
and CL, but I'm still not seeing how Scheme differs enough to warrant it
not being part of the "Lisp family" (the general feeling I get from CL
people on Scheme). It looks to me as if neither Common Lisp or Scheme is
very close to (or equally seperate from?) the original LISP language.
-Tim
Erik Naggum
| Anyhow, people who learn Scheme may voluntarily, with their new-found
| grasp of things, move on to Common Lisp -- and love it "oh so much" that
| they stay with it --, as many have attested here. _They_ switch. As
| this is in addition to people who learn Common Lisp from the get-go, it
| looks like it's a nett gain for Common Lisp. Why complain? The bride is
| too beautiful?
This is nothing but a good reason to tell those who want to learn Scheme
to study Common Lisp first so they do not waste the time on Scheme, and
for Common Lisp people to know enough Scheme to help the wayward.
But why do Scheme freaks argue so strongly against Common Lisp so often?
Is it because nobody in their right mind switches from CL to Scheme, so
CL poses a veritable threat to Scheme?
Siegfried Gonzi
> You are taking me aback. I do not see such a big difference and this
> probably indicates that I still think in C. And switching your way of
> thinking is very diffcult (especially in my age). But then: There are a some
> eexcellent books on teaching using Scheme (SICP, Concret Abstraction, etc.)
> but there is *none* on teaching using CL.
This is a little bit an over-exaggeration. By inccident our university-library
has got a book called "Lisp, 3rd Edition" (P. Winston and B. Horn). It covers
Common Lisp with interesting examples. There are many more other Common Lisp
books out there.
Take a little bit time and use your search-engine in order to search code
(statistics, linear algebra,...) for Common Lisp; and after that, search for
Scheme code (you will not find any). I think this says much and leads to the
next discussion:
> There is a third, personal point: As I am not an expert I must trust
> somebody. I know that you are an expert but then Mr. Abelson and the others
> who say they are using Lisp are experts too. Do you think that their claim
> of using Lisp is not justified?
Have you ever seen a road car which becomes advertised as: "It is excellent for
trainig and learning". The problem with Scheme is not that they claim it as a
tool for learning new concepts the problem is the imagination that Scheme is
Lisp and that in turn Common Lisp *must be a learning tool only*.
This is stupid and stupid and stupid. Common Lisp suffers the same as C++
suffers due to C, because most believe when they know C they know C++ too.
S. Gonzi
Janos Blazi
> The despicability of your servility is only matched by a behavior that
> only invites harsh responses.
What you are mistaking for servility is objectivity: Actually I am a very
balanced person and I pay reference where reference is due. And I try to see
you objectively as well. I appreciate Dr Naggum who is a fine CS expert and
I laugh about and at the same time feel sorry for Mr Naggum who has lost
control after drinking some strange potion.
Your devoted friend, J.
Dorai Sitaram
> This is nothing but a good reason to tell those who want to learn Scheme
True. People whose final goal is CL can obviously
shorten their learning process considerably by learning
CL from the get-go. But every language seems to have
immigrants. I really don't know what measures CL could
take to make sure its adherents are mostly
natural-born. Some measures must already be in place,
such as ALU, Common Lisp books, pointers to edifying
Common Lisp code. Maybe these just need beefing
up.
Practical people are very interested in CL. It is an
industrial-strength language with a promise of wealth
creation. The CL community could reduce the immigrant
fraction in their numbers by having mechanisms to rope
in these people at their first s-expressive stirrings,
instead having them wander around having their non-CL
adventures. I don't know what such mechanisms could
be. Hopefully wider publicizing of _Successful
Lisp_, Paul Graham's already famous books, and
user-friendly impls like Bruno Haible's CLISP would
help.
Failing such mechanisms, one might as well accept these
immigrants as bonus additions. Getting them on the
first round would have been ideal, but at least
you got them on the second round.
> But why do Scheme freaks argue so strongly against Common Lisp so often?
> Is it because nobody in their right mind switches from CL to Scheme, so
> CL poses a veritable threat to Scheme?
As I am personally unaware of these arguments, I can't
comment on it and so will defer to the others. My
anecdotal experience all points to Scheme users being
either silent or celebrating Common Lisp's successes as
a feather in the cap of all Lisps. Of course, there's
some enlightened self-interest involved, because it
reflects some of the limelight of Common Lisp on their
own Lisp. If it weren't for the fact that I have
access to comp.lang.lisp, I wouldn't have suspected
that there could be a canny political aspect behind at
least some of this positive celebration of CL
from the Scheme side! There is no other effective
response to the "Begone, poor relative!" type of
reproof from the Common Lisp side of the fence.
I understand that CL apologists consider it important
to counter this kind of positive coopting. Again, I am
unsure how people could go about it, and indeed,
whether they are not better off just doing routine
things, like say the Linux people have been doing for
the most part, instead of succumbing to the siren call
of the language-is-a-political-party meme so
effectively and persuasively propagated by big names
like Kent Pitman. Another big-time Lisper, Guy Steele,
once started a textbook with the short claim, "Common
Lisp has succeeded." That book, despite claims that
it is outdated, is still the most popular CL
textbook today. Perhaps the CL of today can be as
self-confident and secure in its own undeniable
strength, and not give in to identity panic against a
rather small language like Scheme. I am not saying the
latter is happening yet, but it needn't even be a
hypothesis. "Common Lisp has succeeded."
--d
Erik Naggum
| What you are mistaking for servility is objectivity
Nope.
| Actually I am a very balanced person and I pay reference where reference
| is due.
I am so sure you are the best judge of that.
| And I try to see you objectively as well. I appreciate Dr Naggum who is
| a fine CS expert and I laugh about and at the same time feel sorry for
| Mr Naggum who has lost control after drinking some strange potion.
This is not "objectivity" in any known human language on planet earth.
Please get abducted again and consult their intergalactic dictionary
before you return. Better yet, do not return, teach them Scheme so they
never get around to implement a sufficiently "pure" invation strategy.
cbbr...@acm.org
> * "Janos Blazi" <jbl...@hotmail.com>
> | And I try to see you objectively as well. I appreciate Dr Naggum who is
> | a fine CS expert and I laugh about and at the same time feel sorry for
> | Mr Naggum who has lost control after drinking some strange potion.
> This is not "objectivity" in any known human language on planet
> earth. Please get abducted again and consult their intergalactic
> dictionary before you return. Better yet, do not return, teach them
> Scheme so they never get around to implement a sufficiently "pure"
> invation strategy.
Come on, guys.
Just go back to the joke: "I'm not sure if it's a _bug_ that Scheme
has no #Erik, or whether it's a _feature_."
Laugh once, because it _is_ funny. It's worth a chuckle. Perhaps not
a full-scale belly-laugh of total hilarity, but at least the chuckle
of wondering what the original writer intended.
And _move on_...
--
(reverse (concatenate 'string "ac.ocitapmys@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/wp.html
Rules of the Evil Overlord #210. "All guest-quarters will be bugged
and monitored so that I can keep track of what the visitors I have for
some reason allowed to roam about my fortress are actually plotting."
<http://www.eviloverlord.com/>
Janos Blazi
Anyway Erik: Fröhliche Weihnachten!
J.B. (immediately before getting abducted)
Kaz Kylheku
>> It is because you are a dog who needs a master who can tug your leash.
>> The despicability of your servility is only matched by a behavior that
>> only invites harsh responses.
>
>What you are mistaking for servility is objectivity: Actually I am a very
>balanced person and I pay reference where reference is due. And I try to see
ITYM ``deference'', no? ;)
Kaz Kylheku
>
>Anyway Erik: Fröhliche Weihnachten!
My best guess there would be ``Gledelig Jul''.
Anyway Janos: Kellemes Karacsonyi unnepeket, right? :)
Kenny Tilton
I was thinking maybe "reverence"?
:)
kenny
Kurt B. Kaiser
> On a side note, I am starting to see the many differences between Scheme
> and CL, but I'm still not seeing how Scheme differs enough to warrant it
> not being part of the "Lisp family" (the general feeling I get from CL
> people on Scheme). It looks to me as if neither Common Lisp or Scheme is
> very close to (or equally seperate from?) the original LISP language.
Of course Scheme is a Lisp! It was an attempt, among other things, to push
back towards the roots of Lisp. There are many in c.l.l who don't feel that it
is a suitable language for production, because it doesn't have a standard
library and the language itself is too poverty-stricken to be useful. This
judgement may be justified, but could be fixed (in principle :) by implementing
a standard library. Scheme is, IMHO, a very clean language and easy to
read. That contributes to ease of maintenance.
Another complaint I've heard here about Scheme is that the use of call/cc can
lead to unmaintainable code, but the same applies to macros in either language.
On the other hand, for the uninitiated, CL is pretty baroque and consequently
professional code can be harder to read than Scheme due to the additional
syntax and functionality. The complexity of the standard cannot easily be
reduced at this point, so professionals must make an effort to keep their code
readable.
There must be many thousands of students being exposed to Lisp via Scheme each
year, and this number is increasing. Part of that tradition is to understand
Scheme well enough to do a (simple) implementation. This _has_ to be be a win
for the Lisp community, because it promotes a Lispy way of thinking about CS.
Then when those kids gain the confidence to do something big, CL is waiting!
Enough of the internecine warfare! Just tell them, "OK, people, now you're
ready to come over to the big time, welcome!"
And I suspect that neither CL nor Scheme is the 'final' Lispy language.
Seasons Greetings, KBK
Erik Naggum
| Come on, guys.
Why do you think it was ignored at first? Jokes are never harmless,
however, and if someone wants to make them harmful, they will succeed.
I have not seen you respond well to "jokes" about yourself, yet.
Erik Naggum
| Of course Scheme is a Lisp!
Of course Scheme is not a Lisp!
| Scheme is, IMHO, a very clean language and easy to read. That
| contributes to ease of maintenance.
Of course you are a Scheme fan. Who could have _guessed_?
| On the other hand, for the uninitiated, CL is pretty baroque [...]
Of course you are a Common Lisp non-fan. Who could have _guessed_?
| There must be many thousands of students being exposed to Lisp via Scheme
| each year, and this number is increasing.
They are not exposed to Lisp when they are exposed to Scheme.
| Part of that tradition is to understand Scheme well enough to do a
| (simple) implementation.
This is one of the reasons that Schame is such a sucky language. Real
languages are so hard to implement that it makes sense to have someone
_competent_ do that job for you. You know, that division of labor thing
that economists tend to think is so useful for advanced societies. And
what do people implement? An interpreter that relies on the underlying
compiler or interpreter, right? How _useful_ is that? If they spend a
lot of time writing a _simple_ compiler and support libraries, etc, with
a lot of stuff you simply cannot do in Scheme itself, they will discover
how to bootstrap a system using another system. How _useful_ is that?
_Why_ does the world need more Scheme implementations than programmers?
| This _has_ to be be a win for the Lisp community, because it promotes a
| Lispy way of thinking about CS.
No, what it tells people is that the most important feature of "Lisp" is
that professors get to annoy students with a stupid exercise to implement
the language in itself. Scheme is a stupid, stupid thing to teach people
who want to _program_. It is even more harmful to teach people who want
to do research. It is yet more harmful to teach people who do not want
to write programs for the rest of their lives.
| Then when those kids gain the confidence to do something big, CL is
| waiting!
This is just plain wrong. Is MIT Scheme implemented in Common Lisp? Why not?
Scheme is a way of thinking that differs from every other language on the
planet, _including_ Common Lisp, which in important ways is a mainstream
language with non-mainstream operator names.
| Enough of the internecine warfare!
Go back to your Scheme cave and the warfare will at least quiet down.
| Just tell them, "OK, people, now you're ready to come over to the big
| time, welcome!"
This sillitude betrays a misunderstanding of the fundamental differences
between Scheme and Common Lisp, which only Scheme freaks suffer from.
Common Lisp people understand that Scheme is very different, since you
can write Scheme in Common Lisp but not vice versa. I have seen _so_
much Scheme in Common Lisp from people who have been brainwashed in
Scheme that it is in fact _the_ strongest reason for me to want Scheme to
go to hell. _Unteaching_ Scheme victims takes longer than teaching a
person who has never seen any Lisp at all to become a good Common Lisp
programmer.
There is an old joke about which platform Oracle ran best on (35 mm slide
projector), but I think it might need to be revised:
Q: Which platform is best for running Scheme?
A: A blackboard.
As long as Scheme is marketed as a Lisp, it must be fought by every other
Lisp. Scheme may be closer to the "roots of Lisp", but if you want to
write your project reports in the language of Beowulf, or Shakespeare,
expect to be unemployed. Scheme is one of the strongest reasons people
who have a fraction of a degree in computer science loathe Lisp and hate
parentheses. For _real_ programmers who want to use large languages so
their code can be small instead of re-implementing small languages and
their own large libraries, Scheme is a silly toy, and it taints the whole
Lisp family with its silliness.
_Maybe_ if Scheme was taught differently and would be so kind as to avoid
communicating bad things about the entire Lisp family, it would not be so
bad. I am currently reading Structure and Interpretation of Classical
Mechanics, and it is a _tremendous_ book -- it makes me want to return to
calculus and analysis with Tom Apostol and Richad Courant and write a
calculus book with Common Lisp and a graphics library to do 3D plots.
But, again, Scheme is used to teach. This time, however, Scheme is used
productively to teach mechanics, not mastubatorily to reimplement Scheme.
Janos Blazi
VOWWW! CL users seem to be familiar with everything!
J.B.