5 ms·

I find its syntax & idiomatic style incredibly difficult to follow, in a way nearly no other languages have been for me, including some functional languages (OC

I find its syntax & idiomatic style incredibly difficult to follow, in a way nearly no other languages have been for me, including some functional languages (OCaml doesn't seem nearly as bad to me, for instance). It's sometimes implied that those who trip over Haskell just aren't big-brained enough to understand various important concepts related to it, but I've found they're usually very easy to grasp, provided the explanation's not using Haskell examples. If all programming were Haskell, I probably never would have become a programmer in the first place. Would have taken me too long to figure any of it out, probably would have concluded I wasn't smart enough to be a programmer. I do wonder if there are some shared experiences or common patterns to who tends to love Haskell, and those who don't. I also feel nigh-dyslexic trying to read math formulas. Human language and broadly C-family programming languages, on the other hand, seemed easy and natural to me, almost effortless to pick up. Wonder if there's a "mathy"-person versus "languagey"-person divide on finding Haskell legible. I'm not sure it's the whole thing, but I think I've also figured out that I find algorithm-type reasoning far easier to follow and work with than equations or proofs. Like, the only way I can begin to get traction with an unfamiliar equation is to break down what each term and operation "does" to something "moving through" it—it's tedious as hell. Might be something there.

alpaca128 4y ago
I'm in the exact same boat. Haskell code feels more like abstract maths and I feel more at home when I can just easily track the data flow. The language and community uses relatively abstract terminology due to its roots and it's just a bit too cryptic to me. Though I'm glad newer languages are starting to adopt more features from the functional territory for the situations where it just makes more sense.
Hirrolot 4y ago
I find the terminology that Haskell uses quite misleading for software engineering. It borrows concepts from category theory with quaint names such as a "monad", "endofunctor", "catamorphism", etc. The problem is that, instead of a "monad", we can say "brrrdogcogfog" and nothing will change -- the name is absolutely irrelevant to the problem being solved. Given that a monad is an interface for sequential computation, a much better name would be something like "Seq", "SeqComp", or something like that.
- medstrom 4y ago
  Like a Javascript ArrayBuffer? No, a Stream?
- viscanti 4y ago
  A monad is just a monoid in the category of endofunctors. Would most people know what "brrrdogcogfog" means? Couldn't we make that argument about literally any word? I don't see why it applies more here than elsewhere. For people who have experienced it before, it's straightforward and easy to work with, for those who haven't, then there's a learning curve. No one would likely have encountered "brrrdogcogfog" before and everyone would have to go through the learning curve.
- throwaway17_17 4y ago
  tl;dr -> I agree that the terminology is probably not something that enhances cohesion amongst devs using Haskell, and certainly can be distracting in a pedagogical setting. I think the fact your experience leads you to believe that a monad is an interface for sequential computation. A monad is often used for ordering computations, but Haskell’s monads can also be commutative (like the Reader instance of monad) which do not order anything. The real issue is that the naming convention where some typeclass is named after a concept in category theory means wildly different things to different developers. For instance, I would expect a type/typeclass named for some categorical construct to behave in the way the categorical construct behaves and that would be the extent of what I use it for. However, some developer may see a particular usage the same construct and extrapolate that said construct is intrinsically tied to that algorithmic pattern of usage. So the problem is controlling expectation and managing consistency throughout the dev community. I doubt Haskell will ever get away from the category theory inspired libraries and the subsequent naming conventions. See the relatively lively development of the profunctor optics based work. But, I can certainly see how it may distract or confuse newcomers.
- pharmakom 4y ago
  F# calls them Computation Expressions which is far more approachable imo
  - 4y ago
yoyohello13 4y ago
My original degree was in Math and I can definitely 'feel' a difference when reading Haskell vs other languages. Writing/Reading Haskell gives me a similar feeling to doing proofs than programming. Even other functional programming languages don't give me that 'in the math class' feeling that Haskell does.
paddw 4y ago
I suspect you are right that there's a type of person Haskell feels very intuitive to. I think if your mind works that way you might have a hard time appreciating the degree of confusion "regular" programmers face when trying to decipher the mess of symbolic soup.
- yakshaving_jgt 4y ago
  There is no reason for Haskell to be a "mess of symbolic soup". You can make Haskell about as human-readable as Ruby if you choose to.
  - WorldMaker 4y ago
    Syntactically Haskell and OCaml are extremely close. A lot of the surface difference between the two languages has nothing to do with syntax and has so much more to do with how things are named by default in the standard libraries. (There are massive differences in the type system and all sorts of subtle differences below the surface, of course.)
- hgsgm 4y ago
  Regular programmers were pretty happy with Perl soup.
jokoon 4y ago
I use generators, list comprehension and a lot of lambda stuff with python. It's a bit fun because it's very short to write, it's concise and it helps a lot working only with dict and tuples etc. Not sure if it's faster, but it's always a bit longer to write and think about, and I'm not sure it's easier to read and understand. Sometimes it feels a bit like code golfing, because you can do a lot of things with very few lines. It's immensely better to remove 99% of side effects, the code is shorter and more compartmentalized, so it's just easier to deal with. Although I'm doing this alone, and I'm not confident that I could enforce this sort of software design in a team.
lincpa 4y ago
[dead]
mrkeen 4y ago
> I'm not sure it's the whole thing, but I think I've also figured out that I find algorithm-type reasoning far easier to follow and work with than equations or proofs. For me it's the opposite. Once i figure out what an expression is, I do not want it to change on the next clock cycle.

alpaca128 4y ago

I'm in the exact same boat. Haskell code feels more like abstract maths and I feel more at home when I can just easily track the data flow. The language and community uses relatively abstract terminology due to its roots and it's just a bit too cryptic to me. Though I'm glad newer languages are starting to adopt more features from the functional territory for the situations where it just makes more sense.

Hirrolot 4y ago

I find the terminology that Haskell uses quite misleading for software engineering. It borrows concepts from category theory with quaint names such as a "monad", "endofunctor", "catamorphism", etc. The problem is that, instead of a "monad", we can say "brrrdogcogfog" and nothing will change -- the name is absolutely irrelevant to the problem being solved. Given that a monad is an interface for sequential computation, a much better name would be something like "Seq", "SeqComp", or something like that.

medstrom 4y ago
Like a Javascript ArrayBuffer? No, a Stream?
viscanti 4y ago
A monad is just a monoid in the category of endofunctors. Would most people know what "brrrdogcogfog" means? Couldn't we make that argument about literally any word? I don't see why it applies more here than elsewhere. For people who have experienced it before, it's straightforward and easy to work with, for those who haven't, then there's a learning curve. No one would likely have encountered "brrrdogcogfog" before and everyone would have to go through the learning curve.
throwaway17_17 4y ago
tl;dr -> I agree that the terminology is probably not something that enhances cohesion amongst devs using Haskell, and certainly can be distracting in a pedagogical setting. I think the fact your experience leads you to believe that a monad is an interface for sequential computation. A monad is often used for ordering computations, but Haskell’s monads can also be commutative (like the Reader instance of monad) which do not order anything. The real issue is that the naming convention where some typeclass is named after a concept in category theory means wildly different things to different developers. For instance, I would expect a type/typeclass named for some categorical construct to behave in the way the categorical construct behaves and that would be the extent of what I use it for. However, some developer may see a particular usage the same construct and extrapolate that said construct is intrinsically tied to that algorithmic pattern of usage. So the problem is controlling expectation and managing consistency throughout the dev community. I doubt Haskell will ever get away from the category theory inspired libraries and the subsequent naming conventions. See the relatively lively development of the profunctor optics based work. But, I can certainly see how it may distract or confuse newcomers.
pharmakom 4y ago
F# calls them Computation Expressions which is far more approachable imo
- 4y ago

yoyohello13 4y ago

My original degree was in Math and I can definitely 'feel' a difference when reading Haskell vs other languages. Writing/Reading Haskell gives me a similar feeling to doing proofs than programming. Even other functional programming languages don't give me that 'in the math class' feeling that Haskell does.

paddw 4y ago

I suspect you are right that there's a type of person Haskell feels very intuitive to. I think if your mind works that way you might have a hard time appreciating the degree of confusion "regular" programmers face when trying to decipher the mess of symbolic soup.

yakshaving_jgt 4y ago
There is no reason for Haskell to be a "mess of symbolic soup". You can make Haskell about as human-readable as Ruby if you choose to.
- WorldMaker 4y ago
  Syntactically Haskell and OCaml are extremely close. A lot of the surface difference between the two languages has nothing to do with syntax and has so much more to do with how things are named by default in the standard libraries. (There are massive differences in the type system and all sorts of subtle differences below the surface, of course.)
hgsgm 4y ago
Regular programmers were pretty happy with Perl soup.

jokoon 4y ago

I use generators, list comprehension and a lot of lambda stuff with python. It's a bit fun because it's very short to write, it's concise and it helps a lot working only with dict and tuples etc. Not sure if it's faster, but it's always a bit longer to write and think about, and I'm not sure it's easier to read and understand. Sometimes it feels a bit like code golfing, because you can do a lot of things with very few lines. It's immensely better to remove 99% of side effects, the code is shorter and more compartmentalized, so it's just easier to deal with. Although I'm doing this alone, and I'm not confident that I could enforce this sort of software design in a team.

lincpa 4y ago

[dead]

mrkeen 4y ago

> I'm not sure it's the whole thing, but I think I've also figured out that I find algorithm-type reasoning far easier to follow and work with than equations or proofs. For me it's the opposite. Once i figure out what an expression is, I do not want it to change on the next clock cycle.