Software's evil

Another is to use a sane language, such as Ada.

To be accurate, it is your fault for letting any Microsoft software get within sight of your project. There should be nothing that you don't have the source for, and thus the ability to correct.

Indeed, the company were I was previously, intended to do that before I left. I told them that we were previously at level 1 and that, thanks to their reorganisation, we were now at level 0. They didn't believe it. One year later the company was closed.

The buzzword was "cost reduction", so everything went away, procedures, tests, validation, etc.

WOW! Now, that's something you don't hear every day.

If anyone would have the solution, he or she would probably win the Nobel Prize. You should think about the proportions of the things we are talking about. Imagine You have some program that accepts a string of up to 50 characters (and these are lower case letters (26 of them), upper case letters (26 of them) and numbers (10 of them), not to mention other possible characters which I will forget for now. If You want to fully test that program, You would have to offer it (26+26+10)^50=an incredibly huge number of strings. But apart from that, You will have to offer it strings that are too big, to check if the program will handle those in an OK fashion.

Off course You can check the source if it somehow does input checking but to be absolutely sure (what if the compiler has an error?) You would have to perform that test.

It is impossible.

Yours sincerely, Rene

You could check that some property is true for 'a', and that, if it is true for x, it is also true for x+1.

But then we are talking formal methods.

Given unlimited time and budget, what is really impossible ? ;)

Getting unlimited time and budget. ;-P

Indeed. One of my friends was the lead engineer for the first automatic teller machine. One of the design goals was that it would dispense cash with the same or better accuracy as a human teller, not perfection...

larwe wrote:

Only because too few programmers recognize the benefits of using a type-safe language. Ada is type-safe provided you do not use the Unchecked_Conversion and Unchecked_Deallocation packages.

By comparison, in C and C++ it is *extremely* difficult (impossible in the fully general case) for a compiler to ensure type safety.

While a type-safe language obviously doesn't eliminate all software bugs, it does completely eliminate one significant class of bugs.

Back in the 1980s and 1990s, a lot of people criticized Ada for being too big a language. Those same people seem to love C++ now, despite it being a bigger, more complex language than Ada 95.

Eric

If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one? -- Tom Cargin (C++ Journal, Fall 1990)

That is 4.165 E+89 combinations plus the error checking limit tests (another two orders of magnitude perhaps). Sounds quite formidable. However, such a routine should be made up of smaller tested components which have each undergone thorough testing.

My methods include static code inspections (including comparison with the requirements specification), functional performance checking and limits error checking. It starts with the smallest component (very thoroughly detailed) through to the upper levels of the application (more concentration on identified limiting conditions). Of course, the compilers I use are quite simple, thoroughly tested and validated from source to the machine code that is laid down.

Of course, none of the above gets done in any sort of a hurry. Such thorough testing has to be planned properly and any methods utilised need to be validated as appropriate and adequate.

I remember several Apollo program disasters (not all software related). Yes I am ancient enough for that. NASA did a significant amount of final testing on Live TV in those days.

Yes, Static Code Inspections, especially when you can also compare with the requirements specification, will eliminate the majority of the coding errors (and even some of those errors that other tools will not discover).

I would suggest that the one man outfit had better have some form of process in place which he employs to ensure the quality of his product. As one who has operated as a one man band at times I used to hire people to just walk through the code inspections with me. Countless silly errors were eliminated that way.

Schedules need to be estimated with a range of likely-hoods and properly managed in their publication to management. Steve McConnell's book "Software Estimation - Demystifying the Black Art" is an interesting read on the topic. I now realise why I like the PERT planning methods (and diagramming) so much.

The main message in this thread has been (I think) that having a decent documented and implemented development process matters. Ensuring that the process is truly followed is paramount. Inspections and Reviews are worthwhile activities that will improve the overall bottom line for the accountants even though they may seem intensive and expensive at the time. And finally, short cuts cost more money in the long run.

That is probably because they still haven't got the message that the choice of language has very little to do with the final product integrity. The Development Process and its proper management is a much more important factor, along with rigorous code inspection and design reviews.

Can you give some specific references? I would like to read such studies, because my intuition and experience say otherwise. There is also evidence for the importance of language, for example in a post on c.a.e. by John R. Strohm (12/17/2003) that is part of a thread at

Quoting from Strohm:

Same question as above: reference?

That has been shown repeatedly in studies of safety critical projects

Proper process is required and requirements... I suggested this on the accu mail list and gout laughed out of caught... apparently none of their members bother with requirements specs and most say they have never done a flow chart! Or much documentation!

In the safety critical systems club journal there as an article saying that the choice of language was irrelevant as process was correct.

Incidentally it is easy to have a type safe C... you just run PC-lint with the strong typing enabled. Lint is a much a part of the C language as the compiler which is why lint was invented whilst C was still being stabilised (before K&R1)

I can beat that - did you know that flowcharting is no longer taught as part of an embedded engineering degree in many tertiary institutions here?

Basic UML data relationship modeling is taught (in a brandy^H^H^H^H^H^HJava sauce); that's about it.

... snip ...

Not so. Nothing gives you integer sub-ranges, or checks array access when the mechanism is a pure pointer, for example. These dynamic runtime checks are not feasible in C.

Ada is a boring language, because it provides so few opportunities to show off. And this is only slightly tongue in cheek: a C++ guru can write code that a novice would struggle to understand. It would be much more difficult to do that in Ada.

One of the best experiences I have ever had with a compiler was an Ada compiler back in the 80's, which gave me a warning that basically said: "I compiled your program because you asked, but if you ever try to run it, it will raise constraint_error on line X. To see why it would do that, see the language reference manual, section Y.Z."

But the measurement was limited to correctness of final product, right?

I would agree that a good process can produce the same result with either ADA or some "unsafe" language like C or assembler. But I would bet dollars to donuts that the ADA team will complete the work faster, with fewer repeat inspections per module, and with fewer modules (not counting those provided by the language). Why? because programmer productivity has been shown to be fairly constant in debugged lines per day. Given that, any language that is closer to the problem domain will result in shorter development time.

Otherwise, I cannot believe language choice is "irrelevant", even in a strong development process environment.

Ed

Language is irrelevant to the final quality and integrity of the product which depends more on the quality and integrity of the development process.

There may be productivity differences between languages but to determine what they are may require some carefully formulated comparison experiments to determine. Counting Function Points over a range of projects using different languages might get some sort of feel for language choice and productivity.