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.
