Re: Teaching new tricks to an old dog (C++ -->Ada)

[<adaworks@sbcglobal.net>]

"Ioannis Vranos" <ivr@remove.this.grad.com> wrote in message
news:1111719129.745924@athnrd02...
>
> In C++, multithreading is platform-specific. I think this is better than
> Ada, but may be I am just used to it.
>
Better is a relative assessment, in this case.

When concurrency is a part of the programming language,
the language is simpler.  If Ada did not have concurrency,
many other things in the language would be much easier.
The addition of concurrency, as part of the language
definition, does place some restrictions on some features
that some designers might find less restrictive in other
languages.

On the other hand, Ada's expressive power includes the
ability to write concurrent program units that are checked
for consistency by the compiler.   An important idea
in Ada concurrency is that the tasks (Ada's primary
unit for concurrency) are as type safe as the rest of
the program.   They are also portable across many
different platforms.

The ability to write type-safe, portable concurrent software
has proven its value in many projects.

There are always tradeoffs.  When we compare any set
of languages, feature by feature, we have to realize that
someone can easily highlight some set of features in one
that is present or absent in some form or other.  Further,
some of us will find a feature of a language ugly, difficult,
or ask "Why would I even want to do that?" when others
will revel in their good their good fortune as having such
a feature available.

The example of C++ templates versus Ada generics has
been cited.   I understand the very interesting instantiation
model of C++.  In fact, I had to explain it to a colleague
about a year ago who was stymied by its seemingly
obfuscating nature in a program he was trying to read.
And, I am not one of those who is particularly enamoured
of it.   Ada generics, with the exception of generic formal
package parameters, are wonderfully easy to understand,
and have consistenly provided a good model for writing
easy to understand code.   On the other hand, with generic
formal package parameters, a more difficult concept (but
one I have tried to clarify in my Ada Letters article several
years ago),  we can accomplish things that can be done
with C++ templates, and some of those things a little
better.

In this thread, we have discussed C++ templates as a
way to do the equivalent of Ada's range definitions;  posted
code to prove that Ada is better than C++ or that C++ is
better than Ada;  lamented that language A does not have
the features of language B;  argued that language A does
not really need the features of language B; and retaliated
to ad hominen attacks by lobbing code grenades across
the entire set of comp.?.? Newsgroups.

By now it should be clear that some of us prefer Ada for
some kinds of programming.  Some of us who also use
C++ understand that we have to live with it, and that it
can be useful for certain classes of programming.   Those
who prefer C++ are unlikely to ever succumb to the
charms of Ada.   It is reminiscent of the old saw "He
convinced against his will, is of the same opinion still."

So is there a common ground for the two sides?   I suppose
we could agreee that neither language is ideal.   There are
features I would like to see in Ada.   There are things I
would like to have in C++.   Java is not an option, not for
the kind of programming I do.   Eiffel comes pretty close
to being a good option.  I prefer it to C++, but still lean
toward Ada, at present.

At present there is no way for anyone to win this debate,
certainly not as long as we restrict the conversation to
a comparison between two imperfect languages.   Then
again, I defy anyone to introduce a third language into the
debate that is not imperfect.  I don't don't think there is
one.

Dr. Richard Hamming, a pioneer in computer science I
once had the honor of knowing, once said of our profession,
"We stand on the toes of giants."    It is strange that any of
us have the audacity to proclaim that our preferred language
deserved such reverence when we all know that they all
fall short of what we really need to build the kind of software
necessary for the coming century.

Richard Riehle