6 ms·
I would argue that imperative programming is the only one with a concept of linear time. Here's a functional example: map (*3) [0,1,2,3,4,5,6,7,8,9] Are
by itishappy 10mo ago
I would argue that imperative programming is the only one with a concept of linear time.
Here's a functional example:
map (*3) [0,1,2,3,4,5,6,7,8,9]
Are those multiplications run in sequence or parallel?
Here's a fancier functional one:
getUser = User <$> getName <*> getEmail <*> getStartDate
What order are the fields fetched?
If you answered "unspecified" then you're right! A compiler could parallelize either of these expressions!
- 1718627440 10mo ago> A compiler could parallelize either of these expressions! But that's also true for imperative languages.
- itishappy 10mo agoFair point, but I think it's a lot more true of functional ones. The problem is pretty easy to see in a C-style for loop: for (int i = 0; i < 5; i++) { printf("%d\n", i); if (i % 2 == 0) i++; } The index variable depends on it's value in previous versions of the loop and can be modified in the loop body! Can't parallelize that! Side effects and mutation break many of the promises provided by functional constructs. Hybrid languages like Python can illustrate this: # pure, parallelizable [2 * item for item in items] # side effect! order matters! [print(item) for item in items] # side effect! order matters! [arr.append(item) for item in items] A language like Haskell might be the other extreme. You're not allowed to use an `f` that breaks this: [f item | item <- items]