

Can functional programming be liberated from the von Neumann paradigm? - 0x44
http://conal.net/blog/posts/can-functional-programming-be-liberated-from-the-von-neumann-paradigm/

======
frisco
It isn't often I hear people complaining that Haskell isn't pure enough.

~~~
tel
Haskell's motto _is_ "avoid success at all costs".

------
1053r
To carry the philosophy of functional programming to its logical extreme is to
deny the existence of time. Some physicists have seriously suggested models
that don't include time, but in the milieu of common human existence things
happen and stuff has state.

State and time are always going to rear their ugly heads for functional
programmers (often in the form of "the i/o problem"). There's just no way
around it. This isn't to discount functional programming as a tool in the
toolbox, but "philosophically pure" functional programming is an ideal as
platonic and unreachable as the math it is derived from.

~~~
winter_blue
Beautifully said. I was going to post a comment saying the same thing, but
you've put it in much better words than I would have. Thanks.

It's sad some programmer fall into the purity trap and try to make things as
functional as possible and end up taking a lot more time than they normally
would have, make the code incredibly hard to understand, etc.

I once fell into this trap and paid dearly. I'm a university student and for
one of my semester projects I decided to try out pure functional programming.
I ended up failing that class because I didn't finish the project, and doing
bad in others because I spent ridiculous amounts of time doing the impossible
project. (The project itself was easy - a simple 2D sidescroller game in C++,
something I could have done in a week if I had been sensible; but writing a
game in functional style in C++ proved to be incredibly hard.)

~~~
chipsy
You may have failed classes, but the lessons learned in working on something
so improbable were probably worth the price of admission.

It's good to be too pure for learning purposes, because it makes you
comfortable with a lot of nitpicky stuff. When you move towards commercial
software, you won't get an environment that encourages you to take on the
risky stuff. "Lean and mean" is the order of the day. So having the other
experience gives you an edge in perspective.

~~~
vog
I disagree. The lesson to be learned is _not_ that pure functional programming
it too extreme, but that it _takes time to adopt that style_.

As with any other style (OO, etc.), you won't get it right in your first
attempt. It takes time to get a feeling for good design - in any style.

~~~
eru
And C++ is not really the right language to try functional approaches. (You
should at least at a garbage collector to vanilla C++ if you want to try.)

~~~
scott_s
Well... you actually can try out functional approaches in C++, and even gain
something out of it. It's just that doing so requires a sophisticated
understanding of C++.

~~~
eru
And probably a sophisticated understanding FP as well, if you want to apply it
in such a hostile environment.

Not really a good idea when you are starting out, I guess.

------
anonymousDan
Can anyone explain to me how the io monad gives referential transparency? So,
say I have a function to read a file:

readFile :: String -> IO String

readFile filename = ...

At time t1, if I invoke it it returns say:

IO "Contents at t1"

At time t2, if I invoke it it returns say:

IO "Contents at t2"

Given that we supplied the function with the same argument (i.e. fname), and
it returns two different values, how can they be said to be equal? I'm
probably totally misunderstanding this but anyway....

~~~
yummyfajitas
It isn't just IO that breaks referential transparency, State does the same
thing. The function get might have different values at different times.

Of course, get is a pure function mapping (State a) -> (State a) a, and the
value hidden in the state is different between successive function calls.

Now just treat IO as State World, and think of the compiler as the function
execState initialWorldValue.

