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=0.6 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00, HK_RANDOM_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,df1a7f1c3c3bc77e X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!cyclone1.gnilink.net!spamkiller.gnilink.net!gnilink.net!trnddc07.POSTED!f0d9c8c1!not-for-mail Newsgroups: comp.lang.ada From: Justin Gombos Subject: Re: An Ada Advice Inquiry References: <1178448459.256329.28590@n76g2000hsh.googlegroups.com> <1178480316.415370.194260@n76g2000hsh.googlegroups.com> <463ed042$1@news.post.ch> <1178527820.949652.143060@l77g2000hsb.googlegroups.com> <1g1r9ddu19ka7$.1kq3tc2btm98o.dlg@40tude.net> <1178542830.662912.295270@y5g2000hsa.googlegroups.com> <2825529.4NRNKvsDf2@linux1.krischik.com> <1178573171.037577.54370@u30g2000hsc.googlegroups.com> <1178612111.615658.14600@w5g2000hsg.googlegroups.com> User-Agent: slrn/0.9.8.1 (Linux) Message-ID: Date: Wed, 09 May 2007 00:19:53 GMT NNTP-Posting-Host: 72.86.114.139 X-Complaints-To: abuse@verizon.net X-Trace: trnddc07 1178669993 72.86.114.139 (Tue, 08 May 2007 20:19:53 EDT) NNTP-Posting-Date: Tue, 08 May 2007 20:19:53 EDT Xref: g2news1.google.com comp.lang.ada:15667 Date: 2007-05-09T00:19:53+00:00 List-Id: On 2007-05-08, Maciej Sobczak wrote: > On 8 Maj, 04:42, Justin Gombos wrote: > >> An Ada implementation is considerably more complex. > > This statement is inconsistent with the usual criticism of C++ as > the most difficult to parse, with too many exceptions and > self-conflicting standard. I would agree that C++ is more difficult to parse, but it's only inconsistent with one element of the total effort. The parsing difficulty is only a marginal factor once you account for more components of compiler production, like the runtime environment, and the expressive power of the target language. >> It takes one man year to produce a C++ compiler > > This statement is inconsistent with the usual criticism of C++ as > the language that 9 years after the standard still doesn't have > conforming compilers. There's no inconsistency there, considering all the reasons why a C++ compiler might not conform to a standard beyond the effort of doing so. The first excuse that enters my mind is C++ compiler writers have nowhere near the pressure that Ada compiler writers have to conform to a standard. The Ada market is very small, and an Ada compiler that doesn't conform is nearly worthless. And you said it yourself: C++ is a self-conflicting standard. That doesn't necessarily make the compiler more complex, unless the authors choose to support multiple conflicting rules and enable the user to choose between them - but that's extra work it would be purely voluntary. > It is also inconsistent with your expectation to get bug-free > certified compilers. If making a C++ compiler is 10 times easier > than the Ada one, then surely C++ compilers are more likely to > produce high- quality code, no? No. Products produced using Ada achieve the most significant degree of reliability not simply because the compiler is more correct, but because the *language* enables developers to write correct high level code. Neglecting compiler induced errors, the C++ language alone results in 3 times the defect rate of Ada code before the compiler even touches it. So the importance of a correct C++ compiler is insulated by the fact that C++ is not the language of choice for quality products. The nature of Ada projects and the expectation of the end products compell rigid conformance to standards to a much higher degree. > Apart from that, if you really think that 1m-y is enough to crank up > the C++ compiler, why not start a company and sell one? There are so many out there. I would rather compete in a market with less competition. -- PM instructions: do a C4esar Ciph3r on my address; retain punctuation.