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-Thread: 103376,703c4f68db81387d X-Google-Thread: 109fba,703c4f68db81387d X-Google-Thread: 115aec,703c4f68db81387d X-Google-Thread: f43e6,703c4f68db81387d X-Google-Attributes: gid103376,gid109fba,gid115aec,gidf43e6,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!z14g2000cwz.googlegroups.com!not-for-mail From: "Jerry Coffin" Newsgroups: comp.lang.ada,comp.lang.c++,comp.realtime,comp.software-eng Subject: Re: Teaching new tricks to an old dog (C++ -->Ada) Date: 13 Mar 2005 10:41:16 -0800 Organization: http://groups.google.com Message-ID: <1110739276.774946.103020@z14g2000cwz.googlegroups.com> References: <87r7iu85lf.fsf@insalien.org> <87is4598pm.fsf@insalien.org> <1110054476.533590@athnrd02> <1110059861.560004@athnrd02> <422b6d49.1141887367@news.xs4all.nl> <1110266099.441421.179290@o13g2000cwo.googlegroups.com> <1110332933.587110.260410@z14g2000cwz.googlegroups.com> <1110390097.532139.43430@f14g2000cwb.googlegroups.com> <422f3808$0$30165$ba620e4c@news.skynet.be> <1110409958.685759.249420@g14g2000cwa.googlegroups.com> <15SdnYvJ0_x3Vq3fRVn-3Q@megapath.net> <1110522060.091940.178510@l41g2000cwc.googlegroups.com> <1110556346.841594.212520@z14g2000cwz.googlegroups.com> <4952804.Myubg7stsI@linux1.krischik.com> NNTP-Posting-Host: 70.33.25.135 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1110739281 18130 127.0.0.1 (13 Mar 2005 18:41:21 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sun, 13 Mar 2005 18:41:21 +0000 (UTC) User-Agent: G2/0.2 Complaints-To: groups-abuse@google.com Injection-Info: z14g2000cwz.googlegroups.com; posting-host=70.33.25.135; posting-account=mZiOqwwAAAC5YZsJDHJLeReHGPXV5ENp Xref: g2news1.google.com comp.lang.ada:9327 comp.lang.c++:45443 comp.realtime:1427 comp.software-eng:4990 Date: 2005-03-13T10:41:16-08:00 List-Id: Martin Krischik wrote: [ ... ] > Did they? Or did they just implemented some 80% of the new features? > My experience with C/C++ (and I have 10 years + of that) is that at > no time there was a fully compiant C compiler available. There where > allways a lot of compiler avaliable who claimed to be > almost complinant - but never one which realy was. > > Partily because - unlike Ada (http://en.wikipedia.org/wiki/ISO_18009) > - there is not official testsuite to test a C/C++ compiler and > runtime library. Such an official testsuite would do C/C++ all sorts > of good. I'm quite impressed with the statements above -- lots of Usenet posts contain errors, but most of them are pretty obvious. You've managed to fit more plausibile-sounding errors into fewer sentences than nearly any other post I've ever seen. Let's address the Ada side first. Official Ada validation was done under the auspices of NIST, who delegated this task to the Ada Joint Program Office. The AJPO ceased to exist years ago, and the job was never turned over to anybody else when that happened. Meanwhile, NIST has discontinued _all_ of its compiler validation programs, not just the Ada program. Currently, both the ISO standard at a number of FIPS pubs _require_ Ada compilers to be officially validated, but at least in the US, there is absolutely NO agency to do that. The situation on the C side isn't nearly as different as you seem to think. After the C standard was published, NIST and BSI (to name only two that I know of with certainty) started doing validation of C compilers. BSI certified at least one C implementation in 1990, the same year the ISO C standard was approved. While that first one was for code-checking, not production of executables, other implementations (e.g. at least one version from Borland) were certified as well. As mentioned above, NIST no longer validates/certifies compilers, so at least in the US, there is no such thing as an officially validated compiler for C, Ada, or any other language. > What do you mean by "exists today"? C99 is 5 years old and still no\ > compiler is available which support all C99 features. "restrict" - > missing in MS-C (even thrue restrict can be implemented as "no > operation") - VA - arrays (savety critical feature) - missing in > MS-C, buggy in GCC. I take it you've never used or even tested the Comeau compiler? > Maybe just maybe - if there realy was any standart compiler available > - but there isn't - the C/C++ compiler vendors are allways one > release behind the actual ISO standart. I see Greg has entered the thread, so he can speak for himself, but unless memory serves me particularly poorly today, he had C++ 2003 implemented _before_ it was officially approved. In fairness, I should add that I found a _few_ defects in the Borland compiler that was certified -- but back when I worked in Ada, I found defects in every certified Ada compiler I used as well. In both cases the defects were small and easily avoided, but the defects in the C compilers were smaller and more easily avoided. [ ... ] > It is true that a programming language need some minimum features set > to be usefull. And that feature set is a lot larger then most belive. > If a successfull language does not provide that set it will be bolted > on later. If anything the current C/C++ ISO standards clearly show' > that the advocates for slim languages hat been wrong all along. More nonsense, I'm afraid. First of all, the argument is defective from the beginning: changes in C and/or C++ absolutely cannot prove anything about languages in general. Second, some extremely slim languages have clearly been useful at times, easily disproving your conclusion on minimum feature sets as well. None of this proves, or even provides evidence, directly related to what is claimed by most advocates of smaller languages. Most have said, for example, that all else being equal, a smaller feature set is easier to understand completely. Now you may be convinced that a larger feature set outweighs this fact, and you might even be right -- but that doesn't make them wrong. IMO, arguments of the benefits of "small" ("slim", etc.) vs. larger languages mostly miss the point though. IMO, there's a much more fundamental and useful distinction to be considered. That is the distinction between those where the language itself is the major player, and those were the language is mostly a way of producing and/or using libraries. Ada certainly provides facilities useful for writing libraries, but at least to me seems to fall into the former group -- it works well for writing code directly, but attempting to write good libraries in it tends to be frustrating. C++, while certainly providing some features useful for direct coding, is strongly oriented toward the language providing facilities for building libraries, and much (in many cases, MOST) of what the end-user does is uses the libraries. Looking at things from this perspective, Ada may be the last of its line. 30 years ago, Lisp was nearly the only library-oriented language, with a miniscule market share. Now, the library oriented languages dominate. Fortran and Cobol may never die, but they're certainly not the market leaders they once were. PL/I is dead, and Ada is hardly dominant. C++ has already been mentioned. Java is a fairly small language with a huge library. The next obvious step is .NET, which de-emphasizes languages to the point that .NET itself IS simply a huge library, with facilities to make it easy to use that library from any (or all) of a large and growing collection of languages. Of course, if you want to discuss slim languages, there's always Smalltalk -- the language itself is absolutely puny, providing little more than the ability to send messsages to objects, and receive back results. Everything else is in the standard library, even such basics as creating an object. This means the language needs a fairly large, pre-existing standard library to be able to do anything at all. -- Later, Jerry. The universe is a figment of its own imagination.