Re: ada and robots

[Samuel Mize <smize@link.com>]

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


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