At AT&T, the evolution from B to C was quite smooth, as was the
evolution of C itself. Most B programs were converted to "nb" (the
first C incarnation) by hacking on the character strings and putting
in some types where needed. It wasn't a big deal. So I'd be
surprised if there were substantial B programs that survived.
One lesson learned that I've never forgotten is how smooth it is to
evolve a language using the following process:
* Announce that the change is coming and explain why
* Change the compiler to accept both the old and new syntax
* Produce a simple warning message when the old syntax was used, but
make it still work
* Produce a more complicated, verbose message, but still make it work
* Produce a message that says "After date xxxx, the old stuff won't
work any more"
* On the date, change the warning to fatal, but keep recognizing the
old syntax and emit "Error: You used the old xxx, change to the new
one"
* Eventually, stop recognizing the old syntax and remove the message.
Dennis was a master at this strategy, so things like the otherwise
painful evolution of changing =+ to += went well.
Steve
----- Original Message -----
From: "Robert Swierczek" <rmswierczek(a)gmail.com>
To:"Toby Thain" <toby(a)telegraphics.com.au>
Cc:<tuhs@minnie.tuhs.org>
Sent:Fri, 7 Apr 2017 17:51:03 -0400
Subject:Re: [TUHS] Non-US Unix Activities
Yes, there's always SOME way to avoid it, but obviously
significantly more
work. Just depends what the priorities are...
Preserving fanfold
seems like
a strange priority, wouldn't it be more practical
bound book-like
anyway?
Or, similar to your suggestion, load it into a compatible printer
(so that
it can be sprocket fed), with some kind of takeup
spool, then form
feed
pages through, snapping each one between feeds.
Fully agree! If there is anything I can do to help get that online
(in whatever form) let me know.
Are there any other surviving examples of B code from that era in
this
ballpark of complexity?