[TUHS] long lived programs (was Re: RIP John Backus

Bakul Shah bakul at bitblocks.com
Fri Mar 23 07:05:14 AEST 2018


On Mar 17, 2018, at 3:27 PM, Steve Johnson <scj at yaccman.com> wrote:
> 
> Let me offer a somewhat different perspective on FORTRAN.  When an airplane is designed, the design undergoes a number of engineering tests under simulation at the design stage.  Many countries require that these simulation runs be archived for the lifetime of the airplane so that, in the event of a crash, they can be run again with the conditions experienced by the aircraft to see whether the problem was in the design.  Airplanes commonly take 10 years from first design to first shipment.  And then are sold for 10 years or so.  And the planes can fly for up to 30 years after that.   So these tests need to be written in a computer language that can be run 50 years in the future -- that is a stipulation of the archive requirement.  There really aren't any alternative languages that I'm aware of that could meet this criterion -- that's particularly true today, when there is a sea change from serial to parallel programming and it's hard to pick a winner with five decades of life ahead of it...
> 
> Does anyone have any candidates?

I was thinking about a similar issue after reading Bradshaw's
message about FORTRAN programs being critical to his country's
security. What happens in 50-100 years when such programs have
been in use for a long time but none of the original authors
may be alive? The world may have moved on to newer languages
and there may be very few people who study "ancient" computer
languages and even they won't have in-depth experience to
understand the nuances & traps of these languages well enough.
No guarantee that FORTRAN will be in much use then! Will it be
like in science fiction where ancient spaceships continue
working but no one knows what to do when they break?

Even on a much much smaller time scale I have seen million+
line code base, with original programmers long gone. Newer
programmers understand enough to add new layers of code or fix
some bugs but not enough to fix any deep problems. Such
programs are difficult to understand *today* due to their poor
structure but as they serve a useful purpose and continued to
be used.

We move archived data to newer media & may be make multiple
copies so as to be able to continue accessing them but when it
comes to "moving" critical programs to newer programming
languages, we are stuck. I think "y2k" was just a small taste
of this. We don't have enough tests to fully characterize
them, not clear specifications etc. You can reimplement a
small programs (up to 5K lines of C/C++ or so) with some
effort by analyzing their IO behavior but this gets
exponentially harder for larger programs.

The only thing I can think of is to use have programs that
translate programs in todays languages to a common but very
simple universal language for their "long term storage". May
be something like Lamport's TLA+? A very tough job.

We may be incurring a lot of "technical debt" that future
generations may have to pay!





More information about the TUHS mailing list