Re: ada and robots

["Matthew S. Whiting" <whiting@epix.net>]

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


Robert Dewar wrote:
> 
> I asked Joe for specific code, and he responded:
> 
> <<There is tons of such code available for free on the internet.  Just look
> for I/O drivers, such as for UNIX and VxWorks. VxWorks Board Support
> Packages are another example.
> 
> Even C-coded I/O drivers and kernel initialization sequences resort to
> some assembly code.
> 
> As for shared memory, look into the handling of driver comm pools, queues
> shared between tasks and also with ISRs.  And so on.
>  >>
> 
> Sorry that is not what I asked for. I asked for specific code. If you are
> just repeating what others have told you, fine, such second hand information
> is often ill-informed and inaccurate. But if on the other hand, you have a
> real technical point to make, please illustrate it with very specific code.
> 
> (P.S. I have written lots of device drivers, and I cannot think of anything
> I have ever done that could not be done in Ada), but if you think you have
> such an example, let's see it!

Robert,

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.  I'm not an Ada expert so I'm
not qualifed to respond to his list point-by-point, and you may not wish
to take the time, but here at least are some specific points rather than
vague generalities.  As background, the author of the note below is
currently quite proficient in C and C++ and formerly programmed in Ada
(Ada83) for a defense industry contractor.  He's taken a cursory look at
Ada95, but remains convinced that Ada is inferior to C++ (and probably
even C) for the kinds of systems we develop (industrial process, machine
and motion control systems primarily).

I've tried to sanitize the message below to eliminate the name of my
company and the author.  Hopefully, I succeeded (Netscape has no "find"
function when doing a newsgroup reply ... sigh).

Matt

>Matt,
>
>OK � I am glad you are not a Macintosh advocate too. I guess this Ada debate
>is too much like debating PC vs. Macintosh (or I guess this is how I associate
>the Ada camp trying to get acceptance). The debate is very similar. Ha ha �
>
>I remember the discussion with [another colleague] and my comments about Ada. I
>remember stating that Ada was by no means a good language of choice for doing
>low-level complex programming, but you could use Ada (as well as many other
>languages that are also non-efficient). I said, "Ada is not as effective or
>efficient as C/C++ in writing device drivers (low-level programming)�", which
>I do not think any programmer could argue due to many factors:
>
>*      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). 
>*      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 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. Moreover,
>this functionality is almost required when processing communications packets
>that may be variable-sized.
>*      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 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;
>
>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.
>
>*      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.
>*      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. And looking at
>our current IO vendors, they appear to be supplying C/C++ libraries, which
>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�
>
>
>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.
>
>
>There truly are many more serious negatives with Ada programming versus
>C/C++. I, as well as many others, realize that one must design and program a
>system correctly (with proper CM and SQA) but feel that C++ by far gives a
>programmer much more programming efficiencies than Ada; and in the long run a
>better performing and reliable system.
>
>I think I could go on and on about many different areas that would be
>negatives for [our company] (regarding resourcing, software development, vendor
>support, tool & analysis support, �) but I don't want to keep re-living these
>facts. I feel that C++ and C are buy far the best solution for [our company]. We
>are currently using C/C++, many vendors that we have are using C++ (and do
>not support Ada), DSP development has now moved to C, etc., along with the
>items I placed in my decision analysis.
>
>Hopefully I have given you enough reasons why Ada is not any programmers
>choice for low-level systems programming. If not, we should try writing a
>device driver for a simple timer card for NT. I think it would become
>extremely clear at that point.