Re: ada paper critic

[Andrew Maizels <pixymisa@ozemail.com.au>]

Alderson, Paul A. wrote:

>    MY_BIG_BLOATED_PACKAGE_NAME.MY_BIG_BLOATED_VARIABLE_NAME :=
> MY_OTHER_BIG_BLOATED_PACKAGE_NAME.MY_BIG_BLOATED_ARRAY_OR_FUNCTION(MY_BIG_BL
> OATED_GLOBAL_LIT_PACKAGE.AND_OF_COURSE_A_BIG_BLOATED_LITERAL);

Yeah, this sucks.  And having to haul in a dozen different packages to 
do anything useful sucks too.

> The main point here is that the Ada code above requires one to go and lookup
> what MY_BIG_BLOATED_ARRAY_OR_FUNCTION is.  Is it a function or an array?

This is a deliberate design feature.  I'm not sure whether I agree 
entirely or not.  But if you use [] for arrays and () for functions, 
what do you use for hashes and other structures where the lookup is 
actually performed by a function?

> Who knows?  The other not so subtle point is that Ada programs tend to use
> very large variable names.  Probably because many projects insist that "use"
> is a bad thing and require the package to be specified.  And since we want
> the package name to be descriptive everything referenced inside it uses
> allot of textual real-estate.  Therefore I personally think of Ada as a
> write only language.

To which I reply:
   if (++*(int *)*pc<*(int *)*(pc+1)) pc=*(pc+2);
(just something from a project I'm working on).

> Another issue that is often overlooked is that the computer language can not
> realistically be treated as a stand-alone unit.  Sure if you want to argue
> about "what ifs" or are into fantasy writings....  Here is where Ada falls
> by tripping over a steel girder onto its' face into a titanium floor.  The
> big issues of why Ada is either dead or in severe decline are:
> 
> (And the top ten "Why Ada is dead" reasons are!:)
> 
> 	1.) Ada is not taught anymore. (Never really ever were that many
> classes for it.)

Maybe.

> 	2.) Ada development environments lag 10 years behind MSVC for
> example.

I don't care for MSVC, but many people are lost without that sort of 
environment.  I haven't seen the commercial Ada environments, though, so 
I'm not sure you're right here.

> 	3.) Ada has no nice string handling capabilities.  
>          (Yeah yeah yeah library XYZ does...is it in the standard
> distribution?)

Huh?  Ada's string handling is just peachy.  It's annoying that there 
are six different string types, but everything you could ask for is there.

C, on the other hand, has the worst string handling of any major 
language.  C strings are *EVIL*.

> 	4.) Ada has no in-expensive development suits that are easy to use.

Gnat is easy to use.  Not flashy, but easy enough.

> 	5.) The Ada language is based upon hardware notions such as integers
> being a certain size and etc.
> 		(Would not it have had been better to make numeric
> declarations fit their use instead
>              of forcing the programmer to think about the computer
> hardware?)
> 		Example:
> 			If I want a number that represents the month in
> terms of a whole value
> 			would not the following be a better way:
> 
> 			month : 1..12;
> 
> 			Do I care that a byte or int is allocated?  If I do
> then I'll say so!

Again, huh?  I can specify a subrange if I want.  I can specify a 
precise number of bits if I want, too.  And C gives me, what?  Short is 
no longer than int, and long is no shorter than int.  Wonderful.

> 			One might argue that you CAN DO RANGES, but my
> pre-emptive counter point is
>                   that one does not have to use pointers in C either!
> Meaning why does integer
> 			exist?

As far as I can tell, this is a complete non-sequitur.

>       6.) GENERICS GENERICS GENERICS
> 		If the programmer used generics heavily and you must certify
> to level-A you either:
> 			A.) Test one instance and say the rest are the same
> (hopefully)
> 			B.) Incur huge verification costs.

Compared to what?

[snip]

> To be fair Ada does have its beneficial side, but it comes at a high price.
> People will argue that its that much safer and better and you can't be safe
> with C.  When you point out the use of LINT they then interject that its an
> additional cost and not part of the language.  But it still is available and
> essentially gets you Ada type checking and great analysis of your code (even
> style!).  So pretty much in my eyes all current languages are severely
> flawed in one aspect or another.  It all really boils down to good software
> people - not the language.  Just remember things have gone boom using Ada
> and things have gone boom using C.  So it seems that the language can't
> prevent these things!  The overall point is that Ada is not the answer to
> everything.

There's still no silver bullet, it's true.  I find C better when I want 
to get close to the metal; I can look at a line of C and be pretty sure 
how the executable will come out.  But errors in my C code tend to make 
my program crash in strange and wonderful ways, while Ada catches the 
problem at compile time.  Lint doesn't come close to the kind of 
compile-time and run-time safety that Ada offers.

Andrew.
-- 
This sig no verb.