[59nadir]

In our codebase we enforced usage of `>>>` instead, which composes forward instead of backwards:

    strSum = words >>> map read >>> sum

For most people this then becomes "Apply `words` to the input argument, pass the result to `map read` and then `sum` the results of that".

I don't think `.` is super complex to read and parse, but we had people new to Haskell so I thought it prudent to start them off just with `>>>` and keep it that way. Most things are read left-to-right and top-to-bottom in a codebase otherwise so I don't see why not.

Edit:

I also told everyone it's fine to just spell out your arguments:

    stringSum sentence =
        sentence
        & words
        & map read
        & sum

In the example above `&` is just your average pipe-operator. Not currying when you don't have to is also fine, and will actually improve performance in certain scenarios.

Edit 2:

The truth is that there are way more important things to talk about in a production code base than currying, and people not using currying very much wouldn't be an issue; but they'll have to understand different pointer/reference types, the `ReaderT` monad (transformer), etc., and how a `ReaderT env IO` stack works and why it's going to be better than whatever nonsense theoretical stack with many layers and transformers that can be thought up. Once you've taught them `ReaderT env IO` and pointer types (maybe including `TVar`s) you're up and running and can write pretty sophisticated multi-threaded, safe production code.