4 ms·
Indeed, it might be sometimes frustrating to pass around state that in C would be directly modifiable, but the benefits are huge. Such as? Ok, so you get bette
by didroe 17y ago
Indeed, it might be sometimes frustrating to pass around state that in C would be directly modifiable, but the benefits are huge.
Such as? Ok, so you get better multithreaded behaviour but now you're copying state all the time and having to thread it though all your functions. Sometimes just updating state is the right thing to do.
Personally, I think a good tradeoff is immutable data but mutable references.
- miloshh 17y agoThe main benefit, as I mentioned above, is that if a pure function works once, it works all the time. This is captured by the saying "in Haskell, if it compiles, it works", which is surprisingly often true. If you have a function that moves a player in a game such as movePlayer :: PlayerState -> PlayerState, you know that it only changes the state of this player, and nothing else. In an OO language you would do something like player.doUpdate(), which has absolutely no guarantees. Plus there are many facilities available to deal with threading and hiding state.
- silentbicycle 17y ago> you know that it only changes the state of this player, and nothing else. This gets ugly when the state of every actor can potentially affect the state of every other actor, though. This is pretty common in games. That's the main point the linked article is making.
- miloshh 17y agoYes, and it is a weak point. My point, instead, was that FP does not break down when things get ugly; on the contrary, it gives much stronger guarantees on correctness. Of course, it takes effort to express the problem in the more restrictive functional paradigm.
- ellyagg 17y agoYeah. I fail to see how scads of global data is less ugly.