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.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,52fd60a337c05842 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-14 20:02:59 PST From: Vinzent Hoefler Newsgroups: comp.lang.ada Subject: Re: ada paper critic Date: Sat, 15 Jun 2002 05:02:47 +0200 Organization: JeLlyFish software References: X-Newsreader: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 213.3.190.128 Message-ID: <3d0aae5c_1@news.bluewin.ch> X-Trace: news.bluewin.ch 1024110172 213.3.190.128 (15 Jun 2002 05:02:52 +0200) X-Complaints-To: abuse@bluewin.ch Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-han1.dfn.de!news-stu1.dfn.de!news.belwue.de!news.tesion.net!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.bluewin.ch!not-for-mail Xref: archiver1.google.com comp.lang.ada:26003 Date: 2002-06-15T05:02:47+02:00 List-Id: "Alderson, Paul A." 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_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 s, so in Ada the 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.