Teaching C/C++ from Ada perspective?

Teaching C/C++ from Ada perspective?

[kouaoua16]

Hello,

Ada is my programming language of choice. I have used it much in scientific programming. At an University I am asked to teach programming but in C and C++ to fist year students. After having spent some years with Ada, I'm relecutant to "throw away" my good programming habits from Ada and embrace C/C++. I would like to know if there exist(s) good book(s) at introductory level for C/C++ that may go in the spirit of Ada so that I won't feel wasting my time and energy teaching C/C++?

Also I will start the above course with Algorithms in which I have little knowledge. Any suggestions for good books on this topic?


Thank you.

Kouaoua

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

[Luke A. Guest]

Don’t know of any books and I doubt there are any. 

Good luck, because you’ll likely be writing macros and templates to handle
Ada-isms like ranges with checks.

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

[Dan'l Miller]

On Saturday, June 30, 2018 at 1:04:30 PM UTC-5, koua...@gmail.com wrote:
> Hello,
> 
> Ada is my programming language of choice. I have used it much in scientific programming. At an University I am asked to teach programming but in C and C++ to fist year students. After having spent some years with Ada, I'm relecutant to "throw away" my good programming habits from Ada and embrace C/C++. I would like to know if there exist(s) good book(s) at introductory level for C/C++ that may go in the spirit of Ada so that I won't feel wasting my time and energy teaching C/C++?
> 
> Also I will start the above course with Algorithms in which I have little knowledge. Any suggestions for good books on this topic?
> 
> 
> Thank you.
> 
> Kouaoua

Short answer:  purge as close to 100% of your usage of C semantics from your C++ code.

Long answer:
Well, if you are really really wanting to do this, you would write a whole bunch of class templates to displace every usage of C-semantics stuff.  You would start with C-semantics scalar types; replace them wholesale.  You would then progress onward to C-semantics typedefs; replace then wholesale with struct-wrapped templates.  You would then progress onward to making a before-after list of all C-semantics C++ language constructs to never ever utilize (the before column in the table) followed by the corresponding replacement in the modern C++ standard library.  You would then extend your table to also have before-after list of all C-semantics idioms to never ever utilize (the before column in the table) followed by the corresponding replacement in the modern C++{11,14,17} idioms.

When writing wholesale replacements for C-semantics scalar data, you would go chapter by chapter through the Ada _LRM_ and design Ada-esque ‘language design’ utilizing C++ templates of every single C-semantics topic.

1) Every time that you would otherwise write {int, short, long, signed, unsigned, float, double, char, uint8_t, uint16_t, uint32_t, uint64_t, int8_t, int16_t, int32_t, int64_t, any combination/permutation thereof}, you would instead write ::Adaesque::Integer< _LowerBound_, _UpperBound_ > as the Ada-esque replacement in C++ for the lack of subtype constraints.

2) Every time that you would otherwise write one of the C-isms in the ‘before’ column of the table, you would instead utilize the Ada-esque idioms in the ‘after’ column of the table.

3) You would utilize C++ allocators to emulate Ada-esque pools and subpools.

4) You would utilize C++{11,14,17,20} concurrency library content and/or language primitives to emulate Ada tasking.

Wholesale replacement of C++'s scalar types with class template replacements is first explored in §5 of Chapter 16 of Barton & Nackman's _Scientific and Engineering C++: An introduction with advanced techniques and examples_ (1993).  This was done for adding physical-units dimensions to C++; your motivation is analogous but endorsing Ada instead of SI as the philosophical projection onto C++.  This was then developed further by Walter Brown at Fermi Lab and presented to the C++ standardization committee during 2002.  AIUI, that Fermi Lab work fed into Boost Units library:
https://www.boost.org/doc/libs/1_37_0/doc/html/boost_units.html

Here is another treatment of the topic by Scott Meyers, much the same as Barton & Nackman's:
http://se.ethz.ch/~meyer/publications/OTHERS/scott_meyers/dimensions.pdf

In other words, your coursework would not be the first programming culture to jettison C-semantics baggage from C++, replacing it wholesale with class template replacements.

Hmmmm, the more that I think about this, the more that I think that this would be an outreach mechanism to draw C++ programmers into Ada:  get them to start programming in Ada-esque concepts as close to 100% of the time while still remaining in C++.

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

[Dan'l Miller]

On Saturday, June 30, 2018 at 1:15:29 PM UTC-5, Luke A. Guest wrote:
> Don’t know of any books and I doubt there are any. 
> 
> Good luck, because you’ll likely be writing macros

overloaded operators that utilize the Adaesque template data-types galore, instead of macros

> and templates to handle Ada-isms like ranges with checks.

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

[kouaoua16]

Dear all,

Thank you very much for your replies. Perhaps I should think twice before accepting this teaching offer. Once you go Ada it is hard to think of other languages that are not as good as Ada!

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

[Luke A. Guest]

<kouaoua16@gmail.com> wrote:
> Dear all,
> 
> Thank you very much for your replies. Perhaps I should think twice before
> accepting this teaching offer. Once you go Ada it is hard to think of
> other languages that are not as good as Ada!
> 
> 

Maybe you should teach Ada with c/c++ shown as counter examples?

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

[Dan'l Miller]

On Sunday, July 1, 2018 at 12:08:57 PM UTC-5, Luke A. Guest wrote:
> <kouaoua16@gmail.com> wrote:
> > Dear all,
> > 
> > Thank you very much for your replies. Perhaps I should think twice before
> > accepting this teaching offer. Once you go Ada it is hard to think of
> > other languages that are not as good as Ada!
> 
> Maybe you should teach Ada with c/c++ shown as counter examples?

This!  This from Luke!

My Fortran77 class was taught this way as a series of anecdotes:  embarrassment-eye-roll anti-Pascal-in-translation.  It was my first programming class Pascal and Fortran77.  Fortran was taught by lambasting Fortran77-per-se, showing instead how to import Pascal ideas into Fortran.  2/3rds of the class was Pascal to teach how to do things correctly.  1/6th of the class was taught as:  don't ever do this legal-Fortran77 language construct in Fortran77 programs.  1/6th of the class was taught as:  here is how to write the Pascal concept in analogous good Fortran77.  And practically all of Fortran66 was condemned wholesale.

The counterexamples can take 3 forms:

1) Look at what a disaster this is was C++ historically up to C++2003, partially mitigated nowadays.

2) Look at how incrementally better C++{11,14,17,20} & their standard libraries are than C++{cfront/ARM/C++1990, C++1998, C++2003}.

3) Look via the aforementioned Adaesque library that I the professor whipped up at how C++ as standardized is really just a bunch of half-baked primitives to write a stronger closer-to-fully-baked library.

I almost think that modern C++ and even features like restricted keyword in C99 are more to drive consultants' & library-writers' businesses than to be a well-designed language.  The reason that C++ has half-baked features might actually be to beget market demand for more-fully-baked C++ libraries than the raw language provides.  And heaven help the poor employee at an enterprise that doesn't cultivate its own roll-your-own/harvest-the-web to arrive at a set of more-fully-baked set of libraries.  (My own résumé reads like:  wrote libraries to back-fill all the major gaps in C++ at this employer, and oh did much the same a little differently at that employer, and yet again at the next employer but this time extended from a prior open-source basis.)

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

[Maciej Sobczak]

> After having spent some years with Ada, I'm relecutant to "throw away" my good programming habits from Ada and embrace C/C++.

There is absolutely no reason to throw away your good habits. On the contrary, your good habits (no matter where you got them from, Ada or elsewhere) will be very useful when teaching C++ (or whatever else).

> I would like to know if there exist(s) good book(s) at introductory level for C/C++ that may go in the spirit of Ada

No and there should not be any, just as there are no introductory books teaching Ada in the spirit of C++. This would be pointless, as the spirits of different languages are different and forcing one language into the spirit of another one is counterproductive.

Having said that, you might think that the two answers above are contradictory. They are not, because they refer to distinct aspects.

Ada is strong in directing the user towards a good program structure. Pick this and try to show your students how to design the program in C++ using the tools that it has - namespaces and classes. The notion of packages in Ada do not map 1:1 into namespaces and classes in C++, but the big picture of encapsulation and program decomposition translates well. Show them how the physical structure of translation units in C++ can be used to enhance encapsulation. Show them how to use templates. Use the standard library whenever you can. Stay away from raw pointers as long as you can (which might as well be forever).

Now, I take the risk of being controversial here, but I have enough C++ experience to stand by my words: don't bother implementing your own broken version of integer ranges in C++, no matter whether with macros or with templates. Just don't. If you try to do this, you will teach your students something that they will not be able to reuse or translate in the real world, in the real existing code. You will be blamed afterwards for the bad teaching and you will have nothing to defend yourself. Just don't. It is true that some attempts have been made in this direction, but none got any recognizable acceptance. C++ is not the language for doing ranges and I'm not sure whether this is entirely bad - don't confuse them with range-checked arrays, which are available in the standard library and are (and should be) used. In the same spirit, don't get obsessed too much on defining gazillion of incompatible types for everything, as some Ada books insist on. Classes as separate types are good for medium to big design concepts, but not for micromanaging integers. Don't bother with reimplementing Ada in C++ at this level and you will be successful in your teaching.

> so that I won't feel wasting my time and energy teaching C/C++?

It works the other way round. If you don't accept this position, your time and energy will be wasted, because you will not be able to pass your good habits to C++ students. Somebody else will pass their bad habits instead. Surprise.

> Also I will start the above course with Algorithms in which I have little knowledge. Any suggestions for good books on this topic?

There are plenty of algo books that base their presentation on C++. Another surprise.

-- 
Maciej Sobczak * http://www.inspirel.com

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

[Dan'l Miller]

On Sunday, July 1, 2018 at 3:52:37 PM UTC-5, Maciej Sobczak wrote:
> > After having spent some years with Ada, I'm relecutant to "throw away" my good programming habits from Ada and embrace C/C++.
> 
> There is absolutely no reason to throw away your good habits. On the contrary, your good habits (no matter where you got them from, Ada or elsewhere) will be very useful when teaching C++ (or whatever else).
> 
> > I would like to know if there exist(s) good book(s) at introductory level for C/C++ that may go in the spirit of Ada
> 
> No and there should not be any, just as there are no introductory books teaching Ada in the spirit of C++. This would be pointless, as the spirits of different languages are different and forcing one language into the spirit of another one is counterproductive.
> 
> Having said that, you might think that the two answers above are contradictory. They are not, because they refer to distinct aspects.
> 
> Ada is strong in directing the user towards a good program structure. Pick this and try to show your students how to design the program in C++ using the tools that it has - namespaces and classes. The notion of packages in Ada do not map 1:1 into namespaces and classes in C++, but the big picture of encapsulation and program decomposition translates well. Show them how the physical structure of translation units in C++ can be used to enhance encapsulation. Show them how to use templates. Use the standard library whenever you can. Stay away from raw pointers as long as you can (which might as well be forever).
> 
> Now, I take the risk of being controversial here, but I have enough C++ experience to stand by my words: don't bother implementing your own broken version of integer ranges in C++, no matter whether with macros or with templates. Just don't. If you try to do this, you will teach your students something that they will not be able to reuse or translate in the real world, in the real existing code. You will be blamed afterwards for the bad teaching and you will have nothing to defend yourself. Just don't. It is true that some attempts have been made in this direction, but none got any recognizable acceptance. C++ is not the language for doing ranges and I'm not sure whether this is entirely bad - don't confuse them with range-checked arrays, which are available in the standard library and are (and should be) used. In the same spirit, don't get obsessed too much on defining gazillion of incompatible types for everything, as some Ada books insist on. Classes as separate types are good for medium to big design concepts, but not for micromanaging integers. Don't bother with reimplementing Ada in C++ at this level and you will be successful in your teaching.
> 
> > so that I won't feel wasting my time and energy teaching C/C++?
> 
> It works the other way round. If you don't accept this position, your time and energy will be wasted, because you will not be able to pass your good habits to C++ students. Somebody else will pass their bad habits instead. Surprise.

Oh, so the take-away is:  bad C++ instructors don't teach classes and namespaces and C++ standard library's containers?  ••Make sure that you use classes & namespaces & C++ standard library's containers•• is the level of deep-wisdom contribution that an insightful Ada perspective brings to C++?  Wow, bad C++ instructors must be really really bad if they skip or botch those 3 topics.  Who knew?

I strongly believe that thinking-in-Ada has so vastly much more to contribute to C++-based program design than merely “Make sure that you use classes & namespaces & C++ standard library's containers”.

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

[Paul Rubin]

kouaoua16@gmail.com writes:
> I would like to know if there exist(s) good book(s) at introductory
> level for C/C++ that may go in the spirit of Ada so that I won't feel
> wasting my time and energy teaching C/C++?

I'd advise against this: it's fine to be influenced by Ada, but if
you're teaching C++, try to teach and use the idioms that have grown
around it, similarly for C.  That said, C and C++ should be treated as
completely separate languages that are at most distantly related to each
other.  

> Also I will start the above course with Algorithms in which I have
> little knowledge. Any suggestions for good books on this topic?

Really no.  Before trying to teach that subject you should first know
something about it.

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

[Maciej Sobczak]

 
> Oh, so the take-away is:
[...]

Nothing of what you wrote is a take-away, because I did not write any of this.

> bad C++ instructors don't teach classes and namespaces and C++ standard library's containers?

I don't know what bad instructors teach. I know what good instructors should teach.

> I strongly believe that thinking-in-Ada has so vastly much more to contribute to C++-based program design than merely “Make sure that you use classes & namespaces & C++ standard library's containers”.

You have skipped other important points that I have made. Don't troll with me, it's too cheap.
"Thinking-in-Ada" is a micro-skill that is best used in Ada. Conversely, if you are using Ada but you do not think-in-Ada, then it is a recipe for disaster.  Thinking-in-Ada is a very valuable skill once you have it, but it is still a micro-skill that has its proper use only with Ada. What you need when transitioning to another language (even more when you teach others) is thinking in terms of good design and good idioms, so that you can apply them onto your thinking-in-other-language. Ada has a lot to contribute in this area and learning Ada is a good way to acquire these skills, but these skills are not exclusive or limited to Ada, so I will not call them thinking-in-Ada.

In other words: if you are about to teach C++, then think-in-C++ and bring in your good design and idiomatic habits that you have already acquired.
But don't get obsessed with micro details, because this is where you will be forcing a round peg into a square whole. It's not effective.

The following:

#define begin {
#define end }

is a very bad example of thinking-in-Ada applied to C++. On the other end of the scale you have modular design with the use of physical program structure, which is a good example of a skill that is transferable (and therefore not exclusive to any language, but possible to acquire in Ada). Everything else is somewhere in between with a gray division area with space for subjective judgement. Integer ranges is an example of thinking-in-Ada that does not translate well to C++. The select statement is another example of thinking-in-Ada that should not be forced to C++, although protected objects are very welcome. And so on.

-- 
Maciej Sobczak * http://www.inspirel.com

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

[Maciej Sobczak]

> (My own résumé reads like:  wrote libraries to back-fill all the major gaps in C++ at this employer, and oh did much the same a little differently at that employer, and yet again at the next employer but this time extended from a prior open-source basis.)

You have picked the wrong argument. The proliferation of libraries in C++ comes from the fact that the standard library is relatively (compared to fully baked platforms like .NET) small and omits many important areas. The problem with your argument is that in Ada it is not any better and since the usual way to solve the problem in Ada is to write bindings to libraries written in C or C++, you just have additional layer of mess (or additional dimension). More versions to care about, more bugs to fix/rely on, more incompatible APIs that prevent you from merging or reusing code, etc.

A very good example of this mess is GUI, where in C++ you have a mess of multiple libraries, but in Ada you have a 2D mess of multiple bindings to those. And there is no sign of this getting any better in any foreseeable future.

-- 
Maciej Sobczak * http://www.inspirel.com

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

[Marius Amado-Alves]

<<
#define begin {
#define end }
>>

Thanks, Maciej, you've just put a big smile in my face:-)

Kouaoua, I'm afraid I am even more radical than Maciej: the least bad C++ style possible has nothing to do with Ada.

It takes a formidable C++ programmer to write in the least bad C++ style possible. Like one in a million. Because it is necessary to understand the entire language (one in a thousand programmers), and then be able to pick the least bad idioms all the time (one in a thousand of the former thousandth).

/* I myself used to be a (forced) knowledgeable C++ programmer, but that was some time ago, and since then C++ has grown in its kludginess beyond my capacity. However I'm am fortunate(?) enough to have colleagues in at least the first thousandth, heading for the second. */

Sorry to say, Kouaoua, you're in a very difficult spot. Teaching the whole of C++ (necessary for the least bad style) is a doomed endeavour unless it is a 4-semester programme or so.

For one semester you must choose a fragment (probably classes), and relegate style issues to "further reading".

(Whereas in Ada you can take a fragment and keep the good style.)

In sum, and to the point, I see nothing you can transpose from Ada.

Except, maybe, promote a bit of Ada, in between the lines, a propos problems that arise (a soft, maybe feasible, version of Luke's unfeasible proposal of turning the table completely).

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

[Maciej Sobczak]

> Because it is necessary to understand the entire language

I would discuss with this. The Ada and C++ standards have comparable "volumes" in terms of number of pages (and both are *huge*) and I do not see any fundamental reason for why partial knowledge of the language is guaranteed to be safe in one language but not in the other. Looking at the questions that are being (sometimes periodically) asked on this group shows that Ada beginners are not entirely safe.
It is still possible, though, to present the part of the language that is sufficiently complete to allow students write reasonable programs. If you are looking for a C++ book at this level of presentation, start with "Accelerated C++", it is known for its focus on good selection of idioms from the very beginning.

> For one semester you must choose a fragment (probably classes), and relegate style issues to "further reading".

Yes.

> (Whereas in Ada you can take a fragment and keep the good style.)

No. Or I see no reason for Ada to be better here. I mean - this is the mood that everybody here likes to share, but just check the first screenful of questions to see how easy it is for the beginner to go astray.

> In sum, and to the point, I see nothing you can transpose from Ada.

Both languages are in the same family with regard to being imperative and value-oriented. There is a lot of conceptual commonality here, much more than, say, between C++ and Java.

-- 
Maciej Sobczak * http://www.inspirel.com

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

[Marius Amado-Alves]

/*
> > (Whereas in Ada you can take a fragment and keep the good style.)
> No. Or I see no reason for Ada to be better here ...just check the first screenful of questions to see how easy it is for the beginner to go astray.

Well, your mileage may vary. Personally I have learnt C++ and Ada both fragment by fragment. With each new fragment (and version!) of C++ I often have to adapt, revise, change, or ditch an idiom entirely. (Classes being the exception, hence the recommendation.) With each new fragment of Ada I could keep the previous idioms, seldom change them, never ditch them. As I said, personal memory, maybe I used the wrong books.

Thanks for the "Accelerated" book recommendation, I'll check. My learned colleages recommend the "42 ways".
*/

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

[kouaoua16]

Thank you all for the interesting discussions. Anyone with experience with this Ada to C++ translator:

https://www.ada2cc.com/faq/faq.htm

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

[kouaoua16]

On Monday, July 2, 2018 at 12:52:37 AM UTC+4, Maciej Sobczak wrote:

> > Also I will start the above course with Algorithms in which I have little knowledge. Any suggestions for good books on this topic?
> 
> There are plenty of algo books that base their presentation on C++. Another surprise.
> 

The course is too start with Algorithms first and then end with programming. Perhaps this is counterintuitive as students will then tend to learn the Algorithms part by heart. But if I start with programming first and move on to Algorithms, then students will better understand the logic of the presentation. What is your opinion?

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

[Dennis Lee Bieber]

On Mon, 2 Jul 2018 10:10:00 -0700 (PDT), kouaoua16@gmail.com declaimed the
following:

>
>The course is too start with Algorithms first and then end with programming. Perhaps this is counterintuitive as students will then tend to learn the Algorithms part by heart. But if I start with programming first and move on to Algorithms, then students will better understand the logic of the presentation. What is your opinion?

	Ideally, algorithms should be language agnostic... Basic conceptual
building blocks: sequential statements, branching (if/else; switch/case --
I'd try to avoid goto), functions/procedures (or in ancient FORTRAN terms:
function subprograms and subroutine subprograms); data structures: arrays,
record structures, linked lists (in my day, taught by using static arrays
with tags for the index -- no dynamic allocation in FORTRAN-IV), hashes
(for my data structures class we had the assignment of implementing a
hashed head multiple-linked list "phone directory" -- we were allowed to
use any language the instructor was familiar with [so no SNOBOL or APL, and
no C in 1979 Sigma CP/V, just FORTRAN IV, COBOL, Assembler, BASIC -- maybe
UCSD Pascal if one had access to the two LSI-11s]; on a whim I used BASIC,
chain-loading functionality as the BASIC only permitted four open data
files at a time). 

	Converting an algorithm to an implementation language is a different
matter from understanding algorithms. And if these are truly beginners, you
probably don't have time to introduce object-oriented analysis/design
(which should also be language agnostic -- you later map what the design
comes up with into the features of the implementation language). Which
likely also means that the OO features of C++ will barely be touched...


-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/ 

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

[Maciej Sobczak]

> The course is too start with Algorithms first and then end with programming.
[...]

Go ahead with introducing both at the same time.
You need some form of "language" anyway, to present the algorithms precisely, so hand-waving is not sufficient. If you decide to use some pseudocode that students will not be able to execute, then you might as well use a language that is actually executable. Introduce language features as you need them for the progressively more complex algorithms.

It works the other way round, too. If you teach a language, you need some motivating use cases to drive the teaching so that the programs actually do something useful and involving. It might be algorithms. Introduce more algorithms as enabled by progressively more complete language presentation.

In short, teaching one without the other (or in sequence, in any order) is counterproductive.

BTW - you can safely assume that the majority of your students have already coded something. This used to be different some decades ago, but nowadays kids are learning basic coding skills in primary schools. You can easily build on that; teaching algorithms without touching actual programming has no justification.

-- 
Maciej Sobczak * http://www.inspirel.com

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

[Dan'l Miller]

On Monday, July 2, 2018 at 12:56:43 AM UTC-5, Maciej Sobczak wrote:
> > Oh, so the take-away is:
> [...]
> 
> Nothing of what you wrote is a take-away, because I did not write any of this.

And I quote from you below, emphasizing the recommendation to teach •classes•, •namespaces•, and C++ •standard-library* (oh, sorry, •encapsulation• and •templates• too, which a bad C++ instructor would skip or botch too, right?) as the ••enlightened way to bring OP's thinking-in-Ada to novice C++ students••.  Of these, only your unspecified allusion to Pimpl as an idiomatic work-around for lacking Ada's separately-compiled private portions of packages is higher in the food chain of bringing think-in-Ada to C++.  The others are not bringing think-in-Ada to C++ at all; they are merely garden-variety everyday barebones run-of-the-mill embracing of the commonplace party-line mantras in C++.

On Sunday, July 1, 2018 at 3:52:37 PM UTC-5, Maciej Sobczak wrote:
> Ada is strong in directing the user towards a good program structure. Pick this and try to show your
> students ••how to design the program in C++ using the tools that it has•• - •namespaces• and
> •classes•. The notion of packages in Ada do not map 1:1 into •namespaces• and •classes• in C++, but
> the big picture of encapsulation and program decomposition translates well. Show them how the
> physical structure of translation units in C++ can be used to enhance encapsulation [e.g., the PIMPL
> idiom]. Show them how to use •templates•. Use the •standard library• whenever you can.

Then in that paragraph, you switch to the negative, telling OP what not to do, but never positively telling the OP what to actually teach in Ada-think regarding C++'s utilization of or avoidance of pointers, lvalue references, rvalue references, ::std::unique_ptr, ::std::shared_ptr, and/or ::std::weak_ptr.  (Indeed, are only pointers “raw pointers” in your negative scorched earth or are all the others on the list too to be avoided? and where? and how?)  The OP is yearning for:  what portion of accesses and pools and subpools can be brought over from Ada's wise memory management (and the incrementally-formulating-a-proof-by-mathematical-induction rules thereof)? and how?

> Stay away from raw pointers as long as you can (which might as well be forever).

Then the next paragraph is hardly anything other than negatively casting aspersions on Luke & my advice to bring over more sophisticated specific thinking-in-Ada concepts, and what it would take to raise C++ up a bit, a little closer to Ada's level of software-engineering wisdom.  That next paragraph is repeatedly telling OP what /not/ to do, instead of advising which think-in-Ada concepts can be brought over to woo C++ programmers to Ada-think—if not woo over to Ada the language, woo over to the standing-on-the-sholders-of-giants-who-came-before software-engineering wisdoms throughout Ada.  Negativity and embrace-the-pure-tried-&-true-party-line-C++-way was not what OP was requesting.

> Now, I take the risk of being controversial here, but I have enough C++ experience to stand by my words:
> don't bother implementing your own broken version of integer ranges in C++, no matter whether with
> macros or with templates. Just don't.

Overtly declaring the range of integers over which this portion of code operates can be a key portion of eliminating all variants of the overflow/overrun vuln(erabilitie)s that worms utilize as their attack vector to insert machine code.  But never mind SEI software engineering principles, eh?  Obey the party-line mantra of C++ without deviation, eh?  Don't try to evangelize think-in-Ada to a nonAda audience, eh?  Keep all that Ada stuff behind your Ada community's closed doors, eh?

Btw, integer ranges were merely utilized in passing by me as an easy-to-see-at-a-glance example in crawl, walk, run warm-up to meatier topics to bring over from Ada:
1) pool-based memory management, emulating Janus Ada-esque sharing of single copies of generic/template instantiations to avoid bloat,
2) rendezvous idiom for multithreading,
3) C++'s Pimpl idiom to emulate Ada's separate compilation of private portion of packages,
4) emulation of discriminated records,
5) enum class as emulating Ada's strongly-type enumerations,
and so forth, each of which are too big for newsgroup postings.

