Re: ada and robots

[bobduff@world.std.com (Robert A Duff)]

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


In article <33A5D644.37A3@epix.net>,
Matthew S. Whiting <whiting@epix.net> wrote:
>Robert Dewar wrote:
>> 
>> I asked Joe for specific code, ...

>I'm not Joe, but I've been having a similar line of, shall we say,
>"discussion" with a colleague where I work.  Here's his reply when I
>asked for specific issues that C or C++ could easily handle that were
>difficult or impossible to handle in Ada.  

Still not specific.  Robert asked for specific C code, and we still
haven't seen any.  Your colleague gives us (1) vague generalities, and
(2) misinformation.

>>*      Ada's strong typing does not allow very complex structures to be
>>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 an example of (1).  You should insist that your colleague show
the C code for at least one such example.  Only *then* can we argue
about whether Ada can't do it, or can't do it well.  From the above, I
have no idea what he's talking about.

>>*      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,
>>are very critical for supporting applications that need to support many data
>>types within a limited memory area. Ada does have some hacks to get around
>>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�  Also, I believe this
>>is an issue when declaring an object array with Ada95 where all elements must
>>be of the defined type; yet using the C++ array template, one may store
>>objects of different types into the same array.

Ada *does* have discriminated unions, and can do the above (passing
array, blah blah blah).  The only problem I can see here is that Ada
insists that the discriminant be part of the object, whereas some
hardware-defined data structures encode the "discriminant" in weird
ways.

>>*      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 so vastly wrong (for both Ada 83 and Ada 95) that I have a hard
time believing that your colleague ever wrote an Ada program.  I mean,
the simplest "Hello, world" program in Ada uses this feature -- how
could he have missed it?

>>*      Ada does not support variable length parameter lists.

Granted.  IMHO, a "nice to have" feature, but certainly nothing to do
with why C is better or worse at accessing low-level hardware
functionality.  It was left out of Ada to simplify the language.

>... 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 limitation can greatly effect a programs function (overload) count due
>>to this limitation. For example, lets look at the following simple
>>non-critical I/O code:
>>
>>C Code: 
>>
>>printf("\n\n The roller outputs for Roll[%d] are:\n Torque-%f\nVelocity-%f\
>>nForce- %f\n", roll, torque, velocity, force);
>>
>>Ada Code:
>>
>>Ada.Text_IO.New_Line(2);
>>Ada.Text_IO.Put("The roller outputs for Roll[");
>>Ada.Int_IO.Put(roll);
>>Ada.Text_IO.Put("] are:");
>>Ada.Text_IO.New_Line;
>>Ada.Text_IO.Put("Torque-");
>>Ada.Real_IO.Put(torque);
>>Ada.Text_IO.New_Line;
>>Ada.Text_IO.Put("Velocity-");
>>Ada.Real_IO.Put(velocity);
>>Ada.Text_IO.New_Line;
>>Ada.Text_IO.Put("Force-");
>>Ada.Real_IO.Put(force);
>>Ada.Text_IO.New_Line;

In Ada, I would write something like this:

    use Ada.Text_IO;
    ...
    New_Line(2);
    Put_Line(" The roller outputs for Roll[" & Image(Roll)
             & "] are:");
    Put_Line(" Torque-" & Image(Torque));
    Put_Line(" Velocity-" & Image(Velocity));
    Put_Line(" Force-" & Image(Force));

Given suitable Image functions (which I always define), or else use the
standard 'Image attribute.  We can argue about whether this is better or
worse than the corresponding C code, but it's nowhere near as bad as
the Ada code your colleague wrote.  I claim my Ada code is far better
than the C code, since it does type checking.

>>I don't think a lot of debug text I/O to a VT320 screen included in a system
>>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
>>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.

I agree that variable-length parameter lists are a nice convenience.
However, your colleague is wrong: in Ada, you would *not* have 20
overloadings here -- you would have a procedure that takes a single
parameter of some sort of array or sequence type.

>>*      DCOM (which OPC will be based) uses DCE IDL. DCE IDL is a superset of CORBA
>>IDL and offers many complex data types that are essential for low-level,
>>high-performance system applications that are not supported in Ada, Java, �
>>This lack or inability of the language to handle complex data structures can
>>again increase the lines of coding.

I don't know DCE IDL enough to comment.

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

Granted.  This is a problem with using Ada.

>>Here are just a few items that truly make Ada very ineffective and
>>inefficient to program in � And many of them focus around the inability of
>>the language to support complex (but required) data structures and types, as
>>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). Once elements such as these are used (and
>>they must in many low-level systems programs), the touted type-safe, robust
>>Ada system is no longer� but now in the same field as many other languages.

This is a bogus argument.  Just because one part of a program uses a
low-level features like Unch_Conv, doesn't mean that *all* of the
benefits of Ada are lost to the *entire* program.

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

I count one and a half in the above.  So lets see the "many more".

Again, let's see the C.  Real code.  Ask your colleague to show us some
C code (for a device driver, or part of one, for example), and let's see
whether Ada is up to the job.  I will freely admit that Ada has many
flaws, but the above series of incorrect claims about Ada doesn't help.

- Bob