Re: ada paper critic

[Vinzent Hoefler <JeLlyFish.software@gmx.net>]

"Alderson, Paul A." <Paul.Alderson@avistainc.com> wrote:

> I'm not talking about just style either,
>but the actual syntax of the language.  For example:
>
>Ada code:
>
>   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);

Try this:

|declare
|  MBBPN_MBBVN renames
|      MY_BIG_BLOATED_PACKAGE_NAME.MY_BIG_BLOATED_VARIABLE_NAME;
|  MOBBPN_MBBAOF renames
|      MY_OTHER_BIG_BLOATED_PACKAGE_NAME.MY_BIG_BLOATED_ARRAY_OR_FUNCTION;
|  MBBGLPAOCABBL renames
|      MY_BIG_BLOATED_GLOBAL_LIT_PACKAGE.AND_OF_COURSE_A_BIG_BLOATED_LITERAL;
|begin
|  MBBPN_MBBVN := MOBBPN_MBBAOF (MBBGLP_AOCABBL);
|end;

 :-)

You never heard of renaming? In C terms you would call it a macro,
IIRC. :-)

>C code:
>
>       (for an array)
>   nDaysInMonth = nMonthTable[JAN];

|Days_In_Month := Month_Table (Jan);

What's your problem?

And why do you write n before each variable name? Shouldn't the second
read anMonthTable for an *a*rray of *n*umbers?

Oh I forgot, this is the standard way to bypass the lack of genuine
types in C by *simulating* them.

>The main point here is that the Ada code above requires one to go and lookup
>what MY_BIG_BLOATED_ARRAY_OR_FUNCTION is.

Why? It works. And it still works when you change a heavily
calculating function into a simple look-up-function called array.

>  Is it a function or an array?
>Who knows?

Who wants to know? In most cases it does not really matter.

>The other not so subtle point is that Ada programs tend to use
>very large variable names.

Ada programmers tend to use *descriptive* names.

And do you really think

|#include <my_io_package.h>
|my_io_package_global_variable = ... ;

is substantially better?

Again, the standard way to bypass the scoping problem of C where
everything is global by definition and name clashes often occur?

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

LOL

>	1.) Ada is not taught anymore. (Never really ever were that many
>classes for it.)

Stuttgart (Germany) teaches it, AFAIK.

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

So MSVC runs under *nix? I doubt that.

>	3.) Ada has no nice string handling capabilities.

|while (dest*=src*)
|  ;

is more nice than

|Dest := Src;

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

gnatmake My_Program.ada

What can be easier?

>	5.) The Ada language is based upon hardware notions such as integers
>being a certain size and etc.

That's bullshit, sorry.

>		(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?)

Exactly that's what Ada does with Digits attributes for example.
Instead of caring about what floating point type to use to meet the
requirements you simply *specify* the requirements and let the
compiler choose the most appropriate representation.

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

Yes. And that is what I do in Ada:

|type Month is range 1 .. 12;

What is the point you argueing about here?

>			Do I care that a byte or int is allocated?  If I do
>then I'll say so!

Yes. Exactly. Ada.

BTW, what is the size of the int you are talking about? 16, 32, 64
bits?

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

Huh? Surely I miss something but I do not see the what range
constraints should have to do with pointers.

And

|int main (int argc, char *argv[]) {}

uses no pointers?

>Meaning why does integer exist?

For cases where you do not care about types? As base type for deriving
constrained types from?

>      6.) GENERICS GENERICS GENERICS
>		If the programmer used generics heavily and you must certify
>to level-A you either:

...simply use SPARK that does not include generics. :-)

[lint]
>additional cost and not part of the language.  But it still is available and
>essentially gets you Ada type checking

Woah! Lint gives you Ada type checking? I doubt that.

>and great analysis of your code

That what the Ada *compiler* is already supposed to do.

>(even style!).

You do not need that in Ada. It's self-styling. :-) At least if you do
not try to write C with Ada syntax.

If that really fails:

For the first time : use -gnaty.
For the second time: fire the programmer.

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

I doubt that. Good software people and a good language are always the
better choice.

Perhaps you should take a look at this:

|http://www.adaic.com/whyada/ada-vs-c/cada_art.html

Personally, I even can imagine that chances are good, that a better
language compensates for worse software people.

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

It cannot prevent, that's right. But it *helps* you in preventing
those nasty <boom>s, so in Ada the <boom>s are more seldom.

> The overall point is that Ada is not the answer to
>everything.

Looks like the only statement that contains more than 10% of truth.
But it holds true for *every* language so it is not really an argument
on *anything*.


Vinzent.