[andolanra]

I think this is a question that's orthogonal to OOP-versus-functional-programming, but is rather about programming style. Haskell programmers like being terse, but there's also nothing stopping you from writing Haskell like this:

    alignCenter :: [String] -> [String]
    alignCenter lines =
      let maxLineLength = maximum (map length lines) in
      [ leftPadding ++ line
      | line <- lines
      , let leftoverSpace = maxLineLength - length line
            leftPadding = replicate (leftoverSpace `div` 2) ' '
      ]

You could have verbose and easy-to-read functional code—you don't see this often in Haskell by convention, but you might in OCaml or in Scheme—and you could also have terse OOP code filled with single-letter variable names (less so in Objective C by virtue of the method call syntax, but I've definitely seen code like this in Java and JavaScript.)

[roywiggins]

Functional programming seems to let people lapse into "point-free style" fairly easily, which (imho) has a much greater chance of becoming rapidly unreadable. Not to say FP can't be readable as you've demonstrated very well.

https://en.wikipedia.org/wiki/Tacit_programming

[tel]

Point free can totally be abused. It's also, in my opinion, often very useful for clarity.

It's my experience that, especially with FP code, often the important things to write down are the stages/steps in a transformation and that the intermediate outputs do not, by themselves, hold much semantic meaning.

Pointfree lets you write just those steps. Moving to "point-full" coding forces you to give names to these semantically meaningless intermediates. This can sometimes just be noise.

Terseness is also just shocking sometimes. It can take time to get used to it. I feel like when I read more verbose languages I skim each block of code numerous times and collect the meaning iteratively. When I read Haskell, I depend upon each name having distinct and important semantic meaning, I leverage type information heavily, and when I do read something I read each word carefully.

Totally different styles, but I've found strong preference for terseness.

[klodolph]

This may be more common with Haskell specifically, because Haskell makes currying so easy and has tools like http://pointfree.io/ (which I’ve definitely abused before).

[itsbruce]

Point free style possible in languages like Haskell and SML where the syntax makes it practical. Haskell and SML make it easy, Scala does not. If you made an OOP language with the right syntax features, you could have point-free style in that language too. You can do point-free style in Python with just a little effort. It's orthogonal to the FP/OOP debate.

[thsealienbstrds]

Maybe true, but writing readable code is a difficult thing in any language. No matter what language you're using, you're going to have to come up with a set of coding standards in the long run.

[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.