Robert A Duff wrote:
> 
> >>*      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.

Well, in fact it does (from the client perspective) because of
overloading.
DEC Ada uses this extensively in their libraries. Yes, it requires more
lines of code when writing the object, but no additional lines of code
to call it. Therefore, it's just as convienient... unless you're just
hacking
some code together, of course.

> >>*      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.

However, it's not an "extremely dangerous" issue, particularly given
automated C-to-Ada
conversion. It may be a productivity issue, at best.

> 
> >>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.

Presumably, any "C" routine that calls assembly code loses all of the
benefits of
a higher-order language, by the same reasoning.

> 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.

Let's do the opposite: Write an assembly program that can't be coded in
C (or other high-order language), and use that to show that we must all
code in assembly. How about: Do a ones-and-zeros ripple test
of all of memory, including the stack and heap.

> 
> - Bob

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
Who uses Ada? See http://www.lmasc.lmco.com/f22
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com