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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.159.48.216 with SMTP id k24mr29236980uab.39.1481204383964; Thu, 08 Dec 2016 05:39:43 -0800 (PST) X-Received: by 10.157.4.119 with SMTP id 110mr4948023otc.11.1481204383921; Thu, 08 Dec 2016 05:39:43 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!n6no4282226qtd.0!news-out.google.com!j8ni14859qtc.0!nntp.google.com!p16no4278918qta.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 8 Dec 2016 05:39:43 -0800 (PST) In-Reply-To: <87y3zq4t05.fsf@nightsong.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=165.225.80.114; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S NNTP-Posting-Host: 165.225.80.114 References: <1905815374.502825168.454102.laguest-archeia.com@nntp.aioe.org> <87y3zq4t05.fsf@nightsong.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <0ad2eb12-421f-4159-8df2-5bf7e0dddf06@googlegroups.com> Subject: Re: Introductory Presentations, especially aimed at C++ programmers! From: Maciej Sobczak Injection-Date: Thu, 08 Dec 2016 13:39:43 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:32680 Date: 2016-12-08T05:39:43-08:00 List-Id: > I'm not convinced: because of C's lack of checks, more bugs make it > through the testing process, How? Your unit test contains the checks for proper program outcome, so you = don't need them in the language. And conversely, if your tests are incomple= te (that is, their coverage is incomplete), then language checks will not h= elp, either, as they will not be ignited. > An Ada programmer might code the same > bug, but it might get caught right away during the developer's private > workflow How? Let's say I made a bug that overflows the array under some specific co= nditions, but my "private workflow" for testing does not involve input that= overflows that array. This error will go to release, no matter what is the= programming language. You might argue that there is some class of errors that can appear harmless= even under test (like overflowing forth-and-back arithmetic) and language = checks can help detect those errors even with partial unit tests. This woul= d be a good argument for Ada. You can also claim that Ada errors are "safer" (the damage containment that= I already mentioned) or that error handling in Ada is more assisting, thus= reducing the diagnostic effort, but these are different arguments. > I think the claim was that it's impossible for humans to stop making > silly errors in general Agreed. But the argument was that Ada would prevent humans from making such= errors, which is (yet) an unfounded claim. Of course, there are errors that can be detected at compile-time and there = are some that are even prevented by the grammar itself - arguably Ada is st= ronger in this area than C (or C++), but buffer overflows are not, at least= directly, in this category. --=20 Maciej Sobczak * http://www.inspirel.com