Software Quality in Science
in [ADA]
|
From: Ludovic Brenta on 10 Feb 2010 08:55 On Feb 9, 10:51 pm, Jerry <lancebo...(a)qwest.net> wrote: > "The net result of changing languages appears > to be that the overall defect density appears to be about the same, > (Hatton 1997). In other words, when a language corrects one > deficiency, it appears to add one of its own." Ah but the study must have overlooked one thing. A strongly-typed language with an emphasis on software quality will naturally attract developers who understand the benefits of strong typing and value software quality. Conversely, a loosely-typed, lax language will attract sloppy programmers who do not understand why typing should be strong or who believe that bugs are good for their job security. So, even if the author's assertion were true (i.e. Ada has just as many traps and pitfalls as C, which I disagree with), developing in Ada with Ada-minded programmers will always be safer than developing in C with C-minded programmers. In fact, developing in C with Ada- minded programmers is safer, too. The same reasoning applies to Spark vs. Ada. -- Ludovic Brenta.
From: Hibou57 (Yannick Duchêne) on 10 Feb 2010 09:21 On 10 fév, 14:55, Ludovic Brenta <ludo...(a)ludovic-brenta.org> wrote: > The same reasoning applies to Spark vs. Ada. Such a comparison would not come without a difference : Ada is safer than C, while it is capable of more than C. SPARK is safer than Ada, but although attractive at first sight, it imposes a lot of restrictions which make it less capable than Ada (capable : I'm talking about the extend of constructs you can create with it). While a demanding C developer may be wonderfully happy to learn about Ada, an Ada designer may possibly have less reasons to switch to SPARK (unless otherwise required). Proof : near to all Adaiste know about SPARK, but just a few of them use it. The path from Ada to SPARK has nothing to be compared to the one of from C to Ada. Side note for little words about C : the typical laxity of C is sometime useful for quick modeling when interfacing with system API is involved. Out of subject, I know, it was just to tell C developers we do not really hate them so much and give them a Welcome Here :p (I myself occasionally relying on C by the way).
From: Stephen Leake on 10 Feb 2010 09:29 Robert A Duff <bobduff(a)shell01.TheWorld.com> writes: > Jerry <lanceboyle(a)qwest.net> writes: > >> Here is the link in the Guardian article to the original work: >> >> http://www.leshatton.org/Documents/Texp_ICSE297.pdf > > Thanks for the link. > >> And this comment which addresses the use of Ada: > > Hmm. Looks like it fails to address Ada (or C++) > due to "lack of space". I skept. Me too. Paraphrasing Fermat doesn't make it true; it just makes you look like you are being deliberately mysterious. >> "In C, note that function prototypes were well used only around 60% of >> the time and as a result, interface faults accounted for about 24% of >> the total. In other words, if function prototypes were mandated in all >> C functions, 24% of all serious faults would disappear. > > Surely that's no longer a problem in modern C!? The programmers still have to specify the right switches, and pay attention to the results, and know how to fix them, which is a political/management/skill issue, not a language design issue. I know from personal experience that there is a satellite about to be launched who's control code has many remaining C warnings. Sigh. -- -- Stephe
From: Stephen Leake on 10 Feb 2010 09:34 Georg Bauhaus <rm.tsoh.plus-bug.bauhaus(a)maps.futureapps.de> writes: > Robert A Duff wrote: >> Jerry <lanceboyle(a)qwest.net> writes: >> >>> ...The net result of changing languages appears >>> to be that the overall defect density appears to be about the same, >>> (Hatton 1997). In other words, when a language corrects one >>> deficiency, it appears to add one of its own." >> >> That assertion requires evidence, and I don't see it here! > > Indeed, looking at some of the things that Les Hatton suggests > to be doing for a living, there might be an incentive not to > perform a comparative study of the effects of using statically > checked C (with Safer C (TM)) versus statically "checked" Ada > (Spark, or SofCheck Inspector (TM)). IOW, language choice does not > matter as long as you use our tools and participate in our training > courses. That has almost always been my reaction when I attend a software tools sales pitch; "I don't need that tool, the Ada compiler already does all of it". Adacontrol and SPARK are tools I would consider using (they add real value beyond the Ada compiler), but I've never been to a sales pitch for those :). > His arguments still seem based on studies from the mid 1990s. > A study is something at least. Is there anything in the Tokeneer > data that could serve as a basis for a comparison? > What failure modes might Spark add? Brain pain, for one. Understanding how to use Ada well is an order of magnitude harder than understanding how to use C; I suspect SPARK is another large increase (I've only looked into it lightly, never tried to seriously use it). I suspect this is one reason Ada has failed to take over the programming space; you have to be a really good programmer to fully benefit from it, and it's just not worth it for a mediocre programmer. -- -- Stephe
From: Hyman Rosen on 10 Feb 2010 09:38
On 2/10/2010 9:29 AM, Stephen Leake wrote: > The programmers still have to specify the right switches, and pay > attention to the results, and know how to fix them, which is a > political/management/skill issue, not a language design issue. The same is true for Ada, at least as implemented in GNAT. > I know from personal experience that there is a satellite about to be > launched who's control code has many remaining C warnings. Sigh. Well, isn't that part of "pay attention to the results"? Not all warnings represent things that need to be fixed. |