Re: How to get Ada to ?cross the chasm??

[Paul Rubin <no.email@nospam.invalid>]

Jacob Sparre Andersen <jacob@jacob-sparre.dk> writes:
> Because you then would have to maintain that HLL in a backward
> compatible form for 30+ years.

Do you expect people will be using that code in 30 years?  I think as
code has gotten easier to develop (because of HLLs), its lifetime has
gotten shorter rather than longer.  It's just like anything else.  When
clothing was made by labor-intensive manual processes, it was normal to
keep maintaining it.  So if you found a hole in one of your socks, you'd
patch the sock instead of replacing it.  Do you still do that?  I don't.

>> Why worry about potential integer overflow
> Better worry about it, than getting incorrect results.

Why not use arbitrary precision integers and get correct results without
worrying?

> Long-term survivability and maintainability.  Can you point me to any
> application written in a HLL, which is still maintainable 30 years after
> its first deployment, and after two changes in compiler/run-time
> providers?

I think systems weren't written in HLL's as much 30 years ago (1988!) as
today, and HLL's (unlike C) don't frequently have multiple
implementations (similar to Ada 2012 today).  HLL's themselves weren't
as popular or accessible then easier.  Languages themselves have
advanced a huge amount since that era, which was not much past halfway
between us and the dawn of computers.  Even Java wasn't invented til the
1990s, and Perl was from 1987.  People back then wrote stuff in C that
they'd undoubtedly use a HLL for today.  C hasn't gotten harder, but
HLL's are so much easier that using C would be silly.

But let's see, Macsyma (written in Lisp) started in 1968, is still
maintained and sold, and has run in many Lisp environments.  There's
other old Lisp code running too.  That's probably also lots of SQL code
from the 1970s and 1980s that's been migrated across multiple databases
and still maintained.  It wouldn't surprise me if some APL financial
programs from back then aren't also still being used.

Erlang was written 32 years ago and has been reimplemented once or twice
since then, though within the same company.  I don't know if very early
Erlang programs are still being used though.  It's absolutely the case
that Erlang programs are written to be maintained for 30 years.  In fact
they're supposed to run nonstop in phone switches for that long: you can
maintain an Erlang program and update its code without stopping it.  I
don't know if that's ever done with Ada.

> The Ada part is there to ensure separation, and to check that the
> results from the R and Python calculations make sense

Sure, that's fine, but it sounds like a fairly thin wrapper.