14 ms·

People are being dismissive of the premise here. But I remember when someone gave me a link to a Haskell repository. I had no idea what was going on, or what

People are being dismissive of the premise here. But I remember when someone gave me a link to a Haskell repository. I had no idea what was going on, or what those alien symbols meant. I can only imagine that the barrier to entry for Haskell is much, much, much higher than that of an Algol descended language.

taneq 6y ago
If you're familiar with a recipe for baking a cake, the barrier to entry for most imperative languages is small. If you're familiar with Lambda calculus, I imagine the barrier to entry for Haskell is similar. In both cases, entry is the easy bit. Learning the notation is a somewhat orthogonal and arguably much smaller impediment than the inescapable difficulty of figuring out what you're trying to accomplish, and then how to accomplish it.
- Macha 6y ago
  There is a tendency among the more academic of CS researchers, of spending so much time in academia to assume that because they find math notation so simple from their experience using it that this means it is clearly superior to the notation actual programmers use in actual programming languages and treat that like some aberration from industry. Personally I've always found math notation feels like it was optimised for space efficiency and writing speed on paper, akin to legal shorthand rather than the beauty I'm always told it has. Similarly for attempts to bring programming syntax closer to math syntax. In college I found myself translating equations of medium complexity such as the Fourier transform into pseudocode to understand. Obviously however, my familiarity with programming notation colours my perspective as much as their experience with math notation colours theirs
deleted 6y ago
[deleted]
ardfard 6y ago
Actually basic Haskell syntax is very simple, it's lot closer to basic math symbol and equation. What make it hard to understand is the use of abstractions like Monad, Transformers etc, and people use it a lot in Haskell. It's very hard in fact to make a useful Haskell program without a Monad. That said, I don't think another mainstream languages that use advanced abstraction like Haskell is gonna be easier to read either. Try to imagine a Java program that trying to use higher-kinded abstraction, I bet it won't be pretty and easy to teach. I have experience trying to explain about Monad in Ruby to a coworker and it's really hard.
- yencabulator 6y ago
  Monads, Transformers etc can make Haskell code hard to follow. But the culture of overusing unpronounceable/unmemorable operators is what makes Haskell really hard to read. >@> <$> <*> <|> <=< <+> <$> --> <&&> <||> ||| .|. None of the above are made up, all are from real code.
  - whateveracct 6y ago
    Of code is using <$>, <*>, And <|>, it's probably easier to read & understand at a glance than the the best, most read-optimized Go equivalent. If you know what those symbols mean (aka the interfaces they belong to.) If you don't have that knowledge and are instead complaining about the fact that they have symbols period, I suggest you quit spouting answers when you should be asking questions.
    - Macha 6y ago
      Why is <$> for example easier to read, type, understand, Google, or any dimension really over "fmap"?
      - whateveracct 6y ago
        Applicative style for one data Person = Person { age :: Int , name :: Text , height :: Int } Person <$> parseAge <*> parseName <*> parseHeight Applicative style is one of the easiest constructs to read relative to the power of what it typically does. Most other times when you use <$>, you're using it instead of something like this: fmap f $ x y z Which is simplified by f <$> x y z Google is a non-issue. Hoogle exists and works great (and can even index all symbols importable by your project)
  - siraben 6y ago
    Some of these are explanable from mathematical conventions. In abstract algebra it's common to surround an operator in a circle to denote a "generic" or "lifted" operator. So <$> denotes a "lifted application", i.e. ($) :: (a → b) → a → b (<$>) :: Functor f => (a → b) → f a → f b
the_af 6y ago
> I can only imagine that the barrier to entry for Haskell is much, much, much higher than that of an Algol descended language. Haskell syntax is not more complex than an Algol descended language. It's only confusing if you expect an Algol descended language, for example because you're already familiar with them.
whateveracct 6y ago
I have an easier time understanding Haskell than Go codebases, and I have equal and large experience with both. When I first learned Haskell, I only knew C. Haskell codebases were immediately so fun to dive into and learn from. I wouldn't hesitate to hit the "Source" button on Hackage. The fact that all code could be reasoned about locally with just simple symbolic substitution was a breath of fresh air. To a person with 0 experience at all, Haskell or Algol-descended languages are going to be equally alien. Your experience is because you had asymmetric familiarity. So I'm not surprised by your experience. But it says more about you than Haskell.

