From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a05:6214:601:: with SMTP id z1mr13854160qvw.197.1565025360114; Mon, 05 Aug 2019 10:16:00 -0700 (PDT) X-Received: by 2002:a9d:6c13:: with SMTP id f19mr74310890otq.76.1565025359859; Mon, 05 Aug 2019 10:15:59 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!b26no3957477qtq.0!news-out.google.com!a5ni1267qtd.0!nntp.google.com!b26no3957470qtq.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 5 Aug 2019 10:15:59 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.223.245; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.223.245 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <3862f4a3-d3b2-4959-b6f4-08086738df2c@googlegroups.com> Subject: Re: The answer to "Can Ada replace FORTRAN for numerical computation? From: Optikos Injection-Date: Mon, 05 Aug 2019 17:16:00 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:56996 Date: 2019-08-05T10:15:59-07:00 List-Id: 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. >=20 > 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 la= tter would obliviate the > aforementioned properties of finding conceptual errors. But there are 2 usages of considering something an integer for the moment i= n 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 f= loating-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 s= uperset of any numeric-analysis semantics or system-programming semantics t= hat IEEE or NIST or NSF or the supercomputing community could dream up=E2= =80=94and then put it into practice with relatively minimal number of years= of delay from that advance emerging from IEEE or NIST or the supercomputin= g community. In that implicit bite-off-more-than-Ada-could-chew implied re= sponsibility 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 array= s needing definite bounds in > certain cases -- the ability to return properly-sized arrays from a funct= ion *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 alloca= tion 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-program= ming duty. Once that perception concrete cured into being rock-solid again= st Ada83, post-1995 Ada was never able to convince people whose mind was al= ready made up to reconsider their now-misperception that such use-cases cou= ld now be supported. And even post-1995 never fully embraced this idea of = Ada being the =C3=BCber-Alles one-language-to-call-them-all lingua-franca e= ye-of-Sauron agenda that it could have (and to accomplish HOLWG's mission f= or Green) taken on. The closest that any language has come to accomplishin= g this mission is Oxygene in the inter-language Elements Compiler from RemO= bjects Software LLC, which can be such an =C3=BCber-Alles one-language-to-= call-them-all lingua-franca eye-of-Sauron among Pascal, Java, C#, Swift, an= y JVM language (e.g., Kotlin), any .NET language (e.g., F#), and any WebAss= embly language. Microsoft's Xlang could (if every potential doesn't end in= a dead end or failure) be a 2nd approximation of this =C3=BCber-Alles one-= language-to-call-them-all lingua-franca eye-of-Sauron vision. Had Jean Ich= biah or HOLWG specified late-1970s Steelman (or would ti have been a succes= sor: StainlessSteelMan*?) requirements for such an Elements Compiler or su= ch an Xlang, Ada would have achieved all its goals of being the replacement= of most other programming languages and most other programming languages w= ould 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-a= ll replacement for all purposes, Ada failed to have an ABI-based ecumenism = to be the lingua franca between disparate languages during the interim deca= des 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-bas= ed ecumenism for Green/Ada to achieve its lofty goals of replacing all othe= r programming languages in use at DoD & NATO (and by extension: in use eve= rywhere, such as including NIST, NSF, and the supercomputing community that= were staunch Fortran hold-outs until Julia appeared in recent years, and n= ow 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 notice= d that Rust appears to be a mocking tongue-in-cheek ferrous reference in th= e Ironman and Steelman sets of requirements for safe computing?