Re:Functional Programming Is Hard, That's Why It's Good
by KirinDave on Saturday August 20, 2011 @08:10PM
(#2908113)
> It's called a database.
Programs have to have state and side effects to interact with the outside world. That's not what's frowned upon.
The goal with functional programming is to try and minimize the number of functions that involve those external transactions. The spine of your program in Haskell will revolve around IO, but all the limbs can probably avoid requiring anything more than inputs and outputs.
Perhaps a concrete example would help? Imagine parsing incoming HTTP requests on your TODO app. Ignoring streaming (which I think we can do safely in this case), your IO code is to read and write to the socket, but the intermediate code to parse the incoming request into data structures for inspection? That can and should NOT be dependent on I/O. Similarly, the code that actually generates your HTML output (before writing it to the socket) need not care about I/O.
Programs have to have state and side effects to interact with the outside world. That's not what's frowned upon.
The goal with functional programming is to try and minimize the number of functions that involve those external transactions. The spine of your program in Haskell will revolve around IO, but all the limbs can probably avoid requiring anything more than inputs and outputs.
Perhaps a concrete example would help? Imagine parsing incoming HTTP requests on your TODO app. Ignoring streaming (which I think we can do safely in this case), your IO code is to read and write to the socket, but the intermediate code to parse the incoming request into data structures for inspection? That can and should NOT be dependent on I/O. Similarly, the code that actually generates your HTML output (before writing it to the socket) need not care about I/O.