taneq 6y ago

If you're familiar with a recipe for baking a cake, the barrier to entry for most imperative languages is small. If you're familiar with Lambda calculus, I imagine the barrier to entry for Haskell is similar. In both cases, entry is the easy bit. Learning the notation is a somewhat orthogonal and arguably much smaller impediment than the inescapable difficulty of figuring out what you're trying to accomplish, and then how to accomplish it.

Macha 6y ago
There is a tendency among the more academic of CS researchers, of spending so much time in academia to assume that because they find math notation so simple from their experience using it that this means it is clearly superior to the notation actual programmers use in actual programming languages and treat that like some aberration from industry. Personally I've always found math notation feels like it was optimised for space efficiency and writing speed on paper, akin to legal shorthand rather than the beauty I'm always told it has. Similarly for attempts to bring programming syntax closer to math syntax. In college I found myself translating equations of medium complexity such as the Fourier transform into pseudocode to understand. Obviously however, my familiarity with programming notation colours my perspective as much as their experience with math notation colours theirs

deleted 6y ago

[deleted]

ardfard 6y ago

Actually basic Haskell syntax is very simple, it's lot closer to basic math symbol and equation. What make it hard to understand is the use of abstractions like Monad, Transformers etc, and people use it a lot in Haskell. It's very hard in fact to make a useful Haskell program without a Monad. That said, I don't think another mainstream languages that use advanced abstraction like Haskell is gonna be easier to read either. Try to imagine a Java program that trying to use higher-kinded abstraction, I bet it won't be pretty and easy to teach. I have experience trying to explain about Monad in Ruby to a coworker and it's really hard.

yencabulator 6y ago
Monads, Transformers etc can make Haskell code hard to follow. But the culture of overusing unpronounceable/unmemorable operators is what makes Haskell really hard to read. >@> <$> <*> <|> <=< <+> <$> --> <&&> <||> ||| .|. None of the above are made up, all are from real code.
- whateveracct 6y ago
  Of code is using <$>, <*>, And <|>, it's probably easier to read & understand at a glance than the the best, most read-optimized Go equivalent. If you know what those symbols mean (aka the interfaces they belong to.) If you don't have that knowledge and are instead complaining about the fact that they have symbols period, I suggest you quit spouting answers when you should be asking questions.
  - Macha 6y ago
    Why is <$> for example easier to read, type, understand, Google, or any dimension really over "fmap"?
    - whateveracct 6y ago
      Applicative style for one data Person = Person { age :: Int , name :: Text , height :: Int } Person <$> parseAge <*> parseName <*> parseHeight Applicative style is one of the easiest constructs to read relative to the power of what it typically does. Most other times when you use <$>, you're using it instead of something like this: fmap f $ x y z Which is simplified by f <$> x y z Google is a non-issue. Hoogle exists and works great (and can even index all symbols importable by your project)
- siraben 6y ago
  Some of these are explanable from mathematical conventions. In abstract algebra it's common to surround an operator in a circle to denote a "generic" or "lifted" operator. So <$> denotes a "lifted application", i.e. ($) :: (a → b) → a → b (<$>) :: Functor f => (a → b) → f a → f b

the_af 6y ago

> I can only imagine that the barrier to entry for Haskell is much, much, much higher than that of an Algol descended language. Haskell syntax is not more complex than an Algol descended language. It's only confusing if you expect an Algol descended language, for example because you're already familiar with them.

whateveracct 6y ago

I have an easier time understanding Haskell than Go codebases, and I have equal and large experience with both. When I first learned Haskell, I only knew C. Haskell codebases were immediately so fun to dive into and learn from. I wouldn't hesitate to hit the "Source" button on Hackage. The fact that all code could be reasoned about locally with just simple symbolic substitution was a breath of fresh air. To a person with 0 experience at all, Haskell or Algol-descended languages are going to be equally alien. Your experience is because you had asymmetric familiarity. So I'm not surprised by your experience. But it says more about you than Haskell.