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

["Dan'l Miller" <optikos@verizon.net>]

On Monday, April 16, 2018 at 12:36:03 AM UTC-5, Paul Rubin wrote:
> "Dan'l Miller" writes:
> > How will Ada use one base of programmers/software-engineers as a basis
> > to move onto convincing another group of programmers/software-
> > engineers of Ada's advantages?  Or is the purpose of Ada to preach to
> > its current choir without trying to fill the pews with new
> > parishioners?
> 
> I'd like to know why Rust was invented: there was obviously a need for a
> safer alternative to C++, but was Ada the answer that everyone simply
> overlooked?

I keep seeing hints in the Rust community that they are aware of the existence of Ada but have never written a program in Ada because of perceived insurmountable time-expenditure/odds/learning-curve.

https://www.reddit.com/r/rust/comments/2og8xf/why_rust_started_rather_than_ada

https://www.reddit.com/r/rust/comments/48vh1m/rust_vs_ada

https://lwn.net/Articles/547614

http://lambda-the-ultimate.org/node/5277

to pick a few.

> I think answering your question would require an informed and critical
> comparison between Rust and Ada.

I haven't yet found •that• blow-by-blow-narrated feature-comparison between Rust and Ada.  But regarding “need for a non-garbage-collected big-systems language even exists any more” as you stated below, this book at the URL below is by far the most scathing critique of C++2011 and C++2014 (and by inference C++2017).  [C++11, C++14, and C++17 are effectively a trilogy that effectively drastically overhauls C++ to be a rather different language than C++1998 and its bug-fix C++2003.]  So Rust is one vector of momentum for big-systems languages, going in roughly the same direction as Ada:  safety and de-emphasis of write-once just-barely-working C-language source code.  But the resurgence of popularity of C++ is apparently occurring due to (or in spite of?) an avalanche of new very finicky language features that are easy to utilize incorrectly.

http://shop.oreilly.com/product/0636920033707.do

Scott Meyers _Effective C++_ series books from the 1990s had an over-arching message effectively of:  ‘just stay away from these troubled topics in C++ and you'll be just fine.’  But this new book in the series has a drastically different feel and message.  It is written in the same self-help book style as his 1990s books at the level of the surface text, but the subtext for the clever reader with deep-insight reading comprehension is effectively a subversive harsh critique of modern C++.  Out of the 42 gotchas that Meyers explores in breadth & depth, there are numerous places where Meyers incredulously gasps* how surprising a new feature of C++ is or behaves.  (And I am using ‘surprise’ there as a pejorative, as in violations of the Principle of Least Surprise.)

* Even though the book is ink-on-paper, the reader can quite clearly hear the author's open-mouth drop-jawed gasps in the implied subtext that the author plasters over with the self-help surface-text.

The reason that I bring this up is:  there is a sector of the programming/engineering society who thinks that a big-systems language not only needs the 42 language features at the heart of Meyers most-recent book in his _Effective C++_ series, but—more troubling—these 42 language features need to be messy affairs that need a 300-page book to untangle various knots.  Many of these 42 language features in isolation seem to be very much needed to bring C++'s vision into fruition (fixing various gaps, goofs & gaffs in C++2003), but the reader of _Effective Modern C++_ is easily left with the feeling of:  “oh really?!, certainly some other programming language could tame the beast of these features quite differently and still accomplish all the same goals to the same degree of efficiency (and vastly better correctness and vastly less chance of taking a misstep off the narrow path through a field of hellfires and landmines).”

>  Something with real depth rather than
> "verbose vs curly braces".  I do know Rust has formal-methods work going
> on.

Coq-esque and Zed-notation-esque systems of logic need to be the future of Ada.

> I'm not convinced that a need for a non-garbage-collected big-systems
> language even exists any more.  Obviously low-level, high reliability
> realtime programming is important, but they tend to run on small
> systems, or else they can be in fairly small subsystems of a bigger
> system.

Conversely, these aren't small systems in the Commodore-64 sense.  These embedded systems and tablet computers are 1 or 2 or 3 decimal orders of magnitude bigger (e.g., DRAM; MIPS; FLOPS in GPUs/physics-processors) than minicomputers prior to 1990.  Low power utilization and augmented-reality commonplace in consumer devices begets a prohibition on luxurious interpreted-language and automatic-garbage-collection techniques.  Even IoT devices are having processors and operating systems and amounts of DRAM that would put some minicomputers of that era to shame; those are the same minicomputers that were large systems during the era in which Ada1983 was designed.

The vast majority of the new language features in C++{2011, 2014, 2017} fall into the category of:  the programmer helps the compiler out by declaring finer-points of programmer-intent so as to evoke various optimizations & efficiencies by the compiler.  Okay, there is that on one hand.  Then on the other hand, the {OCaml, Swift, Rust, Dart} & even interpreted/JIT-compiled {Python, Java, Ruby, Perl6} and, yes, even Ada approach is that the compiler/language-translator can cleverly deduce highly-efficient implementations without C++{2011, 2014, 2017}'s fine-grained syntactic & semantic constructs.  It seems the only way for this to be true for Ada is for Ada202X to have a CoQ-esque or Zed-notation-esque logic-deducing theorem prover in it.  (Indeed, the provably-correct tasking of Ada2020 might need it as well.)

It appears that the future is
1) C++{2011, 2014, 2017}'s need for Scott Meyer's _Effective Modern C++_ untangling of knots, where the compiler is a happy intelligent dog of sorts who looks to its master to teach the dog new tricks (and to not be malicious)
versus
2) CoQ-esque or Zed-notation-esque logic-deducing theorem provers grinding on the source code to effectively have a rigorous argument with the compiler-theorem-prover about the correctness of the source code as mathematical proof, where the compiler-theorem-prover is effectively an automated peer-review mechanism of sorts.
versus
3) glorified PHP where the language-translator just doesn't care that all that much about strict-enforcement principles & correctness on one hand or squeezing out efficiency on the other hand, but rather these languages focus on the programmer adoringly loving to typewrite their source code on a keyboard, right down in new editions of the language to even debating which identifier names in the standard libraries/frameworks are the very most beautiful that programmers would enjoy typewriting. (C#, Java, and Swift seem to fall into this category.)
versus
4) classic cars of yesteryear that don't try to compete with modern cars, but rather just stay refurbished enough to keep running.

I am hoping that #4 is not the model for Ada:  “Hey, look kids, there goes a Model Ada down the road.  I haven't seen one of those antiques since I was your age.  Wow, we used to think that that Model Ada was what the future would be like; boy, were we wrong.”  I am very much hoping that Ada sees #2 above as its emerging mission to extrapolate its current foundation of strengths.

(I am really really hoping that the Ada1995 era of mimicking C/C++ feature-set has reached its natural conclusion, so that #1 above is precluded for Ada.  In #3 above, I am pretty sure that Swift on iOS/MacOS, C# on Windows, Java on Android, and Dart on Fuchsia all have the programmers-love-to-typewrite-me marketspace all locked up on their respective walled gardens; the only question is whether one of them will emerge as cross-platform to the other 3 to then compete in the portability domain with the historically portability-minded languages:  C, C++, and Ada.)