5 ms·

While it does remove edge cases, the code also becomes more opaque. At least to me, functional style programming seems much harder to read and then reason about

While it does remove edge cases, the code also becomes more opaque. At least to me, functional style programming seems much harder to read and then reason about.

dpc_pw 7y ago
It takes some time to get used to and change mental model from "program describes step by step what to do" to "program describes logical flow of information". I moved from first camp to the second one somewhere during my adult life. And IMO: Both are valid, sometimes first one is necessary (because that's how the machines actually work), but second one is clearly better most of the time for humans, especially in business-logic heavy cases.
- thaumasiotes 7y ago
  There's an analogous switch in algebra from notation like f(g(x)) to something more like X_{GF} (where the _{} indicates subscripting, not written symbols). Note the better left-to-right ordering in the terser system. It's the same dichotomy; are you thinking of f(x) as an instruction to do f to x, or are you thinking of X_F as what happens when X goes through F?
vippy 7y ago
This is a learning thing, honestly. Once you start thinking in types, it clicks: you're thinking at a higher level of abstraction, so the code is less important than understanding how the programmer put the types together in their head to solve a problem.
- Mirioron 7y ago
  But I am already thinking about what the code should do. The problem is that if I read functional code I get bogged down in the details of what limits are set by the operations, because they're usually not as explicit. It's like reading a chain of functions on some element (actually, it quite literally is that).
lmkg 7y ago
It's subjective. My experience is exactly the opposite. A pipeline of sequence operations is something I can skim at a glance, but a for-loop is a pile of code that I need to stare at before I understand what it represents. This does not invalidate your experience. It's common, and with good reason. This sort of dissimilar experience with the same code is why coding standards need to be views as social norms for the team using them, and not just technical things.
- eru 7y ago
  The problem with loops is that they are too powerful. They can do almost anything. The functions map and filter are nice and restricted. If you want more power, you use eg a fold. And if you need even more power, you write a new recursive function. So a quick look at the code will tell you what to expect.
  - edflsafoiewq 7y ago
    Personally I've found that although this argument sounds good in theory, in practice I don't find loops harder to read than chains of combinators.
    - eru 7y ago
      Which languages are you reading them in? For me the argument holds in practice as well. I'm mostly reading my combinators in Haskell, and the loops in Python or some curly brace language. If you use a general purpose combinator like mapAccumL that has almost as much power as a loop, you don't get that much extra readability compared to the loop. It's still a bit better, because that combinator still has to process one element of your list for each run through it's "body"; and it clearly warns you by it's very name that it's not just a filter or map, so there's less possibility of confusing it for something simpler. And, of course, not all loops are created equal. When applicable, for-each loops are much cleaner than classic C-style for-loops for example.
eru 7y ago
Depends. Though some black-boxing is intended: thanks to enforced information hiding the compiler (and you) can make additional assumptions about what your code can not do.

While it does remove edge cases, the code also becomes more opaque. At least to me, functional style programming seems much harder to read and then reason about.

dpc_pw 7y ago

It takes some time to get used to and change mental model from "program describes step by step what to do" to "program describes logical flow of information". I moved from first camp to the second one somewhere during my adult life. And IMO: Both are valid, sometimes first one is necessary (because that's how the machines actually work), but second one is clearly better most of the time for humans, especially in business-logic heavy cases.

thaumasiotes 7y ago
There's an analogous switch in algebra from notation like f(g(x)) to something more like X_{GF} (where the _{} indicates subscripting, not written symbols). Note the better left-to-right ordering in the terser system. It's the same dichotomy; are you thinking of f(x) as an instruction to do f to x, or are you thinking of X_F as what happens when X goes through F?

vippy 7y ago

This is a learning thing, honestly. Once you start thinking in types, it clicks: you're thinking at a higher level of abstraction, so the code is less important than understanding how the programmer put the types together in their head to solve a problem.

Mirioron 7y ago
But I am already thinking about what the code should do. The problem is that if I read functional code I get bogged down in the details of what limits are set by the operations, because they're usually not as explicit. It's like reading a chain of functions on some element (actually, it quite literally is that).

lmkg 7y ago

It's subjective. My experience is exactly the opposite. A pipeline of sequence operations is something I can skim at a glance, but a for-loop is a pile of code that I need to stare at before I understand what it represents. This does not invalidate your experience. It's common, and with good reason. This sort of dissimilar experience with the same code is why coding standards need to be views as social norms for the team using them, and not just technical things.

eru 7y ago
The problem with loops is that they are too powerful. They can do almost anything. The functions map and filter are nice and restricted. If you want more power, you use eg a fold. And if you need even more power, you write a new recursive function. So a quick look at the code will tell you what to expect.
- edflsafoiewq 7y ago
  Personally I've found that although this argument sounds good in theory, in practice I don't find loops harder to read than chains of combinators.
  - eru 7y ago
    Which languages are you reading them in? For me the argument holds in practice as well. I'm mostly reading my combinators in Haskell, and the loops in Python or some curly brace language. If you use a general purpose combinator like mapAccumL that has almost as much power as a loop, you don't get that much extra readability compared to the loop. It's still a bit better, because that combinator still has to process one element of your list for each run through it's "body"; and it clearly warns you by it's very name that it's not just a filter or map, so there's less possibility of confusing it for something simpler. And, of course, not all loops are created equal. When applicable, for-each loops are much cleaner than classic C-style for-loops for example.

eru 7y ago

Depends. Though some black-boxing is intended: thanks to enforced information hiding the compiler (and you) can make additional assumptions about what your code can not do.