> If you try to do this, you will teach your students something that
> they will not be able to reuse or translate in the real world, in the real existing code.

Why not?  Is the professor's teaching copyrighted and licensed only under a restrictive license?  Why can't his students go forth and prosper as evangelists of a better way?  Why must C++ be practiced as only, say, the Boost's mailing-list prescribes?  Why should the The One True And Only Way cult be the only C++ culture permitted?  Why should thinking-in-Ada/thinking-in-SEI-software-engineering be a code smell in C++?

> You will be blamed afterwards for the bad teaching

C++ community runs a black list to ostracize heretics disbelieving in The One True And Only Way cult, eh?  Wow, who knew?

> and you will have nothing to defend yourself.

Yeah right, nothing other than an ever-bigger-every-year group of well-trained students who evangelize the better way in code reviews and the mental battle that is corporate or open-source software development.  Which, btw, is the only defense a professor ever has over the years in the end:  whose lives did the teaching transform toward the better?

> Just don't. It is true that some attempts have been made in this direction,

Yeah like the following yet another major contribution of think-in-Ada deep-wisdom worthy of taking to C++, eh?:
> #define begin { 
> #define end } 

If begin-end instead of {} is some of the think-in-Ada deep-wisdom with which to enlighten C++ students with Ada's better way, then perhaps I have drastically overestimated how much Ada's deep-wisdom has disseminated out from the luminaries/_LRM_/_AARM_/_Rationale_s to the tens of thousands of Ada programmers.  Ada wisdom has so much more software-engineering wisdom to teach C++ students than mere surface-level syntax.

> but none got any recognizable acceptance. C++ is not the language for doing ranges

I suppose C++ is not the language for doing interval arithmetic over the real-numbers-with-tolerances either, eh?  I suppose C++ classes cannot represent scalar data types well at all, eh?  I suppose that the people who build out such libraries (even for inclusion into the C++ standard library) are fools (and should be put on that aforementioned black list “with nothing to defend [themselves]” for practicing C++ without the proper license from The One True And Only Way cult), eh?  Here are some libraries for interval-arithmetic over real numbers in C++, utilizing C++ classes (gasp!) for “micromanaging” each number:

https://docs.oracle.com/cd/E19422-01/819-3696/iapgCreference.html
http://www-sop.inria.fr/members/Sylvain.Pion/cxx/interval/interval.pdf

> and I'm not sure whether this is entirely bad - don't confuse them with range-checked arrays,

Yeah right, the upper and lower bounds of an integer constrainment range is strictly forbidden to be utilized when calculating the number of elements in, say, a ::std::vector or ::std::array, eh?  Magic-number numeric-literals are best, eh?  Constants out of left field are almost as good, eh?  The equivalent of 'First and 'Last on a constrained integer range—no, no, that is far too much colocation of concepts so that the programmer doesn't need to looking hither and yon for some named constant, eh?

> which are available in the standard library and are (and should be) used. In the same spirit, don't get
> obsessed too much on defining gazillion of incompatible types for everything, as some Ada books insist
> on.

or that C++'s enum class was added for

or that strong typedefs are yearned as being (analogous to MyType is new Type in Ada):
https://foonathan.net/blog/2016/10/19/strong-typedefs.html

Yeah right, C++ programmers haven't been yearning for Ada's strong typing on those “gazillion of incompatible types”, eh?

> Classes as separate types are good for medium to big design concepts,

and tiny design concepts such as each number or each type alias

> but not for micromanaging integers.

And not for micromanaging 3 categories of complex numbers in the C++ standard and Boost libraries:  complex, quaternions, octonions, eh?
https://www.boost.org/doc/libs/1_34_0/doc/html/boost_math/quaternions.html
https://www.boost.org/doc/libs/1_34_0/doc/html/boost_math/octonions.html

And not micromanaging the aforementioned interval-arithmetic real numbers, eh?

> Don't bother with reimplementing Ada in C++ at this level and you
> will be successful in your teaching.

Yeah right, teaching students to be evangelists of better ideas is a recipe for being a bad teacher, eh?  Teaching novices to be verbatim-copy drones of The One True And Only Way cult is the only way to be successful in teaching, eh?

> You have skipped other important points that I have made.

To be fair, I subjected your other points to additional scrutiny this time around, to dismantle them too.

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

[G.B.]

On 30.06.18 20:04, kouaoua16@gmail.com wrote:
> but in C and C++ to fist year students

Whichever way you decide to go, perpetuating the misconception
of: C and C++ being closely related languages is going to add
effects to programs written in C as well as to programs written
in C++, in that they'll not be written in idiomatic C or idiomatic
C++. Outside of sales talk---if teaching programming does establish
non-commercial foundations for thinking---the phrase "C/C++", i.e.,
"C Slash C Plus Plus" should raise the alarm.

And 'A' is not 65!

-- 
"HOTDOGS ARE NOT BOOKMARKS"
Springfield Elementary teaching staff

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

[Paul Rubin]

Marius Amado-Alves <amado.alves@gmail.com> writes:
> It takes a formidable C++ programmer to write in the least bad C++
> style possible. Like one in a million. Because it is necessary to
> understand the entire language (one in a thousand programmers),

I think today's received wisdom is the opposite of the above.  The
language is made of many layers of accreted crap and it's unnecessary,
even terrible, to try to understand it all.  Rather it's better to just
use a good subset that leaves the crap behind.

> and then be able to pick the least bad idioms all the time (one in a
> thousand of the former thousandth).

No that's not required at all, at least in the sense of expecting the
working programmer to pick the idioms.  It's sufficient to let the gurus
reach a consensus on best practices, then follow those.  I.e. read this
and do what it says:

https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md

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

[Dan'l Miller]

On Monday, July 2, 2018 at 2:57:38 PM UTC-5, G.B. wrote:
> On 30.06.18 20:04, kouaoua16@gmail.com wrote:
> > but in C and C++ to fist year students
> 
> Whichever way you decide to go, perpetuating the misconception
> of: C and C++ being closely related languages is going to add
> effects to programs written in C as well as to programs written
> in C++, in that they'll not be written in idiomatic C or idiomatic
> C++. Outside of sales talk---if teaching programming does establish
> non-commercial foundations for thinking---the phrase "C/C++", i.e.,
> "C Slash C Plus Plus" should raise the alarm.
> 
> And 'A' is not 65!

Another most-excellent reply by G.B. in recent days.  I agree with this 100%.

Perhaps if there is an olive branch of shared communique between Maciej Sobczak's statements and mine in prior replies, it is what G.B. implies above:  teach as little C in C++ as possible—emphasize the nonC portions of C++.  Maciej and I differ seemingly only on the path to travel to arrive at that general destination.

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

[G.B.]

On 02.07.18 19:10, kouaoua16@gmail.com wrote:
> The course is too start with Algorithms first and then end with programming.

Hypothetically, there is no algorithm that isn't a programm.
It's just the programming language that might appear to be
a little vague. So, the above sentence might perhaps be changed
so as to end in "end with making the programs formal".

I once learned a programming language the has 4 instructions.
The lessons got on using just 3 for quite a while. It thus offered
a very clear and simple way of imagining and understanding
the workings of a technical machine that is built to compute functions.
Simple foundations are good for teaching, I'd say. Just think of the
opposite. For V a variable, actually a natural number,

    V <- V + 1  ; increment
    V <- V - 1  ; decrement, saturated at 0
    IF V /= 0 GOTO L   ; L a label

Thus, very little "structure", no composite types, no characters.
And just one output variable, Y, plus input variables.
An exercise or exposition: an algorithm called "copy", from an input
variable to the output variable, is manageable and instructive.
You learn how to program that thing!
Surprisingly, the result will appear similar to C++'s algorithm "copy",
to some extent, which is based on STL iterators thus using a seemingly
much more complex programming language. For sure, the latter is more
general and computes different functions, but the "steps" of the algorithm,
in number and kind have some overlap

I do not think that C can be taught in one half semester.

-- 
"HOTDOGS ARE NOT BOOKMARKS"
Springfield Elementary teaching staff

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

[Maciej Sobczak]

> And I quote from you below [...] Of these, only your unspecified allusion to Pimpl

Actually, I didn't even have this idiom in mind (so again, don't put what I did not say in my mouth). I meant the general concept of having specifications and (possibly partitioned) implementations as separate physical artifacts. These concepts, at this general level, are shared and are common to both Ada and C++.

BTw - Pimpl solves a different problem (physical dependencies) and, interestingly, that problem exists in Ada as well. There is nothing that C++ lacks in this area when compared to Ada.

> Then in that paragraph, you switch to the negative

Because this was not the only reply in this thread. Others already suggested what to do and some of this I disagree with. I have listed traps to avoid.

> but never positively telling the OP what to actually teach

Wrong. Most of my post was a list of what to teach. Stop trolling, it's too cheap.

> The OP is yearning for: what portion of accesses and pools and subpools

He did not mention any of these in his question. That is, you are accusing me of saying things that I did not say, in reply to what OP did not ask about. It's a very poor trolling.

> can be brought over from Ada's wise memory management

The wise part of the memory management in Ada is that most of it need not be explicit. This is what makes Ada and C++ different from, say, Java, as both Ada and C++ are value-oriented instead of being reference-oriented. This is what I meant by saying that pointers can be avoided for a very long time. 

> That next paragraph is repeatedly telling OP what /not/ to do

Right. I stand by what I wrote. He should /not/ do what I have mentioned and I am fully aware that this opinion is not in line with what was already written in other replies.

> Negativity and embrace-the-pure-tried-&-true-party-line-C++-way was not what OP was requesting.

The OP asked what to do in order not to waste his time (did you read his post, actually? if not, do it now). And this is exactly what have I recommended.

> Overtly declaring the range of integers over which this portion of code operates can be a key portion of eliminating all variants of the overflow/overrun vuln(erabilitie)s that worms utilize as their attack vector to insert machine code.

I think you are having communication troubles. I have written: "don't confuse them with range-checked arrays".

> But never mind SEI software engineering principles, eh?

So can you kindly point me to where exactly SEI recommends defining integer range types in C++? They have a whole set of recommendations for C++. Can you point me to the right place, please?

My recommendation to OP was not to waste time. Please don't troll me, I don't want to waste mine, either.

> Here are some libraries for [...]

