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,971aa11c293c3db1 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-07-19 14:36:23 PST Path: archiver1.google.com!newsfeed.google.com!postnews1.google.com!not-for-mail From: codesavvy@aol.com (codesavvy) Newsgroups: comp.lang.ada Subject: Re: Ada The Best Language? Date: 19 Jul 2001 14:36:22 -0700 Organization: http://groups.google.com/ Message-ID: <5be89e2f.0107191336.39376b9@posting.google.com> 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> NNTP-Posting-Host: 198.59.170.85 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 995578582 9031 127.0.0.1 (19 Jul 2001 21:36:22 GMT) X-Complaints-To: groups-support@google.com NNTP-Posting-Date: 19 Jul 2001 21:36:22 GMT Xref: archiver1.google.com comp.lang.ada:10279 Date: 2001-07-19T21:36:22+00:00 List-Id: "Warren W. Gay VE3WWG" wrote in 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? > Crafting new code. Hopefully I won't have to chase down any more defects that occur during elaboration :-). Seriously I agree that the memory corruption problems can be very nasty and very difficult to fix. > 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. > I like your ideas and I agree with the points you are making. It seems to me that if indeed Ada 95 offers a better, more productive programming solution to many problems that are solved using C++ then it is a travesty that Ada 95 is not more widely used. I think your metric for productivity is exactly right. What has amazed me regarding this discussion is that so many of the participents seem to be unconcerned about measuring productivity. In the final analysis I believe that in order for Ada 95 to be more widely adopted is a case that is backed by quantitative data showing the productivity (cost savings) of using Ada. > 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. > Unchecked_Conversion can "blow away the whole leg" as well :-). I think that skilled developers are the most important factor in acheiving "high productivity." I've seen some very convoluted Ada code as well where type definitions were very poorly designed. You're right about the surprises that C/C++ has. > 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. I basically do agree with your ideas on productivity. I just would like to see some quantitative data that support Ada as being more productive as you have defined productive. If there have been studies done or white papers written that make quatitative arguments I would really like to read them. You make some very good points but management for the most part will not listen because they won't take the risk of using Ada instead of C++ without some hard evidence to back up the claims regarding the increased productivity by using Ada.