4 ms·

> Do you really think it would be clearer to write Absolutely, anyone with programming experience can make sense of the longer (and still quite terse) version.

> Do you really think it would be clearer to write Absolutely, anyone with programming experience can make sense of the longer (and still quite terse) version. whileM ((<=) <$> readLeftIdx <*> readRightIdx) $ do is literally symbolic soup without knowing the context and language in which it is written. For example `(<=)` could be less than or equal, but then again, given all of the other operators, who knows, might pipe output into whatever's calling `whileM`.

catnaroek 10y ago
My point is that a Haskell programmer would be able to make sense of either version equally easily. Chaining applicative actions using <$> and <*> is a very common idiom. If you don't know it, you don't know Haskell.
nilkn 10y ago
> Absolutely, anyone with programming experience can make sense of the longer (and still quite terse) version. Is that true? I'm skeptical. Why is the "<-" symbol clearer to you? In particular, why did the commenter above write li <- readLeftIdx instead of let li = readLeftIdx ? I don't think anyone with programming experience could correctly answer this question unless they also have some specific Haskell experience. What exactly does "return" do? I don't think someone without Haskell experience has any chance of answering that correctly, because it does not have the same meaning that it does in most languages. You might be able to make a reasonable guess, but you're unlikely to actually get it right. I think once you're at the point that you can completely understand and answer these questions, the odds are high that you'll appreciate a more economical syntax for these operations.
- virtualwhys 10y ago
  The repetion of `<-` for both li and ri seems to imply setting the variable on the left with the value on the right. As for return, even if the semantics of return are different in Haskell the keyword itself is quite common in programming languages. Therefore, given that it's the last statement one can assume that it returns the result of `(li <= ri)`. If you know Haskell then the one liner is likely obvious. If not, not at all, there's a lot of domain specific knowledge required to grok what the one liner actually does. The long form version at least provides some guide posts to work off of.
  - catnaroek 10y ago
    > The repetion of `<-` for both li and ri seems to imply setting the variable on the left with the value on the right. (...) one can assume that it returns the result of `(li <= ri)`. No, that's not what it's doing. It's not imperative assignment. It's not even a `let` binding. Against popular belief, you actually need to learn a programming language to make sense of code written in it. > If you know Haskell then the one liner is likely obvious. If not, not at all, there's a lot of domain specific knowledge required to grok what the one liner actually does. s/Haskell/C/, s/one/hundred/g
    - virtualwhys 10y ago
      Even if `<-` is not assigning a value, within the monadic context bind is doing just that, assigning result of the expression on the right to the variable on the left. The point is that everyone can take a guess as to what's happening in the long form version.
      - catnaroek 10y ago
        > Even if `<-` is not assigning a value, within the monadic context bind is doing just that, assigning result of the expression on the right to the variable on the left. What about monadic actions that may return less or more than one value? For instance, parsers for languages with non-deterministic grammars, that return all valid parse trees, rather than just the zeroth one. > The point is that everyone can take a guess as to what's happening in the long form version. And that guess would often be wrong.
  - nilkn 10y ago
    I don't deny that there's value in having someone with no experience with the language be able to make some reasonable guesses about what the code does. It's hard to argue that this could ever be a bad thing. At the same time, I think it's less valuable than it might seem. A vague, cursory understanding is enough in this case to get a gist of what's happening, but it's not enough to actually work with the code, except via luck. The intuition you describe works okay in this case, but it would fail somewhat spectacularly in other cases, for instance with the non-determinism of the list monad.

catnaroek 10y ago

My point is that a Haskell programmer would be able to make sense of either version equally easily. Chaining applicative actions using <$> and <*> is a very common idiom. If you don't know it, you don't know Haskell.

nilkn 10y ago

> Absolutely, anyone with programming experience can make sense of the longer (and still quite terse) version. Is that true? I'm skeptical. Why is the "<-" symbol clearer to you? In particular, why did the commenter above write li <- readLeftIdx instead of let li = readLeftIdx ? I don't think anyone with programming experience could correctly answer this question unless they also have some specific Haskell experience. What exactly does "return" do? I don't think someone without Haskell experience has any chance of answering that correctly, because it does not have the same meaning that it does in most languages. You might be able to make a reasonable guess, but you're unlikely to actually get it right. I think once you're at the point that you can completely understand and answer these questions, the odds are high that you'll appreciate a more economical syntax for these operations.

virtualwhys 10y ago
The repetion of `<-` for both li and ri seems to imply setting the variable on the left with the value on the right. As for return, even if the semantics of return are different in Haskell the keyword itself is quite common in programming languages. Therefore, given that it's the last statement one can assume that it returns the result of `(li <= ri)`. If you know Haskell then the one liner is likely obvious. If not, not at all, there's a lot of domain specific knowledge required to grok what the one liner actually does. The long form version at least provides some guide posts to work off of.
- catnaroek 10y ago
  > The repetion of `<-` for both li and ri seems to imply setting the variable on the left with the value on the right. (...) one can assume that it returns the result of `(li <= ri)`. No, that's not what it's doing. It's not imperative assignment. It's not even a `let` binding. Against popular belief, you actually need to learn a programming language to make sense of code written in it. > If you know Haskell then the one liner is likely obvious. If not, not at all, there's a lot of domain specific knowledge required to grok what the one liner actually does. s/Haskell/C/, s/one/hundred/g
  - virtualwhys 10y ago
    Even if `<-` is not assigning a value, within the monadic context bind is doing just that, assigning result of the expression on the right to the variable on the left. The point is that everyone can take a guess as to what's happening in the long form version.
    - catnaroek 10y ago
      > Even if `<-` is not assigning a value, within the monadic context bind is doing just that, assigning result of the expression on the right to the variable on the left. What about monadic actions that may return less or more than one value? For instance, parsers for languages with non-deterministic grammars, that return all valid parse trees, rather than just the zeroth one. > The point is that everyone can take a guess as to what's happening in the long form version. And that guess would often be wrong.
- nilkn 10y ago
  I don't deny that there's value in having someone with no experience with the language be able to make some reasonable guesses about what the code does. It's hard to argue that this could ever be a bad thing. At the same time, I think it's less valuable than it might seem. A vague, cursory understanding is enough in this case to get a gist of what's happening, but it's not enough to actually work with the code, except via luck. The intuition you describe works okay in this case, but it would fail somewhat spectacularly in other cases, for instance with the non-determinism of the list monad.