4 ms·
FP is not gonna wall you off from doing stuff like this. For example, and this is just off the top of my head, you could: * provide an explicit sequencing of w
by ves 9y ago
FP is not gonna wall you off from doing stuff like this. For example, and this is just off the top of my head, you could:
* provide an explicit sequencing of when actors take their turns, passing updated resources to each in turn. This is your "step by step" imperative approach, and you're basically writing a main game loop.
* don't sequence the actors, but implement a lock on the resource using a TVar. This is the simplest async approach.
* many more approaches I haven't thought of
The point of FP is to be provide as much information about the logic of the program as possible. If two actors can move to the same point at the same time, then you need to write down logic to handle that case, whether actors move in sequence or independently.
Not writing down that logic because "I have an imperative language" is how you get bugs, especially race conditions.
- crimsonalucard 9y agoI'm not arguing about which paradigm is better. I'm not saying theres no way around it. I'm just describing a single pitfall in the functional paradigm. That's all.
- ece 9y agoBeing able to write asynchronous (multi-threaded or not) code so easily using FP is most definitely not a pitfall. Even in the most simple multi-threaded imperative programs, no compiler or hardware will give you almost any sort ordering guarantees by default. You have to use atomics or volatile or something else to get specific ordering guarantees. It's the same in FP compilers too.
- crimsonalucard 9y ago>Being able to write asynchronous (multi-threaded or not) code so easily using FP is most definitely not a pitfall. Your point? You're saying this as if I disagreed with you. What are you trying to argue here? That FP is the better than imperative? Did I ever dispute that claim? Where are you going with this?