An observation of Ada (may offend)

[bill@valiant.gmrc.gecm.com (R.A.L Williams)]

In article <VLADIMIR.95Mar13204932> Vladimir Vukicevic wrote:

[well-deserved dismissal of student gripe deleted]

: Speaking of why people think Ada is not a good language... it'd be nice
: if someone collected the many myths about Ada, and collected them all
: together for distribution to the unbelievers. :-)  This would simplify
: telling people about Ada, especially if all they've heard was that it's
: a "big ugly ancient language used by the government", or that it's too
: 'huge' to be worth doing anything with.

Not 'myths' but 'gripes' - its a matter of perspective!

Some years ago I spent some time writing applications in Ada 83 (of
course, it was just 'Ada' then). I wrote both workstation and embedded
applications and I formulated a number of gripes about the language at
the time. I'm now (re-)learning Ada in its Ada95 form and I'm glad to
see that many of the gripes have been addressed.

Anyway, FWIW, here's a list (in no particular order). I'd be interested 
to see how many strike a chord with other people:

a. No unsigned integers (fixed in Ada95) HCTBAEL.

b. No bit level manipulation (fixed in Ada95 but only for unsigned
ie. mod INTEGERs, I can't test a sign bit, not that I need to) HCTBAEL.

c. Inflexible I/O - no unformatted binary files - this may
have been fixed in Ada95 but GNAT doesn't support STREAMs yet so
I haven't been able to play with it.

d. No pointers to functions - except for the 'ADDRESS attribute which,
being a chapter 13 item is at the whim of the compiler vendor (not very
portable). This is fixed in Ada95.

e. No short cut operators (+= etc.) -- sorry, we've had this debate
already in another thread, I've heard the objections, I still like the
operators.

f. Undefined 'baggage' in the run-time system. OK, this is unavoidable
with a language like Ada, it makes me nervous with Eiffel and C++ as
well, but, so far, I haven't tried to use those languages in embedded
systems (got a C++ one coming up soon). Its not so much needing a
run-time system, its not knowing what's in it. This is largely a compiler
vendor issue, not a language issue. HCTBAEL

g. Task overhead for serialized data access. Fixed in Ada95 with
protected types I believe, that's one of the next things to play with.

h. And a special one for Ada95: poor encapsulation of objects. I can
define a 'member function' for a class by including the class in the
parameter list. Unlike C++ or Eiffel, I can do this *anywhere* in my code,
even a nested function hidden somewhere seemingly 'irrelevant'. Whereas
other features of Ada go out of their way to force the programmer to
follow 'good practice' (sometimes a matter of opinion), this seems
very lax.

HCTBAEL = "How can this be an embedded language?" 

My experience with Ada, confirmed by many people that I spoke to at the
time was that, for embedded systems at least, Ada was used as cosmetic
window dressng to a vast quantity of assembler. This was made necessary
by the shortcomings of the language for addressing low level machine
interactions. To some extent, the same was also true of X11 software
on workstations. I see from responses in other threads that this may
have changed in recent years. All I can say is about time!

: 	-- Vladimir Vukicevicn
: 	-- vladimir@intrepid.com

Bill Williams
bill.williams@gec-mrc.co.uk