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!

> A compiler could parallelize either of these expressions!

But that's also true for imperative languages.

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]

I thought fp was more avoiding mutability/reassigning values to identifiers

What you wrote makes me think more of the point free style

When hearing of assignment statements, I think of mutability. Point free makes me think of (low to) no variables, rather than no assignments