The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: clemc@ccc.com (Clem Cole)
Subject: [TUHS] long lived programs (was Re: RIP John Backus
Date: Thu, 22 Mar 2018 17:35:20 -0400	[thread overview]
Message-ID: <CAC20D2NXwa3wKmwO4GkeKKWmrfBHqp11gDtx0i=kZAs_gTN6Dg@mail.gmail.com> (raw)
In-Reply-To: <D5A7C3A8-F85C-407D-9126-B34D56DE6251@bitblocks.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3399 bytes --]

On Thu, Mar 22, 2018 at 5:05 PM, Bakul Shah <bakul at bitblocks.com> wrote:

>
> 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?
>
​....​


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

​Maybe and maybe not.​ I worried about this a bit myself.  But I think the
difference I think is that while computer scientist may be using Fortran,
it is still pretty heavily used in the 'hard science' - certainly physics
and chemistry - because as was already pointed out -- it is still the best
language for doing complex mathematics.   And more over, the language (like
UNIX) has changed.  If you look at modern Fortran code, it looks more like
Algol than Fortran-IV.

Every scientific code that I know of (with the exception of SPICE), that
got recoded into C or C++ -- *has slowed down or gotten more complex.*
 And in SPICE3's case, TQ spend hours staring at Ellis code in SPICE2.  Tom
was on his own a 'bad ass' Fortran programmer, so he knew the trick Ellis
was taking.   And, like other codes I know, it took a bit before TQ got
SPICE3 in parity much less better.   In the end, what made SPICE3 replace
its older brother, was a new feature (easy addition of new transistor
models), but I think TQ would we one the first to tell you, it was very
hard to beat Ellis's FORTRAN.

The reality is Fortran is a great tool for what it is designed to do.   An
most of us on this list don't do that work, so we don't value it.   But if
you have to nasty math is partial differentials, complex numbers, etc -
Python, C, C++ are fine for very small things.   But if you have a
production code that is going to run for hours, if not days, on a
supercomputer, chances are it is Fortran.

For instance the last time I looked at WRF about a a year ago, which is the
premier weather code (and you hear about every night on the news with the
different 'models' the weatherman talk about), that is a FORTRAN-90 code.
 We were looking at the how to speed of the messaging stack under the
covers and were interested in how it stressed the networking stack.  It has
begin/end style looping, and its very modular.   The complex  and
unreadable part is MPI and the stuff to make it run in parallel.  It's not
the Fortran-ness.   I suspect anyone on this list like me, that reads C
could look at that code and understand it pretty quick.

The question (and a good one) is if you are not 'a Fortran person,' are you
going to be able to understand it well enough to not do damage to it, if
you modify it?  Which is of course the crux the question Bakul is asking.

I suspect, it is not as bad the science fiction movies profess.   Because
the codes have matured over time, which is not what happened with Y2K.
 Are their 'dusty decks' sure - but they are not quite so dusty as it might
think, and as importantly, the code we care about are and have been in
continuous use for years.  So there has been a new generation of
programmers that took of the maintenance of them.

ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180322/990a5dde/attachment-0001.html>


  reply	other threads:[~2018-03-22 21:35 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     ` [TUHS] long lived programs (was " Bakul Shah
2018-03-22 21:35       ` Clem Cole [this message]
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='CAC20D2NXwa3wKmwO4GkeKKWmrfBHqp11gDtx0i=kZAs_gTN6Dg@mail.gmail.com' \
    --to=clemc@ccc.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).