daveb@geac.UUCP (Brown) (08/31/87)
In article <9042@brl-adm.ARPA> dsill@NSWC-OAS.arpa (Dave Sill) writes: >Maybe if software had a mechanism for dying when it was past its prime >we wouldn't have this problem. Unfortunately, though, most people are >too short sighted to see the benefits of periodic regeneration and try >to maintain their software long after it should have been retired. I would suggest that the mechanism for *living* is little-known, rather than the mechanism for dying. My experience is that old programs (ie, ones which depend on peculiar patterns of punches in their control cards) are being hidden under forms interfaces and then disappearing from production as they are rewritten in 4GLs. In effect, they don't evolve, they're *reborn*. Now, if the ARPAnet/Multics mechanisms for evolution had been invented "here" (where here::= everywhere), we might well see programs evolving in at least limited ways... --dave -- David Collier-Brown. {mnetor|yetti|utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
schung@cory.Berkeley.EDU (Stephen the Greatest) (09/03/87)
In article <9042@brl-adm.ARPA> dsill@NSWC-OAS.arpa (Dave Sill) writes: >Maybe if software had a mechanism for dying when it was past its prime >we wouldn't have this problem. [...] Yeah. It always appears to me what a *GREAT* idea it will be for files to automatically committ suicide when their uses are gone. We will then never run into storage problems. - Stephen
dsill@NSWC-OAS.arpa (Dave Sill) (09/03/87)
>In article <9042@brl-adm.ARPA> dsill@NSWC-OAS.arpa (Dave Sill) writes: >>Maybe if software had a mechanism for dying when it was past its prime >>we wouldn't have this problem. [...] > >Yeah. It always appears to me what a *GREAT* idea it will be for files >to automatically commit suicide when their uses are gone. We will then >never run into storage problems. Okay, I can see this requires explanation. I know this is a little off the beaten path for this list, but since the above was posted here I feel I should be allowed a rebuttal. What I envision when I think about a such a mechanism is a little more subtle than "suicide". The scenario is like this: When a language's standard is released, it specifies a date after which source code in that generation of the language would no longer be compilable(*). The standard also specifies that prior to that date, a new standard will be in place for the next generation of the language and will have been available long enough to ensure the availability of new compilers in time to upgrade the old source code. For example, lets say ANSI subcommittee z4x87j42 produces a standard for the S language in 1990. This is the first ANSI standard for S, so it is referred to as Generation 1. The standard specifies that a standard for S language Generation 2 will be available by 2000, and that after 2005, Generation 1 code will become invalid. Programs developed under Gen 1 would still be runnable after 2005, but the source code would not be compilable. Developers would have plenty of time to rewrite their code as Gen 2. No doubt, they would take advantage of the forced rewrite and incorporate any major changes at that time. Of course, there would be no problems with backward compatibility... ... meanwhile, back in the *real* world ... Of course it would take a tremendous amount of self control on the part of the software industry to adhere to such a policy, even if it would be for the greater good. Maybe there would have to be laws prohibiting the compilation of outdated sources... Radical... -Dave (*) While checking the spelling of compilable, which wasn't in my dictionary, I noticed the origin of the word "compile": it comes from the Latin word "compilare" which means "to plunder". The opinions expressed above are those of the author and do not necessarily reflect those of the Department of Defense or the U.S. Navy.