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: Samuel Mize Subject: Re: ada and robots Date: 1997/06/17 Message-ID: <33A6D407.53416C1E@link.com> X-Deja-AN: 249131754 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: Note that I make some comments about the person Mr. Whiting quoted, but none about Mr. Whiting. Some quotations reformatted for length. Stephen Leake wrote: > > Matthew S. Whiting wrote: > ( second hand list of supposed Ada deficiencies ) ... > > >* Ada does not support discriminant unions (which are ... > This is precisely the Ada discriminant record: Ah, but you can't hand-code the discriminant values. This makes it harder to interface to existing C code, which of course makes C fundamentally better. Besides, you can't load the variable with one type and then read it as another type. In C it's simple and safe, while in Ada it requires Unchecked_Conversion, which everyone knows is dangerous. > > >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. Is this template something that couldn't be done with a generic, or a tagged type? Or is the complainer just ignorant? > > >* 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. > > 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). At the slightest error, a procedure with a variable-length parameter list will read undefined values off the end of the stack. What happens if you make this call in C: printf ("%s%s%d%e"); For safer ways to get variable-length lists of parameters, see the "Ada Can Do It" writeup at www.adahome.com. > > >* 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. Why is this dangerous? Can't they afford a week's worth of effort to write a thin partial binding? Or is he just too stupid to write one? > 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. Plus you can write the interface layer to provide the abstractions you need in your programs. Plus, when you port to another OS, you have isolated all the system dependencies -- unless you're talking about system functions that have ISO standard bindings, this is likely to cost you some effort if you are using vendor-supplied bindings. > > >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). Duh. I don't leave my power tools plugged in and laying around the workshop, let alone keep them with me wherever I go. > > >... 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. In the limited and well-identified areas where unchecked programming is being done, yes. In those parts of your code -- typically less than 5% if you design carefully -- you have to be as paranoid, and do as much scut-level debugging, as a C programmer. In the rest of your code, the compiler is helping you avoid fencepost errors, rogue pointers, accidental misuse of data, and so on. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - But the real core of the complainant's thought process is clear: he says that Ada isn't a "programmer's language," and often refers to the (to him) serious problem of writing more code to do something. What he means is that it isn't a hacking language. He's right. It isn't a language for hackers. It's a language for software designers -- people who want automated help designing and building a program that works right EVERY time, reliably, for a long time, that you can modify and port to new systems. It IS hard to just sit down and bang out code in Ada. You have to pick a coherent design, lay out specs that express that design, and code to your design. If you're going to use things in a different way than you specified -- for instance, view an integer as an array of bytes -- you have to tell the compiler what you're doing. Those "extra" lines of code tell the compiler what you're thinking, and how you mean things to work. Then the compiler can check you and spot your mistakes. Some people don't like this approach. They say with great vigor that a good programmer should be allowed to do anything by the compiler, trusting to his skill and care to get things right. They are deeply certain that they need no help managing the complexity of their own code. They are usually quite skilled at debugging. Many Ada programmers have only rudimentary debugging skills, even after years of building successful programs. Think about it. Samuel Mize -- -- Samuel Mize (817) 619-8622 smize@link.com "Team Ada" -- Hughes Training Inc. PO Box 6171 m/s 400, Arlington TX 76005