Thanks, keep the tips coming. I like the ones about the type safety and line counts. Cheers, Paul At 23:33 04/02/2008, you wrote:
Good luck with this - I'd love to see the outcome.
My experience is that FP tends to result in a lot less code, so if there are x bugs per line of code, FP has less bugs per complete application.
Talking about haskell, the typesystem dissalows whole classes of bugs. Things simply do not compile if you stitch the innards together in the wrong order (particuarly if you are agressive about using the most general types possible). Since this accounts for perhaps 90% of where I do things wrong in Java, I get a corresponding decrease in run-time bugs in haskell. However, this is somewhat compensated for by the effort needed to get haskell programs through the compiler in the first place - debug at compile or debug at runtime is the tradeoff here.
FP is easier to verify mechanically than imperative programming - more of the logic is exposed directly. It's easier to do by-case proofs, even if they are by-hand rather than mechanical.
However, all of this is annecdotal. Good luck collecting real stats, or peer-reviewed annecdotes. You may have luck looking at bug-fix times vs number of developers for equivalent FP and Java apps/libs. Worth a shot, given that the bug-trackers tend to be public. You could probably tie it back to the size of the 'fix' patches. Get some nice graphs?
Matthew
On Monday 04 February 2008, you wrote:
Hi folks I'm thinking of writing a little essay arguing the case for the advantages of FP for producing quality software. Can the list recommend any papers/articles which I can use as sources of my argument? I have access to the IEEE database too although earlier I couldn't find anything on the subject. Thanks, Paul
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe