4 ms·

I like chaining, that's a good analogy. I feel like, now that I have a certain level of intuitive understanding of what bind does, to me, the `>>=` symbol best

I like chaining, that's a good analogy. I feel like, now that I have a certain level of intuitive understanding of what bind does, to me, the `>>=` symbol best represents what the operation does. It just looks like some kind of physical gadget that extracts a thing from a container, does something to it, and injects it into the next container. This is pretty ironic given Haskell's (somewhat deserved) reputation as impenetrable symbol soup. I don't know whether I'd endorse trying to use an intuitive mnemonic like this to explain monads to FP beginners.

pas 8y ago
I know a lot of symbols, but I still get irritated when I encounter a new one, and I can't search for it. (At least math got a nice list: https://en.wikipedia.org/wiki/List_of_mathematical_symbols https://en.wikipedia.org/wiki/List_of_mathematical_symbols ) For math it's kind of okay. Because there the point is to talk about that theory. You introduce definitions, and theorems, and use them in proofs. Or in calculations. And even in math proofs usually come with a lot of explanation. (At least the better ones.) In software engineering maintainability is important. And, sure, we can just accept that Haskell is something that you can't learn by looking at real world Haskell code. After all, you can't really learn real world "research math" by looking at it. But I think real world code, especially one that is looking for maintainers should not err on the side of indecipherability and inapproachability. I continue to chastise Scalaz for its bad naming and documentation convention. (Haskell is ... well, it's irredeemable.) And TypeScript is getting into this mess too. The documentation for new releases with new type system goodies (and I really mean it, I like powerful type systems, I just don't want to spend my life on understanding them, I'm happy to use them to get particular jobs done), but with barely enough documentation to let serious TS users with many years of experience understand it.

pas 8y ago

I know a lot of symbols, but I still get irritated when I encounter a new one, and I can't search for it. (At least math got a nice list: https://en.wikipedia.org/wiki/List_of_mathematical_symbols https://en.wikipedia.org/wiki/List_of_mathematical_symbols ) For math it's kind of okay. Because there the point is to talk about that theory. You introduce definitions, and theorems, and use them in proofs. Or in calculations. And even in math proofs usually come with a lot of explanation. (At least the better ones.) In software engineering maintainability is important. And, sure, we can just accept that Haskell is something that you can't learn by looking at real world Haskell code. After all, you can't really learn real world "research math" by looking at it. But I think real world code, especially one that is looking for maintainers should not err on the side of indecipherability and inapproachability. I continue to chastise Scalaz for its bad naming and documentation convention. (Haskell is ... well, it's irredeemable.) And TypeScript is getting into this mess too. The documentation for new releases with new type system goodies (and I really mean it, I like powerful type systems, I just don't want to spend my life on understanding them, I'm happy to use them to get particular jobs done), but with barely enough documentation to let serious TS users with many years of experience understand it.