Prev: Symbolic tracebacks on Debian (Was: About static libraries and Debian policy)
Next: Gnat cross compiler
From: Dmitry A. Kazakov on 6 Jun 2010 13:22 On Sun, 06 Jun 2010 14:58:20 +0100, Simon Wright wrote: > "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes: > >> On Sun, 06 Jun 2010 11:22:41 +0100, Simon Wright wrote: >> >>> "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes: >>> >>>> 2. Your confidence describes you, it does not the program. It fact, it >>>> is like - I give my word, it works. Fine, but why anybody should trust >>>> my word? >>> >>> Because you are a gentleman? (sorry -- been re-watching Lost In Austen!) >> >> A measure of being gentleman? > > This was meant to be a joke, apologies. More-or-less in this sense: > http://en.wikipedia.org/wiki/Gentleman#Gentleman_by_conduct > >>> Because you have given your word in the past and it has proved >>> trustworthy? >> >> Proved how, means, measures? BTW, statistics isn't applicable here either. >> Let you write the same program 100 times. What is the probability that you >> won't make a mistake X? It is not a probability. The code deviation after >> stripping factors of learning, tiredness, disgust, rebellion is null. > > 'proved' might not have been the right word. I meant, if you are the > release manager for a project and receive an updated package from a > developer, you'll have a degree of trust in the suitability of the > update which depends on how reliable that developer has been in the > past. This all does not go beyond confidence factors (AKA truth values). There is no way to estimate a confidence factor otherwise than by an expert poll. The ways evidences are combined are quite ad-hoc. Now, how to translate this into decision making? Input: confidence 0.78 Output: the project will be completed in 2 months Input: confidence 0.78 Output: next engine maintenance is required after 462 flight hours -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: tmoran on 6 Jun 2010 15:27 >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. 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. 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.
From: Georg Bauhaus on 6 Jun 2010 17:22 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).
From: Duke Normandin on 6 Jun 2010 22:15 On 2010-06-06, Fritz Wuehler <fritz(a)spamexpire-201006.rodent.frell.theremailer.net> wrote: >> > Yes, only in H/C. No American bank uses MUMPS. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> Are you sure? I've heard differently from MUMPS folks. > > Pretty sure. There may be the odd ball out there but 99.9% run IBM z/OS or > VSE. If they say otherwise let them name names. > Look here: http://www-01.ibm.com/support/docview.wss?uid=isg1_MUMPSVM_MUMPS-VM MUMPS (the language/database) has run and continues to run, on _many_ platforms, including z/OS. Which means that perhaps the MUMPS hackers still know of what they speak, although I have zero first-hand knowledge on the banking software in the U.S.A. -- Duke Normandin *** Tolerance becomes a crime, when applied to evil [Thomas Mann] ***
From: Non scrivetemi on 7 Jun 2010 02:06
> http://www-01.ibm.com/support/docview.wss?uid=isg1_MUMPSVM_MUMPS-VM > > MUMPS (the language/database) has run and continues to run, on _many_ > platforms, including z/OS. Which means that perhaps the MUMPS hackers > still know of what they speak, although I have zero first-hand knowledge > on the banking software in the U.S.A. I don't know of any American bank that uses it and I work with hundreds of banks. Like I said there may be some oddballs but no major operation is going to mess around with that stuff. |