7 ms·

Haven't seen it listed neither here nor there, so not sure if I'm the only one, but: for me, the first and currently blocking obstacle is of "graphical" syntax.

by akavel 11y ago

Haven't seen it listed neither here nor there, so not sure if I'm the only one, but: for me, the first and currently blocking obstacle is of "graphical" syntax. I'm of the kind of people who hear the words they read as a voice in their head, so when every line is interspersed with multiple "random" <:> >>= <=< @>-,-'-- and whatnot other ascii-art I can't verbalise, I distictly feel my brain stumble, mumble, and grind to a halt and sad emptiness. And I don't even know how to google any one of them. Don't know how to solve this for myself. I've once found a list of suggested names for some common ones, but - I don't like having to learn all that by heart before I even start with the language; and also I feel pretty certain those are not all, and many libraries seem to like to invent their own new ones, so back to square one. That's I believe the main reason I find SML more attractive: it seems to use operators to a much, much lesser extent, apparently preferring alphanumeric function names in the core, and in 3rdparty libraries too.

dllthomas 11y ago
If you find yourself needing to read Haskell, feel free to ask others how they pronounce things.
jgallag8 11y ago
Hoogle could help with the searching problem: https://www.haskell.org/hoogle/ https://www.haskell.org/hoogle/
- akavel 11y ago
  Nice to know. Still, no spelling there, as far I can see. And no docs or examples either, apparently: https://www.haskell.org/hoogle/?hoogle=%3E%3E%3D https://www.haskell.org/hoogle/?hoogle=%3E%3E%3D is still a problem for me
  - bojo 11y ago
    One additional click on any of the links (usually the function name) brings you to the actual documentation. https://hackage.haskell.org/package/base-4.8.2.0/docs/Prelude.html#v:-62--62--61- https://hackage.haskell.org/package/base-4.8.2.0/docs/Prelud... Edit: Granted ">>=" (bind is the word you are after) is kind of special and you need to understand more of the underlying language mechanics to get it. The provided explanation tells you little unless you can grok the function signature. I think it's almost universally accepted that a lot of the documentation is atrocious.