Yes. There are libraries for just about everything. But in the spirit of not wasting time (again, that's what OP asked for), don't show them all to students in the beginner course. They will find them later if they need them, but there is no reason to obstruct the presentation during the course that is devoted to algorithms (again, see what OP was asking about).

> Yeah right, C++ programmers haven't been yearning for Ada's strong typing on those “gazillion of incompatible types”, eh?

This is what I did some 12 years ago:

https://archive.is/9AmoJ

And I will repeat: Do Not Do This.

Don't troll. Don't put words into others' mouths. Read very carefully what you reply to. Let's keep this group a quality discussion place that it always was.

-- 
Maciej Sobczak * http://www.inspirel.com

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

[Marius Amado-Alves]

"...just use a good subset that leaves the crap behind... let the gurus reach a consensus on best practices, then follow those" (Paul)

You are right, that works in a present day academic setting, which is the topic. Thanks for straighten me up. I apologize for the entropic view from history, and from industry where this would only works as long you have a real guru around (the one in a million programmer), or Stroustrup, Alexandrescu, and Meyers agree, the rest of the team are unspoiled beginners, and there's no legacy code (pre C++11/14), or else plenty of time to refactor.

(Still the bottom line remains that there's nothing to transpose from Ada.)

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

[Brian Drummond]

On Sat, 30 Jun 2018 11:04:29 -0700, kouaoua16 wrote:

> Hello,
> 
> Ada is my programming language of choice. I have used it much in
> scientific programming. At an University I am asked to teach programming
> but in C and C++ to fist year students. After having spent some years
> with Ada, I'm relecutant to "throw away" my good programming habits from
> Ada and embrace C/C++. I would like to know if there exist(s) good
> book(s) at introductory level for C/C++ that may go in the spirit of Ada
> so that I won't feel wasting my time and energy teaching C/C++?
> 
> Also I will start the above course with Algorithms in which I have
> little knowledge. Any suggestions for good books on this topic?
> 
>
In some ways Steve McConnell's "Code Complete" may be a good book to look 
at... While it focusses neither on algorithms nor on teaching one 
specific language, it is strong on good practice for creating readable, 
maintainable programs.

He does have a few nice things to say about Ada - regrettably, usually in 
the past tense.

But much of what he pushes as "good practice" (which is optional in C or 
C++) would be enforced by Ada - many of his "bad" examples simply 
wouldn't get past an Ada compiler - many more than he gives Ada credit 
for.

I also like Luke's idea of teaching Ada and C and C++ in parallel - if 
you have to teach algorithms too, this idea may be supportable; you can 
introduce a safe and highly readable version of the algorithm in "pseudo-
English" like "for i in my_array'range loop ... end loop" before 
describing how it maps onto C and where the pitfalls are (arrays don't 
contain their bounds, the lower bound is always 0 and you have to pass 
the upper bound separately; don't forget it's one less than the length, 
security features, etc etc, - and how it maps differently to C++. Last 
time T looked, that was "don't use arrays, use std::vector instead", but 
that's probably obsolete now.

You don't even have to mention that the "pseudo-English" version will 
compile and run without the landmines...

-- Brian

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

[Dan'l Miller]

On Tuesday, July 3, 2018 at 3:00:27 AM UTC-5, Maciej Sobczak wrote:
> BTw - Pimpl solves a different problem (physical dependencies) and, interestingly, that problem exists in
> Ada as well.

For the interested reader, there is an entire book written on the topic of Pimpl (before it was called Pimpl):
John Lakos's _Large Scale C++ Software Design_ (1995).

> There is nothing that C++ lacks in this area when compared to Ada.

Oh really!  Read Lakos's book then.  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.  852 pages.  Eight hundred fifty-two.  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.

By comparison, in Ada's entire history spanning 5 decades, no one needed to write an analogous 852-page tome on that topic.

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

[Maciej Sobczak]

> > 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). It might even mean that engineers prefer C++ for large-scale systems and that's why they needed a C++-oriented book to address their challenges. No, please don't pick this as an invitation to trolling, I'm only demonstrating a beauty of logic.

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. After all, they use the same compiler.

-- 
Maciej Sobczak * http://www.inspirel.com

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

[Paul Rubin]

Marius Amado-Alves <amado.alves@gmail.com> writes:
> Stroustrup, Alexandrescu, and Meyers agree, the rest of the team are
> unspoiled beginners, and there's no legacy code (pre C++11/14), or
> else plenty of time to refactor.

There is no need to write significant new code in legacy style.
Sometimes you have to understand what legacy code does, and patch it
here and there.  But that doesn't involve much picking of idioms.
Rather, you stay with the style of the existing code.

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

[Dan'l Miller]

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

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

[Maciej Sobczak]

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

The coupling is exactly the same as in Ada, where a change in the *private* part of the package specification forces all clients to be recompiled, even though they are presumably not affected by such modifications. The object model is the same in both Ada and C++, which means that the compiler needs the same kind of knowledge about how types and objects are structured.
There is absolutely no difference between C++ and Ada here.

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

GCC and GCC are exactly the same compiler. Interestingly, bragging about that was a marketing strategy to convince potential customers to try Ada.
Now, Janus Ada and VC++ might be different, but I doubt they substantially differ in how they treat files as the physical source code items. I also guess that reading text files is what Ada and C++ front-ends of GCC do similarly.
Stop trolling.

> ••C++ objects have a phenomenal tendency to get tangled up in each other••.

Ada somehow it was necessary to invent "limited with" for Ada. The motivation for this, as explained in the Ada textbooks, was exactly to deal with the problem of cyclic dependencies.
Stop trolling.

> Ada specifications do not utilize primitive header-file textual inclusion mechanisms.

They do, they are just a little bit smarter in how they do it by forcing names to be declared within packages. This is the added value in Ada, but easy to replicate in C++. In any case, the compile-time coupling is present in both languages and can be seen when some root package spec is updated in a large project.

For other citations, you have failed (or rather did not even attempt) to demonstrate that the given challenges do not appear in Ada and so you did not convince me.

> Lakos's physical design is omitted by nearly all C++ coursework

Sure. The physical design challenges become relevant in codebases that span millions of lines of code. Typical students do not produce that much during their homeworks in a one-semester courses and there are more important things to teach that they will need earlier.

BTW - my favorite argument in such discussions is that by writing your posts you are relying on multiple large-scale C++ software systems working properly. Feel free to keep ignoring it.

-- 
Maciej Sobczak * http://www.inspirel.com

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

[Marius Amado-Alves]

"Ada specifications do not utilize primitive header-file textual inclusion mechanisms." (Miller)

"They do, they are just a little bit smarter in how they do it by forcing names to be declared within packages." (Sobczak)

I very much doubt Ada does mere textual inclusion, and this is a world of difference between the languages. Ada has *semantical* devices for programming in the large. Last time I looked C and C++ dont. Other issues provoked by mere textual inclusion include polluting *every* unit with

#ifndef X
#define X

...

#endif

This "feature" alone makes any programmer of good taste refuse the language.

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

[Dan'l Miller]

On Monday, July 2, 2018 at 8:52:59 AM UTC-5, Marius Amado-Alves wrote:
> Thanks for the "Accelerated" book recommendation, I'll check. My learned colleages recommend the "42
> ways".

I also recommend all of Scott Meyers's books _42 ways_ and the older _50 ways_, and _35 ways_.  I just read “/x-many/ ways to improve your C++ programs” as ‘’/x-many/ nightmares in C++ to eliminate’.  Who wouldn't want nightmares eliminated right?

Programming in C++ versus Ada is all about ‘eliminating nightmares’ (C++) versus ‘curing diseases’ (Ada).  Who wouldn't want their nightmares eliminated by walking the •prescribed• narrow path (C++)?  Who wouldn't want their diseases cured by •proscribing• bad lifestyle (Ada)?

The programming-Zeitgeist always said for decades that Ada was too big and too complex of a language.  C++ needs 42+50+35=125 ways to eliminate C++'s nightmares.  Wouldn't the more prudent and preferable design be to have a language (Ada) with, say, 125 more course-corrections built into the language as a-priori •proscriptions• rather than needing 125 course-corrections to be taught to human beings as a-posteriori •prescriptions•.  (Even more than 125 when you count Lakos and all the other similar books by other authors.)

C++ is like a pill-pushing medical physician:  got an ailment by living badly?  I can •prescribe• a pill for that (after the fact, after you make big mistakes).

Ada is like a holistic natural-medicine nutritionist:  I •proscribe• all the living badly:  lack of exercise, smoking, excessing eating, eating the wrong food (before the fact, keeping you healthy from Day One).

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

[Olivier Henley]

You said it is for first year class so probably not an advanced C++ class.

A tour of C++ by Bjarne Stroustrup, the creator of C++ himself.

IIRC, it has been written in part to emphasize the 'better language' that wants to emerge from C++ (probably starting with C++11 features and above)


NOTE: Better take the offer and promulgate Ada here and there during the semester than leaving those students ignorant. An experimental cinema university teacher of mine once told us:"I do not plan to make experimental cinema aficionado out of you, I only plan to seed the virus."

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

[Maciej Sobczak]

> "They do, they are just a little bit smarter in how they do it by forcing names to be declared within packages." (Sobczak)
> 
> I very much doubt Ada does mere textual inclusion,

It does not do *mere* inclusion in the sense of blindly concatenating bytes, but it does textual read (and processing) of all involved files, which at the end is no different from the point of view of managing large codebases.

> Ada has *semantical* devices for programming in the large.

Let's try these "semantical" devices in practice:

-- p.ads:
package P is
   pragma Pure (P);
end P;

-- q.ads:
with P;
package Q is
   procedure Hello;
end Q;

-- q.adb:
with Ada.Text_IO;
package body Q is
   procedure Hello is
   begin
      Ada.Text_IO.Put_Line ("Hello");
   end Hello;
end Q;

-- test.adb:
with Q;
procedure Test is
begin
   Q.Hello;
end Test;

In this large-scale project the package P has no semantic meaning whatsoever. It does not declare anything and no other package refers to any declarations defined in there (because there are none anyway). The only dependency on this package is in package spec Q, which withs it, for no reason whatsoever. It might be a left-over from some refactoring, perhaps? We don't know, but clearly, the main procedure Test has no relation to P and in particular, the author of Test has never intended to depend on P for any reason.

Yet, the trivial update of P (like adding whitespace, which again has no semantic meaning whatsoever) forces the recompilation of Test (with GNAT). Actually, it forces the recompilation of everything. Why?

There go your "semantic" devices for programming in the large. Sorry, but even though I do understand the intent, I don't see it in practice. As far as I'm concerned, the Ada handling of text files in response to "with" is exactly as primitive as the C++ handling of #include, except for the lack of explicit concatenation (which, by the way, C++ compilers don't do, either - see "precompiled headers"). But the impact on compilation dependencies is exactly the same. In this context both Ada and C++ are shitty in exactly the same way.

> Other issues provoked by mere textual inclusion include polluting *every* unit with
> 
> #ifndef X
> #define X
> 
> ...
> 
> #endif
> 
> This "feature" alone makes any programmer of good taste refuse the language.

Except that nobody cares. This became so idiomatic that every IDE I know of generates these guards automatically. This allows to focus the good taste on other aspects of software engineering.

-- 
Maciej Sobczak * http://www.inspirel.com

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

[Simon Wright]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> Yet, the trivial update of P (like adding whitespace, which again has
> no semantic meaning whatsoever) forces the recompilation of Test (with
> GNAT). Actually, it forces the recompilation of everything. Why?

gprbuild:
  -m       Minimum Ada recompilation

Only rebuild if there's a semantic difference

Of course, the relevant specs need to be parsed for this to work.

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

[kouaoua16]

On Wednesday, July 4, 2018 at 4:18:25 PM UTC+4, Olivier Henley wrote:
> You said it is for first year class so probably not an advanced C++ class.
> 
> A tour of C++ by Bjarne Stroustrup, the creator of C++ himself.
> 

I was thinking of this book:

C++ Primer Plus (6th Edition) by Stephen Prata

https://www.amazon.com/Primer-Plus-6th-Developers-Library/dp/0321776402

which seem more accessible to beginners.

And thank you all for book suggestions and the interesting discussions. At the same time let's not start a fight between Ada and C++. I agree that long time ago C++ was just a superset of C but over time C++ has diverged from C.

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

[Maciej Sobczak]

> > Yet, the trivial update of P (like adding whitespace, which again has
> > no semantic meaning whatsoever) forces the recompilation of Test (with
> > GNAT). Actually, it forces the recompilation of everything. Why?
> 
> gprbuild:
>   -m       Minimum Ada recompilation
> 
> Only rebuild if there's a semantic difference

Great! Let's try it out.
I have added a dummy declaration to P, like here:

-- p.ads:
package P is
   pragma Pure (P);
   type TI is new Integer;  -- new dummy definition
end P;

and... the whole project was recompiled from scratch.

No other part of the project relies on this new type and in particular, the author of Test still could not care less about package P and whatever it contains.
Yet, the author of Test had to wait for the whole project to recompile, because something irrelevant was added to some irrelevant package that he might not even know that exists in the project.

I presume that the -m switch was supposed to handle a trivial (and perhaps frequent) case of editing comments and whitespace. There is some added value in this, but it is easy to replicate for C++ and sorry, but I don't call it "semantic" if it cannot figure out even the most basic cases like the one above.

My claim that Ada and C++ compilers have the same challenges when it comes to handling the physical project structure holds.

-- 
Maciej Sobczak * http://www.inspirel.com

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

[Dmitry A. Kazakov]

On 2018-07-04 16:56, 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, like DEC Ada had. Your 
examples are related to GNAT, which intentionally uses no such library 
and deploys plain files instead. C++ on its part could not have a 
library. Precompiled headers is no substitute, even if they worked.

P.S. I agree that Ada has issues with separation of implementation and 
interfaces but these are minor comparing to C++.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Simon Wright]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

>> > Yet, the trivial update of P (like adding whitespace, which again has
>> > no semantic meaning whatsoever) forces the recompilation of Test (with
>> > GNAT). Actually, it forces the recompilation of everything. Why?
>> 
>> gprbuild:
>>   -m       Minimum Ada recompilation
>> 
>> Only rebuild if there's a semantic difference
>
> Great! Let's try it out.
> I have added a dummy declaration to P, like here:
>
> -- p.ads:
> package P is
>    pragma Pure (P);
>    type TI is new Integer;  -- new dummy definition
> end P;
>
> and... the whole project was recompiled from scratch.
>
> No other part of the project relies on this new type and in
> particular, the author of Test still could not care less about package
> P and whatever it contains.
> Yet, the author of Test had to wait for the whole project to
> recompile, because something irrelevant was added to some irrelevant
> package that he might not even know that exists in the project.
>
> I presume that the -m switch was supposed to handle a trivial (and
> perhaps frequent) case of editing comments and whitespace. There is
> some added value in this, but it is easy to replicate for C++ and
> sorry, but I don't call it "semantic" if it cannot figure out even the
> most basic cases like the one above.

I think we'll have to agree to differ on what "semantic" means, then.

> My claim that Ada and C++ compilers have the same challenges when it
> comes to handling the physical project structure holds.

Indeed.

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

[Alejandro R. Mosteo]

On 04/07/2018 17:52, Dmitry A. Kazakov wrote:
> On 2018-07-04 16:56, 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, like DEC Ada had. Your 

Ah, I seem to remember that the Meridian Ada compiler in my first year at 
university also had something like that.

> examples are related to GNAT, which intentionally uses no such library 
> and deploys plain files instead. C++ on its part could not have a 
> library. Precompiled headers is no substitute, even if they worked.
> 
> P.S. I agree that Ada has issues with separation of implementation and 
> interfaces but these are minor comparing to C++.

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

[G. B.]

Maciej Sobczak <see.my.homepage@gmail.com> wrote:

>> gprbuild:
>> -m       Minimum Ada recompilation
>> 
>> Only rebuild if there's a semantic difference
> 
> Great! Let's try it out.
> I have added a dummy declaration to P, like here:
> 
> -- p.ads:
> package P is
>    pragma Pure (P);
>    type TI is new Integer;  -- new dummy definition
> end P;
> 
> and... the whole project was recompiled from scratch.
> 

From the Ada perspective a potentially use-visible identifier is
introduced.

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

[Dan'l Miller]

On Wednesday, July 4, 2018 at 9:56:46 AM UTC-5, Maciej Sobczak wrote:
> > > Yet, the trivial update of P (like adding whitespace, which again has
> > > no semantic meaning whatsoever) forces the recompilation of Test (with
> > > GNAT). Actually, it forces the recompilation of everything. Why?
> > 
> > gprbuild:
> >   -m       Minimum Ada recompilation
> > 
> > Only rebuild if there's a semantic difference
> 
> Great! Let's try it out.
> I have added a dummy declaration to P, like here:
> 
> -- p.ads:
> package P is
>    pragma Pure (P);
>    type TI is new Integer;  -- new dummy definition
> end P;
> 
> and... the whole project was recompiled from scratch.
> 
> No other part of the project relies on this new type and in particular, the author of Test still could not care less about package P and whatever it contains.
> Yet, the author of Test had to wait for the whole project to recompile, because something irrelevant was added to some irrelevant package that he might not even know that exists in the project.
> 
> I presume that the -m switch was supposed to handle a trivial (and perhaps frequent) case of editing comments and whitespace. There is some added value in this, but it is easy to replicate for C++ and sorry, but I don't call it "semantic" if it cannot figure out even the most basic cases like the one above.
> 
> My claim that Ada and C++ compilers have the same challenges when it comes to handling the physical project structure holds.

Maciej, btw, which precise version of GNAT are you utilizing?

GNAT in 2018 (or whichever recent year is your release) is defective compared to the Rational R1000 in the late 1980s.  

http://www.dtic.mil/dtic/tr/fulltext/u2/a198934.pdf

§2.1.2.1. Basis for Effective Smart Processing, page 12:
“The Rational Environment is able to provide smart processing because it maintains Ada programs as logical units, storing them in the Diana representation. This permits the Rational Environment to track user modifications to the program at the granularity of program units and •smaller units• (i.e., •••individual declarations and statements•••). The Diana representation not only reflects the abstract syntax of Ada programs (from which textual representations can be regenerated), but also contains semantic information. Semantic information includes type information and depend- ency information. Dependency information not only reflects export/import dependencies due to Ada with clauses, but actual usage sites (e.g., all procedure call sites). These actual usage sites are maintained within program units as well as across program units at the level of individual declarations.

Ҧ On one hand, the Rational Environment makes this semantic information available to the user through queries. On the other hand, the Rational Environment takes advantage of this infor- mation to perform "smart reprocessing," i.e., keeping the reprocessing due to a change at a minimum. It maintains semantic information in the Diana representation consistently by demoting dependent program units when a declaring unit is demoted to allow modification. Note that demotion to source state results in removing the demoted unit from semantic information in the Diana representation, i.e., units in source state will not be found when queries are run on seman- tic information such as finding usage sites.

Ҧ Conventional Ada environments require reprocessing of dependent program units any time any
change is made to a program unit specification. The Rational Environment takes advantage of
the Diana structure to permit certain modifications without invalidating dependent program units.
These include modification of comments, ••addition of declaration to package specifications••, etc.
(see Section 2.1.1.2). As a result, fewer recompilations are required than in conventional Ada environments.”

I see your sloppy GNAT and raise you one well-disciplined(-by-William-Wulf) Rational R1000.  Maciej, please provide any C++ compilation system from any point in human history which a normative reference claims to have this rebuild-avoidance feature at the level of “individual declarations and statements”.

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

[Jeffrey R. Carter]

On 07/04/2018 06:24 PM, Alejandro R. Mosteo wrote:
> On 04/07/2018 17:52, Dmitry A. Kazakov wrote:
>>
>> Yet Ada allows having a library of packages, like DEC Ada had. Your 
> 
> Ah, I seem to remember that the Meridian Ada compiler in my first year at 
> university also had something like that.

Ada 83 required it.

-- 
Jeff Carter
"When and now is this guitar piece from Stottlemeyer?
Yes, it's with Mr. Dog in Gertrude's pinball forest."
The World's Funniest Joke
133

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

[Maciej Sobczak]

> > 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 
> examples are related to GNAT

Which happens to be The Ada Compiler that potential users are going to use.

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

> P.S. I agree that Ada has issues with separation of implementation and 
> interfaces but these are minor comparing to C++.

And yet, after so many posts were written in this discussion, I still do not see any convincing example of why Ada is sooooo much better in this regard. On the other hand, I have presented examples showing that C++ problems exist in Ada, too.

-- 
Maciej Sobczak * http://www.inspirel.com

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

[Maciej Sobczak]

> From the Ada perspective a potentially use-visible identifier is
> introduced.

From the Ada perspective that same identifier is not visible at all to the Test unit, because there is no "with P" there. There is no reason whatsoever to recompile that unit and the fact that it is recompiled makes the whole system operationally equivalent to the dumb text inclusion in C++.

-- 
Maciej Sobczak * http://www.inspirel.com

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

[Maciej Sobczak]

> GNAT in 2018 (or whichever recent year is your release) is defective compared to the Rational R1000 in the late 1980s.

Which makes your whole argument completely hypothetical and useless, as we are in late 2010s instead.
It's not only the availability of products - it is also the expectation to support some set of available language features. From the Ada side, anything less than Ada 2012 will not be considered by potential users, unless they are already drowning in some archaic codebase, in which case they are chained to some compiler anyway. No matter who you talk to, recommending R1000 is a waste of time.

> Maciej, please provide any C++ compilation system from any point in human history

I'm not interested in such points from the human history. We have 2018 now and the OP was asked to run a C++ course at the university. This context quite precisely defines the toolset he is able to use.

I'm glad that we have, in practice, exhausted this discussion.

-- 
Maciej Sobczak * http://www.inspirel.com

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

[G.B.]

On 04.07.18 22:18, Maciej Sobczak wrote:
>>  From the Ada perspective a potentially use-visible identifier is
>> introduced.
> 
>  From the Ada perspective that same identifier is not visible at all to the Test unit, because there is no "with P" there. 
I was wondering how that semantic smartness could work at all.
The docs of `-m' mention comments and reformatting only.
They warn us of potentially misleading line numbers caused
by ignoring layout changes. Anyway, the resulting program must
change as another type declaration is added to package P.

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

[Dmitry A. Kazakov]

On 2018-07-04 22:13, 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.

Why should it? The language should merely offer a possibility to 
implement and maintain such a library in a reasonable and effective way. 
On top of that you can define "modified" a more intelligent than stupid 
"newer timestamp".

> And ironically, for a large-scale system, I would not trust anything else than a dumb set of files.

Huh, did you checked your file system recently? It is likely that a dumb 
set files sits on top something with caching, mirroring, journaling, 
transactions, versioning etc. You trust them but do not a library of 
precompiled units?

>> Your examples are related to GNAT
> 
> Which happens to be The Ada Compiler that potential users are going to use.
> 
>> 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.

For multiple decades people failed to make precompiled headers working, 
many many people. If AdaCode had so much time and so many caffeinated 
workers, just 1% of those, then GNAT would have a library and everything 
else!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Dan'l Miller]

On Wednesday, July 4, 2018 at 3:36:45 PM UTC-5, Maciej Sobczak wrote:
> > GNAT in 2018 (or whichever recent year is your release) is defective compared to the Rational R1000 in the late 1980s.
> 
> Which makes your whole argument completely hypothetical and useless, as we are in late 2010s instead.
> It's not only the availability of products - it is also the expectation to support some set of available language features. From the Ada side, anything less than Ada 2012 will not be considered by potential users, unless they are already drowning in some archaic codebase, in which case they are chained to some compiler anyway. No matter who you talk to, recommending R1000 is a waste of time.
> 
> > Maciej, please provide any C++ compilation system from any point in human history
> 
> I'm not interested in such points from the human history. We have 2018 now and the OP was asked to run a C++ course at the university. This context quite precisely defines the toolset he is able to use.
> 
> I'm glad that we have, in practice, exhausted this discussion.

As soon as the play-by-play sports-announcer yells, “scorrrrrrRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRrrr.” for Ada's goal, Maciej declares the game over and takes his soccer ball home, refusing to recognize the point.

Btw, C++ as currently defined •cannot ever• score that point, whereas Ada can bring back R1000 at any time—all we need is $6 million.  “Gentlemen, we can rebuild him; we have the technology.”  The world's 2nd bionic Ada development environment.
https://youtu.be/bGO57y4td-c?t=30

I reiterate:  Maciej, btw, which precise version of GNAT are you utilizing?

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

[Luke A. Guest]

Dan'l Miller <optikos@verizon.net> wrote:

> Btw, C++ as currently defined "cannot ever" score that point, whereas Ada
> can bring back R1000 at any time\x14all we need is $6 million.  \x1cGentlemen,
> we can rebuild him; we have the technology.\x1d  The world's 2nd bionic Ada
> development environment.
> https://youtu.be/bGO57y4td-c?t0

I’m with Maciej in this one, I don’t get the fascination with all this
ancient Ada stuff, R1000, DIANA, DB storage, program library, etc.

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

[Dan'l Miller]

On Wednesday, July 4, 2018 at 9:01:43 PM UTC-5, Luke A. Guest wrote:
> Dan'l Miller wrote:
> 
> > Btw, C++ as currently defined "cannot ever" score that point, whereas Ada
> > can bring back R1000 at any time all we need is $6 million.   Gentlemen,
> > we can rebuild him; we have the technology.   The world's 2nd bionic Ada
> > development environment.
> > https://youtu.be/bGO57y4td-c?t0
> 
> I’m with Maciej in this one, I don’t get the fascination with all this
> ancient Ada stuff, R1000, DIANA, DB storage, program library, etc.

Gee, _The Six Million Dollar Man_ prologue means nothing to you in Great Britain?  Sheesh.  (Apparently you weren't 6 years old in 1974ish.)

Okay, for ye of little faith, how about something higher-brow instead:
“Progress, far from consisting in change, depends on •retentiveness•.
When change is absolute there remains no being to improve and no direction is set for possible improvement:
and when experience is not retained, as among savages, infancy is perpetual.
••Those who cannot remember the past are condemned to repeat [C++'s mistakes]••.”
—George Santayana (1906) _The Life of Reason: The Phases of Human Progress: Volume 1: Reason in Common Sense_

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

[Maciej Sobczak]

> > 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.
> 
> Why should it?

Because AARM does not put any requirements on it.
And because C++ does not put any restrictions on how how this is done on the C++ side, we are again at level ground. That is, this hypothetical possibility that you described (and that no vendor cared to reap during the last 30 years) does not make Ada any better language than C++ (in this particular regard).

> The language should merely offer a possibility to 
> implement and maintain such a library in a reasonable and effective way.

Both Ada and C++ do. Both languages equally fail to deliver on this point.

> > And ironically, for a large-scale system, I would not trust anything else than a dumb set of files.
> 
> Huh, did you checked your file system recently?

It's not about storage, it's about modularity of the tool set. Compiling is not the only thing I want to do to with the source code. I need reliable configuration management, too, and most often than not, it is imposed on me independently on the language. Like, say, I'm told to use Git. It does not matter whether I like Git or not, but what does matter to me is whether I can use it seamlessly. I need to run an independent static analysis tool, too, and if my source lives in some nebulous "library" and needs to be regenerated only so that I can run SA on it, then not only this is a burden, but also raises tool qualification issues in the rigorous environment of safety critical processes. I also need a UML tool to reverse-engineer the model, a code generation scripts for some selected parts of the code, and so on, you can extend this story indefinitely.
All this is possible only when the tools are based on the same common denominator, which is a set of dumb files. The dumber, the better.

I have worked with a library-based tool some years ago, it was called PowerBuilder. I still have nightmares.

> For multiple decades people failed to make precompiled headers working,

And after so many decades of language development the leading Ada compiler fails to deliver on the "semantic" promises in the area of managing large (4 short files, actually...) codebase.

> If AdaCode had so much time and so many caffeinated 
> workers, just 1% of those, then GNAT would have a library and everything 
> else!

Perhaps. But it didn't and it doesn't. And today, when I'm trying to convince people to use Ada, I will refer to many other arguments, but not the one that Ada will be a silver bullet for solving their large-scale physical design issues. Such arguments fail even the basic, superficial scrutiny.

-- 
Maciej Sobczak * http://www.inspirel.com

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

[Maciej Sobczak]

> > I'm glad that we have, in practice, exhausted this discussion.
> 
> As soon as the play-by-play sports-announcer yells, “scorrrrrrRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRrrr.” for Ada's goal, Maciej declares the game over and takes his soccer ball home, refusing to recognize the point.

Sigh...

> Btw, C++ as currently defined •cannot ever• score that point, whereas Ada can bring back R1000 at any time—all we need is $6 million.

Does this price cover the development of all remaining Ada95, Ada2005 and Ada2012 language features?
Is this your final recommendation to the OP, who needs to run a C++ course at the university?

> I reiterate:  Maciej, btw, which precise version of GNAT are you utilizing?

7.3.0

Do you think that some other GNAT version implements all the hypothetical features that will ultimately solve all 852 pages of problems that only C++ has?

By saying that we have exhausted the discussion I do not mean that I "refuse to recognize the point". I mean that after so many posts you have failed to make any.

-- 
Maciej Sobczak * http://www.inspirel.com

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

[Dmitry A. Kazakov]

On 2018-07-05 07:49, Maciej Sobczak wrote:
>>> 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.
>>
>> Why should it?
> 
> Because AARM does not put any requirements on it.

It defines compilation units and their relationships, which quite enough.

>> The language should merely offer a possibility to
>> implement and maintain such a library in a reasonable and effective way.
> 
> Both Ada and C++ do. Both languages equally fail to deliver on this point.

I don't see how it could be accomplished in any reasonable way with 
header files and preprocessor.

>>> And ironically, for a large-scale system, I would not trust anything else than a dumb set of files.
>>
>> Huh, did you checked your file system recently?
> 
> It's not about storage, it's about modularity of the tool set. Compiling is not the only thing I want to do to with the source code. I need reliable configuration management, too, and most often than not, it is imposed on me independently on the language. Like, say, I'm told to use Git. It does not matter whether I like Git or not, but what does matter to me is whether I can use it seamlessly. I need to run an independent static analysis tool, too, and if my source lives in some nebulous "library" and needs to be regenerated only so that I can run SA on it, then not only this is a burden, but also raises tool qualification issues in the rigorous environment of safety critical processes. I also need a UML tool to reverse-engineer the model, a code generation scripts for some selected parts of the code, and so on, you can extend this story indefinitely.

You describe exactly the scenario how not to do a tool chain.

> All this is possible only when the tools are based on the same common denominator, which is a set of dumb files. The dumber, the better.

Yes. But the correct sentence is: this mess is economically viable 
because of other mess. Tools feed on design errors, it is an illness.

> And after so many decades of language development the leading Ada compiler fails to deliver on the "semantic" promises in the area of managing large (4 short files, actually...) codebase.

Pretty much impressing considering AdaCore's size.

>> If AdaCode had so much time and so many caffeinated
>> workers, just 1% of those, then GNAT would have a library and everything
>> else!
> 
> Perhaps. But it didn't and it doesn't. And today, when I'm trying to convince people to use Ada, I will refer to many other arguments, but not the one that Ada will be a silver bullet for solving their large-scale physical design issues. Such arguments fail even the basic, superficial scrutiny.

Sure, there is no alternative history. But the argument is good enough 
to counter equally fallacious - why GNAT does not do this or that.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Alejandro R. Mosteo]

On 05/07/2018 07:49, Maciej Sobczak wrote:
>>> 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.
>>
>> Why should it?
> 
> Because AARM does not put any requirements on it.
> And because C++ does not put any restrictions on how how this is done on the C++ side, we are again at level ground. That is, this hypothetical possibility that you described (and that no vendor cared to reap during the last 30 years) does not make Ada any better language than C++ (in this particular regard).
> 
>> The language should merely offer a possibility to
>> implement and maintain such a library in a reasonable and effective way.
> 
> Both Ada and C++ do. Both languages equally fail to deliver on this point.
> 
>>> And ironically, for a large-scale system, I would not trust anything else than a dumb set of files.
>>
>> Huh, did you checked your file system recently?
> 
> It's not about storage, it's about modularity of the tool set. Compiling is not the only thing I want to do to with the source code. I need reliable configuration management, too, and most often than not, it is imposed on me independently on the language. Like, say, I'm told to use Git. It does not matter whether I like Git or not, but what does matter to me is whether I can use it seamlessly. I need to run an independent static analysis tool, too, and if my source lives in some nebulous "library" and needs to be regenerated only so that I can run SA on it, then not only this is a burden, but also raises tool qualification issues in the rigorous environment of safety critical processes. I also need a UML tool to reverse-engineer the model, a code generation scripts for some selected parts of the code, and so on, you can extend this story indefinitely.
> All this is possible only when the tools are based on the same common denominator, which is a set of dumb files. The dumber, the better.
> 
> I have worked with a library-based tool some years ago, it was called PowerBuilder. I still have nightmares.

At a former job they had the rule of "regenerate three times" whenever PB 
crashed mysteriously.

Álex.

> 
>> For multiple decades people failed to make precompiled headers working,
> 
> And after so many decades of language development the leading Ada compiler fails to deliver on the "semantic" promises in the area of managing large (4 short files, actually...) codebase.
> 
>> If AdaCode had so much time and so many caffeinated
>> workers, just 1% of those, then GNAT would have a library and everything
>> else!
> 
> Perhaps. But it didn't and it doesn't. And today, when I'm trying to convince people to use Ada, I will refer to many other arguments, but not the one that Ada will be a silver bullet for solving their large-scale physical design issues. Such arguments fail even the basic, superficial scrutiny.
> 

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

[Maciej Sobczak]

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

You might argue that it is not possible to do for C++ and I will disagree. You can point to the small size of AdaCore as a reason for why this is not done in GNAT, but this argument also loses its strenght if you think about Goliaths like Apple, Microsoft or Oracle, which also develop compilers. Do they do this kind of stuff, having essentially unlimited resources? If not, then why do you think that AdaCore would do that for Ada, even if they had the money to spend?

My guess is that nobody actually needs it.

> You describe exactly the scenario how not to do a tool chain.

I disagree. I want dumb text files.

> Yes. But the correct sentence is: this mess is economically viable 
> because of other mess. Tools feed on design errors, it is an illness.

In the ideal (?) world where you have only one company producing all the tools, perhaps the idea of "library" would be viable. But I want open interfaces and a dumb text file happens to be a pretty good one.
Notice that even in the Ada world the ASIS, which might be a good foundation for semantic-oriented tools, seems to be falling out of fashion. This shows that such constructs cannot be treated as a basis for very long-term projects and large-scale systems are usually long-term as well. That's why I prefer dumb text files as a stable format that can outlive not only fashions, but also vendors themselves. Today, R1000 is a history, but dumb text files are still kicking. This is the kind of format stability that we need in large-scale, long-term projects.

> Sure, there is no alternative history. But the argument is good enough 
> to counter equally fallacious - why GNAT does not do this or that.

But it is still only hypothetical. Whereas the problems that *both* C++ and Ada share in the space of physical code management with actual compilers that are available on the market, are real.

-- 
Maciej Sobczak * http://www.inspirel.com

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

[Dmitry A. Kazakov]

On 2018-07-05 15:14, Maciej Sobczak wrote:

>> Yes. But the correct sentence is: this mess is economically viable
>> because of other mess. Tools feed on design errors, it is an illness.
> 
> In the ideal (?) world where you have only one company producing all the tools, perhaps the idea of "library" would be viable. But I want open interfaces and a dumb text file happens to be a pretty good one.

I don't want any tools beyond the compiler, IDE and source/project 
management. Each new tool multiplies complexity and fragility.

> Notice that even in the Ada world the ASIS, which might be a good foundation for semantic-oriented tools, seems to be falling out of fashion. This shows that such constructs cannot be treated as a basis for very long-term projects and large-scale systems are usually long-term as well. That's why I prefer dumb text files as a stable format that can outlive not only fashions, but also vendors themselves. Today, R1000 is a history, but dumb text files are still kicking. This is the kind of format stability that we need in large-scale, long-term projects.

Problems remain independent on whether you keep everything as a bunch of 
assorted files. Having files makes things only more difficult. Did you 
ever tried to browse a samba share folder with 20K+ files in it?

Clearly source/project management must be integrated with IDE. There is 
absolutely no doubt about it. Then a reasonably designed source control 
system is an ideal place to keep the Ada library in.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Dan'l Miller]

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

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

[Randy Brukardt]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:559657f8-bbf4-4a70-9449-f85bc98d6c6b@googlegroups.com...
...
>Yet, the trivial update of P (like adding whitespace, which again has no
>semantic meaning whatsoever) forces the recompilation of Test (with
>GNAT). Actually, it forces the recompilation of everything. Why?
>
>There go your "semantic" devices for programming in the large. Sorry,
>but even though I do understand the intent, I don't see it in practice.

You need to use a "better" Ada compiler. GNAT /= Ada!!! In particular, the 
Rational environment from back in the day used incremental compilation 
techniques such that a modification to P would only cause recompilation of 
entities that actually depended on declarations in P. So your example of a 
whitespace change would cause no recompilation at all (even of P).

One could make an argument that the "market" finds this entire issue 
irrelevant, since it seems to gravitate to C++ and Ada compilers like GNAT 
rather than ones like Rational. (For Janus/Ada, recompilation is fast enough 
that there's little value to trying to avoid recompilation in such cases --  
it would be more work than it would gain time. Perhaps it would matter more 
in multi-million line codebases, but we don't have any such customers.)

                                                          Randy.

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

[Randy Brukardt]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:phj901$3a0$1@dont-email.me...
> On 07/04/2018 06:24 PM, Alejandro R. Mosteo wrote:
>> On 04/07/2018 17:52, Dmitry A. Kazakov wrote:
>>>
>>> Yet Ada allows having a library of packages, like DEC Ada had. Your
>>
>> Ah, I seem to remember that the Meridian Ada compiler in my first year at 
>> university also had something like that.
>
> Ada 83 required it.

Not really, it's more accurate to say that no one had tried to figure out an 
alternative with the needed semantics. That didn't happen until the GNAT 
people invented source-based translation for Ada (since copied by some other 
compilers).

In any case, Janus/Ada uses a "library", really mostly a set of already 
compiled files. (It imports already-compiled symboltables, it doesn't try to 
recreate them each time. This is complex enough that it doesn't provide any 
significant advantage over the source-based alternative.)

                                     Randy.

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

[Randy Brukardt]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:8de6b5ba-25ab-4d46-b80c-1544f43a9b05@googlegroups.com...
...
>> Your examples are related to GNAT
>
>Which happens to be The Ada Compiler that potential users are going to use.

A compiler that was purposely designed to be as much like C++ as possible, 
thus including all of it's problems as well. GNAT doesn't even try to take 
advantage of many Ada capabilities, because it is so closely tied too GCC.

If you're comparing *languages* rather than *implementations*, the results 
would be rather different.

...
>And yet, after so many posts were written in this discussion, I still do 
>not
>see any convincing example of why Ada is sooooo much better in this
>regard. On the other hand, I have presented examples showing that
>C++ problems exist in Ada, too.

Mainly because you're focused on a issue that is OBE. "Compile-time 
coupling" mattered a lot when compilations took five minutes per unit; 
recompilation of an entire system literally took days. Nowdays, when 
compilation only takes a couple of seconds for most units, recompiling an 
entire system takes 10-15 minutes. Since good health requires walking away 
from your desk periodically, a language that didn't require this sometimes 
would be bad for the health of it's practitioners. ;-)

                                               Randy.

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

[Randy Brukardt]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:c91c4183-a8fe-4b7a-858e-616728fbe844@googlegroups.com...
...
>That is, this hypothetical possibility that you described (and that no
>vendor cared to reap during the last 30 years) does not make Ada
>any better language than C++ (in this particular regard).

This statement is completely False: the Rational environment did take 
advantage of these possibilities decades ago. (I presume the version 
available from PTC still does.) As recently discussed here, people who used 
that development environment tended to be very happy; perhaps this was one 
of the factors?

In any case, semantic coupling is many times more important than 
compile-time coupling, since it causes actual maintenance problems. Perhaps 
focusing on that would make the differences more apparent???

                                              Randy.

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

[Dan'l Miller]

On Thursday, July 5, 2018 at 1:53:31 PM UTC-5, Randy Brukardt wrote:
> "Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
> news:c91c4183-a8fe-4b7a-858e-616728fbe844@googlegroups.com...
> ...
> >That is, this hypothetical possibility that you described (and that no
> >vendor cared to reap during the last 30 years) does not make Ada
> >any better language than C++ (in this particular regard).
> 
> This statement is completely False: the Rational environment did take 
> advantage of these possibilities decades ago. (I presume the version 
> available from PTC still does.) As recently discussed here, people who used 
> that development environment tended to be very happy; perhaps this was one 
> of the factors?
> 
> In any case, semantic coupling is many times more important than 
> compile-time coupling, since it causes actual maintenance problems. Perhaps 
> focusing on that would make the differences more apparent???

What would semantic coupling that lacks a syntactic* representation look like in Ada [with at least a smidgeon of wise & good, I hope]—or in C++ for that matter [worse, I suspect])?

* and thus doesn't appear in compile-time coupling, which is what we have discussed so far

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

[Randy Brukardt]

> On 2018-07-05 07:49, Maciej Sobczak wrote:
> It's not about storage, it's about modularity of the tool set. Compiling 
> is not the only thing I want to do to with the source code. I need 
> reliable configuration management, too, and most often than not, it is 
> imposed on me independently on the language. Like, say, I'm told to use 
> Git. It does not matter whether I like Git or not, but what does matter to
>me is whether I can use it seamlessly. I need to run an independent static
>analysis tool, too, and if my source lives in some nebulous "library" and 
>needs to be regenerated only ...

You're seriously confused as to how a "library" works in Ada. It has 
*nothing* to do with source code.

Take Janus/Ada, for example. The source code lives wherever the programmer 
wants it, it's not in the library (unless the programmer is sloppy and uses 
the same direectory for both). It is given to the compiler, and it converts 
it to code and an Ada symboltable. The compiler *never* uses the source 
again; it only cares about one source file at a time and *never* uses it 
after the initial parsing. The information saved in the library is the 
semantic information needed to compile other units; it's not possible to 
regenerate any form of source from it (all of these steps are one way only). 
You keep the original source for use of other tools and possibly to modify 
and recompile again.

Janus/Ada does keep the original source name, solely for the use of other 
tools (build management, debugging, etc.) None of those tools have anything 
to do with implementing the Ada language as described in the Standard --  
they're about adding some ease-of-use to the system.

You could of course put the source into such a library system (Rational did 
so, I think). Since Rational's system included configuration management and 
modeling, there wasn't a whole lot of reason to leave it. But of course that 
was possible if necessary. (I think that's likely for any such system - 
configuration management needs to be integrated with the IDE, and static 
analysis should [IMHO] be an integral part of any Ada compiler. So leaving 
it would be rare - maybe for modeling if your management is dumb enough to 
think there is anything to be gained there).

                                            Randy.

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

[Randy Brukardt]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:56180ac1-2480-4df7-9b0c-2e007efa5343@googlegroups.com...
>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.

You do know that you can still buy the Apex development system today? (See 
PTC.com). I haven't used it since they dropped the Windows version, but it 
still had all of those incremental features then -- I doubt that they 
disappeared in the interim!

                                              Randy.

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

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:8d1667cb-03dc-4ab3-b521-cd82ab39f36c@googlegroups.com...
...
>Btw, C++ as currently defined .cannot ever. score that point,
>whereas Ada can bring back R1000 at any time-all we need
>is $6 million.

I don't think Apex Ada is *that* expensive. You do know that Rational ported 
most of the R1000 technology into their Apex line of compilers, which still 
exists (acquired a few years ago by PTC). It definitely had that incremental 
compilation technology when I used it in the late 1990s, and I would be 
massively surprised if they got rid of it in the interim.

                                               Randy.

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

[Randy Brukardt]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:77529b0d-b851-4136-82d0-d8bc3832ce12@googlegroups.com...
...
>> Btw, C++ as currently defined .cannot ever. score that point,
>>whereas Ada can bring back R1000 at any time-all we need is $6 million.

>Does this price cover the development of all remaining Ada95, Ada2005 and
>Ada2012 language features?

Apex Ada is Ada 2005, so we'd only have to add Ada 2012 features to it. 
Those are a *lot* easier than the Ada 2005 features of limited with and 
interfaces. $6 million probably would be enough.

When the only thing you even know about is GNAT, Ada looks a lot worse than 
it really is. :-) I would hope to discuss the Ada language here, and not 
(exclusively) one particular implementation thereof.

                              Randy.

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

[Jeffrey R. Carter]

On 07/05/2018 08:35 PM, Randy Brukardt wrote:
> "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message
> news:phj901$3a0$1@dont-email.me...
>> On 07/04/2018 06:24 PM, Alejandro R. Mosteo wrote:
>>> On 04/07/2018 17:52, Dmitry A. Kazakov wrote:
>>>>
>>>> Yet Ada allows having a library of packages, like DEC Ada had. Your
>>>
>>> Ah, I seem to remember that the Meridian Ada compiler in my first year at
>>> university also had something like that.
>>
>> Ada 83 required it.
> 
> Not really, it's more accurate to say that no one had tried to figure out an
> alternative with the needed semantics. That didn't happen until the GNAT
> people invented source-based translation for Ada (since copied by some other
> compilers).

ARM-83 10.4. The Program Library: "[A] library file containing information on 
the compilation units of the program library must be maintained by the compiler 
or compiling environment."

-- 
Jeff Carter
"I certainly have not the talent which some people possess, ...
of conversing easily with those I have never seen before."
Pride and Prejudice
121

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

[Maciej Sobczak]

> Take Janus/Ada, for example. The source code lives wherever the programmer 
> wants it, it's not in the library

OK, but since I don't have access to this compiler, is it possible to complete your description with the explanation of what will happen when the equivalent exercise is performed in this environment?

I mean - when somebody:
- adds a whitespace to a file with package spec P, or
- adds a new type definition to the same file.

What will need to be reparsed or recompiled or relinked?

> configuration management needs to be integrated with the IDE

What if my IDE is a plain text editor and I intentionally don't have all possible tools glued to it?
Do you mean (and I think that Dmitry shares your point) that Ada discourages me to use a regular text editor to edit source files?

-- 
Maciej Sobczak * http://www.inspirel.com

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

[Maciej Sobczak]

> In any case, semantic coupling is many times more important than 
> compile-time coupling, since it causes actual maintenance problems. Perhaps 
> focusing on that would make the differences more apparent???

So let's do focus on that. Is there some short example that you would like to present to demonstrate this point?

-- 
Maciej Sobczak * http://www.inspirel.com

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

[Maciej Sobczak]

> 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 [...]

And this is where you contradict yourself. If a) all C++ is one big undefined behavior and b) thus the visible effects can be anything, then the implementation can behave like R1000 [*], which contradicts your statement that it cannot be done.

[*] The problem is - apparently nobody wants it.

> When the •absence of evidence• [...]

I'm sorry, but I got completely lost in your convoluted elaboration on this matter.
Let's make this discussion more concrete again (if it ever was): can you show a short (that is, practical for the discussion group) code example that demonstrates your point (whatever it is)? Please note that I cannot verify a statement that requires access to the compiler that I cannot use in real life.

(Note to Randy as well) I will *always* prefer a C++ compiler that I have over the Ada compiler that I don't have. And my clients appreciate that choice, too.
If you want to compete with C++, you need to do it in practice, not in theory.

-- 
Maciej Sobczak * http://www.inspirel.com

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

[Dan'l Miller]

On Thursday, July 5, 2018 at 3:38:43 PM UTC-5, Maciej Sobczak wrote:
> > 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).
> 
> And this is where you contradict yourself. If a) all C++ is one big undefined behavior and b) thus the
> visible effects can be anything, then the implementation can behave like R1000 [*], which contradicts
> your statement that it cannot be done.

If C++ is one big undefined behavior, and thus visible effects can be anything, then C++ can behave as if it is a million monkeys banging on typewriter keyboards accidentally writing the works of Shakespeare (or better yet, a non-troller-fisherman response from you).

I never said that all of C++ is one big undefined behavior.  I effectively said that C++ is uncouth enough in numerous enough places to be a long-horned bull in a densely-stocked china-porcelain shop, ruining all attempts to elevate software engineering to the level that R1000 achieved by cohesive integration.  C++ has dragged down GNAT.  C++ has thus dragged down our entire industry.  A bull in a china shop won't accidentally bang out the works of Shakespeare on a million typewriter keyboards.

> [*] The problem is - apparently nobody wants it.

If no one wants it, then why is it still for sale all these decades later by the company that bought IBM's Rational compiler intellectual property?  And why do they have paying customers who buy it?

> > 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). 
> 
> I'm sorry, but I got completely lost in your convoluted elaboration on this matter.
> Let's make this discussion more concrete again (if it ever was): can you show a short (that is, practical for the discussion group) code example that demonstrates your point (whatever it is)?

Your “fundamental logic” insult of me above was not in code; it was in the English prose that you yourself wrote that I then merely quoted back to you.  Now I am to write up a program that insults myself the way you did, just so that you can see it (because you have can't or won't read the English prose that you yourself wrote)?

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

[Dan'l Miller]

On Tuesday, July 3, 2018 at 3:00:27 AM UTC-5, Maciej Sobczak wrote:
> > Overtly declaring the range of integers over which this portion of code operates can be a key portion of eliminating all variants of the overflow/overrun vuln(erabilitie)s that worms utilize as their attack vector to insert machine code.
> ...
> > But never mind SEI software engineering principles, eh?
> 
> So can you kindly point me to where exactly SEI recommends defining integer range types ...

Maciej, I'll see your integer range types as software-engineering principles emanating from the SEI team at CMU, and raise you one Tartan in 1978.  The integer ranges as constant attributes on integer (or, indeed, on any scalar type) comes not merely from the various team members, but from the imprimatur of William A. Wulf himself, the founder-progenitor-anchor-pillar of the entire software-engineering team at CMU.

The Software Engineering Institute was formed on 14 November 1984.  Prior to the official formation of the SEI, William Wulf's team were a DoD-supported research contractor at Carnegie Mellon University.  The DoD High-Order Language Working Group (HOLWG) authored a series of -man requirements for HOLWG's new language:  strawman, woodenman, tinman, ironman, steelman.  Ironman and Steelman were issued to the {Yellow, Blue, Red, Green} color teams to design a language that conforms to the Ironman-at-first and then-Steelman requirements.  Steelman requirements added a brand-new requirement that had no precursor in Ironman:
“3-1C. Numeric Variables. The range of each numeric variable must be specified in programs and shall be determined by the time of its allocation. Such specifications shall be interpreted as the minimum range to be implemented and as the maximum range needed by the application. Explicit conversion operations shall not be required between numeric ranges.”

https://en.wikisource.org/wiki/Steelman_language_requirements

But notably (and the ultimate SEI/CMU answer to your question) there were 2 pre-disqualified noncolor/noncompetitor language designs that had a extra-special relationship with HOLWG:  Tartan from the pre-SEI team at CMU and -75+15PL/I from IBM.

http://archive.adaic.com/pol-hist/history/holwg-93/holwg-93.htm
As mentioned in the 2nd paragraph below Figure 9, Tartan was an apparent wordplay on the color-naming of the 4 official competitors; tartan is a specific kind of plaid in William Wulf's ancestral Scotland.  -75+15PL/I was PL/I with 75% of PL/I removed and a new 15% added.  HOLWG issued Ironman requirements to CMU and IBM to design a language from Ironman, and harshly critique whether Ironman was on-track or off-track.  HOLWG utilized the language definitions (including the language designers' insights and criticisms) that they got back from Tartan and -75+15PL/I to author their Steelman requirements as a definitive improvement over their Ironman requirements.

https://ia800804.us.archive.org/7/items/DTIC_ADA062815/DTIC_ADA062815.pdf
In §1.7 Unresolved Issues, the §1.7.3 Definition of Integers overtly recommends the content that became Steelman's new 3-1C requirement:
“In the reference manual we chose fIxed as a primitive and defined lnt as a special case by choosing attributes appropriately. We believe it is possible to treat int as primitive and define Fixed as nonprlmative by associating •range•/precision bookkeeplng with the operations.”  [Operations were Tartan's jargon for compile-time definitions of the values of the attributes of types.]

[Btw, Dmitry, you & your Steelman 3-3F-esque compile-time constant tag attributes for untagged types should pay especial attention henceforth, because, had more of Tartan made it into Steelman and thus into Green/Ada, then you yourself [not language designers] would have been able to define your own compile-time constant tag attributes for •any• type.  In the form of a standard library of Tartan-esque type compile-time operations, you would have had your tags for untagged types feature in a hypothetical more-Tartan-influenced Ada83+ almost 4 decades ago.]

In §1.5.6 Definition of Types, we see::
“A ••user•• may introduce a new type into his program with a type deflation. The type definition itself merely introduces the <type name> and defines the representation of the type. Operations are introduced by writing routines whose formal parameters are of the newly-dsflned type. …
¶A type definition may be paremeterized with •attributes•. The bindings in the formal parameter list must be •const• or mamfest. If a <binding> is omitted, it will be assumed to be const[, •Dmitry•]. The names of the formal parameters of the type are available throughout the elaboration of the program as •constants• [just as in Steelman requirement 3-3F], called •attributes• [just as they later became known in Ada]. They are accessed by treating the <var ident> as a •record•[, Dmitry] and the type attribute as a [Steelman 3-3F-compliant] •const• field. Attributes for primitive types are given as part of the type definitions [just as they later became in Ada].”

So there we have it, almost* precisely as Maciej requested:
constant compile-time attributes for integer (and fixed-point) ranges (and precision) from Carnegie Mellon University's DoD computer-science research team that a few years later named themselves Software Engineering Institute feeding directly into the requirements document that is to measure the amount of software-engineering-ness present in any programming language.

* just without mentioning C++ by name, mainly because C++ didn't exist yet (nor did C with Classes), because C++ hadn't mimicked Ada to this degree until a half to full decade later

Btw, Maciej, Steelman requirements are governing any programming language that purports to be a software-in-the-large software-engineering language, C++ included.

How well does 1990s-era {Ada95, C, C++, Java, Pascal}, and 2010s-era {D, Rust, Parasail} measure up against Steelman's software-engineering requirements?

https://www.dwheeler.com/steelman/steeltab.htm

http://jedbarber.id.au/steelman.html

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

[Dan'l Miller]

I found another 2 OCR mistakes that occurred within MacOS's PDF-world during the bitmap-to-text copy paste (that I missed during the original edit).  Their correction is interspersed below, to try to preclude anyone from pondering what a “mamfest” is.

On Thursday, July 5, 2018 at 10:32:36 PM UTC-5, Dan'l Miller wrote:
> On Tuesday, July 3, 2018 at 3:00:27 AM UTC-5, Maciej Sobczak wrote:
> > > Overtly declaring the range of integers over which this portion of code operates can be a key portion
> > > of eliminating all variants of the overflow/overrun vuln(erabilitie)s that worms utilize as their attack
> > > vector to insert machine code.
> > ...
> > > But never mind SEI software engineering principles, eh?
> > 
> > So can you kindly point me to where exactly SEI recommends defining integer range types ...
> 
> Maciej, I'll see your integer range types as software-engineering principles emanating from the SEI team
> at CMU, and raise you one Tartan in 1978.  The integer ranges as constant attributes on integer (or,
> indeed, on any scalar type) comes not merely from the various team members, but from the imprimatur
> of William A. Wulf himself, the founder-progenitor-anchor-pillar of the entire software-engineering team
> at CMU.
> 
> The Software Engineering Institute was formed on 14 November 1984.  Prior to the official formation of
> the SEI, William Wulf's team were a DoD-supported research contractor at Carnegie Mellon University.
> The DoD High-Order Language Working Group (HOLWG) authored a series of -man requirements for
> HOLWG's new language:  strawman, woodenman, tinman, ironman, steelman.  Ironman and Steelman
> were issued to the {Yellow, Blue, Red, Green} color teams to design a language that conforms to the
> Ironman-at-first and then-Steelman requirements.  Steelman requirements added a brand-new
> requirement that had no precursor in Ironman:
> “3-1C. Numeric Variables. The range of each numeric variable must be specified in programs and shall
> be determined by the time of its allocation. Such specifications shall be interpreted as the minimum
> range to be implemented and as the maximum range needed by the application. Explicit conversion
> operations shall not be required between numeric ranges.”
> 
> https://en.wikisource.org/wiki/Steelman_language_requirements
> 
> But notably (and the ultimate SEI/CMU answer to your question) there were 2 pre-disqualified
> noncolor/noncompetitor language designs that had a extra-special relationship with HOLWG:  Tartan
> from the pre-SEI team at CMU and -75+15PL/I from IBM.
> 
> http://archive.adaic.com/pol-hist/history/holwg-93/holwg-93.htm
> As mentioned in the 2nd paragraph below Figure 9, Tartan was an apparent wordplay on the color
> naming of the 4 official competitors; tartan is a specific kind of plaid in William Wulf's ancestral
> Scotland.  -75+15PL/I was PL/I with 75% of PL/I removed and a new 15% added.  HOLWG issued Ironman
> requirements to CMU and IBM to design a language from Ironman, and harshly critique whether Ironman
> was on-track or off-track.  HOLWG utilized the language definitions (including the language designers'
> insights and criticisms) that they got back from Tartan and -75+15PL/I to author their Steelman
> requirements as a definitive improvement over their Ironman requirements.
> 
> https://ia800804.us.archive.org/7/items/DTIC_ADA062815/DTIC_ADA062815.pdf
> In §1.7 Unresolved Issues, the §1.7.3 Definition of Integers overtly recommends the content that became
> Steelman's new 3-1C requirement:
> “In the reference manual we chose fIxed as a primitive and defined lnt as a special case by choosing
> attributes appropriately. We believe it is possible to treat int as primitive and define Fixed as
> nonprlmative by associating •range•/precision bookkeeplng with the operations.”  [Operations were
> Tartan's jargon for compile-time definitions of the values of the attributes of types.]
> 
> [Btw, Dmitry, you & your Steelman 3-3F-esque compile-time constant tag attributes for untagged types
> should pay especial attention henceforth, because, had more of Tartan made it into Steelman and thus
> into Green/Ada, then you yourself [not language designers] would have been able to define your own
> compile-time constant tag attributes for •any• type.  In the form of a standard library of Tartan-esque
> type compile-time operations, you would have had your tags for untagged types feature in a
> hypothetical more-Tartan-influenced Ada83+ almost 4 decades ago.]
> 
> In §1.5.6 Definition of Types, we see::
> “A ••user•• may introduce a new type into his program with a type deflation. The type definition itself
> merely introduces the <type name> and defines the representation of the type. Operations are
> introduced by writing routines whose formal parameters are of the newly-dsflned type. …

defined

> ¶A type definition may be paremeterized with •attributes•. The bindings in the formal parameter list
> must be •const• or mamfest. If a <binding> is omitted, it will be assumed to be const[, •Dmitry•]. The

manifest

> names of the formal parameters of the type are available throughout the elaboration of the program as
> •constants• [just as in Steelman requirement 3-3F], called •attributes• [just as they later became known
> in Ada]. They are accessed by treating the <var ident> as a •record•[, Dmitry] and the type attribute as a
> [Steelman 3-3F-compliant] •const• field. Attributes for primitive types are given as part of the type
> definitions [just as they later became in Ada].”
> 
> So there we have it, almost* precisely as Maciej requested:
> constant compile-time attributes for integer (and fixed-point) ranges (and precision) from Carnegie
> Mellon University's DoD computer-science research team that a few years later named themselves
> Software Engineering Institute feeding directly into the requirements document that is to measure the
> amount of software-engineering-ness present in any programming language.
> 
> * just without mentioning C++ by name, mainly because C++ didn't exist yet (nor did C with Classes),
> because C++ hadn't yet mimicked Ada to this degree until a half to full decade later
> 
> Btw, Maciej, Steelman requirements are governing any programming language that purports to be a
> software-in-the-large software-engineering language, C++ included.
> 
> How well does 1990s-era {Ada95, C, C++, Java, Pascal}, and 2010s-era {D, Rust, Parasail} measure up
> against Steelman's software-engineering requirements?
> 
> https://www.dwheeler.com/steelman/steeltab.htm
> 
> http://jedbarber.id.au/steelman.html

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

[Randy Brukardt]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:phls58$fti$1@dont-email.me...
> On 07/05/2018 08:35 PM, Randy Brukardt wrote:
>> "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message
>> news:phj901$3a0$1@dont-email.me...
>>> On 07/04/2018 06:24 PM, Alejandro R. Mosteo wrote:
>>>> On 04/07/2018 17:52, Dmitry A. Kazakov wrote:
>>>>>
>>>>> Yet Ada allows having a library of packages, like DEC Ada had. Your
>>>>
>>>> Ah, I seem to remember that the Meridian Ada compiler in my first year 
>>>> at
>>>> university also had something like that.
>>>
>>> Ada 83 required it.
>>
>> Not really, it's more accurate to say that no one had tried to figure out 
>> an
>> alternative with the needed semantics. That didn't happen until the GNAT
>> people invented source-based translation for Ada (since copied by some 
>> other
>> compilers).
>
> ARM-83 10.4. The Program Library: "[A] library file containing information 
> on the compilation units of the program library must be maintained by the 
> compiler or compiling environment."

Sure, but that can be anything the implementer wants. In early Janus/Ada, it 
was just a collection of files. There'd be no problem mapping the GNAT model 
into a "library" as defined by Ada 83 -- it's just terminology.

                                            Randy.

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

[Randy Brukardt]

Semantic coupling is (I think) a strict subset of compile-time coupling. How 
big a subset is what matters.

                       Randy.

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:9c874b9d-18c8-43bc-ab90-66d2fc446758@googlegroups.com...
On Thursday, July 5, 2018 at 1:53:31 PM UTC-5, Randy Brukardt wrote:
> "Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message
> news:c91c4183-a8fe-4b7a-858e-616728fbe844@googlegroups.com...
> ...
> >That is, this hypothetical possibility that you described (and that no
> >vendor cared to reap during the last 30 years) does not make Ada
> >any better language than C++ (in this particular regard).
>
> This statement is completely False: the Rational environment did take
> advantage of these possibilities decades ago. (I presume the version
> available from PTC still does.) As recently discussed here, people who 
> used
> that development environment tended to be very happy; perhaps this was one
> of the factors?
>
> In any case, semantic coupling is many times more important than
> compile-time coupling, since it causes actual maintenance problems. 
> Perhaps
> focusing on that would make the differences more apparent???

What would semantic coupling that lacks a syntactic* representation look 
like in Ada [with at least a smidgeon of wise & good, I hope]-or in C++ for 
that matter [worse, I suspect])?

* and thus doesn't appear in compile-time coupling, which is what we have 
discussed so far 

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

[Randy Brukardt]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:670baa25-a987-45a0-991f-ec3aa2878233@googlegroups.com...
>> In any case, semantic coupling is many times more important than
>> compile-time coupling, since it causes actual maintenance problems. 
>> Perhaps
>> focusing on that would make the differences more apparent???
>
> So let's do focus on that. Is there some short example that you would like 
> to present to demonstrate this point?

Not off-hand; I shouldn't have wasted the time on this discussion in the 
first place.

But I'll say that examples involving empty packages and useless withs don't 
really prove anything regardless of the language involved - they're not very 
realistic. I'd suggest looking at examples of privacy (which Ada is very 
strict about) and comparing to other languages (which I don't know well 
enough to do myself).

                                     Randy.

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

[Randy Brukardt]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:f7023d0f-3130-4214-a84f-bc682ebf69f8@googlegroups.com...
>> Take Janus/Ada, for example. The source code lives wherever the 
>> programmer
>> wants it, it's not in the library
>
> OK, but since I don't have access to this compiler, is it possible to 
> complete your description with the explanation of what will happen when 
> the equivalent exercise is performed in this environment?
>
> I mean - when somebody:
> - adds a whitespace to a file with package spec P, or
> - adds a new type definition to the same file.

Janus/Ada doesn't make any optimizations in this area. It's not worth the 
effort on modern machines, at least with the system sizes that I'm used to. 
The build tool (which determines the proper order of compilation) is quite a 
bit slower than the compiler (since it reads - at least in part - all of the 
source every time it is run) and often I'm waiting for it to finish moreso 
than waiting for the compiles.

> What will need to be reparsed or recompiled or relinked?

Whatever the build tool tells you. (Think something like Gnatmake if you 
need an example.) It's possible to compile individual files but it is rarely 
done - it requires more human work and is much more likely to fail for some 
reason.

>> configuration management needs to be integrated with the IDE
>
> What if my IDE is a plain text editor and I intentionally don't have all 
> possible tools glued to it?
> Do you mean (and I think that Dmitry shares your point) that Ada 
> discourages me to use a regular text editor to edit source files?

I've never in my life used an IDE other than to see what others are doing. 
Plain text editing is fine if you want that. Even the Claw Builder doesn't 
include any editor since it seemed important to let programmers use whatever 
they are familar with to build code, rather than putting them into some 
necessarily limited environment.

However, the vast majority of programmers have no clue about how to do 
anything for themselves anymore, and you have to provide a IDE that does 
pretty much everything for them if you want customers. Such a system has to 
include configuration management (I'd suggest via a plugin or similar 
scheme, rather than insisting on a particular system). Going in and out of a 
large IDE doesn't really make sense (it's very different than regular 
editing in that way).

                                      Randy.

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

[Dmitry A. Kazakov]

On 2018-07-06 21:01, Randy Brukardt wrote:

> However, the vast majority of programmers have no clue about how to do
> anything for themselves anymore, and you have to provide a IDE that does
> pretty much everything for them if you want customers. Such a system has to
> include configuration management (I'd suggest via a plugin or similar
> scheme, rather than insisting on a particular system). Going in and out of a
> large IDE doesn't really make sense (it's very different than regular
> editing in that way).

There is a third group which enjoys IDE's source code navigation, 
suggestions, expansions, but does all configuration manually. I find it 
much easier to write GNAT gpr files per hand. But I could not live 
without GPS navigation (go to declaration, go to body etc). I am far too 
old to remember all files, all generic instances and which declarations 
they hold.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Dmitry A. Kazakov]

On 2018-07-06 20:51, Randy Brukardt wrote:
> "Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message
> news:670baa25-a987-45a0-991f-ec3aa2878233@googlegroups.com...
>>> In any case, semantic coupling is many times more important than
>>> compile-time coupling, since it causes actual maintenance problems.
>>> Perhaps
>>> focusing on that would make the differences more apparent???
>>
>> So let's do focus on that. Is there some short example that you would like
>> to present to demonstrate this point?
> 
> Not off-hand; I shouldn't have wasted the time on this discussion in the
> first place.
> 
> But I'll say that examples involving empty packages and useless withs don't
> really prove anything regardless of the language involved - they're not very
> realistic. I'd suggest looking at examples of privacy (which Ada is very
> strict about) and comparing to other languages (which I don't know well
> enough to do myself).

I would add that much depends on optimization. If the compiler looks 
into a body in order to perform certain types of optimization then no 
matter how excellent Ada's separation of interface and implementation 
is, it must recompile clients if the body was changed.

But Ada will still beat others here, because for quick runs you can turn 
the optimization off being sure that when you turn it on, then due to 
the separation the optimized code will still work.

It is a really a plague in C++: the debug version works and the release 
crashes. Never happened in Ada to me.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Dan'l Miller]

On Friday, July 6, 2018 at 2:43:21 PM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-07-06 20:51, Randy Brukardt wrote:
> > "Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message
> > news:670baa25-a987-45a0-991f-ec3aa2878233@googlegroups.com...
> >>> In any case, semantic coupling is many times more important than
> >>> compile-time coupling, since it causes actual maintenance problems.
> >>> Perhaps
> >>> focusing on that would make the differences more apparent???
> >>
> >> So let's do focus on that. Is there some short example that you would like
> >> to present to demonstrate this point?
> > 
> > Not off-hand; I shouldn't have wasted the time on this discussion in the
> > first place.
> > 
> > But I'll say that examples involving empty packages and useless withs don't
> > really prove anything regardless of the language involved - they're not very
> > realistic. I'd suggest looking at examples of privacy (which Ada is very
> > strict about) and comparing to other languages (which I don't know well
> > enough to do myself).
> 
> I would add that much depends on optimization. If the compiler looks 
> into a body in order to perform certain types of optimization then no 
> matter how excellent Ada's separation of interface and implementation 
> is, it must recompile clients if the body was changed.
> 
> But Ada will still beat others here, because for quick runs you can turn 
> the optimization off being sure that when you turn it on, then due to 
> the separation the optimized code will still work.

Do you use this rule with GNAT or nonGNAT compilers?  Given GNAT's GIGI/GIMPLE/RTL optimizing backend, might GNAT not respect private-package boundaries when optimizing?

> It is a really a plague in C++: the debug version works and the release 
> crashes. Never happened in Ada to me.

I agree 100%.  This happens precisely because of C++'s “as-if” rule*, permitting the optimizer to interact deleteriously with one or more undefined behaviors (UBs).

* The name is a misnomer.  A better name would be the ‘carte-blanche’ rule, because the optimizer is handed a blank check to fill out untrustworthily whenever one or more UBs occur in a program.

https://stackoverflow.com/questions/15718262/what-exactly-is-the-as-if-rule

It is “as if”** an enemy of C++ snuck into the standards committee and planted the worst possible contortion of the past momentum of C++ culture into the letter of the standard to break vast quantities of real-world programs when the optimizer is turned on.  If they really want this carte-blanche rule in C++-with-optimization, then then C++ absolutely must error all UBs when compiled with optimization.  But they didn't require such.

** Perhaps that is the real reason that it is called the “as if” rule instead of the ‘carte blanche’ rule.

This is the reason that multiple C++ shops with which I have been employed have all picked only one optimization level and performed all development & debugging & everything at only that one optimization level; builds with the optimizer turned off or to any different level were strictly prohibited.

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

[Maciej Sobczak]

> But I'll say that examples involving empty packages and useless withs don't 
> really prove anything regardless of the language involved

Fair point.

> - they're not very 
> realistic.

Empty packages are not, but useless withs quite well reflect the rotting of the codebase during its evolution and refactoring. The whole pimpl idiom (as it is known in the C++ community, but practiced in Ada, too, under the "opaque pointer" name) exists exactly to reduce the number of compile-time dependencies. In the case of my previous example, if you find a way to move the useless "with P" from the Q's spec to its body, then you can gain a lot in terms of this reduction (in particular, Test becomes no longer dependent on P). This phenomenon is very real and proactive application of such techniques is essential to effective physical design. This applies to both Ada and C++.

> I'd suggest looking at examples of privacy (which Ada is very 
> strict about) and comparing to other languages (which I don't know well 
> enough to do myself).

Good point, but here I will argue that Ada does not have any recognizable added value with regard to C++ - that is, I think I am able to translate any typical Ada privacy structure into equivalent C++ definitions. What is interesting in this area, however, is that in large projects I can actually expect that the privacy policies will be intentionally (!) reduced, for example with unit testing and run-time inspection in mind. Yes, it is possible to avoid this, but it is costly and the cheaper option wins. This observation applies to all static languages.

-- 
Maciej Sobczak * http://www.inspirel.com

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

[Maciej Sobczak]

> > So can you kindly point me to where exactly SEI recommends defining integer range types ...
> 
> Maciej, I'll see your integer range types [...]

I really appreciate the effort that you have put into copying all this text here, but it does not actualy answer my question. The Steelman requirement were intended to drive the design of a new language. It is pointless to use it as a benchmark for languages that were not developed within the same competition.
I was asking about today's coding standards that are published by SEI in relation to C++. You did not refer to them. If they say nothing about integer ranges, then it might also indicate that the very long historical connection that you have drawn has lost its meaning even for them. The coding standards that they publish for C++ do not refer to Steelman, so why do you?

You did not convince me, so I will repeat: integer ranges do not fit well the C++ culture and are not recommended there.

> Btw, Maciej, Steelman requirements are governing any programming language that purports to be a software-in-the-large software-engineering language, C++ included.

No, this is the interpretation that you have made yourself. Even the page that you have linked says:

"the original 1978 requirements document for the Ada computer programming language"

These requirements do not govern anything that they were not intended to. Making such comparison benchmarks is interesting as a historical study, but it is far from "governing" anything. In this limited context, the fact that Ada does not meet the requirements for Ada is more funny than the fact that C++ does not meet them.

-- 
Maciej Sobczak * http://www.inspirel.com

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

[Dan'l Miller]

On Friday, July 6, 2018 at 3:42:48 PM UTC-5, Maciej Sobczak wrote:
> _________ do not refer to Steelman, so why do you?

Because Steelman was one of the highest achievements in the history of humankind in defining a system of measurement for what is a software-engineering-facilitating programming language and what is not.

Do you have a suggestion for any other language-agnostic set of requirements that serves as a measuring stick for what is a software-engineering-facilitating programming language and what is not?

The -man series is clearly language agnostic, because no less than 6 quite-different programming languages were devised/modified to attempt to enact them, especially the final 2 refinements:  Ironman & Steelman.

Perhaps you haven't noticed:  the -man series of requirements to devise a measuring stick of what is and is not a software-engineering-facilitating programming language was not only intended to a monumental achievement in the history of Western Civilization (especially The West during the Cold War), but the -man series is intended to be a quite scientific-experiment approach to the topic.
1) Yellow, Blue, Red, and Green were the specimens being experimented upon as evolutionarily-divergent paths to undergo natural selection as survival of the fittest
and
2) Tartan and -75+15PL/I was the control group, pre-disqualifed from winning the natural-selection competition
and
3) the -man series of requirements specifications are the Darwinian stressor to kill off the weak in the natural selection.

C++ was in a legally-protected zoo of sorts, not subjected to this natural selection because of the legalistic fluke of the AT&T Consent Decree in the 1956 break-up of the AT&T monopoly.  We moderns forget that there were 2 break-ups of AT&T, not only the baby-Bell one in 1984, but also the one where AT&T lost NEC split from Western Electric, Nortel (nee Northern Electric) split from Western Electric, ITT's Caribbean-Islands telephone network split from AT&T, Bell Canada split from AT&T, and AT&T severing occupation-of-Japan ties with NTT.  But most especially, AT&T agreed (in the Consent Decree) with IBM and the federal government of the USA in the USA's federal court system to refrain from entering the computers-for-sale marketspace, both as hardware and as software.  For a period of time, AT&T was the largest computer company in the world, selling hardware & software only to itself.  It was during this time from 1956 to 1984 that AT&T developed C and C++ in isolation from the rest of the world, with only a rather few leaks of very restrictive* licenses to a few universities, such as University of California at Berkeley.

* to comply with the Consent Decree

So, Maciej, your logic regarding Steelman not being a measuring stick of the AT&T languages too is quite naïve and flawed:  the primary reason that AT&T's post-PL/I work (upon AT&T's MULTICS divorce from General Electric in 1969) on programming languages was omitted from the HOLWG competition (as perhaps a 5th color language) was because of the Consent Decree that absolutely no one wanted to touch, most especially AT&T, the federal government, and IBM.  There were multiple dozens of lawyers in the USA's federal government, who from the day that they graduated from law school as young men & women to the day that they retired in old age worked ••on only one case post-WWII••:  the 2 break-ups of AT&T from 1949 and 1984.  Of all the Big Deals affecting every aspect of technology in the 20th century, this was one of the Biggest of the Big Deals.

Any alternative measuring stick that you might purport to be another even remotely useful system of measurement of what is and what is not a software-engineering-facilitating programming language would need to meet or exceed that level of science that overtly appears as quite a crescendo in HOLWG's -man series of requirements.

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

[Paul Rubin]

Maciej Sobczak <see.my.homepage@gmail.com> writes:
> What is interesting in this area, however, is that in large projects I
> can actually expect that the privacy policies will be intentionally
> (!) reduced, for example with unit testing and run-time inspection in
> mind. Yes, it is possible to avoid this, but it is costly and the
> cheaper option wins. This observation applies to all static languages.

C++ can mitigate that somewhat with friend declarations: does Ada have
anything like that?  It means exporting a symbol from one package to a
specific other package, rather than choosing between keeping it private
or exporting it to the whole world.

I know Java is quite extreme about privacy since it's designed to
support sandboxing.  That is, private methods and variables are treated
as security feature.  You are supposed to be able to pass instances of
your class to actual malicious code written by attackers, letting the
attacker code access your public methods but preventing it from reaching
the private ones.

Of course Java's sandbox model has experienced many security failures
over the years, but I don't think Ada even attempted anything like that.
C++ would be completely hopeless at it, because of uncontrolled pointers.

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

[J-P. Rosen]

Le 07/07/2018 à 01:26, Paul Rubin a écrit :
> C++ can mitigate that somewhat with friend declarations: does Ada have
> anything like that?  It means exporting a symbol from one package to a
> specific other package, rather than choosing between keeping it private
> or exporting it to the whole world.
Make the other package a child.

I often have packages with procedures declared in the private part for
the benefit of children (only).

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

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

[Micronian Coder]

Hi,

Jean-Pierre beat me to it, but I concur that child packages is Ada's answer to C++ friend. I find child packages much better than C++ friend because you can keep adding additional subprograms, say for testing purposes, without ever touching the original package.

On Friday, July 6, 2018 at 11:17:06 PM UTC-7, J-P. Rosen wrote:
> Le 07/07/2018 à 01:26, Paul Rubin a écrit :
> > C++ can mitigate that somewhat with friend declarations: does Ada have
> > anything like that?  It means exporting a symbol from one package to a
> > specific other package, rather than choosing between keeping it private
> > or exporting it to the whole world.
> Make the other package a child.
> 
> I often have packages with procedures declared in the private part for
> the benefit of children (only).
> 
> -- 
> J-P. Rosen
> Adalog
> 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
> Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
> http://www.adalog.fr

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

[Dmitry A. Kazakov]

On 2018-07-06 22:18, Dan'l Miller wrote:

>> But Ada will still beat others here, because for quick runs you can turn
>> the optimization off being sure that when you turn it on, then due to
>> the separation the optimized code will still work.
> 
> Do you use this rule with GNAT or nonGNAT compilers?

Yes, I compile everything with -O0 in GNAT and use -O2 for releases only.

> Given GNAT's GIGI/GIMPLE/RTL optimizing backend, might GNAT not respect private-package boundaries when optimizing?

Considering expanding generic bodies an "optimization", yes. If there 
are other things it does with -O2, one should check.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Privacy and child packages (Was: Teaching C/C++ from Ada perspective?)

[Jacob Sparre Andersen]

Micronian Coder <micronian2@gmail.com> writes:

> Jean-Pierre beat me to it, but I concur that child packages is Ada's
> answer to C++ friend. I find child packages much better than C++
> friend because you can keep adding additional subprograms, say for
> testing purposes, without ever touching the original package.

Yes.

But the down-side(?) is that a clever programmer can use a child package
to leak private information from its parent.

You can see the package GNAT.Sockets.Compatibility in
<https://bitbucket.org/sparre/gnat-sockets-extras> for an example.  In
this case I used it to be able to use the same input/output operations
for both network connections and regular files.

Greetings,

Jacob
-- 
'I don't think you can fight a whole universe, sir!'
'It's the prerogative of every life form, Mr Stibbons!'

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

[Björn Lundin]

On 2018-07-06 21:43, Dmitry A. Kazakov wrote:
> It is a really a plague in C++: the debug version works and the release
> crashes. Never happened in Ada to me.

Good for you. In the past - this milleneum - we had crashes
with optimized version several times, in fact so many that
we ran production code with no optimization untilo recently (se below).

Bugs like sum of floating types were calculated wrong, and
bad stacktraces (pointed to row 4345 in a file with 300 rows..)
to many times made us use no optimization.
This was gnat pro on windows and aix (both 32 bits)

However we do use -Os now, since the exe-files are too big for the
linker. (ca 300 Mb)
The problems mentioned above was sent to adacore and they were fixed.



-- 
--
Björn

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

[Lucretia]

On Thursday, 5 July 2018 20:16:33 UTC+1, Randy Brukardt  wrote:

> You do know that you can still buy the Apex development system today? (See 
> PTC.com). I haven't used it since they dropped the Windows version, but it 

Hardly visible, go to ptc.com and try to find the link to ApexAda or ObjectAda without searching for "ada."

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

[Maciej Sobczak]

> Make the other package a child.

It's cheating. :-)
The problem is - the "private" in Ada package spec does not correspond to "private" in C++ classes, but rather to "protected". You can extend a C++ class with a derived class and access protected stuff from there - this is the equivalent of creating a child package in Ada in order to access the not-so-private parts from the parent.
In other words, this Ada idiom is replicable in C++ with the use of "protected" parts.

It is the "private" in C++ that has no equivalent in Ada.
That is:

class MyCppClass
{
public:
    // ...
    // this is what you have in the public part of Ada spec

protected:
    // ...
    // this is what you have in the "private" part of Ada spec,
    // you can access this part from derived classes or children packages

private:
    // ...
    // no, you don't have this level of privacy in Ada (!)
    // and definitions in your package body are not exactly equivalents
};

> I often have packages with procedures declared in the private part for
> the benefit of children (only).

As shown above, C++ programmers put this kind of stuff under the "protected" tag.

When it comes to friends, they are implemented in Ada in terms of putting multiple types within the same package, so that they can see each other. I admit that I like this idiom more than than the friendship in C++, even if friends are more flexible (they can make much longer spans, but I would say it is a privacy equivalent of goto, with the same long-term consequences).

-- 
Maciej Sobczak * http://www.inspirel.com

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

[Maciej Sobczak]

> Because Steelman was one of the highest achievements in the history of humankind

Did you consider a career in politics or religion or both? :-)

> Do you have a suggestion for any other language-agnostic set of requirements that serves as a measuring stick for what is a software-engineering-facilitating programming language and what is not?

The measuring stick for me is whether I can convince others or whether others can convince me. This includes factors that extend beyond any hypothetical notion of "purity", or whatever that at the end the industry does not care about. Like "do I have access to compilers for the given language"? Because obviously a language without the compiler cannot be "facilitating" anything.
So I'm rather practice-oriented instead of religion-oriented.

> The -man series is clearly language agnostic

If it's the set of requirements for the Ada language, then obviously it is not agnostic.

> because no less than 6 quite-different programming languages

Nope. All of them wanted to become Ada.

> C++ was in a legally-protected zoo of sorts, not subjected to this natural selection

And this is where I object. The "natural selection" does not happen by committee. The closest industrial analogy to "natural selection" is the tool market, where users are ultimate judges. And this is the arena where your historical and sentimental links are both impressive and useless.
Think about more recent programming languages, which do not have. For some reason most of them try heavily to resemble C++, but you cannot blame AT&T for this any longer. Now it's somebody else's fault, but this is how "natural selection" works.

And, BTW, we were supposed to help the OP, who was asked to teach C++.

-- 
Maciej Sobczak * http://www.inspirel.com

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

[Simon Wright]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> In the case of my previous example, if you find a way to move the
> useless "with P" from the Q's spec to its body, then you can gain a
> lot in terms of this reduction (in particular, Test becomes no longer
> dependent on P). This phenomenon is very real and proactive
> application of such techniques is essential to effective physical
> design. This applies to both Ada and C++.

I do agree, but GNAT has become quite good about warning of "can move
with to body", "useless use type" (the latter is quite annoying, GCC 8 &
CE 2018 both warn on code I thought was OK, grr .. but I fix it anyway).

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

[Dan'l Miller]

On Saturday, July 7, 2018 at 3:43:44 PM UTC-5, Maciej Sobczak wrote:
> > The -man series is clearly language agnostic
> 
> If it's the set of requirements for the Ada language, then obviously it is not agnostic.
> 
> > because no less than 6 quite-different programming languages
> 
> Nope. All of them wanted to become Ada.

By definition of ‘pre-disqualified’, the pre-disqualified Tartan and pre-disqualified -75+15PL/I did not want to become Ada.

There was a 7th language derived from Ironman and Steelman.  The CHILL language ISO/IEC 9496 and ITU-T Z.200 was the European telecom industry's incensed retort to being uninvited to the party.  CHILL is a 3rd language that was designed with the overt knowledge that it would never be Ada.  And unlike Tartan and -75+15PL/I, CHILL became an ITU-T, ISO, and IEC standard, last revised in 1999, and part of GCC all the way through the GCC 2.X era.  And analogous to the Ada9X project, CHILL was revised during the first half of the 1990s to be OO.  And if you have ever made a telephone call in Europe (and much of the rest of the world outside of North America or Japan), then it is highly likely that CHILL's wise software engineering code made that telephone call possible.

7 languages—6 of which are •very• not*-Ada—overtly designed from scratch (CHILL, Ada, Red, Blue, Tartan) or modified (-75+15PL/I, Yellow) don't clearly demonstrate the language agnosticity of Ironman/Steelman, eh?  2 quite different languages (Ada versus CHILL) became ISO/IEC language standards.  CHILL (from Alcatel & Siemens) begat Erlang as a reaction from Ericsson; nearly all the not-Ada-esque/not-Algol-esque/not-C-esque portions of Erlang are directly mimicked from CHILL—and Erlang is gaining popularity today.

* CHILL looks more like PL/I and COBOL.

> Nope. All of them wanted to become Ada.

Btw, Maciej, I've got news for you.  It was common knowledge among those of us** advocating C++ in the latter half of the 1980s that C++ wanted to become the Ada-esque Ada killer as much as CHILL did.  AT&T (North American telecom) and the European PTT equipment manufacturers felt quite spurned for being uninvited to the language competition.  That is a huge part of the reason that AT&T, Alcatel, and Siemens, (and Ericsson, counting Erlang) poured so much effort into designing C with Classes, C++, and CHILL, (and Erlang) instead of adopting Ada for their embedded systems.  (Telecom equipment has always been the 2nd largest realtime embedded software footprint on the planet behind the military.)  If there is one single root-cause reason that Ada failed to launch on the launchpad from, say, 1985 to 1993, it was this spurned-detest of Ada in telecom, not because of what was in or not in Ada, but because telecom was excluded from the selection process.

** I wrote my first C++ programs in 1988 on an Oregon compiler first and a few months later when I first got my hands on a cfront from AT&T on a 3B2.

By C++ and CHILL wanting to very much be the Ada-esque Ada killers from telecom, C++ and CHILL wanted to be Ada even more than Red, Yellow, Blue, Tartan, or -75+15PL/I did.  Your logic is flawed and naïve, •as if• you are unaware of all this history.

(Is that that “as if” rule that you were talking about?)

> > C++ was in a legally-protected zoo of sorts, not subjected to this natural selection
> 
> And this is where I object. The "natural selection" does not happen by committee. The closest industrial
> analogy to "natural selection" is the tool market, where users are ultimate judges. And this is the arena
> where your historical and sentimental links are both impressive and useless.
>
> Think about more recent programming languages, which do not have. For some reason most of them try
> heavily to resemble C++, but you cannot blame AT&T for this any longer. Now it's somebody else's fault,
> but this is how "natural selection" works.

Wow.  What an incredibly jaw-dropping disregard of history.  It is •as if• you didn't live through the 1980s or something.  It is •as if• you didn't live in the USA or something during the cut-throat viciousness of The Unix Wars at the end of The Cold War, or something.  ‘The industrial commercial marketplace’ as some sort of paragon of pure-as-driven-snow Adam Smith unfettered capitalism didn't decide in any way whatsoever.  Government mandates in the USA's federal government decided by fiat.  Allow me to explain how the my-fiat-is-bigger-than-your-fiat scheme worked:

https://www.cbronline.com/news/posix_comes_up_to_starting_gate_as_the_vendor_independent_unix_standard

https://gcn.com/Articles/1995/08/22/NT-is-Posixcompliant-GSBCA-decides-ruling-raises-questions.aspx

A sign that hung in many Bell-System facilities in 1983 read:
“There are two giant entities at work in our country, and they both have an amazing influence on our daily lives ... one has given us radar, sonar, stereo, teletype, the transistor, hearing aids, artificial larynxes, talking movies, and the telephone. The other has given us the Civil War, the Spanish–American War, the First World War, the Second World War, the Korean War, the Vietnam War, double-digit inflation, double-digit unemployment, the Great Depression, the gasoline crisis, and the Watergate fiasco. Guess which one is now trying to tell the other one how to run its business?”

Hence, given their hurt feelings, turn-about was viewed as fair play:
AT&T was so incensed by the federal government's
A) anti-AT&T activities in the 1956 breakup,
B) the HOLWG spurning,
C) the 1984 breakup, and
D) perhaps a few other things (such as the 1968 perceived Carterfone abandonment of Theodore Roosevelt's 1906 Universal Service mandate with AT&T's then-mantra “One policy.  One System.  Universal Service.”)
that AT&T sought a form of swinging the pendulum the other way:  the federal government was to mandate that only AT&T-influenced UNIX-esque computers could be purchased for computer-room usage, putting DEC's VMS, IBM's mainframes, Prime's PRIMOS, Honeywell's OSes including impressively-B2-Orange-Book-compliant MULTICS, and so forth at drastic disadvantage or elimination when selling to the USA's federal government—and AT&T-world at decisively favorable advantage in the federal government's 20% of the USA's GDP.

Because of the artificially-fomented POSIX/UNIX wars from approximately mid-1980s to the mid-1990s, nearly everyone in the federal government obeyed the AT&T-biased POSIX mandate, and in turn nearly everyone wanted to develop UNIX/POSIX software in the AT&T languages so that their software was as close in philosophy to AT&T's/UNIX's/POSIX's as possible.  In effect:

a) the GSA's procurement-requirements mandate-fiat for nearly-100% POSIX server purchases by the 20% of the USA's GDP that is the federal government (including DoD & DoE**)

thoroughly eclipsed

b) the DoD's mandate-fiat for nearly-100% Ada development in national-security contracts.  It was a 2-way tug-of-war between NIST/DoCommerce versus DoD/DoE.

** In effect the backers of C/C++/POSIX said:  haha, DoD/DoE, even if you demand Ada as a thin veneer on top, we demand C/C++/POSIX products underneath at the operating system and computer-procurement level.  Checkmate:  former-pawn takes Queen Ada.

In effect (and actually quite surprisingly!), AT&T-world's government-lobbying planet was bigger than DoD-world's  government-lobbying planet in the competition of ••who was eclipsing whom••, and who was more capable in utilizing their lobbying levers of power within the federal government to pull off the bigger more-impervious of the 2 competing federal-government mandates-fiats with long tentacles that still have harsh lingering overshadowing effects even today 30 years later.  AT&T-world's influence over Commerce/NIST won in every lasting measurable way in the levers of power via government influence; DoD's mandate for Ada faded into history as it shriveled like a dying*** plant in permanent never-ending eclipse from planet-POSIX/C/C++ for the federal-government's out-sized dominance of 20% of the USA's GDP.

*** Fortunately, some people are keeping Ada alive today via UV-grow-lamps, as C++ bakes in the scorching heat of being on the surface the POSIX/C/Unix planet that is still overshadowing us all.  C++ wasn't •designed•‡ for that kind of exposure, as witnessed by the severe-tar-&-feathering lambasting that C++ is currently getting over there‡‡ at Slashdot:

The ++ has been removed in the URL; don't let the URL fool you.
https://developers.slashdot.org/story/18/07/07/0342201/is-c-a-really-terrible-language

‡ C++ was accreted, not designed.

‡‡ I promise that I had absolutely nothing to do with any of that over at Slashdot, other than the sole Anonymous-Coward reply that is ”Ada2012” in response to someone's question of:  other than C++ what good language is there for embedded systems programming.

> And, BTW, we were supposed to help the OP, who was asked to teach C++.

Oh, we are helping him very very much.  We are showing him in its full glory what a mess C++ is.  Any good teacher of C++ looking at all the replies in this thread would say, “Gee, I really must help my students avoid those morasses in C++.”  No one will ever know where the morasses are via polly-anna loving praise of C++.  No, the only way to know where the morasses in C++ are—the only way to know precisely where C++ buried the bodies—is to examine its dirty laundry, clothing-item by clothing-item.  Then, get one of the 9 varieties of Carbona out to remove just that kind of stain from each portion of C++.

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

[Bill Findlay]

On 8 Jul 2018, Dan'l Miller wrote
(in article<1ab5db5c-7892-40a8-ae36-ca1ec1168768@googlegroups.com>):

> If there is one single root-cause reason that Ada failed to launch
> on the launchpad from, say, 1985 to 1993, it was this spurned-detest of Ada
> in telecom, not because of what was in or not in Ada, but because telecom was
> excluded from the selection process.

There is another.

The right-on then-dominant faction in CS academia,
who might have been expected to welcome a language soundly based on SE 
principles,
boycotted it without further consideration, simply because it originated in 
the DoD.

That attitude persists in some quarters, BTW.

Oh, and the reptilian demeanour of some Ada compiler salespersons didn't 
help.
The ones who creeped me out were from Plaid Workshops (or something like 
that).

-- 
Bill Findlay

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

[Dan'l Miller]

On Sunday, July 8, 2018 at 1:39:34 PM UTC-5, Bill Findlay wrote:
> On 8 Jul 2018, Dan'l Miller wrote
> (in article<1ab5db5c-7892-40a8-ae36-ca1ec1168768@googlegroups.com>):
> 
> > If there is one single root-cause reason that Ada failed to launch
> > on the launchpad from, say, 1985 to 1993, it was this spurned-detest of Ada
> > in telecom, not because of what was in or not in Ada, but because telecom was
> > excluded from the selection process.
> 
> There is another.
> 
> The right-on then-dominant faction in CS academia,
> who might have been expected to welcome a language soundly based on SE 
> principles,
> boycotted it without further consideration, simply because it originated in 
> the DoD.

I strongly suspect that was because of universities' desire for finding favor in AT&T's eyes regarding coveted Unix licenses (pre-1984) and regarding POSIX (post-1986) was a big part of that.  Sometimes AT&T's largess walked in through the frontdoor of the revenue-generating admissions office:  for approximately a decade, vast quantities of AT&T's white-collar workforce was offered free tuition and lavish 18-month sabbatical to get their master degrees, fully paid for by corporate.  Low thousands  of employees signed up.

During the 1980s, the pro-Ada universities were also predominantly non-Unix, especially VMS.  Almost to 1.00 correlation.  Most corners of the technology universe back in the 1980s were either:
1) AT&T's lapdog via Unix & C or being hooked in tight with BSD's mimicking thereof,
or
2) IBM's lapdog via mainframes,
or
3) DoD's lapdog via Ada, especially looking for DARPA research grants and/or being under the influence of local defense contractors on steer-the-curriculum advisory boards.

Every college and university (or school/division/department therewithin) hitched their gravytrain wagons to 1 of those 3 during the 1980s.

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

[Maciej Sobczak]

> I do agree, but GNAT has become quite good about warning of "can move
> with to body",

It did not warn me with the trivial and obvious (empty P!) code example that I have presented. Is there some compiler switch that makes GNAT more sensitive to such abuses?

-- 
Maciej Sobczak * http://www.inspirel.com

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

[Maciej Sobczak]

> What an incredibly jaw-dropping disregard of history.

On the other hand, declaring that the leading (and in some sense the only) Ada compiler is broken and that the only Ada compiler worth its name is R1000 is a jaw-dropping disregard of the present.

> It is •as if• you didn't live through the 1980s [...] you didn't live in the USA

I didn't. And I don't feel the slightest regret for this.
Let me get it straight:

You might consider C to be an ultimate disaster, especially when regarded from the Steelman perspective. But if instead of writing it by hand you generate it by means of model-based design and/or formal methods, then the requirements of Steelman are irrelevant and the language, combined with its straightforward traceability to object code [*] and the availability on all modern hardware [*], might be as well be your best bet (literally).

[*] This is a certification must-have in safety-critical systems. Don't sell me the tech that makes it any more difficult.
[**] I think about embedded systems more than PCs.

This example shows that there is more than one way to practice the art of software engineering and I don't think that any single set of requirements, written some 40 years ago, can cut it for absolutely everybody, in every possible context. This is the reason why, even at the risk of being condemned by your church, I official disregard Steelman as the only valid benchmark for measuring the usefulness of programming languages *today*.
Consistently, even though I am genuinely impressed by your historical knowledge, I disregard it, too, as the only valid metric for measuring what is the proper technology choice *today*. This thread is already much longer than it was useful for anybody reading it and since I don't see any hope of finding any common ground, I can only agree to disagree.

> AT&T-world's government-lobbying planet was bigger than DoD-world's  government-lobbying planet in the competition of ••who was eclipsing whom••

This is actually the kind of "natural selection" I was referring to.

> ‡ C++ was accreted, not designed.

In the same manner, only Ada 83 was designed. Ada 95, Ada 2005 and Ada 2012 were accreted. Some of the features were openly admitted to be borrowed from C++.

> > And, BTW, we were supposed to help the OP, who was asked to teach C++.
> 
> Oh, we are helping him very very much.  We are showing him in its full glory what a mess C++ is.

Nope. You did not show *any* single code example, in any language. I have presented code snippets in both languages to demonstrate my arguments.

> Any good teacher of C++ looking at all the replies in this thread

Anybody who was about to consider Ada and has read that:

- the leading Ada compiler is broken,
- the only Ada compiler worth its name is archaic and does not support any of the features that supposedly make Ada competitive today
- one needs 6M$ to get it
- or one needs to buy the compiler from some other company that does not even bother to inform the public that they sell it
- and so on...

(because this is all that I have "learned" in this thread)

will run away from Ada as fast as they can. There is absolutely no chance you can ever convince anybody to switch to Ada if the only thing you have on offer is the unprecedented hatred towards C++ and a point of view that seemingly got stuck several decades ago. With arguments like above, this thread has become the parody of Ada advocacy. Actually, I believe that you are making a substantial damage to Ada with that kind of arguments. I'm afraid you don't realize this.

> “Gee, I really must help my students avoid those morasses in C++.”

You did not show any morasses in C++. You have mentioned some, but I have demonstrated they exist in Ada, too. How is this going to help?

I propose to make this discussion actually concrete [***] or close it.

[***] In short: show the code.

-- 
Maciej Sobczak * http://www.inspirel.com

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

[Dan'l Miller]

On Sunday, July 8, 2018 at 3:43:48 PM UTC-5, Maciej Sobczak wrote:
> > What an incredibly jaw-dropping disregard of history.
> 
> On the other hand, declaring that the leading (and in some sense the only) Ada compiler is broken and that the only Ada compiler worth its name is R1000 is a jaw-dropping disregard of the present.
> 
> > It is •as if• you didn't live through the 1980s [...] you didn't live in the USA
> 
> I didn't. And I don't feel the slightest regret for this.
> Let me get it straight:
> 
> You might consider C

You misspoke there:  C++, not C.

> to be an ultimate disaster, especially when regarded from the Steelman perspective.

> This example shows that there is more than one way to practice the art of software engineering and I
> don't think that any single set of requirements, written some 40 years ago, can cut it for absolutely
> everybody, in every possible context. This is the reason why, even at the risk of being condemned by
> your church, I official disregard Steelman as the only valid benchmark for measuring the usefulness of
> programming languages *today*.

You say this only because not one single entity on the planet ever wrote another/better set of requirements of what is and is not a scientifically-based measurement system of a programming language that facilitates software engineering.  There have been attempts to define what is a better hacker's hacking language (e.g., Jia, Go, even Java, Swift, and Kotlin to some degree, as attempts at the improved hacker's hacking language when compared to C), and a few of them have some valid points about “friction” and the like.  But not one single language-agnostic software-engineering-measurement-system competitor to Steelman has ever arisen from any deep-pockets agency or billionaire.

> since I don't see any hope of finding any common ground, I can only agree to disagree.

https://www.dwheeler.com/essays/make-it-simple-dewar.html

Hey, speaking of all that we agree on is that we disagree with each other, the above is a WWWpage that we can each look at and reach diametrically opposing conclusions.  In Wheeler's praise for the awesome astounding genius of GNAT's multi-dozen pass compilation technique as a “breakthrough” of accomplishment for the advance of feats possible by perfection in engineering as the pinnacle of human development (i.e., the stone-age, the iron-age, the bronze-age, the industrial-age, the space age, and now the multi-dozen-pass-compiler-age), you can look at it as defense of all of your positions, whereas I can look at it as direct evidence of where C++'s devolutionary retrograde influence on Ada compilers has been to undermine software engineering in general and Ada specifically.

> > Oh, we are helping him very very much.  We are showing him in its full glory what a mess C++ is.
> 
> Nope. You did not show *any* single code example, in any language. I have presented code snippets in both languages to demonstrate my arguments.

I gave 125 examples of weak spots in C++ accumulated over 3 books by Scott Meyers.  I gave an 852-page tome that itemizes countless dozens of weaknesses in C++ for supposedly its main claim to fame:  software engineering of enormously large software systems for which C's level of sophistication is too simplistic & barbaric.  You want even longer postings?

Here is yet another book where C++'s warts are inventoried and then work-arounds celebrated as a series of minor victories over C++'s morasses:
_Imperfect C++: Practical Solutions for Real-Life Programming_ by Matthew Wilson
http://blog.ImperfectCPlusPlus.com

> > Any good teacher of C++ looking at all the replies in this thread
> 
> Anybody who was about to consider Ada and has read that:
> 
> - the leading Ada compiler is broken,

There exist quite a few postings to c.l.a where the current state of the front-runner Ada compiler is lamented, even to the point of trying to figure out how a disruptor competitor could conceivably come into existence, especially an LLVM-based one.

> - the only Ada compiler worth its name is archaic and does not support any of the features that
> supposedly make Ada competitive today

Apex Ada supports Ada2005.

> - one needs 6M$ to get it

which would be mere pennies on the dollar compared to the tens or hundreds of millions of dollars expended by even the largest C++ vendor, let alone the next 9 on the top-10 list

> - or one needs to buy the compiler from some other company that does not even bother to inform the
> public that they sell it
> - and so on...
> 
> (because this is all that I have "learned" in this thread)
> 
> will run away from Ada as fast as they can. There is absolutely no chance you can ever convince
> anybody to switch to Ada if the only thing you have on offer is the unprecedented hatred towards C++

No, I am a collector of sorts.  My collection is an unprecedented list of the locations of where C++ buried the bodies in its crimes against software engineering.  Ada is the best thing that I have found to being a crime-scene-investigator lab to dissect all the evidence, figuring out where the C++ deviants went awry in their ‘breaking bad’.

The ultimate goal is 1) to get people to run away from C++ as fast as they can (preferably e.g., to Ada or to Rust, not to scripting/bytecode languages) and 2) to figure out:  How do we solve a problem like Maria?  er, GNAT.

> and a point of view that seemingly got stuck several decades ago. With arguments like above, this
> thread has become the parody of Ada advocacy. Actually, I believe that you are making a substantial
> damage to Ada with that kind of arguments. I'm afraid you don't realize this.
> 
> > “Gee, I really must help my students avoid those morasses in C++.”
> 
> You did not show any morasses in C++.

Then you did not click on any of the URLs that I provided.  Or if you did, you did not read with comprehension.

> You have mentioned some, but I have demonstrated they exist in
> Ada, too. How is this going to help?
> 
> I propose to make this discussion actually concrete [***] or close it.
> 
> [***] In short: show the code.

The books that I have listed in the comments above provide literally hundreds of code snippets of C++'s weaknesses to be avoided at practically all costs, especially the UBs that can evoke C++'s carte-blanche/as-if rule.  You seem to have me & c.l.a confused with a book publisher.

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

[Maciej Sobczak]

> > You might consider C
> 
> You misspoke there:  C++, not C.

Actually, no, I really meant C, not C++ in that very sentence. In the next sentence I have mentioned code generation by model-based design and it seems that C is a more common target choice.

> You say this only because not one single entity on the planet ever wrote another/better set of requirements of what is and is not a scientifically-based measurement system of a programming language that facilitates software engineering.

I have explained that I don't need a *single* measure and since the art of software engineering is apparently multi-dimensional, I don't expect a *single* measure to exist in the first place. And if you want something "better", you first need another measure to objectively compare different measures in order to decide which measure is better. This leads nowhere.

> I gave 125 examples of weak spots in C++ accumulated over 3 books by Scott Meyers.

For me these are advices on how to write good software in C++ (from which some are already outdated and some apply to Ada, too). And I have an impression that the biggest threat to your religion is that people actually can write good software in C++. Which is why the OP was asked to teach it.

> The ultimate goal is 1) to get people to run away from C++ as fast as they can

Did you actually succeeded with this goal? I doubt it. On the other hand, I *have* spread the knowledge of Ada in my workplace. But not by hatred to anything or anybody.

Sorry, this discussion is not useful.

-- 
Maciej Sobczak * http://www.inspirel.com

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

[Alejandro R. Mosteo]

On 08/07/2018 22:00, Maciej Sobczak wrote:
>> I do agree, but GNAT has become quite good about warning of "can move
>> with to body",
> 
> It did not warn me with the trivial and obvious (empty P!) code example that I have presented. Is there some compiler switch that makes GNAT more sensitive to such abuses?

This is what I'm using currently and it warns about all unneeded withs:

for Switches ("ada") use
  ("-gnatVa", "-gnatwa", "-g", "-O2", "-gnato",
   "-fstack-check", "-gnata", "-gnat12");

It's only with Community 2018 that I've started seeing the "use clause 
has no effect".

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

[Bill Findlay]

On 8 Jul 2018, Dan'l Miller wrote
(in article<877d0a01-d342-433c-a541-3662736ae857@googlegroups.com>):

> On Sunday, July 8, 2018 at 1:39:34 PM UTC-5, Bill Findlay wrote:
> > On 8 Jul 2018, Dan'l Miller wrote
> > (in article<1ab5db5c-7892-40a8-ae36-ca1ec1168768@googlegroups.com>):
> >
> > > If there is one single root-cause reason that Ada failed to launch
> > > on the launchpad from, say, 1985 to 1993, it was this spurned-detest of Ada
> > > in telecom, not because of what was in or not in Ada, but because telecom
> > > was
> > > excluded from the selection process.
> >
> > There is another.
> >
> > The right-on then-dominant faction in CS academia,
> > who might have been expected to welcome a language soundly based on SE
> > principles,
> > boycotted it without further consideration, simply because it originated in
> > the DoD.
>
> I strongly suspect that was because of universities' desire for finding favor
> in AT&T's eyes regarding coveted Unix licenses (pre-1984) ...

(a) We had a Unix licence since 1975, and a BSD licence since 1978.

(b) The people who negotiated licences were not the people who decided which 
language to teach.

So no, paranoia about AT&T had nothing to do with it.
Knee jerk aversion to the products of the DoD had everything to do with it.

> Every college and university (or school/division/department therewithin)
> hitched their gravytrain wagons to 1 of those 3 during the 1980s.

In your experience, which was not ours.

-- 
Bill Findlay

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

[Dan'l Miller]

On Monday, July 9, 2018 at 7:34:09 AM UTC-5, Bill Findlay wrote:
> On 8 Jul 2018, Dan'l Miller wrote
> (in article<877d0a01-d342-433c-a541-3662736ae857@googlegroups.com>):
> 
> > On Sunday, July 8, 2018 at 1:39:34 PM UTC-5, Bill Findlay wrote:
> > > On 8 Jul 2018, Dan'l Miller wrote
> > > (in article<1ab5db5c-7892-40a8-ae36-ca1ec1168768@googlegroups.com>):
> > >
> > > > If there is one single root-cause reason that Ada failed to launch
> > > > on the launchpad from, say, 1985 to 1993, it was this spurned-detest of Ada
> > > > in telecom, not because of what was in or not in Ada, but because telecom
> > > > was
> > > > excluded from the selection process.
> > >
> > > There is another.
> > >
> > > The right-on then-dominant faction in CS academia,
> > > who might have been expected to welcome a language soundly based on SE
> > > principles,
> > > boycotted it without further consideration, simply because it originated in
> > > the DoD.

My alma mater had an all-Ada83 computer-science department in the school of engineering, fashioned out an older computer-technologist department.  I went through the final grandfathered era of the mathematics department teaching the computer-science-proper courses.  Some universities and some schools within otherwise-nonAda universities strongly embraced Ada as the definitive wave of the future (because they saw DoD's extant Ada mandate on the table, but not the forthcoming POSIX mandate from DoCommerce/GSA/NIST).

> > I strongly suspect that was because of universities' desire for finding favor
> > in AT&T's eyes regarding coveted Unix licenses (pre-1984) ...
> 
> (a) We had a Unix licence since 1975, and a BSD licence since 1978.
> 
> (b) The people who negotiated licences were not the people who decided which 
> language to teach.

Yeah right.  Letting the C fruit rot on the vine after the gardener carefully cultivated that coveted licensing relationship would not have gone over very well.

Troublesome heads of departments can easily be shuffled back into the deck.  Troublesome deans almost as easily.  The nail that stands out shall be hammered down.

> So no, paranoia about AT&T had nothing to do with it.
> Knee jerk aversion to the products of the DoD had everything to do with it.

In the telecom industry of that era (i.e., the 2nd largest amount of realtime embedded systems), that same* knee-jerk reaction was the basis of the motivation for developing CHILL and C++ (and to some degree the unwavering dedication to C as the workhorse at AT&T, and to some degree AT&T's PL/I divorce in 1969).

* with respect to not-invented-here technology; not w.r.t. to any anti-war anti-military stance that might have been present in universities post-Vietnam

> > Every college and university (or school/division/department therewithin)
> > hitched their gravytrain wagons to 1 of those 3 during the 1980s.
> 
> In your experience, which was not ours.

Yes, in my direct observation:  it varied per campus in regional university systems.  It varied per school on the same campus.  At times, it varied even per department within the same school (e.g., math/hard-sciences versus computer science).  One might be fervently a VMS shop, the other fervently a BSD shop.  One might be a diversity shop (e.g., all of MULTICS, PRIMOS, VMS, HP, DG, IBM-world), the other might be a monolithic shop (e.g., only VMS; only IBM-world).  It all depended on who from corporate world was on the curriculum-advisory committee for that university or campus, on who was donating what gratis, and on what network of other appointments the staff had with research labs or defense contractors or other universities to mimic.

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

[Dan'l Miller]

On Sunday, July 8, 2018 at 3:43:48 PM UTC-5, Maciej Sobczak wrote:
> … if the only thing you have on offer is the unprecedented hatred towards C++

I don't hate C++.  My curation of a set of maps to where C++'s landmines are doesn't mean that I •hate• the soil that I walk on; it means that I •love• having both of my legs still attached to my body.

On Monday, July 9, 2018 at 1:13:02 AM UTC-5, Maciej Sobczak wrote:
> On Sunday, July 8, 2018 at 6:17:26 PM UTC-5, Dan'l Miller wrote:
> > On Sunday, July 8, 2018 at 3:43:48 PM UTC-5, Maciej Sobczak wrote:
> > > You might consider C
> > 
> > You misspoke there:  C++, not C.
> 
> Actually, no, I really meant C, not C++
>
> > > to be an ultimate disaster, especially when regarded from the Steelman perspective. 

No, other than C99's restrict keyword being utilized by human beings instead of code generators, I have no strongly-held ill feelings regarding C.  For the problem space that C tries to occupy, C rates a 5 out of 10, I think.  I think that C should have been quite different though.  C's structured-programming-era mission should have been something closer to Robert DeWar's hardware-agnostic assembly language (see below), not C's (mis)applying/force-fitting PDP/11 assembly-language semantics onto all other processors.

Robert B. K. Dewar; Anthony P. McCann (1979). MINIMAL - A Machine Independent Assembly Language. Computer Science Department Technical Report. No. 12. Courant Institute of Mathematical Sciences.

No, the ultimate disaster was having any amount of C compatibility whatsoever in C++ as a wobbly foundation.  Despite its weak-typing looseness flaws, C is a notable 1970s engineering achievement in •minimalism• that did not need C++'s accretions at all to make C not-minimal.  Why accrete •partial• strong typing & a Turing-complete template-engine onto a •minimalistic• weakly-typed language?  That opposite-of-minimalism doesn't even sound like C at all!  That amalgamation doesn't even pass the sniff test for a language that actually facilitates software engineering!  But by golly, that is what the software industry spent untold hundreds of millions (billions?) of dollars doing as its primary activity for over 30 years, except for parade of all the C-esque-syntaxed Bullwinkle* languages that seek to be a critique-of-C++/C++-done-right which has been yet another sequence of ratholes to pour a misspent hundreds of millions of dollars too, trying to rectify the C-is-a-wobbly-foundation bad idea.

* “This time for sure!” https://www.youtube.com/watch?v=jYMkuOUAg3M&frags=pl%2Cwn

C's involvement with C++ should have been limited to being the backend of cfront. “"Within C++, there is a much smaller and cleaner language struggling to get out” [due in large part to the gratuitous C-syntactic compatibility] —Bjarne Stroustrup _Design and Evolution of C++_ (1994) page 207 when describing his desire for an R1000-esque system for C++ not reliant on repeated textual re-processing

> > You say this only because not one single entity on the planet ever wrote another/better set of
> > requirements of what is and is not a scientifically-based measurement system of a programming
> > language that facilitates software engineering. 
>
> I have explained that I don't need a *single* measure and since the art of software engineering is
> apparently multi-dimensional, I don't expect a *single* measure to exist in the first place. And if you want
> something "better", you first need another measure to objectively compare different measures in order
> to decide which measure is better.

Well, now there you said something in the vicinity of something with which I agree wholeheartedly:  the SI reference meter rod in Paris is only as good as our ability to empirically quantitatively observe & calculate its fidelity of straightness versus its bentness toward deviance.

Software engineering does in fact need a way to empirically quantitatively observe & calculate fidelity of straightness versus bentness toward deviance.

> Sorry, this discussion is not useful.

Perhaps not to you, but it has been to me:  studying the causes & symptoms of deviance.

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

[Bill Findlay]

Dan'l Miller <optikos@verizon.net> wrote:
> On Monday, July 9, 2018 at 7:34:09 AM UTC-5, Bill Findlay wrote:
>> On 8 Jul 2018, Dan'l Miller wrote
>> (in article<877d0a01-d342-433c-a541-3662736ae857@googlegroups.com>):
>> 
>>> On Sunday, July 8, 2018 at 1:39:34 PM UTC-5, Bill Findlay wrote:
>>>> On 8 Jul 2018, Dan'l Miller wrote
>>>> (in article<1ab5db5c-7892-40a8-ae36-ca1ec1168768@googlegroups.com>):
>>>> 
>>>>> If there is one single root-cause reason that Ada failed to launch
>>>>> on the launchpad from, say, 1985 to 1993, it was this spurned-detest of Ada
>>>>> in telecom, not because of what was in or not in Ada, but because telecom
>>>>> was
>>>>> excluded from the selection process.
>>>> 
>>>> There is another.
>>>> 
>>>> The right-on then-dominant faction in CS academia,
>>>> who might have been expected to welcome a language soundly based on SE
>>>> principles,
>>>> boycotted it without further consideration, simply because it originated in
>>>> the DoD.
> 
> My alma mater had an all-Ada83 computer-science department in the school
> of engineering, fashioned out an older computer-technologist department. 
> I went through the final grandfathered era of the mathematics department
> teaching the computer-science-proper courses.  Some universities and some
> schools within otherwise-nonAda universities strongly embraced Ada as the
> definitive wave of the future (because they saw DoD's extant Ada mandate
> on the table, but not the forthcoming POSIX mandate from DoCommerce/GSA/NIST).
> 
>>> I strongly suspect that was because of universities' desire for finding favor
>>> in AT&T's eyes regarding coveted Unix licenses (pre-1984) ...
>> 
>> (a) We had a Unix licence since 1975, and a BSD licence since 1978.
>>  
>> (b) The people who negotiated licences were not the people who decided which 
>> language to teach.
> 
> Yeah right.  Letting the C fruit rot on the vine after the gardener
> carefully cultivated that coveted licensing relationship would not have
> gone over very well.
> 
> Troublesome heads of departments can easily be shuffled back into the
> deck.  Troublesome deans almost as easily.  The nail that stands out
> shall be hammered down.

I seem to have hit the nail on the head with “paranoia”.

>> So no, paranoia about AT&T had nothing to do with it.
>> Knee jerk aversion to the products of the DoD had everything to do with it.
> 
> In the telecom industry of that era (i.e., the 2nd largest amount of
> realtime embedded systems), that same* knee-jerk reaction was the basis
> of the motivation for developing CHILL and C++ (and to some degree the
> unwavering dedication to C as the workhorse at AT&T, and to some degree
> AT&T's PL/I divorce in 1969).
> 
> * with respect to not-invented-here technology; not w.r.t. to any
> anti-war anti-military stance that might have been present in universities post-Vietnam
> 
>>> Every college and university (or school/division/department therewithin)
>>> hitched their gravytrain wagons to 1 of those 3 during the 1980s.
>> 
>> In your experience, which was not ours.
> 
> Yes, in my direct observation:  it varied per campus in regional
> university systems.  It varied per school on the same campus.  At times,
> it varied even per department within the same school (e.g.,
> math/hard-sciences versus computer science).  One might be fervently a
> VMS shop, the other fervently a BSD shop.  One might be a diversity shop
> (e.g., all of MULTICS, PRIMOS, VMS, HP, DG, IBM-world), the other might
> be a monolithic shop (e.g., only VMS; only IBM-world).  It all depended
> on who from corporate world was on the curriculum-advisory committee for
> that university or campus, on who was donating what gratis, and on what
> network of other appointments the staff had with research labs or defense
> contractors or other universities to mimic.
> 

You do not seem to have considered that your observation did not extend to
my continent.

-- 
Bill Findlay

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

[Dan'l Miller]

On Monday, July 9, 2018 at 2:34:07 PM UTC-5, Bill Findlay wrote:
> Dan'l Miller  wrote:
> > On Monday, July 9, 2018 at 7:34:09 AM UTC-5, Bill Findlay wrote:
> >> On 8 Jul 2018, Dan'l Miller wrote
> >> (in article<877d0a01-d342-433c-a541-3662736ae857@googlegroups.com>):
> >> 
> >>> On Sunday, July 8, 2018 at 1:39:34 PM UTC-5, Bill Findlay wrote:
> >>>> On 8 Jul 2018, Dan'l Miller wrote
> >>>> (in article<1ab5db5c-7892-40a8-ae36-ca1ec1168768@googlegroups.com>):
> >>>> 
> >>>>> If there is one single root-cause reason that Ada failed to launch
> >>>>> on the launchpad from, say, 1985 to 1993, it was this spurned-detest of Ada
> >>>>> in telecom, not because of what was in or not in Ada, but because telecom
> >>>>> was
> >>>>> excluded from the selection process.
> >>>> 
> >>>> There is another.
> >>>> 
> >>>> The right-on then-dominant faction in CS academia,
> >>>> who might have been expected to welcome a language soundly based on SE
> >>>> principles,
> >>>> boycotted it without further consideration, simply because it originated in
> >>>> the DoD.
> > 
> > My alma mater had an all-Ada83 computer-science department in the school
> > of engineering, fashioned out an older computer-technologist department. 
> > I went through the final grandfathered era of the mathematics department
> > teaching the computer-science-proper courses.  Some universities and some
> > schools within otherwise-nonAda universities strongly embraced Ada as the
> > definitive wave of the future (because they saw DoD's extant Ada mandate
> > on the table, but not the forthcoming POSIX mandate from DoCommerce/GSA/NIST).
> > 
> >>> I strongly suspect that was because of universities' desire for finding favor
> >>> in AT&T's eyes regarding coveted Unix licenses (pre-1984) ...
> >> 
> >> (a) We had a Unix licence since 1975, and a BSD licence since 1978.
> >>  
> >> (b) The people who negotiated licences were not the people who decided which 
> >> language to teach.
> > 
> > Yeah right.  Letting the C fruit rot on the vine after the gardener
> > carefully cultivated that coveted licensing relationship would not have
> > gone over very well.
> > 
> > Troublesome heads of departments can easily be shuffled back into the
> > deck.  Troublesome deans almost as easily.  The nail that stands out
> > shall be hammered down.
> 
> I seem to have hit the nail on the head with “paranoia”.
> 
> >> So no, paranoia about AT&T had nothing to do with it.
> >> Knee jerk aversion to the products of the DoD had everything to do with it.
> > 
> > In the telecom industry of that era (i.e., the 2nd largest amount of
> > realtime embedded systems), that same* knee-jerk reaction was the basis
> > of the motivation for developing CHILL and C++ (and to some degree the
> > unwavering dedication to C as the workhorse at AT&T, and to some degree
> > AT&T's PL/I divorce in 1969).
> > 
> > * with respect to not-invented-here technology; not w.r.t. to any
> > anti-war anti-military stance that might have been present in universities post-Vietnam
> > 
> >>> Every college and university (or school/division/department therewithin)
> >>> hitched their gravytrain wagons to 1 of those 3 during the 1980s.
> >> 
> >> In your experience, which was not ours.
> > 
> > Yes, in my direct observation:  it varied per campus in regional
> > university systems.  It varied per school on the same campus.  At times,
> > it varied even per department within the same school (e.g.,
> > math/hard-sciences versus computer science).  One might be fervently a
> > VMS shop, the other fervently a BSD shop.  One might be a diversity shop
> > (e.g., all of MULTICS, PRIMOS, VMS, HP, DG, IBM-world), the other might
> > be a monolithic shop (e.g., only VMS; only IBM-world).  It all depended
> > on who from corporate world was on the curriculum-advisory committee for
> > that university or campus, on who was donating what gratis, and on what
> > network of other appointments the staff had with research labs or defense
> > contractors or other universities to mimic.
> > 
> 
> You do not seem to have considered that your observation did not extend to
> my continent.
> 
> -- 
> Bill Findlay

https://www2.seas.gwu.edu/~mfeldman/ada-foundation.html
Although the data are quite stale, the historical trend graph is fascinating.  This shows the uptake of Ada in universities was presumably greater during the 1990s than during the 1980s (unless there was a not-shown precipitous collapse around 1990 or so and then a rebound post-1992).

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

[Bill Findlay]

On 9 Jul 2018, Dan'l Miller wrote
(in article<0908f2ae-ac32-4573-a630-9bf43250c35d@googlegroups.com>):
>
> https://www2.seas.gwu.edu/~mfeldman/ada-foundation.html
> Although the data are quite stale, the historical trend graph is fascinating.
> This shows the uptake of Ada in universities was presumably greater during
> the 1990s than during the 1980s (unless there was a not-shown precipitous
> collapse around 1990 or so and then a rebound post-1992).

After 10 years or so of using Ada 83 only as a CS3/CS4 option,
we committed to Ada 95 as the CS1/CS22 foundation language,
starting in 1996.

That held for about 10 years, when Ada was replaced by Python,
"because it is more fun". Thankfully I was well away by that time.

-- 
Bill Findlay

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

[Lucretia]

On Monday, 9 July 2018 23:35:29 UTC+1, Bill Findlay  wrote:
> On 9 Jul 2018, Dan'l Miller wrote
> (in article<0908f2ae-ac32-4573-a630-9bf43250c35d>):
> >
> > https://www2.seas.gwu.edu/~mfeldman/ada-foundation.html
> > Although the data are quite stale, the historical trend graph is fascinating.
> > This shows the uptake of Ada in universities was presumably greater during
> > the 1990s than during the 1980s (unless there was a not-shown precipitous
> > collapse around 1990 or so and then a rebound post-1992).
> 
> After 10 years or so of using Ada 83 only as a CS3/CS4 option,
> we committed to Ada 95 as the CS1/CS22 foundation language,
> starting in 1996.
> 
> That held for about 10 years, when Ada was replaced by Python,
> "because it is more fun". Thankfully I was well away by that time.

Bradford replaced Ada95 (was Ada9X then) with Java in 1998, as I as leaving.

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

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:877d0a01-d342-433c-a541-3662736ae857@googlegroups.com...
...
>I strongly suspect that was because of universities' desire for finding 
>favor in
>AT&T's eyes regarding coveted Unix licenses (pre-1984) and regarding
>POSIX (post-1986) was a big part of that.  Sometimes AT&T's largess
>walked in through the frontdoor of the revenue-generating admissions 
>office:
> for approximately a decade, vast quantities of AT&T's white-collar 
> workforce
>was offered free tuition and lavish 18-month sabbatical to get their master
>degrees, fully paid for by corporate.  Low thousands  of employees signed 
>up.

That was certainly my experience. About half of my graduate school 
classmates (1980-83) were from Bell Labs. Not coincidentally, almost all of 
the haardware at the University of Wisconsin ran some form of Unix. (The 
outlier was the giant Unisys mainframe, which was rapidly being replaced by 
VAXes.)

Of course, we had one professor who was interested in Ada, who got tapped to 
teach one single semester of the compiler construction course, and thus used 
an Ada-subset as the language for the class-project. And that happened to be 
the semester that my roomate Isaac and I took the compiler construction 
course, so we build a compiler for an Ada-subset. And my frustration with 
the crappy languages available for the various early PCs that we worked on 
led to deciding to build and sell a compiler for a better language that we 
were familiar with. The rest is history.

So far as I know, nothing at UW ever used Ada again. Almost like it happened 
solely to give me a career...

                                       Randy.

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

[Randy Brukardt]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:3a162a7e-4e87-4fb5-9b39-423811271ef3@googlegroups.com...
>> What an incredibly jaw-dropping disregard of history.
>
>On the other hand, declaring that the leading (and in some sense the only)
>Ada compiler is broken and that the only Ada compiler worth its name is
>R1000 is a jaw-dropping disregard of the present.

It's also a fact: the Apex compiler is/was the gold standard of compilers, 
and nothing else has come close.

There's not a heck of a lot good about the present (in pretty much any venue 
that you look in!). Market dominance says nothing whatsoever about good 
(this is clearly visible in programming language usage!).

                         Randy.

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

[Britt]

On Tuesday, July 10, 2018 at 7:20:46 PM UTC-4, Randy Brukardt wrote:
> "Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
> news:3a162a7e-4e87-4fb5-9b39-423811271ef3@googlegroups.com...
> >> What an incredibly jaw-dropping disregard of history.
> >
> >On the other hand, declaring that the leading (and in some sense the only)
> >Ada compiler is broken and that the only Ada compiler worth its name is
> >R1000 is a jaw-dropping disregard of the present.
> 
> It's also a fact: the Apex compiler is/was the gold standard of compilers, 
> and nothing else has come close.


I disagree. DEC Ada was probably the best Ada 83 compiler and Apex the best for Ada 95. I used Apex versions 2/3/4 for several years on a Sun Solaris host and liked it very much. But having used GNAT Pro with GPS, gprbuild and gpr files since then, I would not want to go back to Apex.

> 
> There's not a heck of a lot good about the present (in pretty much any venue 
> that you look in!). Market dominance says nothing whatsoever about good 
> (this is clearly visible in programming language usage!).

Here I agree very much. Regarding good, ClearCase was/is the best software configuration tool but it is rapidly losing market share due to IBM (where good software gets acquired and dies).

- Britt

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

[Dan'l Miller]

On Tuesday, July 10, 2018 at 6:14:34 PM UTC-5, Randy Brukardt wrote:
> "Dan'l Miller"  wrote in message 
> news:877d0a01-d342-433c-a541-3662736ae857@googlegroups.com...
> ...
> >I strongly suspect that was because of universities' desire for finding 
> >favor in
> >AT&T's eyes regarding coveted Unix licenses (pre-1984) and regarding
> >POSIX (post-1986) was a big part of that.  Sometimes AT&T's largess
> >walked in through the frontdoor of the revenue-generating admissions 
> >office:
> > for approximately a decade, vast quantities of AT&T's white-collar 
> > workforce
> >was offered free tuition and lavish 18-month sabbatical to get their master
> >degrees, fully paid for by corporate.  Low thousands  of employees signed 
> >up.
> 
> That was certainly my experience. About half of my graduate school 
> classmates (1980-83) were from Bell Labs. Not coincidentally, almost all of 
> the haardware at the University of Wisconsin ran some form of Unix. (The 
> outlier was the giant Unisys mainframe, which was rapidly being replaced by 
> VAXes.)
> 
> Of course, we had one professor who was interested in Ada, who got tapped to 
> teach one single semester of the compiler construction course, and thus used 
> an Ada-subset as the language for the class-project. And that happened to be 
> the semester that my roomate Isaac and I took the compiler construction 
> course, so we build a compiler for an Ada-subset. And my frustration with 
> the crappy languages available for the various early PCs that we worked on 
> led to deciding to build and sell a compiler for a better language that we 
> were familiar with. The rest is history.
> 
> So far as I know, nothing at UW ever used Ada again. Almost like it happened 
> solely to give me a career...

Sometimes the stars align almost inexplicably so that we are each given a window of transient opportunity to ‘live the dream’ in some way, but only if we recognize it and reify it.

Btw, Randy, thank you very much for •all• that you do regarding Ada, now and through all the years; your fortuitous career actually is elevating civilization.

Randy, do you remember the name of that professor at UW who inadvertently brought your vision for your lifework into focus?  (OP please take note:  that is precisely what a most-excellent professor does for students.)

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

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:4cd5e912-04f6-4c3e-a19a-b19e8e59281d@googlegroups.com...
...
>Randy, do you remember the name of that professor at UW who
>inadvertently brought your vision for your lifework into focus?  (OP
>please take note:  that is precisely what a most-excellent professor
>does for students.)

Yes, of course. His name was Marvin Solomon. I rather viewed him as 
second-best to the man who eventually because my major professor, Raphael 
Finkle. (Hope I spelled their names right!) Prof. Finkle eventually moved to 
Kentucky where he got a chance to run his own CS department. Hope he was 
effective there as he was at Wisconsin. Prof. Solomon had stayed at 
Wisconsin for many years. But I haven't had any contact with the CS 
Department in years, so I have no idea what happened to him.

                                    Randy.

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

[robin.vowels]

On Sunday, July 1, 2018 at 4:04:30 AM UTC+10, koua...@gmail.com wrote:
> Hello,
> 
> Ada is my programming language of choice. I have used it much in scientific programming. At an University I am asked to teach programming but in C and C++ to fist year students. After having spent some years with Ada, I'm relecutant to "throw away" my good programming habits from Ada and embrace C/C++. I would like to know if there exist(s) good book(s) at introductory level for C/C++ that may go in the spirit of Ada so that I won't feel wasting my time and energy teaching C/C++?
> 
> Also I will start the above course with Algorithms in which I have little knowledge. Any suggestions for good books on this topic?

Horowitz and Sahni would be a good start.