Software Quality in Science
in [ADA]
|
From: Martin on 10 Feb 2010 10:09 On Feb 10, 2:34 pm, Stephen Leake <stephen_le...(a)stephe-leake.org> wrote: > Georg Bauhaus <rm.tsoh.plus-bug.bauh...(a)maps.futureapps.de> writes: > > Robert A Duff wrote: > >> Jerry <lancebo...(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 No, no!! I've worked with guys I won't trust to programme my VCR...but with an Ada compiler they were able to generate something that worked (and met timing/space requirements). If they'd been let loose with a C compiler (or worse a C++ one) they'd still be at now (10 years on)... I'd add a smiley but it's sad really... Cheers -- Martin
From: Robert A Duff on 10 Feb 2010 11:24 Hyman Rosen <hyrosen(a)mail.com> writes: > 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. Yes. Seat belts only work if you buckle them. Don't put pennies in your fuse box. >> 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. Yes, but I think you need a way to systematically mark the ones that don't need to be fixed. That's what pragma Warnings(Off) is for. At AdaCore, we insist on warning-free builds for out Ada code, which requires using that pragma sometimes. - Bob
From: Robert A Duff on 10 Feb 2010 11:37 Stephen Leake <stephen_leake(a)stephe-leake.org> writes: > Georg Bauhaus <rm.tsoh.plus-bug.bauhaus(a)maps.futureapps.de> writes: >> 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? I don't know if you'd call this a "failure mode", but SPARK has heavy restrictions. For example, recursion is not allowed. If I'm writing a compiler, I _will_ be using recursion, because languages have recursive features (expressions contain subexpressions, etc). If the language doesn't support recursion directly, I will have to implement it myself, using an explicit stack. That's error prone, compared to using recursion in Ada. So I wouldn't want to write a compiler in SPARK. On the other hand, if you don't need recursion and various other features, then SPARK is an excellent choice. > 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. I'm not sure that's true. McCormick's paper about toy trains says otherwise (students were able to produce working code in Ada, but not in C, even with extra help in the C case). It's true that Ada is a big language, but a lot of it can be safely ignored. There's no need for an Ada programmer to understand the overload resolution rules, for example. - Bob
From: Martin on 10 Feb 2010 12:05 On Feb 10, 4:37 pm, Robert A Duff <bobd...(a)shell01.TheWorld.com> wrote: > It's true that Ada is a big language, but a lot of it > can be safely ignored. There's no need for an Ada > programmer to understand the overload resolution rules, > for example. Unlike C++'s (broken) ADL rules! :roll: -- Martin
From: Bob Spooner on 10 Feb 2010 17:52
"Ludovic Brenta" <ludovic(a)ludovic-brenta.org> wrote in message news:ddb8b59c-d746-4228-b7a9-7ace7058018b(a)u26g2000yqm.googlegroups.com... 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. In my experience, a lot of the problem with lack of improvement in software quality and reliability when using Ada results from developers writing Ada code the same way they write C. Then you don't get Ada's advantages and debugging is just as much of a problem as with C, with problem symptoms showing up far from the cause, etc. If Ada isn't used the way it was designed to be used, you get results similar to when you try to use a pair of pliers as a hammer. Bob Spooner |