The 8008 1803

Well .... More about this later.

I think you've made a point in this post that isn't in the other discussion, and it's a good point: Knowing about the finished product doesn't necessarily tell you about the process used to produce it, including the discussions of tradeoffs, etc., and that process might be more important to preserve and pbutt on than the product. (Is that what you're saying? I'd agree, for what it's worth.)

Discussions in this newsgroup (a.f.c.) could be a way to preserve at least some knowledge of the process. (Maybe you're saying that?)

As for the earlier point (about whether what worked earlier is still any good), I may still not be understanding what you're saying.

If you're saying that just because a solution was great in 1970 doesn't mean it will be worth anything at all in 2005, agreed. (1970 is a more or less arbitrary year; replace with any previous year of your choice in the following.)

If you're saying that therefore it's not particularly useful to know about the solution that was great in 1970, I'm not convinced. (Yet?) Let me try to say why.

I agree that just because an idea was great in 1970 doesn't necessarily imply that it will be great, or even okay, in 2005.

I would claim, though, that an idea that was great in 1970 *might* still be great, or at least good, in 2005. Not necessarily, but possibly.

And even if it's not, I would argue that a knowledge of the "great in 1970" ideas broadens one's horizons in a way that should be useful in solving problems. The only counterargument I can think of is that knowing too many old solutions might inhibit one's creativity in coming up with new solutions. I guess that's possible.

Also, when I say "might still be good", maybe I should say "might be good again". A point made in Andrew Tanenbaum's "Modern Operating Systems" (widely-used textbook, which might or might not mean anything in a.f.c.) is that an idea that was great in year N can be terrible in year N+n1 and then great again in year N+n1+n2 (N, n1, and n2 all greater than zero).

One example he gives is filesystems where all the blocks for a file have to be contiguous -- originally a good (or at least reasonable) idea because simple to implement, discarded because of fairly obvious disadvantages for files on read-write disks, but a good idea again for write-once media such as CDs. (I *think* I'm paraphrasing summarizing this accurately. I'll look up a page-number reference if anyone's interested.)

I'd be interested in hearing views from the group here about whether this line of reasoning makes sense.

(And -- a couple of gold stars might be due you for tracking down this old post and replying to it with material from the more recent discussion.)

-- B. L. Mbuttingill ObDisclaimer: I don't speak for my employers; they return the favor.