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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Ichbiah's Letter Date: Sat, 25 Oct 2014 12:04:04 +0200 Organization: cbb software GmbH Message-ID: <1pgm5po9g6xht$.1svdogelukl6r$.dlg@40tude.net> References: <558688c3-02b0-4e14-838b-2d94074030bd@googlegroups.com> <87k33oecnw.fsf@ixod.org> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: Xn+ybM2JynFOXdIT5N5zBw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: number.nntp.giganews.com comp.lang.ada:190030 Date: 2014-10-25T12:04:04+02:00 List-Id: On Sat, 25 Oct 2014 10:12:03 +0100, Mark Carroll wrote: > Of course, as an Ada novice, it raises the question for me of to what > extent the voiced concerns were actually borne out. There was much truth in what Ichbiah wrote. Newer versions of Ada added greatly to complexity. Still all underlying concepts were sound and necessary. But the shape they took was questionable at best. The only way to maintain complexity of this sort is breaking a new level of generalisation. Ada's design consistently failed this which led to a blown up language. [...] > So, did Ada get all kinds of confusing extra interacting-features stuff > added? Despite any greater consequent complexity in the compiler or > run-time, is it easy for people needing to write really clear, certain > code to avoid those corners of the language and keep with a > solid-feeling subset, or is it all clear enough that there's no need to > hide from scary corners? Language subsets is a very popular and deeply wrong idea, IMO. It is frequently promoted by many in Ada community, e.g. notorious claims that one could choose if he wanted to use OO features or stay strictly procedural. Exactly this attitude leads to explosion of complexity as you need all functionality anyway in all popular subsets of single language. > Basically, if I am learning about modern Ada, I wonder how soon I'll > reach high confidence about what my code that actually compiles will do > when I execute it, or to what extent I'll have to adopt certain > disciplines, or avoid certain things, to achieve that. The concept of safe language Ada 83 promoted was that disciplines must have been a side effect of applying the language rather than of persistent awareness of the programmer moving across the minefield. From the software engineering POV, you cannot depend on willingness to follow the rules to obtain predictable result and desired level of quality. > For instance, I > would imagine that the contract-based programming offered in Ada 2012 is > actually a move toward greater reliability without making the actual > code that does stuff any harder to understand, Actually most these features significantly decrease code reliability as accessibility checks did to Ada 95. Ichbiah mentions them. Presently approximately 50-80% of all run-time faults are due to false-positive dynamic checks. I don't know how large will be the rate of false-positive checks with dynamic constraints. This depends on practice and yet to be seen. However seeing predicates containing Integer'Value (Text) discussed here, I would suggest it high. > and the way they seem to > be written in some logic-based language looks encouraging: plenty of > languages have some kind of "assert " statement, but writing > the predicates declaratively means that the "rephrasing" of at least > some aspect of what the code does This is another problem with it. Declarations shall *not* contain implementation of the behavior. New features do exactly the opposite. A contract should state verifiable constraints on the implementation. It is not "what" it is "how". > might (a) make me think more clearly > and deeply about what it does and (b) being a rephrasing, not propagate > bugs in the code to become matching bugs in how I check that things are > as I thought. There are two related but different concepts: 1. Contract [how] 2. Correctness proof [what] #2 includes checking contracts. Neither shall produce executable code. Yes, both are incredible useful. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de