Re: ada and robots

[jsa@alexandria.organon.com (Jon S Anthony)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 10748 bytes --]


In article <33A5D644.37A3@epix.net> "Matthew S. Whiting" <whiting@epix.net> writes:

<A request for some answers to a co-workers specific "reasons" for why
Ada is not "efficient">

> vague generalities.  As background, the author of the note below is
> currently quite proficient in C and C++ and formerly programmed in Ada
> (Ada83)

As indicated below, the last claim in this statement is very difficult
to believe.  Certainly the fellow does _not_ know even elementary
level Ada.


> >*      Ada does not support discriminant unions (which are extremely useful,
> >almost required). In fact, discriminant union support is required within the
> >data structures that are used within the [one of our systems] data architecture; >and in fact,

At first I thought he meant UNdiscriminated union - the sort of thing
you often see in C stuff (where there is no field in the struct
denoting at runtime which variant of the union is currently active).


> >some of these issues (using the USE AT construct) but still can not get
> >around certain design issues. For example, if a designer wanted to build 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 that
> >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 for
> >processing� A Ada programmer might as well forget it

But then I read this and realized he really _did_ mean discriminated
union.  This is trivial in Ada (including Ada83) and I've done the
very thing he mentions many times.  Here's a canonical form:

    type My_Type ( Kind : Kind_Type ) is record
        case Kind is
    	    when Stg =>
    		S_Val : String_Ref;
    	    when Bool  =>
    		B_Val : Boolean;
    	    when Int   =>
    		I_Val : Integer;
    	    when Long  =>
    		L_Val : Long_Integer;
    	    when Flt   =>
    		F_Val : Float;
    	    when Dbl   =>
    		D_Val : Long_Float;
        end case;
    end record;

type My_Array_Type is array ( Natural range <> ) of My_Type;

...

function F ( X : My_Array_Type ) return ... is
...
    for I in X'range loop
        case X.Kind is
            when int => ...
        ...
end F;


So, at this point (as you can understand) this person's credibility is
closing in on zero.


> >be of the defined type; yet using the C++ array template, one may store
> >objects of different types into the same array.

This is just plain wrong - even for C++!!!  The only thing letting you
store different type objects into a C++ array is if the type is
somehow polymorphic (NOT the array, but its element type).

A template works (more or less) like a generic in Ada (where a generic
array type could be exported - but there is no good reason to do this
in Ada as it already directly supports arrays).

A typical array template in C++ gives you nothing more than what you
can get in Ada by merely writing:

(a)    type Some_Array_Type is array ( Natural range <> ) of Element_Type;

Then you can write:

    A : Some_Array_Type(0..Get_The_Desired_Size);

    B : Some_Array_Type := Some_Initial_Value;

etc.

So, there is the extra step of giving (a) for each element type - but
then you don't need to write or use a template - which your compiler
probably can't compile anyway and which you will almost certainly get
different results from different compilers (and your arrays will be
more efficient).

If you really want a single polymorphic array type, then make the
element type polymorphic:

    type Object_Type is tagged ...

    type Element_Type is access all Object'Class


> >* Ada does not support conforment arrays. You can not pass an array
> with 5 >elements to a routine one time and then pass an array of 10
> elements the next >because of the typing. This is an extremely
> critical aspect that is extremely >difficult to get around within
> Ada compared with C/C++ or Pascal.

This is outright embarrassing for this person.  This is exactly what
unconstrained arrays give you and you get much more expressivity with
them than with C or C++ or Pascal or many others.  Function F above
shows this very thing in action (this is all _very trivial_ and
elementary Ada forms - i.e., anyone will know this stuff after only a
brief aquaintence with the language).  A trivial example using
Some_Array_Type where Element_Type has an "+" operation defined and an
appropriate Identity_Element (for example, if Element_Type is Integer,
and "+" is regular addition, then Identity_Element is 0):

function Sum ( X : Some_Array_Type ) return Element_Type is
    S : Element_Type := Identity_Elememt;
begin
    for I in X'range loop
        S := S + X(I);  -- Dispatch to correct "+"
    end loop;
    return S;
end Sum;


...
    ... Sum((1, 2, 3, 4));  -- returns 10
    ... Sum(("a", "B", "C", "d"));  -- returns "aBCd"


> >* 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 inputs.

This is really silly.  Just use an array of discriminated types and
pass an explicit aggregate:

    -- Call F with varying number of arguments:
    --
    ... F(( (Int, 2), (Flt, Pi), (Stg, "Hi There") ));
    ... F(( (Bool, True), (Dbl, E) ));

