Coming from the OOP I started in the last weeks to read about functional programming and started to learn Haskell. Very often I was reading that (pure) functions are easier to test since there are no complicated set-up and tear-down routines. This sounds reasonable and I was agreeing. Composing these functions allows me to build more complicated functions with a very well tested “base”.
As I stared to write my first programs some functions got more and more parameters and so I started to create new data types which are for me similar to structures. Of course the data types bundle what logically belongs together and are sometimes composed of other data types.
Calling functions then like
MyTpye = foo(MyTpye, someParam)
feels a little bit like doing OOP with really ugly syntax as back in the times of C with function pointers in structs:
MyType = foo(this, someParam) = {
...
return modified_copy_of_this;
}
Testing these functions also requires me to setup the my new data type first which can be complicated and I just feel that I don’t win much.
I suppose I am still too narrow minded and focused on the OOP way of writing code. I just have the feeling that calling functions on data types is nothing else than calling methods on immutable objects (of course each setter would have to return a modified version of the object).
Can somebody please clarify this a little bit for me?
Thank you very much!
I added this Haskell example. These are my first steps and I tried to avaoid posting ugly code like this.
It’s just the first parts of a reinformcement learning algorithm. Setting up an “environment” with available states, actions and a reward function.
type Action = [Double]
type State = [Double]
data StateSet = StateSet [State] deriving (Show)
data ActionSet = ActionSet [Action] deriving (Show)
data Environment = Environment {
availableStates :: StateSet,
availableActions:: ActionSet,
currentState :: State,
rewardfnc :: State -> Action -> Double,
lastReward :: Double
}
rewardFunction :: State -> Action -> Double
rewardFunction s a = (-1)
doAction :: Environment -> Action -> Environment
doAction env a = Environment (availableStates env) (availableActions env) a (rewardfnc env) ((rewardfnc env) (currentState env) a)
getReward :: Environment -> Double
getReward env = (lastReward env)
states = StateSet [[i,j] | i <- [1..10], j <- [1..10]]
actions = ActionSet [[i,j] | i <- [1..10], j <- [1..10]]
initEnv = Environment states actions [0,0] rewardFunction 0.0
env = doAction initEnv [2,2]
reward = getReward(env)
I felt the same way as you did when I first started learning functional programming — that
calling functions on data types is nothing else than calling methods on immutable objects.I think it’s important to realize that this is one way to look at FP, and not the only way. Simiarly, the OOP methodology of grouping data and procedures together into classes is one way to think about programming, but not the only way. For some problems, OOP leads to great solutions, while for others, it’s not so good.
The example you’ve given, or the way you’ve chosen to solve it, may just happen to a better fit for OOP than for FP. Not that you can’t solve it with FP, just that doing so seems a little awkward and forced — as you’ve noticed. My guess as to the reason that this example is giving you trouble, is because it deals with changing an environment — very natural for OOP.
There are other problems for which the FP solution will seem natural and simple, and the OOP version awkward and forced. Think of problems where the solution involves transforming the input into output:
To sum it up, if you continue with functional programming, you’ll find that there are other problems for which FP is well-suited, and whose solutions are much simpler and natural than they would be in OO languages.