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: jsa@alexandria.organon.com (Jon S Anthony) Subject: Re: ada and robots Date: 1997/06/17 Message-ID: X-Deja-AN: 249161545 References: <338CDA96.53EA@halcyon.com> <338F5D7D.6C03@tiac.net> <338F9D05.5EB3@bix.com> <5mqpj3$bc5$1@goanna.cs.rmit.edu.au> <33930245.12A1@sprintmail.com> <5mv984$7kn@news.emi.com> <33A5D644.37A3@epix.net> Organization: PSI Public Usenet Link 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" writes: > 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