7 ms·

Many of these address "paper cuts". Individually, they aren't huge issues. But lots of small annoyances can easily add up and make a language not fun to use, an

Many of these address "paper cuts". Individually, they aren't huge issues. But lots of small annoyances can easily add up and make a language not fun to use, and especially punishing for beginners. That's why some language communities prioritize fixing such paper cut problems. The Haskell community mostly doesn't seem to. Another minor thing that happens to annoy me very much is how everything about Haskell's syntax and standard conventions is so diff-unfriendly. To see what I mean, I picked the first "official" example I could find. Here are a few lines of code from the one of the examples in the Haskell playground (https://play.haskell.org/ https://play.haskell.org/ -- it seems to pick a random one each time you load it): data Visitor = Member Profile | NonMember (Maybe T.Text) deriving Show data Profile = Profile { name :: T.Text , birthday :: Time.Day } deriving Show You see Haskell code like this all the time, and the (IMO old-fashioned) lack of an optional trailing comma practically forces you into something like this. But just imagine inserting another variant to Visitor before Member, or removing the name field from Profile! A more practically minded language might allow a syntax like this: data Visitor = | Member Profile | NonMember (Maybe T.Text) deriving Show data Profile = Profile { name :: T.Text, birthday :: Time.Day, } deriving Show Bamm, each line is identical, editing is easy, diffs are clean. TypeScript, for example, has something like this for union types. Haskell unfortunately doesn't.

crote 3y ago
This resonates quite strongly with me. Back when I first learned Haskell, I strongly got the impression that the Haskell community just... didn't like programming? I kept running into endless papercuts like these, language extensions which were poorly documented and mutually incompatible but basically mandatory due to widespread usage, and libraries which were considered "top-of-the-line" but where anything beyond the happy path was considered an open research topic. All in all, it felt more like a loose collection of unfinished PhD theses than an actual programming language. Which is a real shame, because it has quite a few excellent concepts which are a genuine pleasure to use. Unfortunately I think languages like Rust and F# are essentially killing any chance it has at gaining a mainstream foothold: they bring over enough of the good parts of Haskell into mainstream programming that it simply isn't worth having to deal with the bad parts anymore.
- tome 3y ago
  > language extensions which were poorly documented and mutually incompatible I often hear complaints about mutually incompatible language extensions, but when I aske I hardly ever find anyone who can name two! Can you?
  - kccqzy 3y ago
    One thing GP may be thinking of is the multitude of deriving-related extensions. For example when DeriveAnyClass and GeneralizedNewtypeDeriving are turned on simultaneously, the latter often doesn't work due to GHC silently picking the former on a newtype when both could be used. This particular annoyance has been fixed by a new extension, DerivingStrategies. Until this, it's impossible to turn on both extensions in a single module and have some newtypes derive some classes using one and some using the other. I can't think of anything else that could be incompatible. I would also disagree GP's claim that extensions are poorly documented. GHC is very well documented, including all its extensions.
    - crote 3y ago
      I believe that is exactly the one I ran into. One library required DeriveAnyClass, another library required GeneralizedNewtypeDeriving. I couldn't enable both into one file at once, and I couldn't split the definition into two files. In other words: you're screwed. DerivingStrategies solved this, but that came out years after the problem started. As to the "poorly documented": I believe at the time neither the docs for DeriveAnyClass nor those for GeneralizedNewtypeDeriving mentioned the issue even existed, let alone a potential workaround. A lot of other extensions have documentation written for computer scientists, not for programmers who just want to use it. It was not unusual for me to end up enabling an extension because some library required it, opening up the docs and having literally zero clue what was going on, and just end up copy/pasting the example code and praying it worked. Extensions like OverloadedLists are totally fine, but once you get beyond the "Syntax" section the docs quickly become unreadable for most people not actively researching programming languages. It's not unusual for the docs here to start with "more details can be found in the paper XYZ", and be filled with terminology which is neither explained in-place nor have a link to an explanation. When I read docs, I quickly want to know 1) what it is 2) why it is needed 3) how I can use it 4) what the implications are. From my personal experience, the GHC docs simply do not provide me with these.
