Re: Ichbiah's Letter

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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 <Boolean>" 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