Re: Ada / C++ comparison paper

["Hyman Rosen" <hyrosen@mail.com>]

David C. Hoos wrote (in an e-mail to me):
> Agreed that the cited paper is approaching ten years of age --
> but would you do the kind service to the community of
> pointing out just which are the "typical lies, half-truths, and
> drive-by shootings" of which this paper is "full?"
>
> I, for one, do not wish to repeat "typical lies, half-truths,
> and drive-by shootings" in my advocacy of Ada.

I don't intend to do a line-by-line refutation, but I'll post a
few examples. I should state that I am not claiming that
C++ is better than Ada, and I'm even willing to entertain
the notion that Ada is better than C++. But that doesn't
mean that every Ada advocacy statement is correct.

The age of the paper makes some claims now completely
false. C++ has a standard, and exceptions and templates
are widely (universally, actually) implemented. C++'s
exception mechanism is unarguably superior to Ada's,
and its template mechanism is arguably so.

The paper claims that Ada's library mechanism is
superior to C++'s ad hocery of Makefiles, tools, and
conventions. But Ada's library mechanism is simply a
description of what depends on what, and what must be
recompiled when something changes. The actual
mechanisms used by Ada compilers are wildly different,
and must be learned anew on each platform. Pray tell,
for example, where the Ada standard mentions
"gnatchop". Indeed, for a long time some Ada library
mechanisms were notorious for "recompile the world"
problems, and programmers would go through
contortions in editing their code to avoid this.

The paper says "Many consider [C++'s friend mechanism]
unsafe, and advise against its use". This is what I mean by
a drive-by shooting, similar to "Many consider Ada's syntax
ugly and difficult to read because it lacks punctuation". In
fact, a C++ programming abstraction is typically formed by
several related classes and non-meber functions, and there
is nothing unsafe in allowing those functions access to internal
class members. Not only that, but the paper itself argues that
Ada's lack of member functions is an advantage of Ada!

The paper claims that code reuse is the critical benefit of OOP.
This is nonsense, implying, among other things, that OOP has
an "eat your spinach" flavor - that it's use in a project is primarily
for the purpose of aiding future projects. I would suggest that
OOP's critical benefit is run-time polymorphism.

Section 4 of the paper is just plain strange. It argues that if I
have a dispatching merge(x, y: parent) function then I want
inheritance to enforce same-tagness on the method which
derived classes inherit. Why? Or more precisely, sometimes
I might and sometimes I might not, but I don't see why it is
an advantage of Ada that it assumes one or the other. The
paper also says that merge defined as a member function in
C++ would take a parent parameter and not a child. But the
object structure means that a child is-a parent, so you could
pass in a child. The section also claims that it is possible in
C++ to "subvert the dispatching mechanism and to call a
dispatching operation with invalid arguments -- and unpredictable
results" but fails to give an example. The reason is that no such
subversion mechanism exists!

The paper argues that C++'s lack of a standard for multi-
tasking and real-time programming leads to the use of ad-hoc,
unportable, and incomplete libraries. It fails to mention that
Ada's lack of standard containers and algorithms leads to the
same (as witness the unending List Strawman thread).

The paper claims that C++ programs "can easily become
contaminated with environmental details". I invite you to read
http://groups.google.com/groups?hl=en&lr=lang_en&selm=7j7d4e%24hc%241%40nnrp
1.deja.com.
What prevents Ada programs from becoming contaminated
with non-standard pragmas and representation clauses?