From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: fd6dd,c78177ec2e61f4ac X-Google-Attributes: gidfd6dd,public X-Google-Thread: 103376,c78177ec2e61f4ac X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: ada and robots Date: 1997/06/17 Message-ID: X-Deja-AN: 249144566 References: <338CDA96.53EA@halcyon.com> <33A5D644.37A3@epix.net> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.robotics.misc,comp.lang.ada Date: 1997-06-17T00:00:00+00:00 List-Id: In article <33A5D644.37A3@epix.net>, Matthew S. Whiting 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