Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
From: Erik Naggum <erik@naggum.net>
Date: 2000/11/05
Newsgroups: comp.lang.lisp
Message-ID: <3182427125786078@naggum.net>
* Erik Naggum
| One of the first things I did in Allegro CL was (setq-default
| *print-case* :downcase), just like I had figured out how to stop
| CMUCL from shouting, simply because I think a computer that talks to
| me in upper case is very rude and smells of age like some of the
| things in my refrigerator that had to be shot before they attacked
| Xyzzy, my lovely cat, but that does not _necessarily_ mean that I
| think symbols should be in lower-cased and the reader case sensitive.
* Christopher Browne
| Where does setq-default come from? That appears to be an
| "Allegro-ism;" it's not in CMUCL or CLISP, nor is it in the
| HyperSpec.
Jesus, Christopher, of course. But what can I say to this nonsense?
You need to think carefully about the purpose of standards and
portable code so you do not fall prey to a religious belief in them.
You should also think _very_ carefully about the purpose and means
of customization of a specific environment and why some environments
and languages are designed to be customized and others are not.
To achieve uniform external behavior, it is always necessary to
write some non-portable code in different environments. It is a
_luxury_ to be able to use such portable code, it does _not_ come
for free. If you are unwilling to work to create that luxury for
yourself, you will create _varying_ external behavior, instead.
Perl succeeded in the mish-mash of Unix differences because it
assumed the burden of unifying the behavior at a very high level, in
stark contrast to the morass of #ifdefs in C and the inability to
get shell scripts to work the same across the many implementations.
Perl did not deny the differences, it did not suggest that people
stick to some standard and hope they could do everything they wanted
with it, it did not live in the world of wishful thinking and the
irrational idiocy that only portable code is good code.
Perl did some things well: It transcended implementation differences
by staring them in the eye and fighting it out, not by giving up,
whining that something isn't standard and portable, etc. It gave
the bad standards and their nonsensical implementation differences
the finger and wrote its own standard. For the kinds of tasks Perl
does well, it is downright _impressively_ portable. You need the
ever expanding Perl book, but not the tens or hundreds of shelf-feet
of manuals that you used to have to deal with. Perl has created its
own operating system interface precisely by being an incredibly ugly
implementation, and I'll give Larry Wall this, but not much else: He
did fully understand the value of uniform external behavior of a
tool and he was willing to pay the price to get it. There is no
excuse for the _language_ he created in order to do this, however.
Now, some people try to compare Perl and Common Lisp, which I think
is an incredibly tasteless insult to the work of the Common Lisp
community to create Common Lisp, because it already _did_ the same
good things that Perl did. Some people do not appreciate this and
go ballistic over the complexity of pathnames, hailing Unix as the
simple and elegant solution, but Unix is only simple, not elegant:
That's why it needed Perl. Common Lisp doesn't need _its_ Perl: It
already _is_ everything that Perl aspired to be from the beginning.
What needs to be done is to _build_ on that environment in the same
vein: Uniform external behavior. That means only one thing: Ugly,
implementation-specific code that _exports_ simplicity and elegance,
transcends the silliness of operating system vendors with only their
own concerns to consider, transcends the incompetence of the Evil
Empire, and defines a virtual operating system on top of whatever
cruft people get for free on their fine computing machines. This
requires tons of code the equivalent of dirt under fingernails.
This requires tons of work that is never seen because its main value
is to hide and gloss over. Once upon a time, the Common Lisp
community was willing to do such work. These days, most are so
spoiled with the result of that prior work they are not even willing
to use implementation-specific features to get what they _want_.
People who go off to do their own thing need both policing and good
friends. Vendors cannot normally be trusted to do the right thing
on their own unless they have wise critics and co-conspirators alike
to guide them with input from the outside world at crucial times
before releases and during development. In much smaller capacity
than I would like, I try to help Franz Inc that way, and it's much
more work than I thought it would be, but it's rewarding most of the
time. Many people here favor some free software implementations
where everybody's an insider, destroying that customer-critic-friend
trichotomy, and brushing people aside by asking them to just supply
patches, but that is not what this is all about, and write access to
the source as in many Open Sores projects doesn't even work when you
want politicing and good friends who tell you what you shouldn't do.
Sharing code builds one type of community. Sharing visions for the
uniform external behavior builds another type of community. Perl
had the latter, but is moving towards the former. Lisp sort of
began with the former and is moving towards the latter. However, if
the "vision" is "don't use implementation-specific features; don't
write non-portable code", it's an accountant's vision of the future:
That of looking backwards in the books detailing the past. We don't
need that. We need implementation-specific code where people agree
on what matters: What other programmers will need to know and do to
use it, not agreement on the code and a laissez-faire attitude to
the interface.
What does this all mean? Respect the standard absolutely, but such
respect comes from realizing that it was made by people in a process
of much disagreement and pain. Reject the standard as a limitation:
It should never have been regarded that way if it were. Reject the
standard as the final vision: It isn't that, either. Step onto it
and use it as a higher vantage point. (This works in the literal
sense with ANSI Common Lisp, too.)
And above all: Shoot the anti-visionaries. They have kept Common
Lisp back for many years by refusing to use non-standard tools,
which has only led to a dearth of solutions to interesting problems
after the standard. Now, post-partum depression sets in with the
release of standards, but even though we had a prolonged birth with
that longish freeze time and final quibbles, it shouldn't still be a
problem. Especially not with people who weren't even there when the
standard was hammered out, but who act like it's _their_ baby. For
some reason mankind shall probably never fully understand given that
we _do_ understand what they go through, many women give birth to
more than one child, so maybe some have felt that after the standard
came out it was a good time to cut the wires and make like a raven
and go "nevermore". I don't see that in the people who are most
likely to be able to pull the locomotive, then push it before they
leave it running in its own. I see that in a lot of people who look
like they are fearful of being run over by _any_ moving object by
virtue of standing completely still, themselves. It's time to get
this baby rolling again, to mix this paragraph's metaphors badly.
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush