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?