Subject: Re: pitman laid off by harlequin
From: Erik Naggum <>
Date: 1998/11/09
Newsgroups: comp.lang.lisp
Message-ID: <>

* Barry Margolin <>
| 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. 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.

  The Microsoft Dating Program -- where do you want to crash tonight?