The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: bakul@bitblocks.com (Bakul Shah)
Subject: [TUHS] long lived programs (was Re:  RIP John Backus
Date: Thu, 22 Mar 2018 14:05:14 -0700	[thread overview]
Message-ID: <D5A7C3A8-F85C-407D-9126-B34D56DE6251@bitblocks.com> (raw)
In-Reply-To: <284abf07f5b9d442caf233a8017a8cebb5518bbc@webmail.yaccman.com>

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!




  reply	other threads:[~2018-03-22 21:05 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.21.1521314548.3788.tuhs@minnie.tuhs.org>
2018-03-17 20:14 ` [TUHS] " Paul McJones
2018-03-17 22:27   ` Steve Johnson
2018-03-22 21:05     ` Bakul Shah [this message]
2018-03-22 21:35       ` [TUHS] long lived programs (was " Clem Cole
2018-03-23 19:28         ` Bakul Shah
2018-03-23 19:44           ` Larry McVoy
2018-03-23 21:23           ` Clem Cole
2018-03-23 21:36             ` Warner Losh
2018-03-23 22:02               ` Steve Johnson
2018-03-26 13:43           ` Tim Bradshaw
2018-03-26 16:19             ` Paul Winalski
2018-03-26 16:41               ` Arthur Krewat
2018-03-26 19:53                 ` Larry McVoy
2018-03-27  1:08               ` Clem Cole
2018-03-26 19:04             ` Bakul Shah
2018-03-27  1:21             ` Steve Johnson
2018-03-27  1:46               ` Clem Cole
2018-03-23 10:43       ` Tim Bradshaw
     [not found]         ` <CAC20D2P1CZwaD0uJpMhWg11muDeH9rEn3X+AUjXvwMKsNjs7ng@mail.gmail.com>
2018-03-26  0:53           ` [TUHS] Fwd: " Clem Cole
2018-03-23  2:53 [TUHS] " Doug McIlroy
2018-03-23 18:27 ` Bakul Shah

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D5A7C3A8-F85C-407D-9126-B34D56DE6251@bitblocks.com \
    --to=bakul@bitblocks.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).