[newen]

Honestly...how is that more readable? It's more verbose sure but the first example is much more readable and straightforward. Here, you have to remember Haskell's list comprehension syntax and you have to scan up and down a few times to keep track of the variables.

[andolanra]

> …you have to remember Haskell's list comprehension syntax…

I get the point you're trying to make, but this feels like a huge stretch. Haskell's list comprehension syntax is straightforward and in many cases a terse and useful way of implementing complex functionality. You'll find multiple uses of it in the base libraries; notably, catMaybes is implemented in terms of list comprehension:

    catMaybes :: [Maybe a] -> [a]
    catMaybes ls = [x | Just x <- ls]

I'm all for reducing cognitive load, but Haskell has such a sparse syntax and this specific feature is so useful (and honestly, so consistent with the rest of Haskell's syntax) that arguing it's some kind of unnecessary cognitive burden feels ridiculous to me.

[newen]

Yeah I mostly agree but I mentioned it because I spent some time trying to figure how how the leftPadding variable in the let block can be referenced outside the let block. It's been a couple of years since I've used Haskell.

[misja]

The main benefit of example 2 IMO is that some variables got readable names. E.g. n became maxLineLength and x became line.

But bad naming practices have nothing to do with FP per se. Although it does seem to be fashionable in part of the FP community to have everything as terse as possible including variable names.

[newen]

To me, code with terse variables are much more readable since it's much easier to keep track of the variables when scanning the code. When I read that piece of code above, I didn't try to ascertain meaning from the variable names which, it's arguable whether I (or anyone) should or not since coders can assign variables arbitrary names.