logoalt Hacker News

1718627440last Tuesday at 11:53 AM1 replyview on HN

> A compiler could parallelize either of these expressions!

But that's also true for imperative languages.


Replies

itishappylast Wednesday at 10:39 PM

Fair 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]