Re:John Carmack on Functional Programming (2013) [video]
by crimsonalucard on Thursday August 17, 2017 @06:51PM
(#15041793)
I'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.
Re:John Carmack on Functional Programming (2013) [video]
by ece on Thursday August 17, 2017 @07:40PM
(#15042085)
Being 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.
Re:John Carmack on Functional Programming (2013) [video]
by crimsonalucard on Thursday August 17, 2017 @11:43PM
(#15043379)
>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?
* 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.