5 ms·

> the `do` syntax makes it patently obvious what is the important value Given that it seems that the majority of people who attempt to learn Haskell end up giv

> the `do` syntax makes it patently obvious what is the important value Given that it seems that the majority of people who attempt to learn Haskell end up giving up, I'd argue that very little about it is "patently obvious". > it is the one being assigned into variables within the block and used as argument of functions I think this is part of what confounds me when it comes to Haskell (aside from the terrible syntax and horrible coding conventions): when I'm reading an expression I understand the overall expression by understanding what the sub-expressions do. That is, I can start at the leaves of the expression tree and work my way up to the root. In Haskell, sometimes this is not possible, because sometimes the type of the subexpression is constrained by something higher up in the AST. This leaves me not knowing where to start with trying to decipher the type of an expression. > About the aversion to using parens, matched operators make your code brittle and hard to change. This is not obvious if you have never seen any other way of organizing code, but it is a large effect. What are "matched operators"? The aversion to using parens means that I can't even parse code unless I know the fixity rules of all of the operators in an expression. I'm sure you'll say this is easy to pick up after a while, but that has not been my experience.

marcosdumay 9y ago
> In Haskell, sometimes this is not possible, because sometimes the type of the subexpression is constrained by something higher up in the AST. The point is that this constraint always have the exact same format. It may have some different semantics, but Haskell makes you abstract over those to get into the operational function, while the compiler verifies anything that isn't local operations to fit your overall structure. Really, learning Haskell is the process of learning to abstract semantics away from your code. It's a hard process, it's not something natural. > What are "matched operators"? Those are operators that require a matching. Usually parenthesis, square brackets and braces. Haskell has the unmatched operators `.` and `$` that people use instead, and for reading it you do have to understand their priority. Most operators do not a set fixity, but those two are a must.
- xenomachina 9y ago
  > > In Haskell, sometimes this is not possible, because sometimes the type of the subexpression is constrained by something higher up in the AST. > The point is that this constraint always have the exact same format. I'm not sure how to even parse that sentence. Let me phrase as a question: when trying to understand a given piece of code, how can I determine the type of an expression when its type is someone determined by its sub-expressions (like virtually any other typed language), but sometimes is determined by what consumes it? The way people can deal with the complex is by decomposing them into smaller parts, understanding those, and then composing that to understand the whole. It seems that in Haskell you are required to understand the whole thing at once, because you can't reliably determine the type of a sub-expression out of context. > > What are "matched operators"? > Those are operators that require a matching. Usually parenthesis, square brackets and braces. And how do "matched operators" make code more brittle and harder to maintain? I think the opposite is true: to maintain code you must first be able to read it, and what you call "matched operators" are far superior for readability compared to having to remember fixity rules. Even after 3 years of dealing with Haskell I found myself constantly misreading code because I didn't get the fixity right.
  - tome 9y ago
    Could you please give a concrete example? The majority of Haskell expressions have what is called a "principal type". The type of such an expression is independent of its subexpressions or super- expressions.
    - xenomachina 9y ago
      A concrete example of what?
      - tome 9y ago
        A concrete example of an expression that you have difficulty determining the type of.

marcosdumay 9y ago

> In Haskell, sometimes this is not possible, because sometimes the type of the subexpression is constrained by something higher up in the AST. The point is that this constraint always have the exact same format. It may have some different semantics, but Haskell makes you abstract over those to get into the operational function, while the compiler verifies anything that isn't local operations to fit your overall structure. Really, learning Haskell is the process of learning to abstract semantics away from your code. It's a hard process, it's not something natural. > What are "matched operators"? Those are operators that require a matching. Usually parenthesis, square brackets and braces. Haskell has the unmatched operators `.` and `$` that people use instead, and for reading it you do have to understand their priority. Most operators do not a set fixity, but those two are a must.

xenomachina 9y ago
> > In Haskell, sometimes this is not possible, because sometimes the type of the subexpression is constrained by something higher up in the AST. > The point is that this constraint always have the exact same format. I'm not sure how to even parse that sentence. Let me phrase as a question: when trying to understand a given piece of code, how can I determine the type of an expression when its type is someone determined by its sub-expressions (like virtually any other typed language), but sometimes is determined by what consumes it? The way people can deal with the complex is by decomposing them into smaller parts, understanding those, and then composing that to understand the whole. It seems that in Haskell you are required to understand the whole thing at once, because you can't reliably determine the type of a sub-expression out of context. > > What are "matched operators"? > Those are operators that require a matching. Usually parenthesis, square brackets and braces. And how do "matched operators" make code more brittle and harder to maintain? I think the opposite is true: to maintain code you must first be able to read it, and what you call "matched operators" are far superior for readability compared to having to remember fixity rules. Even after 3 years of dealing with Haskell I found myself constantly misreading code because I didn't get the fixity right.
- tome 9y ago
  Could you please give a concrete example? The majority of Haskell expressions have what is called a "principal type". The type of such an expression is independent of its subexpressions or super- expressions.
  - xenomachina 9y ago
    A concrete example of what?
    - tome 9y ago
      A concrete example of an expression that you have difficulty determining the type of.