It’s not a good review, tbf.
I have to kinda agree with the ada part…
Especially that common concepts have different names and that the “older" ada community (and documentation) is somewhat elitist.
Having to look up "Ada enums” and finding type X is. Looking for “Ada structs” and getting type X is record. Searching “Ada classes” and finding the Americans with Disabilities Act type X is tagged record.[1] I know that most of these conventions are remnants from the past and newer languages were able to learn from old ones and that Ada95 build up on records to implement OOP. But it still happens that I try to write type X is enum and constantly having to look up the syntax. That is a problem that can’t really be fixed but something that I am open to adapt and learn.
The elitist part is mostly noticble on old email threads, specific wikis like osdev (which is somewhat elitist itself in its nature) and sometimes documentation underselling other languages to make Ada sound better even tho they are both well suited. I explain myself that most knowledgeable Ada developers are retired contractors under NDA wanting to brag about their skillset and working with so many other experts that they lost contact with beginners. (Ada is used by experts in high integrity fields after all)
The new Ada generation (and thus newer documentation/tutorials) do not have this problem! We understood that there are not that many Ada developers compared to C/C++ and rust. The conversations on the matrix chat rooms are (most of the time) kind and helpful! And the tutorias have become more beginner friendly[2] compared to university lectures and books aimed at experts.
On the positive that “Ada” is also a human name I’ll add that 90% for my reason to learn Ada is because my name is also Ada.
3 Likes
Newer languages learnt noting and forgot much. The construct is actually:
type X is <types-algebra-expression>;
The expression of types algebra can be abstract array operation (takes two types builds a new one), abstract record operation, abstract enumeration (e.g. from a list), subtyping operation, type extension operation etc. It could even be a direct product of types (not in Ada). Ada deviates from this syntax for subtypes, tasks, protected objects.
P.S. There were no advances is types systems since Ada 95 and “newer” languages are all about curly brackets, adhockery and hobby stuff.
4 Likes
What our friend Dmitry means about the elitism, in short, is: deal with it.
Ada’s terminology is older than that of most modern languages, and has no reason to change just to appeal to today’s whippersnappers who don’t understand that each language has its own related yet different concepts. A tagged type definitely does not behave like a class, an enumeration type is not a C enum: you can’t assign it a numerical value.
ps: I even dare say, such attitude is close to insulting to young people who do try to effort to adopt the software engineer state of mind.
2 Likes
Everything in c is either an int or a pointer, or a float at a push and even they can be cast to be ints and pointers.
1 Like
In both examples you cite, the Ada terminology is ~10 years newer than the related C/C++ concepts!
To say how much market domination is able to fool our understanding of reality!
3 Likes
Enumeration type was in Pascal.
Tagged type behaves exactly like C++ types having vptr (primitive operations = virtual functions). In fact vptr is a specific case of a more general tag. Most differences come from design inconsistency of C++ which does not distinguish polymorphic and type-specific instances. In C++ both have same type called in C++ “class.” In Ada it is T’Class vs. T. Note the word “class” in both languages.
BTW Ada 83 had classes already, e.g. integer class. They were not dynamically polymorphic, though.
My point was not about whether Ada’s terms predate C++'s it is about ignorance and elementary inability to think.
P.S. It is interesting how Liskov’s sub/super/type vs. Cardelli’s sub/super/class fed decades of pointless discussions including whether circle is an ellipse. I am afraid that modern time programmers would not be able to follow the arguments…
I rather meant that when it started in 83, a number of languages existed to take inspiration from, two years before C++’s publication. Smalltalk’s classes differed C++’s classes, then there were “modules”, prototypes, traits, abstract data types, likely more than I don’t know of, all different implementation of “objects”. So it’s not like the original team and that of Ada95 had distanciated themselves from some kind of “ruling consensus”.
Ada did not distance from anything. You should look beyond the words into the meaning of in the context of the concept of a type system.
Smalltalk’s OO is not like C++'s classes, Smalltalk used actual messages to objects, like Objective-C does. All other class languages do OO the “wrong way” (according to Smalltalk people).
Any dynamically typed language can be considered statically typed with a single type from a single “god-class.” Smalltalk’s message = method. The implementation of a method occasionally throws “message not understood” or “type error” as Python does, another example. The behaviour depends on the object’s tag. It is not different in any way except for unsafety and utter primitivism of the “type system.” Yes, you can achieve polymorphism this way. So you can in Ada by using a giant variant record with the choice discriminant playing the role of a tag. You will find a massive support of this “brilliant” idea in Ada community. Then you can call each record choice a “type” and be incredibly proud of inventing the wheel again… 
Repeating the point ad nauseum, there is no difference except in words and in the consequences for software safety, testability, readability, maintainability.