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

[Tim Bradshaw]

On 23 Mar 2018, at 19:28, Bakul Shah <bakul at bitblocks.com> wrote:
> 
> By now most major systems has been computerized. Banks,
> govt, finance, communication, shipping, various industries,
> research, publishing, medicine etc. Will the critical
> systems within each area have as many resources as & when
> needed as weather forecasting system Tim is talking about?

I think that this is indeed a problem: it just isn't a problem for the kind of huge numerical simulation that gave rise to this thread.  In general programs where

- you continually are looking for more performance,
- you are continually updating what the program can do (adding better cloud models, say),

are pretty safe.  But programs which get deployed *and then just work* are liable to rot.  So, for instance, a retail bank's writes or buys a system to deal with mortgages: once this thing works then the chances are it will keep working for a very long time because the number of mortgages might double in ten years or something, but it won't go up by enormous factors and mortgages (at the retail bank end, not at the mortgage-backs end) are kind of boring.

Retail banks are risk-averse so they like to avoid the risks associated with porting the thing to new platforms.  And since there's no development most of the developers leave.

And then ten or twenty years later you have this arcane thing which no-one understands any more running on a platform which is falling off the end of support.

And if that was the only problem everything would be fine.  In fact, several times during the life of this thing, the bank wanted to offer some new kind of mortgage.  But no-one understood the existing mortgage platform any more, *so they deployed a new one alongside it*.  So in fact you have *four* of these platforms, all of them critical, and none of them understood by anyone.

To bring this back to Unix history, I think this is an example of a place where Unix has failed (or, perhaps, where people have failed to make use of it properly).  Half the reason these things are such a trouble is that they aren't written to any really portable API, so the bit that runs on Solaris isn't going to run on AIX or Linux, and it only might run on the current version of Solaris in fact.

I don't know what the solution to this problem: I think it is essentially teleological to assume that there *is* a solution.

--tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180326/989dbb4e/attachment.html>