4 ms·
"I don't actually know what it's doing" Sorry, but that means you couldn't read it.
by dscrd 14y ago
"I don't actually know what it's doing"
Sorry, but that means you couldn't read it.
- dwc 14y agoIn a very real sense, that's true. But...I don't know what it's doing but I know how it's doing it, so to speak. With languages in which I'm quite fluent (Haskell not so much), I can sometimes spot problems in the code of someone coming to me for help without knowing anything about the libraries, et al, because even though I "couldn't read it" in your sense I could read it in the other sense.
- papsosouid 14y agoNo it doesn't: foo(bar(x)) Can you read that code? Yes? But you don't know what it is doing, because you don't know what the functions foo and bar do. Same deal with the haskell code in question. Just because you don't know what Compose and getCompose do, doesn't mean you can't read the code.
- dscrd 14y agoI don't feel it's so clear cut. Haskell fuzzies the difference between syntactic and semantic elements. What in your piece of code is the parentheses might very well be defined as functions in Haskell. For instance, the ($) and (.) functions, but also I would call StateT and perhaps Compose and WrapMonad (while not knowing what they do) such things too. So, I still feel that understanding a piece of Haskell means that you will need to understand the individual functions at least superficially.
- papsosouid 14y agoYou feel wrong. There is no such fuzzy. StateT, Compose and WrapMonad are functions. They are just like foo and bar in my example. Just as in a C-style language you need to know the parens mean function application, in haskell you need to know spaces and ($) are function application, and (.) is function composition. The code is perfectly readable even if you don't know what the functions being used do.