bradrn 3y ago
> the (IMO old-fashioned) lack of an optional trailing comma I’ll note that in Haskell circles, the usual proposal is a leading comma, which would look like this: data Profile = Profile { , name :: T.Text , birthday :: Time.Day } deriving Show The commas essentially end up like bullets — a style I thoroughly like.
- nh2 3y ago
  Your syntax is incorrect, it should be data Profile = Profile { name :: T.Text , birthday :: Time.Day } deriving Show (You can't write `,` directly after `{`.) This is also why the commas are _not_ like bullets, no matter how you format them. The first one is always special. I agree that somebody should make a language extension that allows what the parent posts says. Doing this does not need a language split / new frontend; this is what language extensions do very well. If they are popuplar, they become part of a new (de-facto) standard, such as GHC2021: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/control.html#extension-GHC2021 https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/cont... And there is precedent for this: There is one place where trailing commas for good diffability are already allowed: Module exports. module MyModule ( fun1, fun2, main, ) where Many language extensions exist to remove such "papercuts"; this looks like a good candidate.
  - mjan22640 3y ago
    When breaking an expression into multiple lines, it is best to place an operator at the start of a line.
  - poorlyknit 3y ago
    The comment you're replying to refers to the fact that the usual proposal is a leading comma You're right that it's not valid Haskell but that wasn't the goal here.
    - nh2 3y ago
      I understood "the usual proposal" as "how people usually propose to format current code when others complain about lack of trailing comma", not as a proposal for an actual change to the language.

crote 3y ago

This resonates quite strongly with me. Back when I first learned Haskell, I strongly got the impression that the Haskell community just... didn't like programming? I kept running into endless papercuts like these, language extensions which were poorly documented and mutually incompatible but basically mandatory due to widespread usage, and libraries which were considered "top-of-the-line" but where anything beyond the happy path was considered an open research topic. All in all, it felt more like a loose collection of unfinished PhD theses than an actual programming language. Which is a real shame, because it has quite a few excellent concepts which are a genuine pleasure to use. Unfortunately I think languages like Rust and F# are essentially killing any chance it has at gaining a mainstream foothold: they bring over enough of the good parts of Haskell into mainstream programming that it simply isn't worth having to deal with the bad parts anymore.

tome 3y ago
> language extensions which were poorly documented and mutually incompatible I often hear complaints about mutually incompatible language extensions, but when I aske I hardly ever find anyone who can name two! Can you?
- kccqzy 3y ago
  One thing GP may be thinking of is the multitude of deriving-related extensions. For example when DeriveAnyClass and GeneralizedNewtypeDeriving are turned on simultaneously, the latter often doesn't work due to GHC silently picking the former on a newtype when both could be used. This particular annoyance has been fixed by a new extension, DerivingStrategies. Until this, it's impossible to turn on both extensions in a single module and have some newtypes derive some classes using one and some using the other. I can't think of anything else that could be incompatible. I would also disagree GP's claim that extensions are poorly documented. GHC is very well documented, including all its extensions.
  - crote 3y ago
    I believe that is exactly the one I ran into. One library required DeriveAnyClass, another library required GeneralizedNewtypeDeriving. I couldn't enable both into one file at once, and I couldn't split the definition into two files. In other words: you're screwed. DerivingStrategies solved this, but that came out years after the problem started. As to the "poorly documented": I believe at the time neither the docs for DeriveAnyClass nor those for GeneralizedNewtypeDeriving mentioned the issue even existed, let alone a potential workaround. A lot of other extensions have documentation written for computer scientists, not for programmers who just want to use it. It was not unusual for me to end up enabling an extension because some library required it, opening up the docs and having literally zero clue what was going on, and just end up copy/pasting the example code and praying it worked. Extensions like OverloadedLists are totally fine, but once you get beyond the "Syntax" section the docs quickly become unreadable for most people not actively researching programming languages. It's not unusual for the docs here to start with "more details can be found in the paper XYZ", and be filled with terminology which is neither explained in-place nor have a link to an explanation. When I read docs, I quickly want to know 1) what it is 2) why it is needed 3) how I can use it 4) what the implications are. From my personal experience, the GHC docs simply do not provide me with these.

bradrn 3y ago

> the (IMO old-fashioned) lack of an optional trailing comma I’ll note that in Haskell circles, the usual proposal is a leading comma, which would look like this: data Profile = Profile { , name :: T.Text , birthday :: Time.Day } deriving Show The commas essentially end up like bullets — a style I thoroughly like.

nh2 3y ago
Your syntax is incorrect, it should be data Profile = Profile { name :: T.Text , birthday :: Time.Day } deriving Show (You can't write `,` directly after `{`.) This is also why the commas are _not_ like bullets, no matter how you format them. The first one is always special. I agree that somebody should make a language extension that allows what the parent posts says. Doing this does not need a language split / new frontend; this is what language extensions do very well. If they are popuplar, they become part of a new (de-facto) standard, such as GHC2021: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/control.html#extension-GHC2021 https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/cont... And there is precedent for this: There is one place where trailing commas for good diffability are already allowed: Module exports. module MyModule ( fun1, fun2, main, ) where Many language extensions exist to remove such "papercuts"; this looks like a good candidate.
- mjan22640 3y ago
  When breaking an expression into multiple lines, it is best to place an operator at the start of a line.
- poorlyknit 3y ago
  The comment you're replying to refers to the fact that the usual proposal is a leading comma You're right that it's not valid Haskell but that wasn't the goal here.
  - nh2 3y ago
    I understood "the usual proposal" as "how people usually propose to format current code when others complain about lack of trailing comma", not as a proposal for an actual change to the language.