bugs from n+k patterns (was: Re: Preventing/handling space leaks)

[Henk-Jan van Tuyl]

L.S.,

On Thu, 11 Dec 2003 06:23:51 -0800, Iavor S. Diatchki <diatchki at cse.ogi.edu> wrote:

:
:
> Henk-Jan van Tuyl wrote:
>
>> 1) It takes no effort, once you are use to it, to code without n+k patterns;
>
> this does not seem like a good argument.  there are many other features like that in haskell. for example, going by that we could
> remove lambda abstractions (i am not saying we should)

This is, of course, as apposed to the effort it takes to solve problems that might occur when using n+k patterns.

>> on the other hand, when you often use these patterns, you might spend hours debugging an endless looping program.
>
> how do n+k patterns lead to looping programs?

I can't remember exactly, it was a complicated story and I already decided not to use these patterns (it had something to do with pattern bindings; I don't know where I read it).

>
>> If you are working under high pressure in a large project, chances are, that the testing departement will find your bug and write a bug report (or worse, the customer might find it). Report handling and bug solving costs an enormous amount of money. This has resulted in the "clean room" approach for software design: prevent bugs rather than solve them. See also Finnagle's Law.
>
> i find this reasoning backward.  i agree (of course!) that we should write programs without bugs. i find it strange that people often motivate that, by telling me that bugs cost a lot of money for some company.
> if companies happened to make money out of bugs (and some do), would it then be ok to write buggy software?
> i guess it all comes down to what one takes as primary -- writing good software, or making money.

It is almost impossible to write large programs without bugs; it takes a lot of effort to prevent/solve bugs, and a lot of people don't seem to care much about this.
I have often heard remarks like:
   - We don't have time to do things right the first time; our software will be too expensive if we try to do that.
   - It's easier to solve bugs afterwards. (How will you know you found every bug?)
   - It takes too much time to think about a structured solution.
   - If I use a goto, I have less typing to do. You can write perfect programs using gotos.
   - After explaining the first few steps of the V-model to a new project leader: "Whenever will you get to the real work if you do all that?!"
   - (At the yearly performance evaluation:) You asked me to write down the specs of the program that you were to design: you shouldn't stick to formalism when we have so little time.
   - We have to release version 3.0 before our competitor (or: we have to stick to the release date); we will solve the rest of the bugs in 3.1 (as we had only one month to solve a lot of bugs and add the missing pieces and it wasn't properly tested, release 3.1.1 was necessary to get the product accepted by our customers).
   - The client doesn't mind a few bugs.

If you look up statistics in software engineering books, you will find that only one or two percent of the software is "bugfree" and according to customer specifications, at the first release. An amazing percentage of projects is even never finished (I believe it was twenty percent).

To get back to the topic of this mailing list: in my search for reliable software for a reasonable amount of work, I found that Lockheed uses a functional language in the specification phase of their projects, to create testable function specifications. That's why I am now studying Haskell, to use either as a specification language or for coding the final product.

>> 2) It is likely, that n+k patterns dissapear in the next Haskell standard. If you don't like to rewrite, test and debug all your software every few years, don't use any language/compiler features that are likely to dissapear. This is another thing that might cost companies a lot of money.
>
> i didn't know anyone is working on a next haskell standard.  have n+k patterns been made obsolete?

See http://www.haskell.org/development/ or search the web for "Haskell 2" or "Haskell II".

>
> -iavor
>



-- 
Best regards,
Henk-Jan van Tuyl