Re: Ada vs C++ vs Java

[adam@irvine.com]

In article <8p6yan1xger.fsf@Eng.Sun.COM>,
  Mike Coffin <mhc@Eng.Sun.COM> wrote:

>
>   Matthew Heaney <matthew_heaney@acm.org> writes:
>
>   > I am interested in specifics.  List 5 specific language features by
>   > which you conclude Ada is "complex."
>
>   I'll have to answer based on Classic Ada; I haven't had occasion to
>   look seriously at the latest version.
>
>   Here are some broad areas that I think are way too complicated:
>
>   1. Generics.  Ada generics are much more complicated and harder to use
>      than need be.

So don't use them.

>      If you insist on complete run-time type checking,
>      ML's type system is easier to use and more powerful.  (I don't
>      blame Ada for this: Hindley-Milner-style type systems probably
>      didn't exist and certainly weren't widely known.)  I know that
>      there were some efforts to get some type-inference technology into
>      Ada Mark II or whatever it's called, but I don't know if any
>      succeeded.
>
>      On the other hand, if you're of the opinion that exceptions do
>      happen, and that type exceptions are just another kind of
>      exception, OO type systems such as Java and Smalltalk are a *lot*
>      simpler than Ada's.

I don't know enough about ML's type system to comment.  However, I've
never thought of Ada's type checking system as complicated.  You have
types, and for each type you can have subtypes.  When you move stuff
from one variable to another, or from an expression to a parameter, or
whatever, the types have to match.  That's the basic idea.  How hard
is that to understand?  It does get a bit more complicated when Ada
95's tagged types and class-wide types are involved.

>   2. Rendezvous.  Compare accept/select/when, with all their
>      permutations and ramifications, with SR's "in" statement which is
>      much more powerful.  (This is chiefly because "when" clauses can't
>      reference entry parameters in Ada).  In fact, compare all of Ada's
>      interprocess communication with SR's.  SR's is much more powerful
>      and easier to use.  (But I'm biased; I worked on SR back when the
>      world was new :-)

So don't use rendezvous.  (I don't know anything about SR, but your
fictional programmer never mentioned this; he was trying to argue for
using C.)

>   3. Treatment of variables shared between tasks.  Task A changes a
>      variable.  When does task B see the change?  Trying to maintain too
>      much generality made Ada much more complicated than any language I
>      can think of in this regard.  It's not so much that the language
>      rules are complex, it's that writing programs that work reasonably
>      given then weak language rules is so hard.  Anyone know of another
>      language that tries to conflate shared-memory and distributed
>      programming?

So don't use tasks.

>   4. Parameter passing.  Three modes; named parameters; default values
>      (but not for in-out parameters, for some reason).

If you say "for some reason", then you really haven't grasped what the
in-out parameter mode is for.  It's for passing a variable that the
procedure is supposed to modify.  A default value would make no sense.

>      In spite of all
>      the features, the behavior is mostly unspecified for arrays and
>      records.

I fail to see how this is "complicated".  It's really simple.  An "in"
parameter is one that goes IN to the procedure.  The procedure uses it
as INput, not as OUTput.  An "out" parameter is one that the procedure
uses as OUTput; it's not used as INput and should not use whatever
value the parameter has when the procedure starts.  An "in out"
parameter is both INput and OUTput.  The procedure takes its current
value as INput, but may modify the value, i.e. OUTput.  How is this
complicated?  I'm sure my 16-month-old could understand it.  (Well,
that's an exaggeration, but he's very good at taking everything out of
a box and putting it back in, and the concept behind Ada parameter
passing isn't much more difficult that that.)  Meanwhile, in C, if you
declare a parameter type to be a pointer, you can't tell whether the
procedure actually wants to input a pointer, or whether it wants to
input the address of an array, or whether it's trying to emulate Ada's
"in out" parameter.  Is Ada really more complex here?  Which one is
harder to learn, harder to use, harder to read?

As far as being unspecified for arrays and records, that's just not
true.  It works just the same as scalars.  If you have an IN OUT
record or array parameter, the variable used by the caller has its
value passed to the procedure, and the procedure gives the variable a
new value.  Same as for anything else.  What's unspecified is that you
don't know whether the variable gets its new value at the end of the
procedure or at some time before that, but usually that doesn't
matter.  In fact, that's a good feature, because it has allowed
compilers that will pass *small* records and arrays in registers and
lets the procedure work with them efficiently in registers, while in
some languages, your only option is to pass the address of the record
or array and force the procedure to make indirect registers through
that address.  I know, you probably think the only computer around is
the register-challenged Intel 80x86/Pentium, in which this isn't an
issue because there aren't enough registers for passing parameters.

As for default values: So don't use them.

>      Compare with rules of C, Java, or almost any other
>      language: they lack *all* these nifty features and seem to get
>      along fine.

So does assembly language, for that matter.

>   5. Overloading.  Do result types matter?  Do parameter names matter?
>      Do default values matter?  Why, or why not?  And, hey:
>      parameterless subroutines and enumeration literals look sort of the
>      same.  Can they overload each other?  Can they hide each other?  If
>      so, when and where?  It could be worse though, as C++ demonstrates.

So don't use this feature.

Out of the five things you think are "way too complicated", four and a
half of them are things that you don't need to use to program in Ada.
I mean, if your complaint is that "Something I can do easily in C [the
language your fictional programmer wanted to use] is complicated to do
in Ada", you might have a valid argument.  But all these examples are
more of the form "Something is complicated in Ada that C doesn't
support at all."  So how is Ada's "complexity" a negative?  OK, so
tasks might be complex, but if you have a program that doesn't need
them, so what?  And if you have a program that does require this kind
of concept, is it "less complex" to do it in C, where you'd have to
write all the synchronization and task-switching and time-slicing
routines yourself?  Maybe "overloading" seems complex (although I
don't see why), but C doesn't have it at all, so you have to come up
with distinct names for everything---so why can't you just do the same
thing in Ada?  Ada does not put a gun to your head and say you must
understand and use overloading.  It's a nice feature if you want to
use it, but if you don't, don't---why would that be a point against
using the language?

I recently bought Quicken Deluxe 99.  There are a lot of options on
there that I don't understand at all, and I'd have to do a fair amount
of reading to see if I wanted to use them and then to use them
effectively.  So what?  Does this mean I'm supposed to return the
program to the store?  The program does the things I need to do all
the time nicely, and I like it; and as for the other features, maybe
if I have time I'll look into it, but I don't need to know anything
about them in order to use the rest of the program.  Ada is pretty
much the same way, and I just can't understand why this "too complex"
argument is used so often as a reason not to use Ada (particularly by
people who want to use C).  It seems silly.


>   Next time I make a joke I'll make it about something that people don't
>   take so damn seriously.  Death, famine, or nuclear winter maybe. :-)

No, next time you make a joke that's not intended to make a point,
write it in such a way so that it looks like it's not intended to make
a point.  Sometimes humor is just to make people laugh, but sometimes
it's a good form for expressing an opinion.  Since several people
(including myself) have assumed you were attempting the latter, I'd
say that the fault lies in your writing style, not in our being
humor-impaired.  And if you were really trying to make a point, then
expect your point to be criticized.

                                -- Adam

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own