3 ms·
> I would say pure FP languages such as Haskell are actually the best for such a case. Because in these languages the order/timing of lines of code are decouple
by slver 5y ago
> I would say pure FP languages such as Haskell are actually the best for such a case. Because in these languages the order/timing of lines of code are decoupled from the execution order/timing.
... That's good in your opinion?
- valenterry 5y agoIf your program is simple and LoC are executed one by one and that is totally fine, then FP just takes away the natural relation between LoC and execution and adds another layer of unnecessary complexity. But when the percentage of concurrent code grows bigger, then it is better - because you lose the LoC<->execution relation anyways. You can for example see that in Python. Python makes it really hard to break out of that model and have a line of code running while another one is running. That's why paralle and async/concurrent programming is such a PITA in python. So, in my opinion for some problems the FP style is much better, because instead of "working your way around", you embrace the fact that LoC and execution are inherently decoupled.