Re: ada and robots

[Stephen Leake <Stephen.Leake@gsfc.nasa.gov>]

Matthew S. Whiting wrote:
 ( second hand list of supposed Ada deficiencies )

> >*      Ada's strong typing does not allow very complex structures to b=
e
> >manipulated and/or used efficiently due to its typing scheme (which in=
 turn
> >causes a programmer to code many more lines of code, or to structure a=

> >particular data set in a ineffective manner, or not at all).

This is not specific enough; for a counter argument, see the Ada Booch
components, at: http://www.rivatech.com:80/booch/

> >*      Ada does not support discriminant unions (which are extremely u=
seful,
> >almost required). In fact, discriminant union support is required with=
in the
> >data structures that are used within the [one of our systems] data arc=
hitecture; >and in fact,
> >are very critical for supporting applications that need to support man=
y data
> >types within a limited memory area. Ada does have some hacks to get ar=
ound
> >some of these issues (using the USE AT construct) but still can not ge=
t
> >around certain design issues. For example, if a designer wanted to bui=
ld a
> >data area that would store strings, booleans, ints, longs, float, and =
doubles
> >all under one type called MyType (which was defined as a structure tha=
t
> >contained a type discriminant, and a union to hold the desired value) =
and
> >then pass an array of these elements (with mixed types) to a routine f=
or
> >processing=85 A Ada programmer might as well forget it=85  Also, I bel=
ieve this
> >is an issue when declaring an object array with Ada95 where all elemen=
ts must
> >be of the defined type; yet using the C++ array template, one may stor=
e
> >objects of different types into the same array.

This is precisely the Ada discriminant record:

type Label_Type is (String, Boolean, Int, Float);

type MyType (Label : Label_Type :=3D String) is record
   case Label is
   when String =3D>
      String_Value : String (1 .. 80);
   when Boolean =3D>
      Boolean_Value : Boolean;
   when Int =3D>
      Int_Value : Integer;
   when Float =3D>
      Float_Value : Float;
   end case;
end record;

These can be stored in an array.
      =

> >*      Ada does not support conforment arrays. You can not pass an arr=
ay with 5
> >elements to a routine one time and then pass an array of 10 elements t=
he next
> >because of the typing. This is an extremely critical aspect that is ex=
tremely
> >difficult to get around within Ada compared with C/C++ or Pascal. More=
over,
> >this functionality is almost required when processing communications p=
ackets
> >that may be variable-sized.

Wrong again; this is precisely what a String is! The Ada terminology is
"unconstrained arrays".

type String is array (POSITIVE range <>) of character;

procedure Put (Item : in String);

> >*      Ada does not support variable length parameter lists. This is a=
 very tacky
> >aspect of the language, which in turn, causes many more lines of code =
to be
> >generated to support some functionality that requires different data i=
nputs.
> >This limitation can greatly effect a programs function (overload) coun=
t due
> >to this limitation. =


This is true. The reason is type safety and run-time simplicity. When
porting GCC to a new processor, one of my biggest problems was getting
variable arguments working; I'm still finding bugs related to this! But
even given a correct implementation, variable argument lists are just
not type safe. Ada provides alternatives that are safe (see MyType
above).

> >*      DCOM (which OPC will be based) uses DCE IDL. DCE IDL is a super=
set of CORBA
> >IDL and offers many complex data types that are essential for low-leve=
l,
> >high-performance system applications that are not supported in Ada, Ja=
va, =85
> >This lack or inability of the language to handle complex data structur=
es can
> >again increase the lines of coding.

What are the specific types that DCOM requires that (supposedly) cannot
be defined in Ada? This is arguing from ignorance.

> >*      Interface Packages - Another extremely dangerous issue with Ada=
 is the fact
> >that under certain OS's we may be required to write the interface bind=
ings to
> >vendor routines, and these may not be commercially available. And look=
ing at
> >our current IO vendors, they appear to be supplying C/C++ libraries, w=
hich
> >almost guarantees that we will need C bindings to what OS we're using.=

> >VxWorks may have bindings, but what about pSOS, and other potential OS=
's. I
> >do not see to many IO vendors supplying Ada routines for the hardware=85=


This is not an argument against the language itself, but it is relevant.
Currently, there are more bindings available for C; projects that use
Ada will have to write bindings themselves. This will change as Ada
becomes more popular.

A side benefit of writing your own bindings is that you become more
aware of the details of the system you are binding to; this is sometimes
a good thing.

> >
> >
> >Here are just a few items that truly make Ada very ineffective and
> >inefficient to program in =85 And many of them focus around the inabil=
ity of
> >the language to support complex (but required) data structures and typ=
es, as
> >well as, the intolerable type scheme. =


Ada supports all the complex data structures and types that C does;
please give real examples! The fact that one programmer finds the strong
typing "intolerable" does not mean it is not up to the job.

> >The fact the Ada has the following
> >semantics: USE AT, Unchecked_Conversion, Unchecked_Access, and
> >Unchecked_Deallocation; one might ask why Ada needs such dangerous ele=
ments
> >within the language unless they are required so that the language can =
perform
> >certain tasks (which require them). Once elements such as these are us=
ed (and
> >they must in many low-level systems programs), the touted type-safe, r=
obust
> >Ada system is no longer=85 but now in the same field as many other lan=
guages.

Yes, Ada has dangerous features; so does C, C++, and any other
real-world language. The point is that proper system design isolates use
of these dangerous features to small sections of code, and hides them
behind well-defined abstractions. Then the full strong typing of Ada
protects the rest of the system. C and C++ cannot do this.

To paraphrase Robert Dewar, the moral of this story is "don't presume to
critique a language you have not used extensively". In this case, the
critiquer appears to not have used Ada at all!
-- =

- Stephe