bojo 11y ago
It can be overwhelming, and trying to use Google is terrible. There's a really nice Haskell specific search engine though: https://www.haskell.org/hoogle/ https://www.haskell.org/hoogle/ - you can query module/function names, type signatures, etc. A lot of these weird "operators" are also typically defined with a synonymous named function. These types of operators are usually functions after all, not actual language operators.
- sid-kap 11y ago
  Check out Hayoo (http://hayoo.fh-wedel.de/ http://hayoo.fh-wedel.de/) -- I like it more than Hoogle
  - berdario 11y ago
    Also, fpcomplete's instance of Hoogle: https://www.fpcomplete.com/hoogle https://www.fpcomplete.com/hoogle It searches on all the stackage set of packages, afaik (another explanation: http://stackoverflow.com/a/21955591/293735 http://stackoverflow.com/a/21955591/293735 )
wirrbel 11y ago
I felt the same way (and still do in general, with notable exceptions). I.e. to put this first: I think a lot of the Haskell community is obsessed with mathematical "cuteness", which basically they take to mean "infix-operator-heavy" notation. Nevertheless, I have learned to like some operators, <$> <*>, *>, <* are ones that come to my mind. The operator <$> is basically fmap as infix notation, so `fmap f [1,2,3]` would be `f <$> [1,2,3]`. This makes mapping as easy as a normal function call (and the operator name `<$>` was not choosen arbitrarily. `$` by itsself is the function application operator, so `f $ 3` does on a single element, what `f <$> x` maps over an instance of Functor. With applicatives, the pattern of f <$> a <*> b <*> c is very common (with a type signature f :: a -> b -> c -> ....
- JadeNB 11y ago
  I think that your second indented block, which is currently <*> , is supposed to be `<$>` (based on the rest of your discussion).
  - spion 11y ago
    Yes, <$> is the general `map` (`fmap`) <*> takes function(s) out of a mappable and applies it (them) to argument(s) within a mappable. (+) <$> [1,2,3] = [add 1, add 2, add 3] (+) <$> [1,2,3] <*> [10, 20] = [(1 +), (2 +), (3 +)] <*> [10, 20] = [11, 21, 12, 22, 13, 23] (+) <$> Just 3 <*> Just 5 = Just (3 + ) <*> Just 5 = Just 8 (+) <$> readLn <*> readLn = ... well that depends on the inputs :)
  - wirrbel 11y ago
    indeed, fixed it, thx.
- akavel 11y ago
  Now that is the first time I see an explanation which tries to point out some sense in the apparent madness. Appreciated! Would you or someone else knowledgeable be willing to create a guide like this, but spanning all the magic runic incantations known to Haskell wizards? Showing similarities, analogies, etc? And targeted at dumb apprentices like me? I'd be happy to serve as a somewhat (though not perfectly) dumb specimen to bounce explanation attempts off! (email in my profile - just added, in case someone was crazy enough to try to pull that off)
sillysaurus3 11y ago
I'm of the kind of people who hear the words they read as a voice in their head, so when every line is interspersed with multiple "random" <:> >>= <=< @>-,-'-- and whatnot other ascii-art I can't verbalise, I distictly feel my brain stumble, mumble, and grind to a halt and sad emptiness. Incidentally, this is why prefix notation seems so foreign. (+ 1 2) reads as "plus one two." It's possible to overcome this, with dedication. (And it's worth doing.)
- duaneb 11y ago
  Precedence is easier to parse with prefix/sexp/stack notation than infix.
- iak8god 11y ago
  Incidentally, this is why prefix notation seems so foreign. (+ 1 2) reads as "plus one two." It might just be the Lisp version of Stockholm Syndrome, but it seems perfectly natural to me to gloss that as "Add one and two."
  - sillysaurus3 11y ago
    Good point. (eq (+ 1 2) 3) would read "is add one to two equal to three?" though.
    - Retra 11y ago
      "Are the sum of one and two equal to three" is how you'd read that.
      - jjnoakes 11y ago
        Equal would come first for lisp. "Would you consider equal the sum of 1 and 2 to 3?"
        sillysaurus3 11y ago
        Lisp is read from the middle. (+ 1 2) sort of comes first since it's evaluated first. Though now that I type that out, I'm acutely aware of how strange it sounds. Interesting. It's also not true in the case of macros, e.g. let. So, you're right. No wonder it seems so foreign.
douche 11y ago
Interesting that Haskell goes in so hard for operator overloading. In other languages I've used, while you can overload a bunch of operators, it's not a common thing to encounter, outside of math code, where it makes the most sense. Technically you could do all sorts of crazy operators in C++, but that tends to be frowned upon in that community.
- ch0wn 11y ago
  It's not operator overloading. It's using symbols as function names. Some operators like (<>) may have different implementations based on the Monoid instance of the underlying types, but they are based on laws which is different from say Python where >> can mean anything based on the context (even though it is used sparingly there).
stepvhen 11y ago
Haskell is too sugary; there's too many ways to write out exactly the same thing (semantically identical, not computationally). And most resources choose one way to do things over another and it all becomes fractured and difficult. In comparison, J is all about symbols, but provide a canonical dictionary and strict semantics about how those symbols work. Still complex to learn, but easier overall.
rntz 11y ago
> And I don't even know how to google any one of them. Don't know how to solve this for myself. https://www.haskell.org/hoogle/ https://www.haskell.org/hoogle/ lets you search for functions by name, including symbol-named functions like <$> and co. (You can also search for functions by type, which is a pretty cool feature, but not what you were asking for.)
userbinator 11y ago
The "separatorless" style is also another aspect of the syntax that's turned me off Haskell --- most other languages have characters like ';' that serve to delimit statements, ',' to separate list elements, and ample use of parentheses to clarify how things should be parsed (e.g. identifier followed by '(' signals "function call", and the matching one signals the end of the argument list.) In comparison, Haskell code reads to me like a giant run-on sentence where you need to make much greater use of context in parsing. I suppose the other extreme is Lisp, which I've played around with and found quite pleasant because of its very unambiguous syntax.
- tome 11y ago
  I agree that Haskell library writers can assume too much knowledge of operator precedence on the part of their readers. It can often make it very hard to read unfamiliar code.
- Peaker 11y ago
  In recent years, I've switched to a Haskell style that is much more "separator-ful". I chain my computations together using the `&`, `<&>` and `>>=` operators. These operators are flipped function application, flipped fmap, and bind. They are all declared as left-associative with precedence 1, which means that they read left-to-right. i.e: they're the separators, so you don't need extra parenthesis. So you can have something like: employees database <&> salary & sum & writeReport title >>= sendReport destination This lets you read your data processing pipe-line, while also seeing what kind of effects are being composed together at each step.
- dllthomas 11y ago
  Haskell does seperate list items (and tuple elements, and record member assignments) with commas. You are, of course, free to object to the lack of separators between (and parentheses around) function arguments. I find it pretty natural when everything is curried.
tome 11y ago
> I don't like having to learn all that by heart before I even start with the language I'm very curious about this. Why do you think you have to learn it all by heart before you start with the language?
- skybrian 11y ago
  I'd guess this happens when you don't know an easy way to look up the definitions on the fly.
  - akavel 11y ago
    Also I meant it about having to memorize the spelling.
- deleted 11y ago
  [deleted]
neutronicus 11y ago
As a counterpoint, I love this about Haskell. It seems like my ability to hold logic in my head is partly visuo-spatial, and the terseness makes it easier for me to tell what's going on. (I also do Scientific Computing, so a general resemblance to mathematical notation is hugely helpful for me reading code).
- ajuc 11y ago
  I think similarly (I sometimes write code like this let A be sth X be sth else, ... and then the equations and predicates and pseudocode using one-letter names). Then I change these to regular variable names of course (my friends don't think it's readable). I also really like the fact that in clojure identifiers can use math symbols exactly for this reason. I love the fact that + is a regular function, that I don't have to wrap it to reduce or map with it, and don't have to remember how to turn it from infix to prefix or vice-versa. That it works with any number of arguments. Same with <, >, =. This the prettiest definition of dot product I've seen in any programming language (reduce + (map * v1 v2)) It's great because with 2 very universal language constructs you get to express tons of stuff cleanly. There's no incidental complexity there. But I just can't force myself to like Haskell operator-happy style. I've tried learning Haskell a few times, and never sticked to it for more than a week, because operators everywhere just make my uneasy, and there's too much specialized version of functions. I tried to learn common lisp a few times before clojure and nvere managed to get through the weird historical naming nonsense. Haskell sometimes feels like common lisp in that respect.
pjc50 11y ago
I suspect this is due to its mathematician-heavy user base, who are very used to just defining new operators with a squiggle on the blackboard. The worst language for this was APL, where most of the common operators could not be typed on a normal keyboard.
Schoon 11y ago
If you are ever confronted with a non-trivial parsing problem, have a look at Haskell again and use Attoparsec. <$>, <>, >, <*, <|> will become incredible concise tools for expressing your ideas!

by akavel 11y ago

dllthomas 11y ago

If you find yourself needing to read Haskell, feel free to ask others how they pronounce things.

jgallag8 11y ago

Hoogle could help with the searching problem: https://www.haskell.org/hoogle/ https://www.haskell.org/hoogle/

akavel 11y ago
Nice to know. Still, no spelling there, as far I can see. And no docs or examples either, apparently: https://www.haskell.org/hoogle/?hoogle=%3E%3E%3D https://www.haskell.org/hoogle/?hoogle=%3E%3E%3D is still a problem for me
- bojo 11y ago
  One additional click on any of the links (usually the function name) brings you to the actual documentation. https://hackage.haskell.org/package/base-4.8.2.0/docs/Prelude.html#v:-62--62--61- https://hackage.haskell.org/package/base-4.8.2.0/docs/Prelud... Edit: Granted ">>=" (bind is the word you are after) is kind of special and you need to understand more of the underlying language mechanics to get it. The provided explanation tells you little unless you can grok the function signature. I think it's almost universally accepted that a lot of the documentation is atrocious.

bojo 11y ago

It can be overwhelming, and trying to use Google is terrible. There's a really nice Haskell specific search engine though: https://www.haskell.org/hoogle/ https://www.haskell.org/hoogle/ - you can query module/function names, type signatures, etc. A lot of these weird "operators" are also typically defined with a synonymous named function. These types of operators are usually functions after all, not actual language operators.

sid-kap 11y ago
Check out Hayoo (http://hayoo.fh-wedel.de/ http://hayoo.fh-wedel.de/) -- I like it more than Hoogle
- berdario 11y ago
  Also, fpcomplete's instance of Hoogle: https://www.fpcomplete.com/hoogle https://www.fpcomplete.com/hoogle It searches on all the stackage set of packages, afaik (another explanation: http://stackoverflow.com/a/21955591/293735 http://stackoverflow.com/a/21955591/293735 )

wirrbel 11y ago

I felt the same way (and still do in general, with notable exceptions). I.e. to put this first: I think a lot of the Haskell community is obsessed with mathematical "cuteness", which basically they take to mean "infix-operator-heavy" notation. Nevertheless, I have learned to like some operators, <$> <*>, *>, <* are ones that come to my mind. The operator <$> is basically fmap as infix notation, so `fmap f [1,2,3]` would be `f <$> [1,2,3]`. This makes mapping as easy as a normal function call (and the operator name `<$>` was not choosen arbitrarily. `$` by itsself is the function application operator, so `f $ 3` does on a single element, what `f <$> x` maps over an instance of Functor. With applicatives, the pattern of f <$> a <*> b <*> c is very common (with a type signature f :: a -> b -> c -> ....

JadeNB 11y ago
I think that your second indented block, which is currently <*> , is supposed to be `<$>` (based on the rest of your discussion).
- spion 11y ago
  Yes, <$> is the general `map` (`fmap`) <*> takes function(s) out of a mappable and applies it (them) to argument(s) within a mappable. (+) <$> [1,2,3] = [add 1, add 2, add 3] (+) <$> [1,2,3] <*> [10, 20] = [(1 +), (2 +), (3 +)] <*> [10, 20] = [11, 21, 12, 22, 13, 23] (+) <$> Just 3 <*> Just 5 = Just (3 + ) <*> Just 5 = Just 8 (+) <$> readLn <*> readLn = ... well that depends on the inputs :)
- wirrbel 11y ago
  indeed, fixed it, thx.
akavel 11y ago
Now that is the first time I see an explanation which tries to point out some sense in the apparent madness. Appreciated! Would you or someone else knowledgeable be willing to create a guide like this, but spanning all the magic runic incantations known to Haskell wizards? Showing similarities, analogies, etc? And targeted at dumb apprentices like me? I'd be happy to serve as a somewhat (though not perfectly) dumb specimen to bounce explanation attempts off! (email in my profile - just added, in case someone was crazy enough to try to pull that off)

sillysaurus3 11y ago

I'm of the kind of people who hear the words they read as a voice in their head, so when every line is interspersed with multiple "random" <:> >>= <=< @>-,-'-- and whatnot other ascii-art I can't verbalise, I distictly feel my brain stumble, mumble, and grind to a halt and sad emptiness. Incidentally, this is why prefix notation seems so foreign. (+ 1 2) reads as "plus one two." It's possible to overcome this, with dedication. (And it's worth doing.)

duaneb 11y ago
Precedence is easier to parse with prefix/sexp/stack notation than infix.
iak8god 11y ago
Incidentally, this is why prefix notation seems so foreign. (+ 1 2) reads as "plus one two." It might just be the Lisp version of Stockholm Syndrome, but it seems perfectly natural to me to gloss that as "Add one and two."
- sillysaurus3 11y ago
  Good point. (eq (+ 1 2) 3) would read "is add one to two equal to three?" though.
  - Retra 11y ago
    "Are the sum of one and two equal to three" is how you'd read that.
    - jjnoakes 11y ago
      Equal would come first for lisp. "Would you consider equal the sum of 1 and 2 to 3?"
      - sillysaurus3 11y ago
        Lisp is read from the middle. (+ 1 2) sort of comes first since it's evaluated first. Though now that I type that out, I'm acutely aware of how strange it sounds. Interesting. It's also not true in the case of macros, e.g. let. So, you're right. No wonder it seems so foreign.

douche 11y ago

Interesting that Haskell goes in so hard for operator overloading. In other languages I've used, while you can overload a bunch of operators, it's not a common thing to encounter, outside of math code, where it makes the most sense. Technically you could do all sorts of crazy operators in C++, but that tends to be frowned upon in that community.

ch0wn 11y ago
It's not operator overloading. It's using symbols as function names. Some operators like (<>) may have different implementations based on the Monoid instance of the underlying types, but they are based on laws which is different from say Python where >> can mean anything based on the context (even though it is used sparingly there).

stepvhen 11y ago

Haskell is too sugary; there's too many ways to write out exactly the same thing (semantically identical, not computationally). And most resources choose one way to do things over another and it all becomes fractured and difficult. In comparison, J is all about symbols, but provide a canonical dictionary and strict semantics about how those symbols work. Still complex to learn, but easier overall.

rntz 11y ago

> And I don't even know how to google any one of them. Don't know how to solve this for myself. https://www.haskell.org/hoogle/ https://www.haskell.org/hoogle/ lets you search for functions by name, including symbol-named functions like <$> and co. (You can also search for functions by type, which is a pretty cool feature, but not what you were asking for.)

userbinator 11y ago

The "separatorless" style is also another aspect of the syntax that's turned me off Haskell --- most other languages have characters like ';' that serve to delimit statements, ',' to separate list elements, and ample use of parentheses to clarify how things should be parsed (e.g. identifier followed by '(' signals "function call", and the matching one signals the end of the argument list.) In comparison, Haskell code reads to me like a giant run-on sentence where you need to make much greater use of context in parsing. I suppose the other extreme is Lisp, which I've played around with and found quite pleasant because of its very unambiguous syntax.

tome 11y ago
I agree that Haskell library writers can assume too much knowledge of operator precedence on the part of their readers. It can often make it very hard to read unfamiliar code.
Peaker 11y ago
In recent years, I've switched to a Haskell style that is much more "separator-ful". I chain my computations together using the `&`, `<&>` and `>>=` operators. These operators are flipped function application, flipped fmap, and bind. They are all declared as left-associative with precedence 1, which means that they read left-to-right. i.e: they're the separators, so you don't need extra parenthesis. So you can have something like: employees database <&> salary & sum & writeReport title >>= sendReport destination This lets you read your data processing pipe-line, while also seeing what kind of effects are being composed together at each step.
dllthomas 11y ago
Haskell does seperate list items (and tuple elements, and record member assignments) with commas. You are, of course, free to object to the lack of separators between (and parentheses around) function arguments. I find it pretty natural when everything is curried.

tome 11y ago

> I don't like having to learn all that by heart before I even start with the language I'm very curious about this. Why do you think you have to learn it all by heart before you start with the language?

skybrian 11y ago
I'd guess this happens when you don't know an easy way to look up the definitions on the fly.
- akavel 11y ago
  Also I meant it about having to memorize the spelling.
deleted 11y ago
[deleted]

neutronicus 11y ago

As a counterpoint, I love this about Haskell. It seems like my ability to hold logic in my head is partly visuo-spatial, and the terseness makes it easier for me to tell what's going on. (I also do Scientific Computing, so a general resemblance to mathematical notation is hugely helpful for me reading code).

ajuc 11y ago
I think similarly (I sometimes write code like this let A be sth X be sth else, ... and then the equations and predicates and pseudocode using one-letter names). Then I change these to regular variable names of course (my friends don't think it's readable). I also really like the fact that in clojure identifiers can use math symbols exactly for this reason. I love the fact that + is a regular function, that I don't have to wrap it to reduce or map with it, and don't have to remember how to turn it from infix to prefix or vice-versa. That it works with any number of arguments. Same with <, >, =. This the prettiest definition of dot product I've seen in any programming language (reduce + (map * v1 v2)) It's great because with 2 very universal language constructs you get to express tons of stuff cleanly. There's no incidental complexity there. But I just can't force myself to like Haskell operator-happy style. I've tried learning Haskell a few times, and never sticked to it for more than a week, because operators everywhere just make my uneasy, and there's too much specialized version of functions. I tried to learn common lisp a few times before clojure and nvere managed to get through the weird historical naming nonsense. Haskell sometimes feels like common lisp in that respect.

pjc50 11y ago

I suspect this is due to its mathematician-heavy user base, who are very used to just defining new operators with a squiggle on the blackboard. The worst language for this was APL, where most of the common operators could not be typed on a normal keyboard.

Schoon 11y ago

If you are ever confronted with a non-trivial parsing problem, have a look at Haskell again and use Attoparsec. <$>, <>, >, <*, <|> will become incredible concise tools for expressing your ideas!