Re: [Haskell-cafe] FP and Quality
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
How about the following papers on real-world Haskell
programming results:
----- text follows immediately after this line -----
Haskell vs. Ada vs. C++ vs. Awk vs. ... An Experiment
in Software Prototyping Productivity (1994),
by Paul Hudak and Mark P. Jones:
http://citeseer.ist.psu.edu/41732.html
Why Functional Programming Matters (1984),
by John Hughes:
http://www.md.chalmers.se/~rjmh/Papers/whyfp.html
Why Haskell matters (date unknown) (Web page),
originally by Sebastian Sylvan:
http://www.haskell.org/haskellwiki/Why_Haskell_matters
----- text ends immediately before this line -----
The following resource page may also be useful:
Haskell in industry:
http://www.haskell.org/haskellwiki/Haskell_in_industry
The following site may also be useful:
Commercial Users of Functional Programming: Functional
Programming As a Means, Not an End:
http://cufp.galois.com/
Barring time constraints, I may post additional
findings later.
Benjamin L. Russell
--- PR Stanley
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
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: 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
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On 07/02/2008, Benjamin L. Russell
----- text follows immediately after this line ----- Haskell vs. Ada vs. C++ vs. Awk vs. ... An Experiment in Software Prototyping Productivity (1994), by Paul Hudak and Mark P. Jones: http://citeseer.ist.psu.edu/41732.html
This one's quite interesting but refers to the much longer report. In the bibliography it is listed as unpublished, but during the text the authors suggest you read it anyway. Does anyone have a source for this document. (A quick search has only produced further citations in other places.) J.A.N. Lee, B. Blum, P. Kanellakis, H. Crisp, and J.A. Caruso. ProtoTech HiPer-D Joint Prototyping Demonstration Project, February 1994. Unpublished; 400 pages. Cheers, D -- Dougal Stanton dougal@dougalstanton.net // http://www.dougalstanton.net
participants (3)
-
Benjamin L. Russell -
Dougal Stanton -
PR Stanley