Ada noob here! Is Ada widely used?
in [ADA]
|
Prev: Symbolic tracebacks on Debian (Was: About static libraries and Debian policy)
Next: Gnat cross compiler
From: Dmitry A. Kazakov on 7 Jun 2010 03:26 On Sun, 06 Jun 2010 23:22:15 +0200, Georg Bauhaus wrote: > On 6/6/10 3:10 PM, Dmitry A. Kazakov wrote: > >>>> Some, but as I said Ada drifts towards less checks. >>> Really ? I don't feel so much and don't believe most interested parties >>> will allow it. >>> The introduction of DbC in the Ada 2012 language itself, even goes the >>> opposite way. Isn't it ? >> >> You forgot that run-time check is not a check to me. It is a language >> design bug. I am afraid I will like Ada 2012 even less than Ada 2005. > > It seems worthwhile mentioning that DbC's primary purpose > is not to augment programs with run-time checks; rather, DbC asks > for programmers who write as if there was no assertion monitoring > but who explain their code with pre/post/inv. The operator may > turn on run-time monitoring so that he/she is notified if something goes > wrong (disproving the programmers' assumptions; the monitor stops > the program or runs the remains in a debugger). Yes, and this manifests a language design bug to me. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Dmitry A. Kazakov on 7 Jun 2010 03:48 On Sun, 6 Jun 2010 19:27:48 +0000 (UTC), tmoran(a)acm.org wrote: >>The problem is that to apply this theory to software you need maybe, >>imaginary space of elementary outcomes (independent, complete etc). I don't >>see any of that in the software. It is a fundamental issue. > The number of bugs in a certain piece of software is analogous to the > number of unexploded WWII bombs buried in Berlin. No. Both are realizations of some process. The latter was to some extent random, the former was not. If you drop bombs from the same spot they will distribute themselves in some area. If you rewrite a line of code, you introduce the same bug or no bug each time. The way how the source code line N receives a bug M is not random. Lines are not equivalent in their affinity to bugs. Bugs are not necessarily located in a single line. Bugs are not necessary located in adjacent lines. Bugs are not same, and so on and so forth. > There are a certain, > unknown, number, and next Wednesday none, or at least one, will be > discovered. But the probability of discovering a bug, or a bomb, is a > number which can be guesstimated. OK, that is yet another process. It only makes things more complicated. The way bombs are discovered could be considered stochastic, however I am not very sure about it. As for bugs, it is certainly not stochastic. But in any case the discovery process tells nothing about the software itself. You need some theory/model in order to be able to say that if the bug discovery rate was Rn-3, Rn-2, Rn-1, Rn, then it is to expect the next rate Rn=f(Rn-3, Rn-2, Rn-1, Rn). I don't see any such theory. And it seems to me that it cannot be mathematical statistics, at least prior to a probabilistic model of bugs (not their discovery process). > And the size of that probability > informs our decision about whether to launch the rocket that depends on > that software, or whether to disband the bomb squad. In the real world > you can't throw up your hands and say "I don't know the probability" > because someone will ask "OK, should we launch/disband or not?" and you > need to give an answer. Yes, and the answer is as always: 4.12... (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Martin Krischik on 7 Jun 2010 03:56 Am 06.06.2010, 23:22 Uhr, schrieb Georg Bauhaus <rm-host.bauhaus(a)maps.futureapps.de>: > On 6/6/10 3:10 PM, Dmitry A. Kazakov wrote: > It seems worthwhile mentioning that DbC's primary purpose > is not to augment programs with run-time checks; rather, DbC asks > for programmers who write as if there was no assertion monitoring > but who explain their code with pre/post/inv. The operator may > turn on run-time monitoring so that he/she is notified if something goes > wrong (disproving the programmers' assumptions; the monitor stops > the program or runs the remains in a debugger). Sounds a lot like Java assertions. We makes me think: If the captain thinks that there might be icebergs on route he orders to take on live boats. If not he leaves them at shore to save petrol and gain extra speed. The later is default if the captain forgets to make a decision. Or worse: If the captain does not believe the engineer that the ship is unsinkable he orders to take on of live boats. If not … Martin -- Martin Krischik mailto://krischik(a)users.sourceforge.net https://sourceforge.net/users/krischik
From: Georg Bauhaus on 7 Jun 2010 07:13 On 07.06.10 09:56, Martin Krischik wrote: > Am 06.06.2010, 23:22 Uhr, schrieb Georg Bauhaus > <rm-host.bauhaus(a)maps.futureapps.de>: > >> On 6/6/10 3:10 PM, Dmitry A. Kazakov wrote: > >> It seems worthwhile mentioning that DbC's primary purpose >> is not to augment programs with run-time checks; rather, DbC asks >> for programmers who write as if there was no assertion monitoring >> but who explain their code with pre/post/inv. The operator may >> turn on run-time monitoring so that he/she is notified if something goes >> wrong (disproving the programmers' assumptions; the monitor stops >> the program or runs the remains in a debugger). > > Sounds a lot like Java assertions. We makes me think: > > If the captain thinks that there might be icebergs on route he orders to > take on live boats. If not he leaves them at shore to save petrol and > gain extra speed. The later is default if the captain forgets to make a > decision. A captain requesting lifeboats does not prepare for exception handling. You use lifeboats when the ship sinks, the ship's components have failed, possibly after an impact of unexpected I/O (an iceberg popping up, say). By analogy, sinking is when the program stops. DbC, however, has to do with designing components of the ship. You can have rescue clauses (exception handlers) in DbC. But the idea is that a correct program is better. Yet, praising one-self to be preparing for exceptional situations is only as safe normal flow of control within and from exception handlers---if they are at all prepared to handle a situation. Exceptional situations is "unprogrammed" exceptional state, since this is what "exceptional" is about, if anything. And if a hammer turns out to be made of wood, some contract is broken. If no one thought of such a preposterous choice of material for a hammer, it will be reasonable to expect there is no handler for this outcome. Hence no rescue clause. Next ship will have a type, though, that allows distinguishing different kinds of hammer.
From: Dmitry A. Kazakov on 7 Jun 2010 08:22
On Mon, 07 Jun 2010 13:13:18 +0200, Georg Bauhaus wrote: > DbC, however, has to do with designing components of the ship. > You can have rescue clauses (exception handlers) > in DbC. To whom should Titanic have sent the exception? To the humpback whales? > Exceptional situations is "unprogrammed" exceptional state, > since this is what "exceptional" is about, if anything. Any state is programmed. This includes the exceptional ones. When bug happens, the program is in no state. > And if a hammer turns out to be made of wood, > some contract is broken. http://en.wikipedia.org/wiki/Mallet -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |