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: Yannick Duchêne (Hibou57) on 4 Jun 2010 08:59 Le Fri, 04 Jun 2010 14:23:07 +0200, Dmitry A. Kazakov <mailbox(a)dmitry-kazakov.de> a écrit: > If you mean mathematical statistics, then its applicability depends on > strict conditions. Prior these established the statistics (samples) of > failures is just a collection of anecdotes... As usual, with mathematics and logic, interpretation is an issue. The interpretation here should be correlation (I am not arguing this is true that software is less or more reliable than mechanical parts, as I don't have needed materials to assert anything about it). Statistics are intermediate results, and intermediate result are not always interpretable, ok, you're right. > If you mean "lies, damned lies, and statistics" then yes. (Did you know > that 90% of people died in car accidents had eaten cucumbers shortly > before > the accident? (:-)) This is not even an implication, so it is unlikely this will legitimately argue for a correlation. Here is why: âHad eaten cucumbersâ may be an antecedent of many other things, so this would not be a meaningful correlation, and moreover âHad eaten cucumbersâ may be an antecedent of âaccident occurredâ as much as âno accident occurred at allâ, so this does not justify an implication or correlation. Well, I am relying on an implicit here, because what is exactly missing, in your example, would exactly be statistics about âHad eaten cucumbersâ when âno accident occurred at allâ. Conclusion : one statistic is not relevant alone, it needs others, forming a good coverage of different cases (logic needs its food). I was wrong just saying âstatisticsâ, so the reformulation I suggest is âthis does not invalidate any noticed correlationâ (statistics being just a tool there, to help see correlation, and multiple statistics are needed for various configurations). I suppose I understand what you mean and was just wrong with my wordings.. Cheers -- There is even better than a pragma Assert: a SPARK --# check. --# check C and WhoKnowWhat and YouKnowWho; --# assert Ada; -- i.e. forget about previous premises which leads to conclusion -- and start with new conclusion as premise.
From: Fritz Wuehler on 4 Jun 2010 15:23 > > Banks get good software for their central money servers, because they > > insist that they actually work, and are secure, and spend the money to > > ensure that happens (and some of them are written in SPARK). > And the others ? None of the bank software I have seen has ever been written in Ada, much less Spark. It's is 100% COBOL. They may have front-ends written in all sorts of garbage languages (Java, etc.) but the financial processing is COBOL and there is still some amount of assembler around. Ada is better than COBOL except in one way. It is easier to write reports (the bulk of financial processing) and define decimal (money) fields in COBOL than Ada. It *could* have been used in financial processing, but COBOL had two decades and a half of a head start.
From: Dirk Craeynest on 4 Jun 2010 18:02 In article <e53f81c956a70a28ffbfdfeabd7606b6(a)msgid.frell.theremailer.net> in the Usenet newsgroup comp.lang.ada, Fritz Wuehler <fritz(a)spamexpire-201006.rodent.frell.theremailer.net> wrote: >None of the bank software I have seen has ever been written in Ada, much >less Spark. It's is 100% COBOL. They may have front-ends written in all >sorts of garbage languages (Java, etc.) but the financial processing is >COBOL and there is still some amount of assembler around. http://www.seas.gwu.edu/~mfeldman/ada-project-summary.html#Banking_and_Financial_Systems_
From: Duke Normandin on 4 Jun 2010 23:33 On 2010-06-04, Fritz Wuehler <fritz(a)spamexpire-201006.rodent.frell.theremailer.net> wrote: >> > Banks get good software for their central money servers, because they >> > insist that they actually work, and are secure, and spend the money to >> > ensure that happens (and some of them are written in SPARK). >> And the others ? > > None of the bank software I have seen has ever been written in Ada, much > less Spark. It's is 100% COBOL. They may have front-ends written in all > sorts of garbage languages (Java, etc.) but the financial processing is > COBOL and there is still some amount of assembler around. > > Ada is better than COBOL except in one way. It is easier to write reports > (the bulk of financial processing) and define decimal (money) fields in > COBOL than Ada. It *could* have been used in financial processing, but > COBOL had two decades and a half of a head start. > COBOL maybe! However, here in Canada, I'm aware that a lot of financial institutions were set up to use Mumps (now M Technology) and they're still using it. I believe the same is true in the U.S.A. Mumps is _still_ big in the Health Care sector. -- Duke Normandin *** Tolerance becomes a crime, when applied to evil [Thomas Mann] ***
From: Stephen Leake on 5 Jun 2010 00:00
"Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes: > On Fri, 04 Jun 2010 05:08:06 -0400, Stephen Leake wrote: > >> "Yannick Duchêne (Hibou57)" <yannick_duchene(a)yahoo.fr> writes: >> >>> Le Tue, 25 May 2010 04:02:20 +0200, Stephen Leake >>> <stephen_leake(a)stephe-leake.org> a écrit: >> >>> What is CMM ? >> >> http://en.wikipedia.org/wiki/Capability_Maturity_Model >> >>>> Commercial airline software is more reliable than the rest of the plane. >>> I encounter difficulties interpreting this one : do you mean >>> commercial applications or an airline company are typically more >>> reliable than the one its planes ? >> >> I mean the software in embedded computers on an airplane is more >> reliable than the mechanical components in the airplane. > > I wonder how would you (or anyone else) substantiate this claim. Just on the basis of news reports of the causes of airplane crashes. To my memory, none have been due to software. > The technical problem is that mechanical components faults have a > stochastic nature. I.e. you have a certain probability of fault (due > to physical processes involved in production and function of the given > component). On the contrary, a software fault is not stochastic, > neither in its production nor at run-time. A given bug is either here > or not. Whether the bug is encountered is sometimes stochastic. But generally you are correct. > There is no probability associated with it. Isn't it comparing apples > and oranges? Yes. And they are both fruits, and can be compared to some extent. It's not like trying to compare science fiction novels and oil wells. -- -- Stephe |