4 ms·

> But the libraries are massively, massively complex and do things in ways that are very often not at all intuitive if you're not familiar with the math behind

> But the libraries are massively, massively complex and do things in ways that are very often not at all intuitive if you're not familiar with the math behind them. I'm just a beginner Haskeller, but this seems like a pretty bold (and false) claim. I've used Parsec for writing a Scheme (while reading the book), Shelly and Shake for build and test automation, and some statistics libraries for, well, statistics. They were all intuitive to use, and there was no "impenetrable morass of esoteric abstractions". I'm not sure what you're on about. Maybe provide examples?

chc 14y ago
I will write this answer in the flavor of your average Haskell library, as read by somebody who has learned the core language very well but not that library: you <*$%^> everyone %%<#>%% experience Are you really going to tell me you have never looked at code written with a package you haven't learned and initially found it to be unintelligible? If not, then I would guess that you are simply well-suited to Haskell. Again, I'm not saying Haskell is bad, but that it does have attributes that make it daunting to many people. The top-rated comment on here even talks about how easy Haskell is now that he's "over the hump." Even compared to a relatively esoteric language like Clojure, Haskell's hump is pretty big. I believe the canonical example of a weird math-based library that makes beginners cry is Control.Arrow. Reading arrow-based code without having fully grasped both the idea of arrows and the API itself (do you think <&&&> could use a few more ampersands?) is an exercise in frustration. Even the humble monoid — simple as it may be — is hard for many people to grasp, because they're such a frustratingly generic idea with horribly unhelpful terminology attached to them. Want more? Here's one of the top Haskell projects on Github — a library that does lenses, folds, traversals, getters and setters: https://github.com/ekmett/lens https://github.com/ekmett/lens With that library, you can write things like _1 .~ "hello" $ ((),"world")
- tomp 14y ago
  You mean that the example would be more readable if it used proper function names instead of operators? You would still need to "learn the library", i.e. look-up what the functions do.
  - rayiner 14y ago
    I'm pretty sure all the railing hard on the symbols above the number keys must be symptomatic of some sort of verbal learning disability in Haskell programmers...
    - chc 14y ago
      I don't think that's fair. It allows for some really concise code that actually is quite readable once you're conversant. For example, I do not think Parsec would be better off if "<|>" were renamed to "parsecOR" or something like that. It's just, like I said, obscure and daunting.
      - sanderjd 14y ago
        I do think Parsec would be better off if "<|>" were something like "parsecOR". Good function names are good.
        chc 14y ago
        If you're really interested in this, I'd encourage you to take some actual Parsec code and make this change, then compare the two for readability. My guess is that while it's conceptually nice, you'll find in practice it hampers readability more than it helps.
        sanderjd 14y ago
        Thanks for the constructive suggestion - I don't have much invested in this particular little debate so I'm not sure I'll take the time to do that, but it's definitely a good idea. I will say that in my opinion, the alternative in the reply above this (which I can't reply to) looks fairly nice, is clearer, and not even a little bit harder to follow. But I'll allow that as a very casual Haskell programmer, my opinions about Haskell are probably not particularly valid.
        tikhonj 14y ago
        The idea is that Parsec represents a grammar, similar to BNF with <|> giving alternative rules. So something like: atom = many digit <|> identifier <|> stringLiteral <|> between (char '(') (char ')') expression I can't imagine any way this would look better with a name instead of the <|> operator. You could write it something like: atom = many digit `or` identifier `or` stringLiteral `or` between (char '(') (char ')') expression but that's no clearer and a bit harder to follow. With a much longer identifier than "or", it would be completely unreadable. If you had to make "or" prefix (the `` let you use a normal function in infix position), it would be even less readable. Combine the two (a longer, prefix identifier) and you have an even bigger mess! The operators let you see the structure of an expression at a glance. You don't have to read the whole thing to figure out what's going on. Moreover, the <|> symbol is pretty intuitive--it's clearly based on | which usually represents some sort of alternation.
- flyinRyan 14y ago
  >you <*$%^> everyone %%<#>%% experience Haskellers like to use symbols for two argument functions because of precedence rules. You learn them for the modules you're using just as you would have had to learn the function names. But usually seeing how the symbol is named combined with it's type signature is enough. As far as lenses, I personally don't like them so far. But not because of the (admittedly, questionably named) functions but rather that doing anything in lenses seems to require template magic.
  - chc 14y ago
    Given a well-designed library that does something concrete related to a task you understand, I find that I generally don't have to learn the function names just to read code that uses it. Like, if see "HTTP.post(data, headers)" or "record.attach(file)", I have a pretty good idea what it's doing even if I don't know those particular libraries.

chc 14y ago

I will write this answer in the flavor of your average Haskell library, as read by somebody who has learned the core language very well but not that library: you <*$%^> everyone %%<#>%% experience Are you really going to tell me you have never looked at code written with a package you haven't learned and initially found it to be unintelligible? If not, then I would guess that you are simply well-suited to Haskell. Again, I'm not saying Haskell is bad, but that it does have attributes that make it daunting to many people. The top-rated comment on here even talks about how easy Haskell is now that he's "over the hump." Even compared to a relatively esoteric language like Clojure, Haskell's hump is pretty big. I believe the canonical example of a weird math-based library that makes beginners cry is Control.Arrow. Reading arrow-based code without having fully grasped both the idea of arrows and the API itself (do you think <&&&> could use a few more ampersands?) is an exercise in frustration. Even the humble monoid — simple as it may be — is hard for many people to grasp, because they're such a frustratingly generic idea with horribly unhelpful terminology attached to them. Want more? Here's one of the top Haskell projects on Github — a library that does lenses, folds, traversals, getters and setters: https://github.com/ekmett/lens https://github.com/ekmett/lens With that library, you can write things like _1 .~ "hello" $ ((),"world")

tomp 14y ago
You mean that the example would be more readable if it used proper function names instead of operators? You would still need to "learn the library", i.e. look-up what the functions do.
- rayiner 14y ago
  I'm pretty sure all the railing hard on the symbols above the number keys must be symptomatic of some sort of verbal learning disability in Haskell programmers...
  - chc 14y ago
    I don't think that's fair. It allows for some really concise code that actually is quite readable once you're conversant. For example, I do not think Parsec would be better off if "<|>" were renamed to "parsecOR" or something like that. It's just, like I said, obscure and daunting.
    - sanderjd 14y ago
      I do think Parsec would be better off if "<|>" were something like "parsecOR". Good function names are good.
      - chc 14y ago
        If you're really interested in this, I'd encourage you to take some actual Parsec code and make this change, then compare the two for readability. My guess is that while it's conceptually nice, you'll find in practice it hampers readability more than it helps.
        sanderjd 14y ago
        Thanks for the constructive suggestion - I don't have much invested in this particular little debate so I'm not sure I'll take the time to do that, but it's definitely a good idea. I will say that in my opinion, the alternative in the reply above this (which I can't reply to) looks fairly nice, is clearer, and not even a little bit harder to follow. But I'll allow that as a very casual Haskell programmer, my opinions about Haskell are probably not particularly valid.
      - tikhonj 14y ago
        The idea is that Parsec represents a grammar, similar to BNF with <|> giving alternative rules. So something like: atom = many digit <|> identifier <|> stringLiteral <|> between (char '(') (char ')') expression I can't imagine any way this would look better with a name instead of the <|> operator. You could write it something like: atom = many digit `or` identifier `or` stringLiteral `or` between (char '(') (char ')') expression but that's no clearer and a bit harder to follow. With a much longer identifier than "or", it would be completely unreadable. If you had to make "or" prefix (the `` let you use a normal function in infix position), it would be even less readable. Combine the two (a longer, prefix identifier) and you have an even bigger mess! The operators let you see the structure of an expression at a glance. You don't have to read the whole thing to figure out what's going on. Moreover, the <|> symbol is pretty intuitive--it's clearly based on | which usually represents some sort of alternation.
flyinRyan 14y ago
>you <*$%^> everyone %%<#>%% experience Haskellers like to use symbols for two argument functions because of precedence rules. You learn them for the modules you're using just as you would have had to learn the function names. But usually seeing how the symbol is named combined with it's type signature is enough. As far as lenses, I personally don't like them so far. But not because of the (admittedly, questionably named) functions but rather that doing anything in lenses seems to require template magic.
- chc 14y ago
  Given a well-designed library that does something concrete related to a task you understand, I find that I generally don't have to learn the function names just to read code that uses it. Like, if see "HTTP.post(data, headers)" or "record.attach(file)", I have a pretty good idea what it's doing even if I don't know those particular libraries.