Philippe Sismondi wrote:
I am the original poster on this. [..]
One of the commonest claims made about pure functional languages, and Haskell in particular, is that programs written in pure functional languages contain fewer bugs than…"other stuff". The claim seems largely to be about (a) avoiding mutability, and (b) type safety and static type checking. (I have no quibble with the typing part of the claim; I love this in Haskell.) In the same spirit, Haskell programmers are wont to assert that they are confident that a program that compiles is a correct program. However, these claims (as made in books on Haskell, and on mailing lists such as this) are no more than anecdotal.
Note that there is a principled argument for (a) that does not rely on empirical evidence. It goes as follows: avoiding mutable state means that a piece of source code, say a function definition, can be reasoned about *without* needing to know about the possible contexts (code paths) in which it can appear. In other words, the correctness of a pure function can be checked by looking only at the function definition, the rest of the program code has no bearing on it. In contrast, mutable state usually means a "spooky action at a distance" between separate code sections.
At the risk of pouring fuel on the fire, I would ask: Can anyone point me to scientific studies quantifying the benefits of pure functional languages? I expect they exist, but I am interested not just in lack of errors, but in overall productivity. (It's easy to avoid program bugs: just write programs that don't do anything, or don't write any software at all.)
You know well that (1) such studies are hard to design for any language and (2) nobody asks for studies that quantify the benefits of imperative languages, simply because they happen to be the status quo. Still, there are some interesting case studies, for instance P Hudak and M P Jones "Haskell vs. Ada vs. C++ vs. Awk vs. ... An Experiment in Software Prototyping Productivity" http://haskell.cs.yale.edu/?post_type=publication&p=366
The value of being able to produce correct programs is, no doubt enormous. But that is hardly the end of the matter.
My sense is that most of us who produce software are less interested in error-free software than in overall productivity. There is an enormous amount of highly useful software out there that contains all kinds of both known and as yet undiscovered bugs. [..]
I always dread the prospect of dealing with non-Haskell libraries, because I often lose several days of development time investigating how a library really behaves as opposed to how it should behave according to the specification. I have mentioned two recent examples in a previous email (HTML 5 drag & drop, WebSockets), but it has also happened to me when doing development with Cocoa.
The world outside your program is stateful, I think (I agree with Heraclitus on this). Any software that must deal with the "world" outside itself over time must deal with state. So even devotees of of pure FP agree that the trick is to somehow hive off or isolate state and IO, or maybe to mimic it with pure techniques in order to ensure correctness.
Note that source code is a *model* and we are free to choose any model we like. The "true nature" of the world being "stateful" has no bearing on this. For instance, physicists actually model the world in a stateless fashion (a particle is modeled by a function from time to position in space).
But the problem of dealing with IO in Haskell is hardly a solved problem. Reading the history of Haskell one discovers that the use of monads was not the first attempt at dealing with IO in the language. Moreover, research papers continue to appear on other ways to handle state and IO in FPL. So it can hardly be said that, "well, we've got this problem licked, so just suck it up and learn it." It can hardly be questioned that people find monads tough to understand; some never do, and some (like me) can use them but find them a pain in the ass (so are arrows).
Huh? How is dealing with IO not a solved problem in Haskell? Note that there may be smarter ways to deal with "IO" (e.g. FRP), but I don't see how experiments with new models invalidate an existing model. Also note that software transactional memory (STM) is a solved problem in Haskell, something that cannot be said of any other imperative language. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com