Re: The answer to "Can Ada replace FORTRAN for numerical computation?

[Optikos <optikos@verizon.net>]

On Monday, August 5, 2019 at 9:35:10 AM UTC-5, Shark8 wrote:
> On Saturday, August 3, 2019 at 6:30:36 AM UTC-6, Nasser M. Abbasi wrote:
> > There are also significant limitation to Ada as a language
> > for scientific computation, in particular with regard to
> > dynamic typing and storage allocation.
> 
> I think this is referring to things like dynamically-sized arrays, rather than "X is an integer there, now it's
> a String!" when talking about dynamic-typing, as it's obvious that the latter would obliviate the
> aforementioned properties of finding conceptual errors.

But there are 2 usages of considering something an integer for the moment in a few lines of code.  One is to floor-truncate a floating- or fixed-point number to an integer; Ada supports syntax for this semantic meaning.  But another is to consider a floating-point representation as a machine-word to perform integer-based bit twiddling to conform the representation of the floating-point number to some machine requirements or machine representation that Ada's syntax and semantics lacks; pre-1995 Ada (the subject matter of the paper referenced) was abysmal at this commonplace use case in Fortran, PL/I, and C.  By pursuing the restrictions that Ada80 and Ada83 did, then Ada effectively bit off more than it could chew:  to always standardize a superset of any numeric-analysis semantics or system-programming semantics that IEEE or NIST or NSF or the supercomputing community could dream up—and then put it into practice with relatively minimal number of years of delay from that advance emerging from IEEE or NIST or the supercomputing community.  In that implicit bite-off-more-than-Ada-could-chew implied responsibility Ada failed miserably, whereas the loosey-goosey languages had no such impediment, hence Ada lost that mindshare pre-1995.  Post-1995 Ada was never able to reverse the already-cemented-in perception that such use-cases could be supported in Ada95 and later.

> As to the storage-allocation, I suspect it is also referring to Ada arrays needing definite bounds in
> certain cases -- the ability to return properly-sized arrays from a function *should* be enough to ease
> this complaint *EXCEPT*, perhaps, when dealing with Very Large Arrays.

Again, Ada has had a storage-pool wisdom at the heart of its storage allocation strategies, but pre-1995 Ada staunchly lacked PL/I's and Fortran's and C's ability to ecumenically reach out and read/write/manipulate some other language's in-memory storage format, as a I-got-you-covered system-programming duty.  Once that perception concrete cured into being rock-solid against Ada83, post-1995 Ada was never able to convince people whose mind was already made up to reconsider their now-misperception that such use-cases could now be supported.  And even post-1995 never fully embraced this idea of Ada being the über-Alles one-language-to-call-them-all lingua-franca eye-of-Sauron agenda that it could have (and to accomplish HOLWG's mission for Green) taken on.  The closest that any language has come to accomplishing this mission is Oxygene in the inter-language Elements Compiler from RemObjects Software LLC, which can be such an  über-Alles one-language-to-call-them-all lingua-franca eye-of-Sauron among Pascal, Java, C#, Swift, any JVM language (e.g., Kotlin), any .NET language (e.g., F#), and any WebAssembly language.  Microsoft's Xlang could (if every potential doesn't end in a dead end or failure) be a 2nd approximation of this über-Alles one-language-to-call-them-all lingua-franca eye-of-Sauron vision.  Had Jean Ichbiah or HOLWG specified late-1970s Steelman (or would ti have been a successor:  StainlessSteelMan*?) requirements for such an Elements Compiler or such an Xlang, Ada would have achieved all its goals of being the replacement of most other programming languages and most other programming languages would have died off by now.

Returning more narrowly to Fortan in numeric computing:
For all the advances that Ada made as being the one-language-to-rule-them-all replacement for all purposes, Ada failed to have an ABI-based ecumenism to be the lingua franca between disparate languages during the interim decades that it would take to retire all other languages' source code & usage.  Ichbiah's team (and HOLWG too) completely botched this need for an ABI-based ecumenism for Green/Ada to achieve its lofty goals of replacing all other programming languages in use at DoD & NATO (and by extension:  in use everywhere, such as including NIST, NSF, and the supercomputing community that were staunch Fortran hold-outs until Julia appeared in recent years, and now we have modern OO-Fortran and upstart Julia duking it out for which will be the dominant mainstream language in those communities henceforth).

* Btw, speaking of a metallic successor to Steelman, has anyone else noticed that Rust appears to be a mocking tongue-in-cheek ferrous reference in the Ironman and Steelman sets of requirements for safe computing?