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,fc52c633190162e0 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx02.iad01.newshosting.com!newshosting.com!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.freenet.de!85.12.40.130.MISMATCH!xlned.com!feeder1.xlned.com!chloor.box.nl!217.188.199.138.MISMATCH!storethat.news.telefonica.de!telefonica.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Sun, 01 Apr 2007 03:23:28 +0200 From: Georg Bauhaus Organization: elsewhere User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: why learn C? References: <1172144043.746296.44680@m58g2000cwm.googlegroups.com> <1172161751.573558.24140@h3g2000cwc.googlegroups.com> <546qkhF1tr7dtU1@mid.individual.net> <5ZULh.48$YL5.40@newssvr29.news.prodigy.net> <1175215906.645110.217810@e65g2000hsc.googlegroups.com> <1175230352.808212.15550@e65g2000hsc.googlegroups.com> <1175236212.771445.135460@y66g2000hsf.googlegroups.com> <1175246243.5771.67.camel@localhost.localdomain> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <460f0951$0$23134$9b4e6d93@newsspool1.arcor-online.net> NNTP-Posting-Date: 01 Apr 2007 03:22:25 CEST NNTP-Posting-Host: 70ed8988.newsspool1.arcor-online.net X-Trace: DXC=XOl]b_G1LELC4i^e1BZ=_Hic==]BZ:afN4Fo<]lROoRAFl8W>\BH3YBWkPUn@1g4BGA:ho7QcPOVCW`kFHDEM=bK[V5FJUQJo:G X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:14701 Date: 2007-04-01T03:22:25+02:00 List-Id: Peter C. Chapin wrote: > Georg Bauhaus wrote in > news:1175246243.5771.67.camel@localhost.localdomain: > >> If you allow me to be pedantic, SPARK is not distinguished from >> Ada by external rules for programmers. Rather, it has its own >> language definition, and translators that know about nothing >> but the SPARK language. This approach is very different from >> establishing coding rules. > > How is it different than using coding guidelines together with a tool > that checks them automatically? Maybe I was incorrectly assuming that coding rules are not enforced in the same way that language rules are enforced, because using a special language parser with rule checks built in requires additional efforts and tedious discipline (in the short run). But I'm not too confident that the efficacy of coding rules without such a tool is de facto the same as that of existing language rules. Coding rules require programmers who will apply the rules by their own free will and who know quite a bit about programming. > As you can probably guess, I'm a big > believer in extending a programming language with tools. I would even hope that a systematic survey of how tools for translation, checking, "architecture" etc. are used can help establish some knowledge of what a future very high level language should provide. But here's a case demonstrating that now we are (still) in sore need of good language rather than good rules. (A difficulty of arguing in favor of a "strict" Ada-like language will be the "works for me razor" applied by those who seem to be using less strict languages with seemingly good success. The argument is similar to that of very good Lisp programmers who build well working macros reflecting their own sophistication with all pros and cons of that. As you have mentioned, it may be fine for small teams.) The case is that of conditionals where a condition is written after the statement that it controls, but the programming language is not really using postfix notation. Postfix conditionals aren't in either C++ or Ada, but they serve well as an example of where the human element matters in adopting rules or not. The postfix conditional has been in Perl for some time, and postfix forms of conditionals and loops are being added to Python. Perl::Critic, a rule checking tool, will warn about postfix conditionals, a negative rule being based on the recommendations of a well received book (Perl Best Practices (PBP)). But why is the postfix form of "if" nevertheless popular in new Perl code, even added to Python, although it has been identified as a problem? My guess is that a human can say, "do this unless there is X", a postfix conditional. By doing so he or she uses a common mode of expression that is well understood by a human, hence seems acceptable, even natural.[1] Another reason of continuing popularity of postfix if, opposing the PBP rules, might be that a popular Perl book doesn't talk about the dangers of postfix if. Like C++ and Ada, Perl is a given language. Corresponding tools are just not used frequently, so we will continue to see code that recreates fancy pitfalls. Therefore, the best way for years of rule checking experience to manifest itself in software is adding the most important results to the language proper. Or, where possible, use a language that enforces these rules by definition. [1] "The *if* and *unless* modifiers work pretty much as you'd expect if you speak English." (Wall, L.; Christiansen, T.; and Schwartz, R.L.: Programming Perl)