Sunday, May 16, 2010

Arguments from Personal Incredulity

Here's one of my favorite Richard Dawkins quotes:
Never say, and never take seriously anyone who says, "I cannot believe that so-and-so could have evolved by gradual selection". I have dubbed this kind of fallacy "the Argument from Personal Incredulity". Time and again, it has proven the prelude to an intellectual banana-skin experience.
Of course, Dawkins is talking about evolution, but I see the same sorts of "Arguments from Personal Incredulity" come up again and again in discussions about functional programming. Except, the "Personal Incredulity" argument is something along the lines of: "I cannot believe that such-and-such can be done without side effects..."

2 comments:

Anonymous said...

Now, the question is what you consider to be side-effects. If the ST monad counts as a side-effect (which I do), then clearly there are things which cannot be done with the same complexity as the lazy-thunk updating machine that is pure Haskell. For example, the simulation of the state of a memory over time.

But you are free to demonstrate the impossible.

Also, certain non-trivial algorithms often use mutable state in certain interesting ways which are also outside of functional programming. I will be the first to point out however that those kinds of algorithms make up less than 5 percent of a large application.

And then there is the abstraction over what run-time system hides. One wants to have a RTS which is efficient without any issues, but this is not the case for a lot of systems (including GHC (look at the open bugs)). Using a well-tested simple system in that case has some advantages over a system which has seen less use.

There are a lot of people that say "functional programming is bad", but saying "functional programming is good" is just as bad.

Paul Chiusano said...

@Anonymous - I could have been a bit more precise and said "no referential-transparency-breaking side effects" or "no observeable side effects" but that seemed overly pedantic :) (although I seriously considered writing both of these!) The ST monad, lazy thunk updating, the IO monad - none of these break RT.

As you suggest, there are probably cases where observable state is needed for efficiency, and I think precise arguments about when this is the case are valuable. It's the handwavy "oh noes!! I NEED observable side effects to do X" type arguments that I have a problem with.