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,a9b0810d3106d9b8 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news2.google.com!goblin1!goblin.stu.neva.ru!noris.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Mon, 18 Apr 2011 23:01:46 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Fun with C References: <27cf3992-4132-4483-9110-adc7a089cd4a@e8g2000vbz.googlegroups.com> <54108d8d-4e7c-4901-bd5e-819d27720d48@a11g2000pro.googlegroups.com> <4daa8fc6$0$7652$9b4e6d93@newsspool1.arcor-online.net> <37428a21-61b4-4cdf-9897-7b84252f8fce@a11g2000pro.googlegroups.com> <4dab6906$0$6893$9b4e6d93@newsspool2.arcor-online.net> <57a1fa4b-4730-41a8-be8a-82061ef9dc22@x37g2000prb.googlegroups.com> In-Reply-To: <57a1fa4b-4730-41a8-be8a-82061ef9dc22@x37g2000prb.googlegroups.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Message-ID: <4daca6ba$0$6773$9b4e6d93@newsspool3.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 18 Apr 2011 23:01:46 CEST NNTP-Posting-Host: 70de937a.newsspool3.arcor-online.net X-Trace: DXC=l^WnFT<02n]I?44J>Z[:RQMcF=Q^Z^V3X4Fo<]lROoRQ8kFkKdk^PCY\c7>ejVX7\oPIW7;kRZ On 4/18/11 9:12 PM, Elias Salom�o Helou Neto wrote: > On Apr 17, 7:26 pm, Georg Bauhaus >> I suggest turning to observable facts and away from >> normative ontology for a moment. Towards justifiable >> language design. Unfortunately, when it comes to empirical research into the effects of language definitions, hardly anyone ever finds a scientific approach worthwhile. > if you wish we can find a metric whereby > C is better than Ada as well. I'm eager to add more metrics to my collection programming language metrics. C's pointer arithmetic is unchecked, unlike Ada's, and thus faster. (A experiment that some embedded C people found fair resulted in a ratio of 10:12). Another metric. So we have three PL metrics and three hypotheses for a start. > I won't argue on that. Specially, your > metric seems to imply that Ada is much better for those who find it > hard to think, most people after all. Uhm, no, that's a misunderstanding, Ada requires quite some thinking, it is just that its basic types do not require so much thinking. I should stress one *major* concern of my favorite approach to language definition: Smart brains should not have to spend time with tackling basic programming techniques. In any language. They should have all their thinking capacity engaged in thinking about smart solutions. Not in keeping track of types' implicit sizes. That's wasted effort. (PC-lint -w 4 seems to confirm this view.) If mastering a relatively basic feature of a language requires much learning, then this investment should be compared to its results. What is the return on investment a programmer spent on implicit type size education, say? Among the observable results are these: (a) you know how to use basic programming features (b) you take pride in this ability (c) you can set yourself apart from others without the skill Which skill is, nota bene, knowing how to write basics. > Of course Ada is a better approach for the masses. Certainly not in full. Like C++. Because no big, detailed language will ever work for the masses. Subsets may do so, as a starting point, I think. > However, here is my piece of advice: it won't work. See Ariane 5's > example. I understand your idea, I think, but it is this very example that has surprisingly little to do with languages, in spite of all the ambitious remarks made about the case. Have you had time to look into the report? > Ada may give programmers a false sense of security, leading > to even more sloppiness. Hmm... Is there an operational definition useful to turn this claim into a hypothesis? I had thought that Ada culture nurtures awareness of security issues more than false beliefs in "secure languages". > Surely Ada would be a good and justifiable choice for most industrial > programming projects, but this is not what C was planned for - don't > blame it. Complaints were addressing using C in industrial projects because of the effects it has in industrial projects. There is evidence that different fundamental type systems help non-dumb people solve their problems more successfully. People will still be using C libraries and additional code generators, as a replacement for a better suited type system. If something is going to replace C, it sure mustn't look like Ada. Just be like it in some ways. That's the crucial part, I think. Keeps face.