You can also use default parameters for this sort of thing and use
named notation:

function X ( Amps : Current_Type := 0.0;  Voltage : Power_Type := ...);

   ... X(Voltage => My_Power);
   ... X(Amps => My_Current, Voltage => Some_Power);


> >printf("\n\n The roller outputs for Roll[%d] are:\n Torque-%f\nVelocity-%f\
> >nForce- %f\n", roll, torque, velocity, force);
> >
> >Ada Code:

This is ridiculous.  "Everybody" knows a) you can make printf in Ada
via overloads of "+" on the data types or b) just write the thing
using the more direct equivalent:

Real Ada code (not strawman rubbish) (Lf is a 1 char string of Ascii.LF):

 Put( Lf & Lf &
     "The roller outputs for Roll(" & Integer'Image(Roll) & ") are:" & lf &
     "Torque-" & Float'Image(torque) & lf &
     "Velocity-" & Float'Image(velocity) & lf &
     "Force-" & Float'Image(force) & lf);

> >for debug would be very nice � And this is a simple example of
> why variable >length parameter lists are so very important. Just
> think if you had a

This is not an example of why variable length parameter lists are
important (I'm not convinced they even _are_ important).  This is just
a silly thing where you want to call an I/O function once.  Trivial
and BFD.


> >Parser() routine that could parse a variable length input list of
> 20 >parameters �, you sure would have a lot of Ada routines for
> each list item to >write and maintain.

No you wouldn't.  Well, if this fellow were hacking it up you might,
but that only shows his own incompetence - not a problem with Ada.


> >* DCOM (which OPC will be based) uses DCE IDL. DCE IDL is a
> superset of CORBA >IDL

DCE IDL is not a superset of CORBA IDL.  It is a different thing
offering similar functionality.


> and offers many complex data types that are essential for low-level,
> >high-performance system applications that are not supported in Ada,
> Java, �

Like what?  Really - this guy does not know what he is talking about.


> >This lack or inability of the language to handle complex data
> structures can >again increase the lines of coding.

What complex data structures?  Discriminated unions?  They are trivial
and hardly "complex".


> >* Interface Packages - Another extremely dangerous issue with Ada
> is the fact >that under certain OS's we may be required to write the
> interface bindings to >vendor routines, and these may not be
> commercially available.

No, this too is wrong.  You can directly access the libraries just
like you would from C/C++.  NOTE: when I say "just like in C/C++"
here, I mean just that.  It will be no more safe or clear than what
you get in those languages.  But then, that is what you would have to
do if using C or C++.  So this is neither a disadvantage nor an
advantage.


> >almost guarantees that we will need C bindings to what OS we're using.

No - just grab the routines you want and use the same low level calls
as you would in C/C++.  The smart thing would be to put this rubbish
in a package body and export an OS _independent_ abstraction (for
which you could plug in various OS dependent bodies) - I've done this
and it's cake.


> >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�

Same here.


> >Here are just a few items that truly make Ada very ineffective and
> >inefficient to program in �

Too bad for this person, they are _all_ in error.  In fact, it seems
clear he does not even understand C++ templates (well, to be fair,
probably nobody really does...)


> And many of them focus around the inability of >the language to
> support complex (but required) data structures and types, as

Like what - discriminated unions??  We've seen he is just plain wrong
about this.


> >well as, the intolerable type scheme. 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 elements >within the language unless they are
> required so that the language can perform >certain tasks (which
> require them).

They are there in order for you to break the type system **IF** you
determine this is really necessary.  And they are specifically ugly in
order to a) call your attention to the fact that something funny is
happening here and b) to in some measure prevent you from willy-nilly
sinking to such low level design at the drop of a hat.


> >There truly are many more serious negatives with Ada programming versus
> >C/C++.

Well - he hasn't managed to come up with even one yet.


> >I think I could go on and on about many different areas that would be

And I suppose this would be a littany of errors as well.


> >Hopefully I have given you enough reasons why Ada is not any programmers

Sorry - he hasn't haven't given _any_!!  In fact, he's given reasons
why using Ada would be a _good_ idea.  Every example this person gives
is _easier_ to do in Ada!!


> >device driver for a simple timer card for NT. I think it would become
> >extremely clear at that point.

Well, if this person is writing it, I would believe it would be
screwed up.  You need a competent Ada person, then it would be obvious
that this too would be a non-issue.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com