Learning Haskell makes you a better programmer?

[Walter Bright]

On 12/28/2012 12:13 AM, Red wrote:
> Why is immutable data considered necessary for functional programming style?
> Can't a a programmer or programmer just do the same thing with mutable data, but
> not mutate it?

People who say that C++ supports functional programming make exactly that argument.

The problem, though, is this:

    T func(U u); // this is a pure function

What does that tell you about func? It takes a U as one of its inputs, and 
returns an instance of T. The comment, of course, means nothing. func may read 
or write mutable global state, it may mutate whatever u references. How would 
you know?

If you wrote all the code yourself, and you didn't make any mistakes, perhaps 
you would know. But if you are handed this code, or you work on a team, you 
would have no idea. There is no tool to check it, so you'd be reduced to 
manually going through every line of it and every line of every function that 
func() calls, etc.

Then when a member of your team checks in code, you're back to square one, and 
have to start over with the manual verification, and hope you didn't make a 
mistake with that.

Of course, nobody does something that tedious, and defaults back to trusting the 
comment, which is what I'd call "faith-based programming".

I don't believe that faith-based programming scales well at all. Programs are 
getting bigger and bigger all the time, and the growth of static analysis tools 
suggests that we *need* mechanical verification of properties. Faith-based 
programming is going to wind up on the ash heap of history.

The bottom line is that a language that does not support mechanical verification 
of functional programming, does not support functional programming.