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,b30bd69fa8f63cb2 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-12 05:39:35 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: kanze@gabi-soft.fr Newsgroups: comp.lang.ada Subject: Re: C bug of the day Date: 12 Jun 2003 05:39:34 -0700 Organization: http://groups.google.com/ Message-ID: References: <1054751321.434656@master.nyc.kbcfp.com> <82347202.0306101232.16776a81@posting.google.com> NNTP-Posting-Host: 62.160.54.162 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1055421575 16944 127.0.0.1 (12 Jun 2003 12:39:35 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 12 Jun 2003 12:39:35 GMT Xref: archiver1.google.com comp.lang.ada:39045 Date: 2003-06-12T12:39:35+00:00 List-Id: James Rogers wrote in message news:... > kanze@gabi-soft.fr wrote in > news:d6652001.0306110131.6ac9e693@posting.google.com: > > jimmaureenrogers@worldnet.att.net (Jim Rogers) wrote in message > > news:<82347202.0306101232.16776a81@posting.google.com>... > >> I suppose, if your whole experience is using C and / or C++ you > >> would have a difficult time understanding Ada from a purely > >> intellectual viewpoint. Some of these understandings must derive > >> from more visceral experience. > > Bingo. I've read about Ada. I've even read the Ada standard. I > > admire Ada. I suspect that it is a really effective language. But > > until I've actually used it, in a real application of some size, I > > can't really know. (I also suspect that it has some hidden catches > > too. Probably less than C++, but it WAS developed by human beings.) > > And don't read too much into my original comment. I was unaware of > > the cross-posting to the Ada group, and the point I was trying to > > make was only that C++ isn't perfect, but that with care, it can be > > used effectively. To a certain degree, of course, the same can be > > said of any language -- I'll stand by my statement that a perfect > > language doesn't exist. But obviously, the amount of care varies > > according to the language. Perhaps more importantly, where the care > > is needed varies: one of the most common errors in Java programs is > > forgetting a finally; in C++, the proper use of destructors make > > this particular problem almost inexistant. > I do not think you will get any significant resistance to the idea > that Ada is imperfect. If you look through the current list of threads > in comp.lang.ada you will find a number of suggestions for improving > the language. That's good news. I know that when I was using Java, you could get seriously flames in comp.lang.java.programming just for suggesting that the language wasn't perfect. > You will also probably see that few of these suggestions are focused > on improving fundamental Ada safety. Most are focused on ways to make > Ada more popular. Obviously, you concentrate on the most important problems first:-). Good luck. (I rather doubt that a language can be both safe and popular. History, at any rate, is against you.) > I assert that it is impossible to develop a universally perfect > language. Different problem domains require different language > strengths. I do not, for instance, believe a single language can > satisfy all the requirements of a scripting language while > simultaneously satisfying all the needs of an embedded language used > in SIL-4 level applications. Exactly. And in some cases, my opinion as to what the safe default is may not agree with yours. If your argument is that it is significantly easier to write a robust application in Ada than in C++, all that I have been able to find out about the language without actually using it makes me think that you are right. If you try to claim that it is impossible to write an incorrect program without overriding a default behavior, on the other hand... -- James Kanze GABI Software mailto:kanze@gabi-soft.fr Conseils en informatique orient�e objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, T�l. : +33 (0)1 30 23 45 16