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:8049:: with SMTP id g70-v6mr249949itd.37.1530673839694; Tue, 03 Jul 2018 20:10:39 -0700 (PDT) X-Received: by 2002:aca:2b06:: with SMTP id i6-v6mr68317oik.0.1530673839405; Tue, 03 Jul 2018 20:10:39 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.swapon.de!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!u78-v6no1264668itb.0!news-out.google.com!z3-v6ni1373iti.0!nntp.google.com!u78-v6no1264666itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 3 Jul 2018 20:10:39 -0700 (PDT) In-Reply-To: <8dc19505-b68a-403c-a164-f1de1864f3f1@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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Teaching C/C++ from Ada perspective? From: "Dan'l Miller" Injection-Date: Wed, 04 Jul 2018 03:10:39 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:53557 Date: 2018-07-03T20:10:39-07:00 List-Id: 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 > > John Lakos's _Large Scale C++ Software Design_ (1995). > > All 852 pages of it effectively say: > > C++ is almost an unmitigated disaster in controlling physical dependen= cies unless you walk the very > > narrow path that he lays out. > > 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. You are factually incorrect. Please read the quotations from Lakos's book = in this reply, both here and below. His entire 144-page chapter 6 is dedic= ated to untangling the disastrous entanglement that is C++ declarations in = textually-included header files. Specifically, Chapter 6 crescendos up to = pages 399 to 405. Pages 399 to 405 of Lakos's book (=E2=80=A2not=E2=80=A2 = Guru-of-the-Week =E2=80=A2years=E2=80=A2 later) introduce the Pimpl idiom (= originally named =E2=80=9Cfully-insulating concrete classes=E2=80=9D in Lak= os's seminal work) to demote vast amounts of content from the private membe= rs of classes in #inculde-d .h header files to the compilation-unit .c file= s. page 335 in =C2=A76.2 C++ Constructs and * Compile-Time Coupling: * The word =E2=80=98excessive=E2=80=99 is practically screamed in context h= ere, as in: C++ headers' excessive compile-time coupling. =E2=80=9CIt is =E2=80=A2easy=E2=80=A2 in C++ to =E2=80=A2inadvertently=E2= =80=A2 introduce implementation details into the physical interface of a co= mponent. Whenever we place any part of the implementation of a component i= n its header file, we =E2=80=A2fail=E2=80=A2 to insulate clients from that = part of our implementation.=E2=80=9D > 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) Janus Ada and Visual Studio C++ are exactly the same compiler, eh? who kne= w? > the challenges that are addressed by this book exists in both languages Oh really! On page 3 (i.e., the beginning of the book, setting the overarc= hing tone of the next 848 pages), Lakos correctly observes, =E2=80=9C=E2=80= =A6 Not being able to understand or use any part of a system independently = is a symptom of a cyclically dependent design. =E2=80=A2=E2=80=A2C++ objec= ts have a phenomenal tendency to get tangled up in each other=E2=80=A2=E2= =80=A2. This insidious form of tight physical coupling is illustrated in F= igure 0-1. =E2=80=A6 The definition for each of these three object types re= side in separate physical components (translation units) in order to improv= e modularity. Even though the implementations of these individual types ar= e fully encapsulated by their interfaces, however, the .c files for each co= mponent are =E2=80=A2=E2=80=A2forced to include the header files of the oth= er two=E2=80=A2=E2=80=A2. The resulting dependency graph for these three c= omponents is cyclic. =E2=80=A6=E2=80=9D Ada specifications do not utilize primitive header-file textual inclusion m= echanisms. Ada specifications & bodies are by their nature not becoming co= -dependent on each other by simply with-ing. Indeed, cyclic nonprivate wit= h-ing is prohibited in Ada. Indeed, Lakos even goes even a little bit farther than your =E2=80=9Cthe ch= allenges that are addressed by this book exists in both languages=E2=80=9D = claim. He says that these challenges are worse in C++ than they were in C: =C2=A70.2.3 Excessive Compile-Time Dependencies, page 9, setting the overar= ching tone for the remaining 842 pages: =E2=80=9CThere are many other causes of unwanted compile-time dependencies.= A large C++ program tends to have many more header files than an equivale= nt C program. The unnecessary inclusion of one header file by another is a= common source of excessive coupling in C++.=E2=80=9D =C2=A70.2.5 Logical vs. Physical Design, page 12: =E2=80=9CC++ supports an overwhelmingly rich set of logical design alternat= ives. =E2=80=A6 Misdiagnosing a situation =E2=80=A6 can lead to inefficienc= ies in both time and space, and can obscure the semantics of the architectu= re to a point where the entire system becomes difficult to maintain. Knowi= ng when (and when not) to use a particular language construct is part of wh= at makes the /experienced/ C++ developer so valuable.=E2=80=9D (Lakos's emp= hasis there)=20 =E2=80=9C=C2=B6Logical design does not address issues such as =E2=80=A2wher= e=E2=80=A2 to place a class definition. =E2=80=A6 =C2=B6 There are severa= l good books on logical design =E2=80=A6. Unfortunately, there are also ma= ny problems, which arise only as programs get larger, that these books don'= t address. This is because much of the material relevant to successful lar= ge-system design falls under a different category, referred to in this book= as /physical design/.=E2=80=9D (Lakos's emphasis there) and here is what people complain about regarding Ada so much: finding a lo= gical design that the compiler will accept, as the compiler enforces all th= e physical-design wisdom that is built into the Ada language that is absent= in C++: =E2=80=9C=C2=B6 Good physical design, however, involves more than passively= deciding how to partition the existing logical entities of a system. Phys= ical design implications often dictate the outcome of logical design decisi= ons. =E2=80=A6 =C2=B6 Simultaneously satisfying the constraints of both l= ogical and physical design may, at times, prove challenging. In fact, =E2= =80=A2=E2=80=A2some logical designs may have to be reworked or even replace= d=E2=80=A2=E2=80=A2 in order to meet the physical design quality criteria. = =E2=80=A6=E2=80=9D [Hence, the walking along the narrow path that Lakos la= ys out, as I was saying] =C2=A70.6 Summary, page 18, hence the almost unmitigated disaster of C++ un= less walking Lakos's narrow path: =E2=80=9CC++ is a whole lot more than just an extension of C. Cyclic link-= time dependencies among translation units can undermine understanding, test= ing, and reuse. Unnecessary or excessive compile-time dependencies can inc= rease compilation cost and =E2=80=A2=E2=80=A2destroy maintainability=E2=80= =A2=E2=80=A2. A disorganized, undisciplined, or na=C3=AFve approach to C++= development will =E2=80=A2=E2=80=A2virtually guarantee=E2=80=A2=E2=80=A2 t= hat these problems occur as projects become larger. =E2=80=A6 =C2=B6 =E2= =80=A6 But tools cannot make up for a lack of inherent design quality in la= rge C++ systems. =E2=80=A2=E2=80=A2=E2=80=A2This book is about how to desi= gn in that quality.=E2=80=A2=E2=80=A2=E2=80=A2=E2=80=9D [because C++-the-la= nguage provided so little guidance] > > 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 does if HOLWG and Jean Ichbiah precluded pre-1983 the entire cyclic-depe= ndency problem that permeates throughout C++ that the C++ community didn't = have a book to teach them the errors of their ways until 1995 and onward. = (And given that Pimpl had to be rediscovered and renamed several years afte= r that, means that some people were later to arrive at the party than 1995.= ) > Interestingly, the theoretical book "Large-Scale Ada Software Design" mig= ht not be needed at all thanks > to the fact that Ada problems at the large scale can be addressed with th= e techniques presented in the > C++ book. So let me get this straight. 1) HOLWG and Jean Ichbiah must have had a time machine that travels to some= year post-1994. 2) Then they must have read Lakos's 1995 book or even Guru of the Week 'blo= g in 1997. 3) Then they must have traveled back in time to pre-1983 to conspire nefari= ously amongst themselves, =E2=80=9CHey, that Lakos is really on to somethin= g 12 to 17 years in the future in 1994 (reprised several years later by Her= b Sutter in Guru of the Week #7 in 1997). In Ada, let's steal their thunde= r by precluding that level of too-much-private-declaration in header files = by having no textual-inclusion-based header files, separate compilation of = private portions of packages, rather-early freezing rules, and prohibition = on cyclic dependencies among frozen declarations.=E2=80=9D 4) Then time-traveling Ada luminaries swiped the idea from C++ luminaries v= ia this time travel (instead of the way it sure looks: C++ world (during a= period of duress & distress) looked over Ada world's shoulder to see how A= da-the-mentor solved the problem then devised C++ knock-offs of Ada's alrea= dy-established wisdoms in these areas). > After all, they use the same compiler. You don't really think that RR Software's Janus Ada and Microsoft's Visual = Studio C++ are the same compiler, do you? You don't really think that there is only one compiler for Ada (i.e., GNAT)= , do you? You don't really think that the source code & inner workings of GNAT's Ada = front-end (prior to the GIGI tree-transducer to GIMPLE) has even one iota t= o do with the source code & inner workings of GCC's C++ front-end (prior to= GENERIC/GIMPLE), do you? Btw, Kouaoua, even though this discussion/debate between Maciej & I seems to gen= erate more heat than light (at least from his side), there are some wonderf= ul gems for your class content: Lakos's physical design is omitted by near= ly all C++ coursework (except as excepted smidgeons such as Pimpl have drif= ted by osmosis into mainstream C++ culture). The self-discipline =E2=80=A2= prescribed=E2=80=A2 by Lakos for C++ is avoiding the portions/bad-habits of= C++ that don't scale to very large software systems, many of which are =E2= =80=A2proscribed=E2=80=A2 by Ada at compile-time. Through the backdoor, we= actually have covered another aspect of your OP question via C++'s versus = Ada's prescribed versus proscribed differing/diametrically-opposed approach= es to the rules-of-wisdom for how to successfully physically design multimi= llion or multi-tens-of-millions of lines of source-code for software-in-the= -large integrated massive systems. During the late 1980s and early 1990s, = software-in-the-very-large was intended to be the A#1 key marketspace to be= addressed by both Ada and its knockoff language C++. In the end, Ada ende= d up accomplishing it better than C++. Either you can be honest with your = students that C++-in-the-small is written much differently than C++-in-the-= large or you can overtly teach the content in Lakos's book (updated for mod= ern C++, much as Guru of the Week GotW has been) as an Ada-esque reinterpre= tation of C++.