4 ms·

Unfortunately, it didn't help to convince me either. For me the question still remains: how is any of this better than good ol' reliable `for` loop?

mrkeen 4y ago
How is the for-loop any better than good ol' GOTO?
- Jorengarenar 4y ago
  Conceptually, `for` loop is just syntactic sugar - it simplifies certain action, not makes it more difficult.
  - pedrovhb 4y ago
    Conceptually, the `map` function is just syntactic sugar for `for` loops, and it's also meant to simplify actions. There are functional equivalents to many small patterns of code that occur often - for instance lst = [] for element in range(10): lst.append(element * 2) Is a very common pattern, that can be expressed with less typing (and less mental overhead, when you become used to it) by lst = list(map(lambda x: x * 2, range(10))) Similarly, another very common mini-pattern is total = 0 for el in range(10): total += 3 * el Which can be more swiftly expressed by total = reduce(lambda acc, el: acc + 3 * el, range(10)) These examples are trivial, but once you start using these higher level syntactic sugar-like constructs, you often find that code tends to fit together more nicely and in ways that make more sense, even if only because you used a filter operation before the map instead of writing another level of nested `if` statements inside a loop body. Code gets easier to follow, not unlike how it's easier to reason about the behavior of a `for` loop than it is to keep a bunch of `goto`s in your mental model of what the code does while at the same time thinking about whether the business logic part of it makes sense.
    - im3w1l 4y ago
      For what its worth, the pythonic solution is lst = [x * 2 for x in range(10)]
    - wruza 4y ago
      Tbh, I get your imperative examples instantly but my mind struggles to autograsp these multilevel functional parts like list(map(lambda. Too much noise, I have to think through it to get it. I’d prefer a loop with ifs and continues/breaks. It may be a lack of experience or habit, but then I can write code like that (and worse), and it doesn’t make any sense to me. Don’t get me wrong, not that I refuse to use maps or filters or folds, but not that I want to make a whole program of them either. They have their place where factoring-out a block of code feels stupid, but if I had something like: [1, 2, for (x of xs) { if (cond) {emit x} }] I’d never bother with these function-al things. It’s not FP that is rich, it’s a traditional imperative syntax that sucks. Paradigm shift is not equal to usage out of [in]convenience.
      - jve 4y ago
        > I can write code like that (and worse), and it doesn’t make any sense to me I'm learning FP and I see value with writing code with map, reduce etc as those are expressions instead of statements. Expressions guarantee you have a result of particular type (with possible side effects if you prefer), but statements DO side effects. The loop may or may not insert some value into resulting list because some branching happened or you forgot some else condition, with map you guarantee you get same number of objects of particular type back. Plus that enables composition (like in C# LINQ) - by not extending some loop with different kind of responsibilities but just passing result to next function that modifies/filters the result. https://fsharpforfunandprofit.com/posts/expressions-vs-statements/ https://fsharpforfunandprofit.com/posts/expressions-vs-state...
      - atraac 4y ago
        > Tbh, I get your imperative examples instantly but my mind struggles to autograsp these multilevel functional parts like list(map(lambda. Too much noise, I have to think through it to get it. That's exactly why most FP languages have pipe operator, so it's incredibly easy to read. lst = range(10) | map(fn x -> x * 2 end) | map(etc...) or total = range(10) | reduce(0, fn elem, acc -> acc + (elem * 3) end)
- Gordonjcp 4y ago
  Why is anything better than GOTO? You use GOTO all the time, even if it's wrapped in an abstraction that makes its intentions less clear.
- wruza 4y ago
  In numbered-lines code you can’t see the start of a goto loop. In labeled-lines code it’s not that hard to infer that it is a jump target, but having a condition/iterator in one place is an obvious benefit. That said, I believe most people who “boo GOTO” never actually used it to make sense of what could be wrong with it and how it feels really. Anyway, I think that this analogy(?) is confusing and makes no sense.
- koonsolo 4y ago
  Indeed! I started programming in GW-BASIC when I was 13. IF and GOTO was all I needed! FOR, FUNCTION, ... why was it there?
em500 4y ago
John Carmack on Twitter: "My younger son said “coding is basically just ifs and for loops.” Which inspired this great cartoon: https://twitter.com/nice_byte/status/1466940940229046273 https://twitter.com/nice_byte/status/1466940940229046273

mrkeen 4y ago

How is the for-loop any better than good ol' GOTO?

Jorengarenar 4y ago
Conceptually, `for` loop is just syntactic sugar - it simplifies certain action, not makes it more difficult.
- pedrovhb 4y ago
  Conceptually, the `map` function is just syntactic sugar for `for` loops, and it's also meant to simplify actions. There are functional equivalents to many small patterns of code that occur often - for instance lst = [] for element in range(10): lst.append(element * 2) Is a very common pattern, that can be expressed with less typing (and less mental overhead, when you become used to it) by lst = list(map(lambda x: x * 2, range(10))) Similarly, another very common mini-pattern is total = 0 for el in range(10): total += 3 * el Which can be more swiftly expressed by total = reduce(lambda acc, el: acc + 3 * el, range(10)) These examples are trivial, but once you start using these higher level syntactic sugar-like constructs, you often find that code tends to fit together more nicely and in ways that make more sense, even if only because you used a filter operation before the map instead of writing another level of nested `if` statements inside a loop body. Code gets easier to follow, not unlike how it's easier to reason about the behavior of a `for` loop than it is to keep a bunch of `goto`s in your mental model of what the code does while at the same time thinking about whether the business logic part of it makes sense.
  - im3w1l 4y ago
    For what its worth, the pythonic solution is lst = [x * 2 for x in range(10)]
  - wruza 4y ago
    Tbh, I get your imperative examples instantly but my mind struggles to autograsp these multilevel functional parts like list(map(lambda. Too much noise, I have to think through it to get it. I’d prefer a loop with ifs and continues/breaks. It may be a lack of experience or habit, but then I can write code like that (and worse), and it doesn’t make any sense to me. Don’t get me wrong, not that I refuse to use maps or filters or folds, but not that I want to make a whole program of them either. They have their place where factoring-out a block of code feels stupid, but if I had something like: [1, 2, for (x of xs) { if (cond) {emit x} }] I’d never bother with these function-al things. It’s not FP that is rich, it’s a traditional imperative syntax that sucks. Paradigm shift is not equal to usage out of [in]convenience.
    - jve 4y ago
      > I can write code like that (and worse), and it doesn’t make any sense to me I'm learning FP and I see value with writing code with map, reduce etc as those are expressions instead of statements. Expressions guarantee you have a result of particular type (with possible side effects if you prefer), but statements DO side effects. The loop may or may not insert some value into resulting list because some branching happened or you forgot some else condition, with map you guarantee you get same number of objects of particular type back. Plus that enables composition (like in C# LINQ) - by not extending some loop with different kind of responsibilities but just passing result to next function that modifies/filters the result. https://fsharpforfunandprofit.com/posts/expressions-vs-statements/ https://fsharpforfunandprofit.com/posts/expressions-vs-state...
    - atraac 4y ago
      > Tbh, I get your imperative examples instantly but my mind struggles to autograsp these multilevel functional parts like list(map(lambda. Too much noise, I have to think through it to get it. That's exactly why most FP languages have pipe operator, so it's incredibly easy to read. lst = range(10) | map(fn x -> x * 2 end) | map(etc...) or total = range(10) | reduce(0, fn elem, acc -> acc + (elem * 3) end)
Gordonjcp 4y ago
Why is anything better than GOTO? You use GOTO all the time, even if it's wrapped in an abstraction that makes its intentions less clear.
wruza 4y ago
In numbered-lines code you can’t see the start of a goto loop. In labeled-lines code it’s not that hard to infer that it is a jump target, but having a condition/iterator in one place is an obvious benefit. That said, I believe most people who “boo GOTO” never actually used it to make sense of what could be wrong with it and how it feels really. Anyway, I think that this analogy(?) is confusing and makes no sense.
koonsolo 4y ago
Indeed! I started programming in GW-BASIC when I was 13. IF and GOTO was all I needed! FOR, FUNCTION, ... why was it there?

em500 4y ago

John Carmack on Twitter: "My younger son said “coding is basically just ifs and for loops.” Which inspired this great cartoon: https://twitter.com/nice_byte/status/1466940940229046273 https://twitter.com/nice_byte/status/1466940940229046273