From ... From: Erik Naggum Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior. Date: 2000/11/05 Message-ID: <3182427125786078@naggum.net> X-Deja-AN: 689928671 References: <3182371042747250@naggum.net> mail-copies-to: never Content-Type: text/plain; charset=us-ascii X-Complaints-To: newsmaster@eunet.no X-Trace: oslo-nntp.eunet.no 973438397 19434 195.0.192.66 (5 Nov 2000 15:33:17 GMT) Organization: Naggum Software; vox: +47 800 35477; gsm: +47 93 256 360; fax: +47 93 270 868; http://naggum.no; http://naggum.net User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 Mime-Version: 1.0 NNTP-Posting-Date: 5 Nov 2000 15:33:17 GMT Newsgroups: comp.lang.lisp * 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