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.3 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI, REPLYTO_WITHOUT_TO_CC autolearn=no 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 07:33:05 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!fr.usenet-edu.net!usenet-edu.net!enst!enst.fr!not-for-mail From: "Alderson, Paul A." Newsgroups: comp.lang.ada Subject: RE: ada paper critic Date: Fri, 14 Jun 2002 09:31:16 -0500 Organization: ENST, France Sender: comp.lang.ada-admin@ada.eu.org Message-ID: Reply-To: comp.lang.ada@ada.eu.org NNTP-Posting-Host: marvin.enst.fr Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: avanie.enst.fr 1024065183 41678 137.194.161.2 (14 Jun 2002 14:33:03 GMT) X-Complaints-To: usenet@enst.fr NNTP-Posting-Date: Fri, 14 Jun 2002 14:33:03 +0000 (UTC) Return-Path: X-Mailer: Internet Mail Service (5.5.2650.21) Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: comp.lang.ada mail<->news gateway List-Unsubscribe: , Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org Xref: archiver1.google.com comp.lang.ada:25939 Date: 2002-06-14T09:31:16-05:00 Immanuel, If you look at just the language then I'd have to say Ada programs are less readable than C or C++ programs. 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); C code: (for an array) nDaysInMonth = nMonthTable[JAN]; (for a function) nDaysInMonth = nMonthLookup(JAN); 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? 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. 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.) (Why the DOD had to drop the requirement!) 2.) Ada development environments lag 10 years behind MSVC for example. 3.) Ada has no nice string handling capabilities. (Yeah yeah yeah library XYZ does...is it in the standard distribution?) 4.) Ada has no in-expensive development suits that are easy to use. 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! 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? 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. 7.) When all else fails - unchecked conversion - sometimes just because! 8.) Unhandled exception in the library? Now what? 9.) Write to comp.lang.ada you'll get an answer there! - NOT! 10.) Getting my marshmellows out! He he he....just being sarcastic in 7 through 10, but there are hints of truth in there. 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. Paul Alderson > -----Original Message----- > From: Immanuel Scholz [mailto:news@kutzsche.net] > Sent: Thursday, June 13, 2002 7:49 PM > To: comp.lang.ada@ada.eu.org > Subject: ada paper critic > > > > Hi, > > I am searching for a book or a paper which tend to explain > the negative > aspects on ada. > > I am writing on a report of the usability of several > programming languages > and up to now, I came out with the fact, that ada seems to > get all the good > honey, letting only rubbish to other languages ;-) > > So are there any papers about the "great disadvantages" of > ada? (There have > to be disadvantages, right?) > > > Immanuel Scholz > > >