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

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

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.
> 
> > 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 dependencies 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 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.

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 dedicated 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 (•not• Guru-of-the-Week •years• later) introduce the Pimpl idiom (originally named “fully-insulating concrete classes” in Lakos's seminal work) to demote vast amounts of content from the private members of classes in #inculde-d .h header files to the compilation-unit .c files.

page 335 in §6.2 C++ Constructs and * Compile-Time Coupling:
* The word ‘excessive’ is practically screamed in context here, as in:  C++ headers' excessive compile-time coupling.
“It is •easy• in C++ to •inadvertently• introduce implementation details into the physical interface of a component.  Whenever we place any part of the implementation of a component in its header file, we •fail• to insulate clients from that part of our implementation.”

> 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)

Janus Ada and Visual Studio C++ are exactly the same compiler, eh?  who knew?

> 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 overarching tone of the next 848 pages), Lakos correctly observes, “… Not being able to understand or use any part of a system independently is a symptom of a cyclically dependent design.  ••C++ objects have a phenomenal tendency to get tangled up in each other••.  This insidious form of tight physical coupling is illustrated in Figure 0-1. … The definition for each of these three object types reside in separate physical components (translation units) in order to improve modularity.  Even though the implementations of these individual types are fully encapsulated by their interfaces, however, the .c files for each component are ••forced to include the header files of the other two••.  The resulting dependency graph for these three components is cyclic. …”

Ada specifications do not utilize primitive header-file textual inclusion mechanisms.  Ada specifications & bodies are by their nature not becoming co-dependent on each other by simply with-ing.  Indeed, cyclic nonprivate with-ing is prohibited in Ada.

Indeed, Lakos even goes even a little bit farther than your “the challenges that are addressed by this book exists in both languages” claim.  He says that these challenges are worse in C++ than they were in C:

§0.2.3 Excessive Compile-Time Dependencies, page 9, setting the overarching tone for the remaining 842 pages:
“There are many other causes of unwanted compile-time dependencies.  A large C++ program tends to have many more header files than an equivalent C program.  The unnecessary inclusion of one header file by another is a common source of excessive coupling in C++.”

§0.2.5 Logical vs. Physical Design, page 12:
“C++ supports an overwhelmingly rich set of logical design alternatives. … Misdiagnosing a situation … can lead to inefficiencies in both time and space, and can obscure the semantics of the architecture to a point where the entire system becomes difficult to maintain.  Knowing when (and when not) to use a particular language construct is part of what makes the /experienced/ C++ developer so valuable.” (Lakos's emphasis there) 

“¶Logical design does not address issues such as •where• to place a class definition.  …  ¶ There are several good books on logical design ….  Unfortunately, there are also many problems, which arise only as programs get larger, that these books don't address.  This is because much of the material relevant to successful large-system design falls under a different category, referred to in this book as /physical design/.”  (Lakos's emphasis there)

and here is what people complain about regarding Ada so much:  finding a logical design that the compiler will accept, as the compiler enforces all the physical-design wisdom that is built into the Ada language that is absent in C++:
“¶ Good physical design, however, involves more than passively deciding how to partition the existing logical entities of a system.  Physical design implications often dictate the outcome of logical design decisions.  …  ¶ Simultaneously satisfying the constraints of both logical and physical design may, at times, prove challenging.  In fact, ••some logical designs may have to be reworked or even replaced•• in order to meet the physical design quality criteria. …”  [Hence, the walking along the narrow path that Lakos lays out, as I was saying]

§0.6 Summary, page 18, hence the almost unmitigated disaster of C++ unless walking Lakos's narrow path:
“C++ is a whole lot more than just an extension of C.  Cyclic link-time dependencies among translation units can undermine understanding, testing, and reuse.  Unnecessary or excessive compile-time dependencies can increase compilation cost and ••destroy maintainability••.  A disorganized, undisciplined, or naïve approach to C++ development will ••virtually guarantee•• that these problems occur as projects become larger.  … ¶ … But tools cannot make up for a lack of inherent design quality in large C++ systems.  •••This book is about how to design in that quality.•••” [because C++-the-language provided so little guidance]

> > 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 does if HOLWG and Jean Ichbiah precluded pre-1983 the entire cyclic-dependency 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 after that, means that some people were later to arrive at the party than 1995.)

> Interestingly, the theoretical book "Large-Scale Ada Software Design" might not be needed at all thanks
> to the fact that Ada problems at the large scale can be addressed with the 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 'blog in 1997.
3) Then they must have traveled back in time to pre-1983 to conspire nefariously amongst themselves, “Hey, that Lakos is really on to something 12 to 17 years in the future in 1994 (reprised several years later by Herb Sutter in Guru of the Week #7 in 1997).  In Ada, let's steal their thunder 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.”
4) Then time-traveling Ada luminaries swiped the idea from C++ luminaries via 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 Ada-the-mentor solved the problem then devised C++ knock-offs of Ada's already-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 to 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 generate more heat than light (at least from his side), there are some wonderful gems for your class content:  Lakos's physical design is omitted by nearly all C++ coursework (except as excepted smidgeons such as Pimpl have drifted by osmosis into mainstream C++ culture).  The self-discipline •prescribed• 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 •proscribed• 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 approaches to the rules-of-wisdom for how to successfully physically design multimillion 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 ended 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 modern C++, much as Guru of the Week GotW has been) as an Ada-esque reinterpretation of C++.