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.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,ea5071f634c2ea8b X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.36.6 with SMTP id m6mr3918415pbj.4.1322046932705; Wed, 23 Nov 2011 03:15:32 -0800 (PST) Path: lh20ni8780pbb.0!nntp.google.com!news2.google.com!goblin1!goblin.stu.neva.ru!noris.net!news.teledata-fn.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Wed, 23 Nov 2011 12:15:30 +0100 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Generic-Package Elaboration Question / Possible GNAT Bug. References: <7bf9bc32-850a-40c6-9ae2-5254fe220533@f29g2000yqa.googlegroups.com> <4295dc09-43de-4557-a095-fc108359f27f@y42g2000yqh.googlegroups.com> <3snehoqgs8ia$.1nobjem6g6hx6$.dlg@40tude.net> <128rdz2581345$.c4td19l7qp9z$.dlg@40tude.net> <16ipwvpdavifr$.17bxf7if7f6kh$.dlg@40tude.net> <4ecb78b1$0$6643$9b4e6d93@newsspool2.arcor-online.net> <1iofgbqznsviu$.phvidtvxlyj4$.dlg@40tude.net> <4ecbb96e$0$6581$9b4e6d93@newsspool3.arcor-online.net> <4ecbdfdb$0$6629$9b4e6d93@newsspool2.arcor-online.net> <12hfiflyf7pr5$.l3pkpgoid8xt$.dlg@40tude.net> <4ecc35b8$0$7628$9b4e6d93@newsspool1.arcor-online.net> In-Reply-To: Message-ID: <4eccd5d2$0$6637$9b4e6d93@newsspool2.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 23 Nov 2011 12:15:30 CET NNTP-Posting-Host: 25cd9d2a.newsspool2.arcor-online.net X-Trace: DXC=08?dHPh0[RZV;Ef1`Jk54\A9EHlD;3YcR4Fo<]lROoRQ8kFejVX1:G4`DH3cX\mD^SADkC9nT X-Complaints-To: usenet-abuse@arcor.de Xref: news2.google.com comp.lang.ada:14566 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2011-11-23T12:15:30+01:00 List-Id: 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.