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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fd6dd,c78177ec2e61f4ac X-Google-Attributes: gidfd6dd,public X-Google-Thread: 103376,c78177ec2e61f4ac X-Google-Attributes: gid103376,public From: Stephen Leake Subject: Re: ada and robots Date: 1997/06/17 Message-ID: <33A69E46.3230@gsfc.nasa.gov> X-Deja-AN: 249076279 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: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Reply-To: Stephen.Leake@gsfc.nasa.gov Newsgroups: comp.robotics.misc,comp.lang.ada Date: 1997-06-17T00:00:00+00:00 List-Id: Matthew S. Whiting wrote: ( second hand list of supposed Ada deficiencies ) > >* Ada's strong typing does not allow very complex structures to b= e > >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 not specific enough; for a counter argument, see the Ada Booch components, at: http://www.rivatech.com:80/booch/ > >* Ada does not support discriminant unions (which are extremely u= seful, > >almost required). In fact, discriminant union support is required with= in the > >data structures that are used within the [one of our systems] data arc= hitecture; >and in fact, > >are very critical for supporting applications that need to support man= y data > >types within a limited memory area. Ada does have some hacks to get ar= ound > >some of these issues (using the USE AT construct) but still can not ge= t > >around certain design issues. For example, if a designer wanted to bui= ld 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 tha= t > >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 f= or > >processing=85 A Ada programmer might as well forget it=85 Also, I bel= ieve this > >is an issue when declaring an object array with Ada95 where all elemen= ts must > >be of the defined type; yet using the C++ array template, one may stor= e > >objects of different types into the same array. This is precisely the Ada discriminant record: type Label_Type is (String, Boolean, Int, Float); type MyType (Label : Label_Type :=3D String) is record case Label is when String =3D> String_Value : String (1 .. 80); when Boolean =3D> Boolean_Value : Boolean; when Int =3D> Int_Value : Integer; when Float =3D> Float_Value : Float; end case; end record; These can be stored in an array. = > >* Ada does not support conforment arrays. You can not pass an arr= ay with 5 > >elements to a routine one time and then pass an array of 10 elements t= he next > >because of the typing. This is an extremely critical aspect that is ex= tremely > >difficult to get around within Ada compared with C/C++ or Pascal. More= over, > >this functionality is almost required when processing communications p= ackets > >that may be variable-sized. Wrong again; this is precisely what a String is! The Ada terminology is "unconstrained arrays". type String is array (POSITIVE range <>) of character; procedure Put (Item : in String); > >* 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 i= nputs. > >This limitation can greatly effect a programs function (overload) coun= t due > >to this limitation. = This is true. The reason is type safety and run-time simplicity. When porting GCC to a new processor, one of my biggest problems was getting variable arguments working; I'm still finding bugs related to this! But even given a correct implementation, variable argument lists are just not type safe. Ada provides alternatives that are safe (see MyType above). > >* DCOM (which OPC will be based) uses DCE IDL. DCE IDL is a super= set of CORBA > >IDL and offers many complex data types that are essential for low-leve= l, > >high-performance system applications that are not supported in Ada, Ja= va, =85 > >This lack or inability of the language to handle complex data structur= es can > >again increase the lines of coding. What are the specific types that DCOM requires that (supposedly) cannot be defined in Ada? This is arguing from ignorance. > >* Interface Packages - Another extremely dangerous issue with Ada= is the fact > >that under certain OS's we may be required to write the interface bind= ings to > >vendor routines, and these may not be commercially available. And look= ing at > >our current IO vendors, they appear to be supplying C/C++ libraries, w= hich > >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=85= This is not an argument against the language itself, but it is relevant. Currently, there are more bindings available for C; projects that use Ada will have to write bindings themselves. This will change as Ada becomes more popular. A side benefit of writing your own bindings is that you become more aware of the details of the system you are binding to; this is sometimes a good thing. > > > > > >Here are just a few items that truly make Ada very ineffective and > >inefficient to program in =85 And many of them focus around the inabil= ity of > >the language to support complex (but required) data structures and typ= es, as > >well as, the intolerable type scheme. = Ada supports all the complex data structures and types that C does; please give real examples! The fact that one programmer finds the strong typing "intolerable" does not mean it is not up to the job. > >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 ele= ments > >within the language unless they are required so that the language can = perform > >certain tasks (which require them). Once elements such as these are us= ed (and > >they must in many low-level systems programs), the touted type-safe, r= obust > >Ada system is no longer=85 but now in the same field as many other lan= guages. Yes, Ada has dangerous features; so does C, C++, and any other real-world language. The point is that proper system design isolates use of these dangerous features to small sections of code, and hides them behind well-defined abstractions. Then the full strong typing of Ada protects the rest of the system. C and C++ cannot do this. To paraphrase Robert Dewar, the moral of this story is "don't presume to critique a language you have not used extensively". In this case, the critiquer appears to not have used Ada at all! -- = - Stephe