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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,971aa11c293c3db1 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-07-20 10:27:54 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!newsfeed.direct.ca!look.ca!east1.newsfeed.sprint-canada.net!news.storm.ca!nnrp1.tor.metronet.ca!not-for-mail Message-ID: <3B586A17.862BA84D@home.com> From: "Warren W. Gay VE3WWG" X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Ada The Best Language? References: <5be89e2f.0107170838.c71ad61@posting.google.com> <5be89e2f.0107180235.726d46a8@posting.google.com> <9j3rrd$g71$1@s1.read.news.oleane.net> <5be89e2f.0107181300.4b4e93d7@posting.google.com> <3B57195E.A3A3FED@home.com> <9j93u6$1ua8$1@norfair.nerim.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Fri, 20 Jul 2001 17:27:53 GMT NNTP-Posting-Host: 198.96.47.195 NNTP-Posting-Date: Fri, 20 Jul 2001 11:27:53 MDT Organization: MetroNet Communications Group Inc. Xref: archiver1.google.com comp.lang.ada:10360 Date: 2001-07-20T17:27:53+00:00 List-Id: Bertrand Augereau wrote: > Don't take it as a troll, but the fact that some people here write C/C++ > makes me think they are not aware of all of the C++ features which make it > (I think) able to compete with Ada95, at least for most common applications. Troll? The best features of C++ still leave numerous faults in the final product: - No overflow checks - In some cases, no divide by zero checks (this feature may need to be enabled on your platform). - No array bounds checking, unless you use classes to do this for you (a very costly approach for small arrays) - Casting - Unnecessary dynamic errors (things that could be statically check at compile time instead). - Everything is externally available (or at least, within the namespace), which leads to unwanted module interactions/conflicts. - implied conversions - weak enumeration types All this is just the tip of the iceberg. For a fuller description of C++'s problems (apart from the Ada comparison), see "Handbook of Programming Languages", Volume 1., MacMillan Technical Publishing (I don't have the book here, so I don't have ISBN). There's quite a description of C++'s problems there, which don't address all of the inherited problems of C. Put the two together, and you have one whopping list of problems. In the final analysis, we're not really talking about a specific feature comparison here anyway. We're really just comparing how the languages and the compilers of same such compare. How they permit the user to develop quality software, and of course within reasonable time frames. Sure, there are "techniques" that can be used to _reduce_ exposure, or enhance type safety etc. But this is generally lame by comparison to what the Ada language enforces. Another way to say this might be to suggest that Ada enforces the "techniques". So if we're still talking about "productivity", it still must be compared over the whole life cycle of the code. Not just "delivery" of the code. There are no sufficient "productivity gains" in the C++ language that will bail itself out of the cost of debugging and troubleshooting the product later. Regarding "common applications" : ================================= Unless you're talking about quick 'n dirty, throw away code, I don't think you can dispense with the need for reliable code. Especially if I am paying you to deliver me as much. Look at the Windows code crashes/seizures etc., it's surprises, or when it does not deliver on functionality that it is supposed to. Netscape/Explorer are two other big applications that could greatly benefit from being developed in Ada95. Ada will not make all of these problems go away, but the original point was that CPU cycles will be expended by the Ada compiler to help the developers of these projects, to identify problems before they occur. BEFORE, testing begins. Consider which approach you would use below? The C/C++/Java approach : 1. Build hang glider 2. Flight test it 3. If you live through the test, fix test identified bugs. 4. Repeat 2 and 3 as required Or.. The Ada approach : 1. Build hang glider 2. Fix identified bugs 3. Repeat 2 as required 4. Flight test The 2nd approach is much safer, and is over the whole life cycle of the project, is much cheaper. If we can't agree on that, then we won't agree on much else ;-) Anyway, WRT the subject line "Ada the Best Language?", I don't think that you can mandate a "best" unless you identify the application, and the user. This is like saying "what is the best car to buy?" However, I do believe that Ada is a better choice for _many_ software applications today. I think it is starting to get more recognition in light of this, also. wwg. > "Warren W. Gay VE3WWG" a �crit dans le message news: > 3B57195E.A3A3FED@home.com... > > codesavvy wrote: > > > Brian Rogoff wrote in message > news:... > > > > On Wed, 18 Jul 2001, Jean-Pierre Rosen wrote: > > > > > From: "codesavvy" > > >.......snip........ > > > > Ada has built in concurrency, and since it isn't a !@#$ing flat > language > > > > like C++ (you may nest function definitions, and you have lexical > scope) > > > > its a lot easier (IMO of course) to use Ada concurrency than some > hacked > > > > on thread library in C++. That's a big plus over C++ IMO. > > > > > > I agree with you. I really do like the Ada 95 concurrancy model. > > > However, I doubt if the gain in productivity is substantial but I > > > could be convinced otherwise. > > > > What soooo many people keep overlooking in this "productivity issue" > > is the _TOTAL_ cost. This has been repeatedly been pointed out by others > > here, but many C/C++ zealots seem to fail to completely grasp this issue. > > The amount of time spent in a debugger for Ada is small. The amount of > > "weird bug" issues is also extremely small for Ada code in general. > > > > I have spent a major part of my career chasing down other peoples' (and > > in some cases my own ;-) memory corruption problems. Sure, it was very > > efficient to slap together that C/C++ project. But when you add all that > > time to find out where the memory corruption came from, and all those > > future bug reports that eventually required investigation, Ada wins > > hands down on a comparison comparison basis. Where do you want to spend > > your time? In the debugger, or crafting new code? > > > > The challenge is to get everyone to recognize that you don't measure > > productivity in terms of delivering the final product. Measure it in > > terms of delivering the "_perfected_ product". Then consider the cost > > of maintaining it after it is delivered/installed. > > > > Another way to look at this issue is that the Ada compiler uses CPU > > cycles to spot programming errors for you. Conversely, the C/C++ > > compiler only looks for gross errors, but otherwise blesses your > > code with the ability to "blow away the whole leg", if that is the > > instruction you have given. And with automatic type promotion etc., > > C/C++ leaves a few surprises in store for good measure. > > > > Anyway, the whole issue keeps coming down to the point of how you > > want to measure "productivity". You need to expand your view on that > > IMHO. > > > > -- > > Warren W. Gay VE3WWG > > http://members.home.net/ve3wwg -- Warren W. Gay VE3WWG http://members.home.net/ve3wwg