Re: How (or Where?) to get started on Ada? (Properly)

[e.s.harney@gmail.com]

> read (for C++) Stan Lippman's _Inside the C++ object model_

That looks fascinating. I have been looking up details on these topics, but it seems I've been looking in the wrong places so far. I never expected there to be books on the inner workings of production-grade compilers/runtimes.

If you have any more suggestions in this direction I would be very excited about them.

> If this is what you mean by "knowing virtually nothing about what the syntax actually does" and "the intricate semantics of C++ were a deal-breaker", then you have completely grasped the current (dystopian) state of C++

Metaprogramming/Generics through templates in C++ is bad, but this is not what I meant. To be fair, Stroustrup himself has condemned some of the template abuse in Boost as "too clever" and they're trying to improve the situation on this front by adding little details like static if and so on.. Also this is a hard problem to solve - mixing subtyping with parametric polymorphism (sort of the equivalent of "duck typing" in more dynamic languages). I'm not aware of any (strongly typed) language that pulls this off without messing up one way or the other (I've yet to look at Ada Generics though, and occaml supposedly has done it pretty sanely too, though the language never really appealed to me.)

Instead I'm more with the C++ FQA in that there is no one single thing that, when looked at in isolation, makes C++ bad. It is rather the way in which things interact that results in too much total complexity. 

Things like type compatibility with const-vs-non-const and const-type-vs-const-pointer, rvalues-vs-lvalues-vs-copies, "logical" const vs mutable vs c++11 "bitwise" const, function return being essentially implementation defined (due to compilers being allowed to exhibit different observable side effects when applying return value optimizations), unclear thread semantics due to "storage locations" being an "implementation defined" detail, and so on. 

And to top it all of, they added lambdas in C++11.. If you want to see some truly mindbogging piece of code (20 LOC only; nested self-capturing/calling reference-counted lambdas to simulate the async/await functionality in C#), look at slide 50 in this presentation by Herb Sutter (http://video.ch9.ms/sessions/build/2013/2-306.pptx or http://postimg.org/image/5xtnrnr63/ for just the piece of code if the PowerPoint file isn't working for you).

No one of these things would too hard to grasp when dealing with it alone, but add them all together and you're in for some real headache. I'm sure there's some reason everything ended up the way it is, but there's (imho) little reason to have to deal with all of it if there's no one actually forcing you to.


On Wednesday, September 4, 2013 6:09:51 PM UTC+2, Dan'l Miller wrote:
> On Wednesday, September 4, 2013 4:14:55 AM UTC-5, e.s.h...@gmail.com wrote:
> 
> > As a programmer that has spent most of his time in managed environments so far (Java mostly, with some PHP and Python here and there), I have been trying to get more into "native code" recently, in order to be able to control things like memory layout and get deterministic resource usage (and thus deterministic run time performance). 
> 
> > 
> 
> > Initially I started looking at C/C++, but soon realized that the intricate semantics of C++ were a deal-breaker (and not necessary for what I was looking for anyways) and that C lacked too many libraries (hash tables, file systems, threading, etc.) to be useful for one-man-projects these days (yes there's things like APR or GLib but those are quite a bit of a hassle). 
> 
> > [...snip...]
> 
> > TL;DR:
> 
> > What I am struggling the most when learning new languages is knowing virtually nothing about what the syntax actually does. I have tried some online tutorials that manage to walk me through the compilation process and then slowly introduce new languages pieces through example programs, but (for me at least) that has been a rather frustrating experience, considering that I'm essentially just copy-pasting code (and having to ignore irrelevant bits in the code that are not relevant yet, but still necessary for it to run)..
> 
> > 
> 
> > What I'm looking for is a text that starts from the other way, i.e. explains the language blocks, the data/object model, etc. first, and only after that goes on to provide full examples of working code. I guess this is something I'll only be able to find in a book.
> 
> > 
> 
> > I did look on Amazon about available books, but all of them seem fairly dated. "Programming in Ada 2005" by John Barnes did look interesting judging by the reviews, yet I'm not sure of how helpful it will be in covering all details that are relevant to writing useful software these days (things like utf8, interfacing with C, etc.).
> 
> > 
> 
> > Do you have any recommendations for me?
> 
> 
> 
> Well, there are generally 4 major eras of Ada:  Ada83, Ada95, Ada2005, Ada2012.  Ada83 (code-named Green during the competition) was a design-by-committee during the 1970s and early 1980s, but with a strong counter-cultural attitude by Jean Ichbiah, Green team's lead designer.  Some of that counter-cultural attitude has been beneficial (e.g., the vigorous pursuit of correct object lifetimes), whereas other portions of that counter-cultural attitude was Ada83's downfall (e.g., accomplishing goals via Draconian restrictions).  I came first to Ada83, then, after having been repulsed by its excessive restrictions and lack of runtime polymorphism, spent the next 20 years in C++, which was designed with the style of Ada83 done "correctly" from the C-minded slapstick perspective of the Marx Brothers' "Doctor it hurts when I do this!"  "Well, then don't do that!"  Like Austin Obyrne's posting above, I came back to modern Ada decades later, when I became repulsed to core of my being at C++'s (especially Boost Libraries') excessive use of (poorly-)emulated functional programming in the metatemplate programming style of using the Turing-complete (at compile-time) capabilities of C++ templates.  The compile-time error messages emitted by metatemplate programming is cryptic & obtuse at best, and little better that "unknown error at unknown location" at worst.  If this is what you mean by "knowing virtually nothing about what the syntax actually does" and "the intricate semantics of C++ were a deal-breaker", then you have completely grasped the current (dystopian) state of C++, and I wholeheartedly agree with you at some level much further along the learning curve.
> 
> 
> 
> But conversely if you mean that you do not understand the canonical implementation of virtual functions as a per-instance pointer to a type's virtual-function table singleton(-per-type) that is an array of runtime-polymorphic function-pointers to call, as the fundamental rubber-meets-the-road mechanism of OOP, then you need to read (for C++) Stan Lippman's _Inside the C++ object model_, which predates metatemplate programming and hence is not contaminated by that MTP filth.  The underlying underpinnings of C++ can be thought of as the child's play-toy version of the industrial-strength underlying underpinnings of Ada95-&-onward, with C++'s per-instance pointer to virtual-function table roughly analogous to Ada95-&-onward's tag in a tagged record, for example.  Independent of language, you need to learn what the "native" machine-language languages do.  I suspect that this book will really stoke the fire in your mind, solving many mysteries in pre-MTP C++, Ada95-&-onward, and even some C.  From this stronger basis in what "native"/"unmanaged" machine-language programming-languages do, your learning of Ada will likely be accelerated as you will be able to visualize in your mind what is happening at the machine-language level for each feature in Ada (even if no such textual explanation appears in the later Ada books that you are reading). http://www.amazon.com/Inside-Object-Model-Stanley-Lippman/dp/0201834545/ref=sr_1_1?s=books&ie=UTF8&qid=1378307415&sr=1-1&keywords=C%2B%2B+object+model
> 
> 
> 
> For C & C++ programmers coming to Ada95-&-onward, I recommend Norman Cohen's _Ada as a second language_, which for you, would be after you read Stan Lippman's underlying-underpinnings-of-C++ book above.  As with Stan Lippman's book, Norman Cohen's book predates metatemplate programming, so it is not polluted by that filth.  http://www.amazon.com/Ada-Second-Language-Norman-Cohen/dp/0070116075/ref=sr_1_5?s=books&ie=UTF8&qid=1378305539&sr=1-5&keywords=ada
> 
> 
> 
> The most lucid revelation of Ada2005 semantics (including Ada95) is (British) John Barnes's _Programming in Ada2005 with CD_.  I wish John Barnes would add another several hundred pages (perhaps as a Volume Two) and merge in the equivalent of Stan Lippman's underlying-underpinning book, but for Ada, so that the reader can crystal-clearly see "what the syntax actually does" under the hood.  There appear to be 2 types of learners:
> 
> 1) those who love learning opaque black-boxes as opaque black-boxes, embracing the opaqueness to the nth degree.  (These people are not me, Stan Lippman, and apparently you.  John Barnes obviously loves voluminous details of the opaque black-box, and does an incredible job of revealing what the language does as an opaque black-box, describing its externally-observable behavior without significant reference to underlying underpinnings.
> 
> 2) those who love learning how to correctly & smoothly (nonjerkingly) drive an automobile with a manual transmission by first looking at a diagram of how the clutch lever actuates a partial-slip/partial-friction plate, then getting behind the wheel in a parking lot to learn to feather in the slip-point on the clutch by visualizing in one's mind an imagined-animated variant of the diagram of the manual transmission.  Stan Lippman's book above is firmly in this school of thought.  Nancy Leveson wrote an entire book on how an accurately not-too-abstracted & not-too-hokus-pokus mental model is one of the most important aspects of learning a complex system correctly (e.g., so that the operators of a nuclear-fission power-plant know how the systems work well enough to respond correctly to various emergent scenarios).  This book is about a style of design for a style of deep learning, not a recommendation for your Ada learning and native machine-code object model learning (but apropos for validating precisely the style of lucidly-revealing learning that your original posting is yearning).  http://www.amazon.com/Safeware-Computers-Nancy-G-Leveson/dp/0201119722/ref=sr_1_fkmr1_1?s=books&ie=UTF8&qid=1378310557&sr=1-1-fkmr1&keywords=Nancy+Levinson+safeware
> 
> 3) Then there are those people who (very partially, very badly) "learn" new things only by mangled analogy to opaque black-boxes that they already know.  They, for example, try to learn to drive a manual-transmission automobile by only direct & unembellished analogy to a automatic-transmission automobile.  Usually, such people with so-impaired thoughts never learn to drive a manual-transmission automobile correctly & smoothly until they disavow their ignorance (and likely join with us #2-type learners above, when some #2-type learner teaches how the underlying underpinnings of the clutch actually work).  Norman Cohen's book partially falls into this rut, and hence is supplemental reading material to fortify already-partially-learned Ada knowledge.  (Nancy Leveson's book lambastes this style of shallow learning and the misguided design style that evokes this shallowness.)
> 
> 
> 
> And when you get beyond basic Ada knowledge on towards intermediate, you should start reading sections of the Ada2012 (or Ada2005 or Ada95) rationale.  When you get to intermediate on towards advanced stage of learning, you should start reading section of the Ada2012 (or Ada2005 or Ada95) annotated reference, which is a further-embellished variant of the language standard.
> 
> http://www.ada-auth.org/standards/rationale12.html
> 
> and
> 
> http://www.adaic.org/ada-resources/standards
> 
> 
> 
> As you read Ada2012, Ada2005, and Ada95 material (perhaps in that reverse-chronological order), you will see Ada83 (codenamed Green) morph further & further toward the 2nd-place runner-up in the competition:  Red.  This is because Ada95, Ada2005, and Ada2012 was steered by the remnants of the Red team, after Green team's Jean Ichbiah resigned from his position of Distinguished Reviewer in protest against Ada95 (or some sanitized rewording thereof).  Studying redder-&-redder Ada95-&-onward along with pre-2000 C++ (predating the metatemplate programming filth) are complementary activities, because redder-&-redder Ada2005-&-onward is what 1990s pre-MTP C++ could have become.