Subject: Re: pitman laid off by harlequin
From: Erik Naggum <erik@naggum.no>
Date: 1998/11/09
Newsgroups: comp.lang.lisp
Message-ID: <3119624997720381@naggum.no>
* Barry Margolin <barmar@bbnplanet.com>
| And because it would be a mass market book, the hardcopy would be less
| expensive than the ANSI document (I'm not sure what ANSI's price is, but
| I expect it's more than twice what CLtL3 would cost).
FWIW, ANSI X3.226-1994 ships for USD 350.
amazon.com still ships CLTL2 for USD 50.
| It doesn't seem like it would take too much work to turn CLtL2 into
| CLtL3. I don't think the language changed by more than about 5% after
| CLtL2 was written. I don't have a printed copy of the standard, and when
| I want something I can page through easily to find an answer I generally
| use CLtL2, and it's rare that I get information that's contradicted by
| the standard.
uhm, this relates to what we were discussing recently. sometimes, the
differences are so subtle that you would miss them if you even _expect_
similarities. expect differences, and be happy about any similarities
you discover after you have compared them, not looking for them.
it may seem like I'm trying to split hairs, but I have been working with
standards and other specifications for more than a decade, and I also get
commissioned to write specifications -- my observation over these years
is that some people start to rely on what they observe to "work" in some
implementation or another, not through study, but rather through sloppy
acquisition of habit, and then get very upset when some unspecified or
undefined or implementation-defined behavior changes from implementation
to implementation, as it has every right and opportunity to do, and they
feel free to go ahead and _assume_ all kinds of things based on what they
only _think_ works, causing no end of frustrations even when upgrading
the same system and something undocumented was changed. stuff like that
is tremendously difficult to fix once it has slipped below consciousness.
e.g., the infamous Y2K problem is often merely a lack of adherence to
simple specifications. like, back in 1990, I took great pains to specify
that the Oslo Stock Exchange Trade Information Protocol's date format had
a window of 100 years that would be updated with a few months of notice,
like all other changes to it. the window initially covered 1950 through
2049, to be moved in the year 2000 to cover 1960 through 2069, and so
forth. only three of the implementers managed to read the specification
and observe the point that 00 through 49 were 2000 through 2049, and that
the application layer was specifically instructed to use 4-digit years
because the protocol used two-digit years for legacy reasons. too many
people had just assumed that two-digit years meant 20th century to deal
with dates in the year 2000 as early as 1997, so to make it less likely
that the same jerks would implement the next protocol with equal disdain
for specifications, the next revision used explicit four-digit years.
the cost of this change were acceptable. the cost of moving the sliding
window already specified were unacceptably high, even though it would be
less than 5% of the costs of dealing with the Y2K fever. go figure.
#:Erik
--
The Microsoft Dating Program -- where do you want to crash tonight?