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 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.ada Subject: Re: How to get Ada to ?cross the chasm?? Date: Sun, 29 Apr 2018 09:54:08 -0700 Organization: A noiseless patient Spider Message-ID: <87vacanebz.fsf@nightsong.com> References: <1c73f159-eae4-4ae7-a348-03964b007197@googlegroups.com> <87k1su7nag.fsf@nightsong.com> <87po2la2qt.fsf@nightsong.com> <87in8buttb.fsf@jacob-sparre.dk> <87wowqpowu.fsf@nightsong.com> <87efiyuh10.fsf@jacob-sparre.dk> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="2973c66b8467d5e5c38d149f2cdfa94b"; logging-data="27162"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18w+aEHs9zY7KcZPAPt69it" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) Cancel-Lock: sha1:lhhkIv/p9fE91xupQLblx+JnrjU= sha1:9Z3fVKauxJ9pbKTad6GzYIjVoTA= Xref: reader02.eternal-september.org comp.lang.ada:51801 Date: 2018-04-29T09:54:08-07:00 List-Id: Jacob Sparre Andersen 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.