Re: Teaching C/C++ from Ada perspective?

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

On Wednesday, July 4, 2018 at 3:13:47 PM UTC-5, Maciej Sobczak wrote:
> > > My claim that Ada and C++ compilers have the same challenges when it comes to handling the
> > > physical project structure holds.
> > 
> > Yet Ada allows having a library of packages
> 
> Yes, but that does not change anything in this regard. One reason is that AARM does not define the
> meaning of this concept. In some sense, the set of source files plays the role of a library. In other words,
> GNAT already implements the standard notion of the library in terms of source files.
> 
> You can implement the same concept in some other way, for example with the use of relational database
> as a backend, but AARM still does not define the functionality of such library or why it would be any
> better. It might as well be as dumb as a plain set of files.
> 
> And ironically, for a large-scale system, I would not trust anything else than a dumb set of files.

Your mileage might vary compared to mine, depending on how you drive.

> > Your 
> > examples are related to GNAT
> 
> Which happens to be The Ada Compiler that potential users are going to use.

Which happens to be the Ada compiler for which you have shown a rather-signficant Achilles heel.  Thank you.  We've been looking for reasons that another Ada compiler is necessary (e.g., with LLVM backend instead, and now with aggressive re-build avoidance to trounce C++ for their mutually-shared intended marketspaces:  software-in-the-very-large).

As currently licensed, GNAT cannot practically have anything isomorphic to R1000's DIANA design, because whatever the DIANA-esque persistent storage might be, Runtime Exception of GPLv3 would deem that DIANA-esque persistent storage as intermedia representation (IR).  By my prior recent analysis here on c.l.a, any persistent emission of IR from a compiler (e.g., GNAT, GCC) that is licensed via GPLv3 with Runtime Exception causes all downstream object files, library-archive files, and executable files to be forcibly licensed as GPLv3 without the Runtime Exception.  That seems to be a major Achilles heel that an Alang (in the spirit of Clang & Flang) in BSD-esque-licensed LLVM-world wouldn't have.  Thank you, Maciej, you have been most useful there.

> > C++ on its part could not have a library.
> 
> Wrong. Everything in the C++ standard is defined in terms of "as if", which means that as long as the
> required visible effects are supported, the underlying implementation can be anything.

https://en.cppreference.com/w/cpp/language/as_if
vis a vis
https://en.cppreference.com/w/cpp/language/ub

The (unacceptable) corollary to C++11's “as-if” rule as stated:
As long as any portion of a program that has even one undefined behavior, the •visible effects• can be anything (on the current target ISA, even if the undefined behavior is quite reliably deterministic & useful on the current target ISA).

This wouldn't be a problem if all C++ compilers were required by the standard to error all undefined behavior, but so many C++ programs in field deployment •dependably rely• on undefined behavior to function “correctly” on a particular target ISA—undefined behavior that the compiler tacitly approved of.

This house-of-cards Swiss cheese is why no R1000-esque development environment can ever exist for C++.  This is the root reason for why the-dumber-the-better files are purported to be adored.  This is the root reason for how any persistent storage more sophisticated than dumbest-of-dumb files can become accumulatedly corrupted.  This is why there is strong shilling against R1000 in this thread:  slight-of-hand obfuscation of this dirty laundry; look at that shiny thing over there instead of C++'s dirty laundry.

On Thursday, July 5, 2018 at 8:15:01 AM UTC-5, Maciej Sobczak wrote:
> Todays' IDEs can figure out and track individual declarations and use that information for editing aids like
> code navigation or automated refactoring. The tech is there (also for C++), but apparently there is no
> motivation to use it at the build stage. … but the fact that no compiler vendor does it today can indicate
> that it is not what people consider a problem worth solving.

Apparently, Maciej, you have never used ClearMake or Vesta, both of which have automated language-agnostic (super-dooper rich*** filesystem-based) ways of perfectly (!) discovering extremely fine-grained dependencies to accomplish aggressive build avoidance (and something even more aggressive:  wink-ins) via proofs by mathematical induction that omnisciently observe the entirety of all compilation units.  Vesta effectively died off with Alpha & Compaq, but ClearCase is still commanding many thousands of dollars per seat in the software-in-the-large companies whose reason to exist is to write millions- or tens-of-millions-of-lines source-code bases.

*** not dumber-than-dumb files

On Tuesday, July 3, 2018 at 3:54:10 PM UTC-5, Maciej Sobczak wrote:
> > > There is nothing that C++ lacks in this area when compared to Ada.
> > 
> > Oh really!  Read Lakos's book then.
> 
> I did. Thank you for recommendation.
> 
> > All 852 pages of it effectively say:
> [...]
> 
> No, they don't (and since I'm already used to your trolling style, I'm not surprised). The abstract is
> available here:
> 
> https://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633620
> 
> and relates to addressing physical challenges of large codebases.
> 
> Considering the fact that the compilation model of Ada and C++ is basically the same (some of this
> might be related to the fact that they use, well, exactly the same compiler), the challenges that are
> addressed by this book exists in both languages and, interestingly, the presented techniques (or most of
> them) are transferable.
> 
> > When a language has a problem that needs 852 pages to explain and straighten out, methinks it
> > actually might have an actual problem (or whole tangled nest of problems) in that vicinity.
> 
> Yes. Another way to look at it is this: C++ is one of the few languages that actually allowed engineers to
> implement systems in the large scale.
> 
> > By comparison, in Ada's entire history spanning 5 decades, no one needed to write an analogous
> > 852-page tome on that topic.
> 
> You have problems with fundamental logic. The fact that such a book does not exist for Ada does not
> mean that it was never needed. It only means that nobody wrote it (as another exercise in logic, try to
> explain why there are essentially no books for algorithms for Ada).

Yeah, right, absence of evidence* is not evidence of absence of such an Ada book, eh?   Perhaps that Ada tome** is just sitting there unpublished on someone's hard drive, lurking undiscovered.  Perhaps, just perhaps.  Who knows, right?  Absence of evidence isn't evidence of absence, right?

* i.e., Ada's lack of a whopping 1.3-kilogram 852-page tome revealing ad infinitum how to walk just the right narrow path to prevent C++-esque physical-design disasters

** regarding Ada's purported(-by-you) 1-to-1 & onto mapping of directly analogous problems that C++'s software-in-the-large physical design has

vis a vis:

On Thursday, July 5, 2018 at 8:15:01 AM UTC-5, Maciej Sobczak wrote:
> > I don't see how it could be accomplished in any reasonable way with 
> > header files and preprocessor.
> 
> Nobody sees how it could be accomplished in the Ada compiler, either. :-)
> 
> Maybe the whole idea is not very reasonable in the first place? I mean - maybe this is over-engineering
> that nobody actually asked for, which explains why we don't have it?
> 
> Todays' IDEs can figure out and track individual declarations and use that information for editing aids like
> code navigation or automated refactoring. The tech is there (also for C++), but apparently there is no
> motivation to use it at the build stage. R1000 might have been an interesting experiment for exploring
> the idea, but the fact that no compiler vendor does it today can indicate that it is not what people
> consider a problem worth solving.

When the •absence of evidence• is in Ada's favor (in the prior quote before “vis a vis”), then the speaker is an ignorant-of-“fundamental-logic” dolt.

When the •absence of evidence• is in C++'s favor (in this quote after “vis a vis”), then it is the paragon of universal-generalization from which vast one-size-fits-all wisdom shall be harvested & weaponized (to kill off any virtues of R1000 and to kill off teaching C++ in an Ada-esque way).