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:a24:c105:: with SMTP id e5-v6mr2849052itg.13.1530804621229; Thu, 05 Jul 2018 08:30:21 -0700 (PDT) X-Received: by 2002:aca:eb15:: with SMTP id j21-v6mr1427353oih.6.1530804620954; Thu, 05 Jul 2018 08:30:20 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!xmission!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!u78-v6no2716553itb.0!news-out.google.com!l67-v6ni2799itl.0!nntp.google.com!d7-v6no2743356itj.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 5 Jul 2018 08:30:20 -0700 (PDT) In-Reply-To: <8de6b5ba-25ab-4d46-b80c-1544f43a9b05@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.195.62; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.195.62 References: <856189aa-fa00-4960-929e-174f352310ad@googlegroups.com> <2718c8d4-5f35-4fd8-a1aa-1e60069a7a5d@googlegroups.com> <39fce60c-9f56-42fb-b679-fa08810b00ee@googlegroups.com> <3701bf07-89a5-4cb0-a704-5aebb589ca79@googlegroups.com> <2f5e4ce0-94e8-4b94-9da7-045ec90a9b22@googlegroups.com> <18554067-1382-4b43-a832-2d27aa5117d7@googlegroups.com> <8dc19505-b68a-403c-a164-f1de1864f3f1@googlegroups.com> <559657f8-bbf4-4a70-9449-f85bc98d6c6b@googlegroups.com> <590d4672-4aef-42a5-823c-57ccd291115a@googlegroups.com> <8de6b5ba-25ab-4d46-b80c-1544f43a9b05@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <235b3f29-becd-476c-9efd-3c4bf6ebfad5@googlegroups.com> Subject: Re: Teaching C/C++ from Ada perspective? From: "Dan'l Miller" Injection-Date: Thu, 05 Jul 2018 15:30:21 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:53653 Date: 2018-07-05T08:30:20-07:00 List-Id: 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. > >=20 > > Yet Ada allows having a library of packages >=20 > 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 so= urce files. >=20 > You can implement the same concept in some other way, for example with th= e use of relational database > as a backend, but AARM still does not define the functionality of such li= brary or why it would be any > better. It might as well be as dumb as a plain set of files. >=20 > 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=20 > > examples are related to GNAT >=20 > Which happens to be The Ada Compiler that potential users are going to us= e. Which happens to be the Ada compiler for which you have shown a rather-sign= ficant Achilles heel. Thank you. We've been looking for reasons that anot= her Ada compiler is necessary (e.g., with LLVM backend instead, and now wit= h aggressive re-build avoidance to trounce C++ for their mutually-shared in= tended 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 m= ight be, Runtime Exception of GPLv3 would deem that DIANA-esque persistent = storage as intermedia representation (IR). By my prior recent analysis her= e 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 ob= ject files, library-archive files, and executable files to be forcibly lice= nsed as GPLv3 without the Runtime Exception. That seems to be a major Achi= lles heel that an Alang (in the spirit of Clang & Flang) in BSD-esque-licen= sed LLVM-world wouldn't have. Thank you, Maciej, you have been most useful= there. > > C++ on its part could not have a library. >=20 > Wrong. Everything in the C++ standard is defined in terms of "as if", whi= ch 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 =E2=80=9Cas-if=E2=80=9D rule as sta= ted: As long as any portion of a program that has even one undefined behavior, t= he =E2=80=A2visible effects=E2=80=A2 can be anything (on the current target= ISA, even if the undefined behavior is quite reliably deterministic & usef= ul on the current target ISA). This wouldn't be a problem if all C++ compilers were required by the standa= rd to error all undefined behavior, but so many C++ programs in field deplo= yment =E2=80=A2dependably rely=E2=80=A2 on undefined behavior to function = =E2=80=9Ccorrectly=E2=80=9D on a particular target ISA=E2=80=94undefined be= havior that the compiler tacitly approved of. This house-of-cards Swiss cheese is why no R1000-esque development environm= ent 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 be= come accumulatedly corrupted. This is why there is strong shilling against= R1000 in this thread: slight-of-hand obfuscation of this dirty laundry; l= ook 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 tha= t 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. =E2=80=A6 but the fact that no c= ompiler 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 h= ave automated language-agnostic (super-dooper rich*** filesystem-based) way= s of perfectly (!) discovering extremely fine-grained dependencies to accom= plish aggressive build avoidance (and something even more aggressive: wink= -ins) via proofs by mathematical induction that omnisciently observe the en= tirety of all compilation units. Vesta effectively died off with Alpha & C= ompaq, 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 m= illions- 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. > >=20 > > Oh really! Read Lakos's book then. >=20 > I did. Thank you for recommendation. >=20 > > All 852 pages of it effectively say: > [...] >=20 > No, they don't (and since I'm already used to your trolling style, I'm no= t surprised). The abstract is > available here: >=20 > https://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/02016336= 20 >=20 > and relates to addressing physical challenges of large codebases. >=20 > Considering the fact that the compilation model of Ada and C++ is basical= ly the same (some of this > might be related to the fact that they use, well, exactly the same compil= er), the challenges that are > addressed by this book exists in both languages and, interestingly, the p= resented techniques (or most of > them) are transferable. >=20 > > When a language has a problem that needs 852 pages to explain and strai= ghten out, methinks it > > actually might have an actual problem (or whole tangled nest of problem= s) in that vicinity. >=20 > Yes. Another way to look at it is this: C++ is one of the few languages t= hat actually allowed engineers to > implement systems in the large scale. >=20 > > By comparison, in Ada's entire history spanning 5 decades, no one neede= d to write an analogous > > 852-page tome on that topic. >=20 > 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 ano= ther 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 s= omeone's hard drive, lurking undiscovered. Perhaps, just perhaps. Who kno= ws, 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 in= finitum how to walk just the right narrow path to prevent C++-esque physica= l-design disasters ** regarding Ada's purported(-by-you) 1-to-1 & onto mapping of directly ana= logous 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=20 > > header files and preprocessor. >=20 > Nobody sees how it could be accomplished in the Ada compiler, either. :-) >=20 > 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? >=20 > Todays' IDEs can figure out and track individual declarations and use tha= t 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 interes= ting 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 =E2=80=A2absence of evidence=E2=80=A2 is in Ada's favor (in the pr= ior quote before =E2=80=9Cvis a vis=E2=80=9D), then the speaker is an ignor= ant-of-=E2=80=9Cfundamental-logic=E2=80=9D dolt. When the =E2=80=A2absence of evidence=E2=80=A2 is in C++'s favor (in this q= uote after =E2=80=9Cvis a vis=E2=80=9D), then it is the paragon of universa= l-generalization from which vast one-size-fits-all wisdom shall be harveste= d & weaponized (to kill off any virtues of R1000 and to kill off teaching C= ++ in an Ada-esque way).