Re: Generic-Package Elaboration Question / Possible GNAT Bug.

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 23.11.11 10:04, Dmitry A. Kazakov wrote:
> On Wed, 23 Nov 2011 00:52:23 +0100, Georg Bauhaus wrote:
>
>> On 22.11.11 20:15, Dmitry A. Kazakov wrote:
>>
>>>> Meyer: "Programming is a human activity".
>>>> Programmers are led towards a solution during the process of programming.
>>>> Depending on the characteristics of the process, then,
>>>> programmers will produce different results.
>>>
>>> I see no word "debugging" there.
>>
>> A debugging aid is a means of finding mistakes when developing programs.
>
> So it is the debugging driven design you are advocating for. Designing by
> fixing bugs. Nice, very nice... exactly the thing I don't want for Ada.

Specifications have bugs.

Since designing with annotations (instead of without them, or with
comments only)  happens at the level of abstract data types,
DbC absolutely wants programmers to be honest about the
bugs in their ADTs' interfaces.  These bugs exist
in brains, on paper, or in package specs. Or, well, as aspects.
At this stage, one cannot use a debugger for executable programs,
because there is no program.  But there are bugs already.
DbC need not happen at the level of concrete implementation (again,
being finally a non-trivial, but redundant consequence of the
annotated program). In fact, DbC emphasizes that assertions
do not replace conditionals.


> I bet that coffee is far more helpful than frantic patching the
> program in the debugger.

What debugger?


> One of the key points of good design is NOT to have such descriptions. The
> reader of the program, be it human or the compiler should be able to
> *understand* what you are describing.

What is it that a reader of a package spec should be able to understand?
ADTs without invariants?
Subprograms of unknown effect, but possibly raising a ubiquitous exception?
Yes, it is possible to understand these things, but I don't understand
how this is so useful in comparison.


>> There is no right or wrong in most programs.
>
> You cannot build safe software on false premises.

Almost all programs have a number of things that can go wrong,
they are not safe, but they are pretty safe. Yes, pretty safe.
That's bad, but it is something. Reduces risk of stress-induced
health problems caused by buggy programs.
My point is that it is better to reduce the number of annoyances
created by such programs, rather than to insist that ensuring
total safety is impossible in general.

> You could bring thousands
> reasons, but none can change the fact. What is wrong is wrong.

Wrong means wrong with respect to some formalism; the one given
is too trivial for my taste, or maybe I don't understand it.
I need proof of "wrong to do this", and will, like you, continue
to use compilers, which might be wrong.