Structure Comparison (ADA vs C)

[mat at hou5d.UUCP]

>From a net author:
	ADA is the best, safest way of expressing algorithms and data
	structures that I have seen yet. It is the result of painstaking
	effort by better informed language designers than almost any of the
	contributors to this newsgroup (I include myself in that description).
	It beats the pants off C for most work -- a shame that its concurrency
	(its most talked about point) is unlikely to be up to scratch for
	serious real time use. GO AWAY AND LEARN IT. Your C might even be
	better afterwards.

Alright.  I HAVE learned Ada (TM of DoD, as you failed to mention).  I learned
it (early Stoneman) from Jerry Fischer @ NYU/Courant, and while I haven't made
large-scale use of it, I feel that I am qualified to at least TALK about some
of it.

	"ADA is the best, safest way ... yet."

Well, Ada MAY have the advantage that only experienced programmers will be
able to get off the ground with it;  this MIGHT prevent nincompoops from being
allowed to write critical code.  I wouldn't bet on it, though.

The bigger the language, the easier it is to hide creeping quicksand in it.
What is creeping quicksand?  Well, consider PL/I's system of types.  If you
don't declare everything, and just right, the interplay between types is gonna
getcha.  Part of the problem comes from default assignemt of types to
undeclared things.  A larger part seems to come from the number of independent
attributes that a fundemental data object must have.  part comes from the need
to insert magic and mysterious conversions in funny places like proceedure
calls.  I won't bother the net with examples ... the problem is well known.

PL/I's quicksand is ready-made.  In Ada, however, the rather large number
of degrees of freedom for numerical types makes it easy to devise quicksand
of your own.

What about overloading?  Overloading is a NECESSARY part of Ada;  you cannot
avoid it since all your default operators overload.  If used with care,
caution, and good judgement born of experience, the rather well-controlled
overloading can help you keep your code sensible and orthogonal in data types
vs. algorithms.  But without a LARGE dose of the above, code can degenerate
into a welter of irregular and incomprehensible references to God-only-knows-
which of a group of not-quite-the-functional-same subprograms.

The previous comments apply to generic packages with even more force.  GPs
provide a fantastic opportunity to foul up -- probably at least on order
more in the size of the programming effort.  They can also be used well.
How many ``real world'' programmers and how many ``maintanance programmers''
will have the needed programming strengths?  I can only pray ... .

What about knowing when to use fully qualified names (Package.Package.Proc() )
and when to get at things with WITH clause ; USE clause ?  Not too tough a
choice if you REALLY know what's going on ... hmm, maybe a tough choice indeed.

Please don't get me wrong ... Ada does a LOT of things right, especially around
enumerated types and the special uses of the "'" operator (like getting a
printable name for your enumeration objects and discriminating between
enumerated types whose objects have the same names).  There are a LOT of
things that were done, in my opinion, ten years too soon.  One of the strengths
of C is the fact that the language really contained nothing new.  Can you say
the same for Ada?  And some of the strengths could/should be taken right into
C.  Today.  But that doesn't mean that everything in Ada was done right.

And what about the problem with the programmer who has a harder and harder time
judging the execution costs on his machine?  The ability to hide a great
deal of work or a complex data structure behind an overloaded operator is
nice, but if you are programming something that is a factor of four away
from becoming time critical, you are going to have to be concerned about
execution costs.

Ada also has a VERY large number of keywords, used in a rather irregular
way.  One has to say ``let's see, is it the IN keyword or the OF keyword
that goes in this statement ...''.  Experience will help here, it is true,
but the list is about 3 times bigger than it has to be and about three
times bigger than seems comfortable.

Finally, I don't share your pessimism about Ada's tasking.  It looks like
a rather good way to do things IN SELF CONTAINED SYSTEMS.  Within the UN*X
kernel, however, it would just get in the way.  You pays yer money and yer
takes yer chers.

Ada was both designed and tested in an industrial/academic laboratory
environment.  DoD should have waited until AFTER the compilers had been
validated and in use in industry for two years before calling the final
freeze on the language.  The issues raised above, and many others, could have
been much better settled that way.  As it stands, the tricky and subtle
issues that came up in Ironman and thereafter were settled by voting
across a large pool of academics.  I don't trust decisions like that.

					Mark Terribile
					Duke of deNet