4 ms·

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 programm

by 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.
    - tome 3y ago
      OK, fair enough that these two were incompatible, but I think your earlier statement is really misleading! > language extensions which were poorly documented and mutually incompatible but basically mandatory due to widespread usage Neither DeriveAnyClass nor GeneralizedNewtypeDeriving is basically mandatory, and this problem only existed between the introduction of the latter in 2015 and the introduction of deriving strategies is 2017. It's definitely fair to say there's a lot of crufty stuff in the Haskell world (there's also a lot of crufty stuff in the ecosystem of any other language I've used) but I think you really overstated the case.
zainhoda 3y ago
> All in all, it felt more like a loose collection of unfinished PhD theses than an actual programming language. Yeah, to me Haskell is the experimental forefront of programming language theory and the most developed concepts get incorporated into the actual programming languages over time.
59nadir 3y ago
Personally I think of Haskell the same way I think of C++ in terms of language features. There are so many and so much to choose from that there should be one person in every company that has simply decided that the company uses this particular subset and that's it, pending very detailed and well-motived discussions in the future, but at a snail's pace. In my particular case I would also prefer for that subset to be chosen with a conservative and considerably less PLT-enthusiastic mindset, i.e. bog standard `RIO` style that prefers imperative code working on bags of mutable values of different types when solving problems. But yeah, Haskell is a wide language and that's why it's so hard to adopt. People tend to learn ostensibly the wrong things, oftentimes from people who've never actually written any real production code but like to theorize and hypothesize about "the best pattern for X" and so on.
yakshaving_jgt 3y ago
> Back when I first learned Haskell, I strongly got the impression that the Haskell community just... didn't like programming? This is such a peculiar value judgement, and for the life of me I can’t work out what leads you to think this way. If you don’t like Haskell, that’s fine. You don’t have to. But people who work with Haskell are generally happy and productive, just like most other programmers in most other general purpose programming languages.
- dagw 3y ago
  for the life of me I can’t work out what leads you to think this way. I suspect what is being referred to is that many Haskell people have a very strong academic background and are much more interest in working on Haskell rather than using Haskell to write 'normal' programs.
  - yakshaving_jgt 3y ago
    I've heard this idea many times over the years, but it just hasn't been my experience. Most of the Haskell programmers I have worked with are programmers. Incidentally, they like writing software in Haskell.
    - dagw 3y ago
      It does match my experience though. Most Haskell programmers I've met are either working at Universities or within research groups at large organisations.
- crote 3y ago
  > If you don’t like Haskell, that’s fine. You don’t have to. That's the problem: I do like most parts of Haskell! It's a language I really want to use more often, as many parts of it are miles beyond most other languages. Just the fact that it has proper first-class support for tagged unions makes programming an absolute joy. All the "introduction to Haskell"-level stuff made me fall in love with the language, and I basically wanted to rewrite all my code into Haskell. But then I started trying to actually write production-level code and engage with the larger ecosystem, and I basically drowned into a marsh of incomprehensible language extensions which were somehow required for pretty much every single library - and more than once I ran into severe project-breaking design limitations only after investing dozens of hours into the library. There are plenty of languages I really can't give a rat's arse about, but I like Haskell too much to just ignore it. To me Haskell is the one that got away, and I am eagerly waiting for someone - like this project - to essentially create a "Haskell for programmers".

by crote 3y ago

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.
  - tome 3y ago
    OK, fair enough that these two were incompatible, but I think your earlier statement is really misleading! > language extensions which were poorly documented and mutually incompatible but basically mandatory due to widespread usage Neither DeriveAnyClass nor GeneralizedNewtypeDeriving is basically mandatory, and this problem only existed between the introduction of the latter in 2015 and the introduction of deriving strategies is 2017. It's definitely fair to say there's a lot of crufty stuff in the Haskell world (there's also a lot of crufty stuff in the ecosystem of any other language I've used) but I think you really overstated the case.

zainhoda 3y ago

> All in all, it felt more like a loose collection of unfinished PhD theses than an actual programming language. Yeah, to me Haskell is the experimental forefront of programming language theory and the most developed concepts get incorporated into the actual programming languages over time.

59nadir 3y ago

Personally I think of Haskell the same way I think of C++ in terms of language features. There are so many and so much to choose from that there should be one person in every company that has simply decided that the company uses this particular subset and that's it, pending very detailed and well-motived discussions in the future, but at a snail's pace. In my particular case I would also prefer for that subset to be chosen with a conservative and considerably less PLT-enthusiastic mindset, i.e. bog standard `RIO` style that prefers imperative code working on bags of mutable values of different types when solving problems. But yeah, Haskell is a wide language and that's why it's so hard to adopt. People tend to learn ostensibly the wrong things, oftentimes from people who've never actually written any real production code but like to theorize and hypothesize about "the best pattern for X" and so on.

yakshaving_jgt 3y ago

> Back when I first learned Haskell, I strongly got the impression that the Haskell community just... didn't like programming? This is such a peculiar value judgement, and for the life of me I can’t work out what leads you to think this way. If you don’t like Haskell, that’s fine. You don’t have to. But people who work with Haskell are generally happy and productive, just like most other programmers in most other general purpose programming languages.

dagw 3y ago
for the life of me I can’t work out what leads you to think this way. I suspect what is being referred to is that many Haskell people have a very strong academic background and are much more interest in working on Haskell rather than using Haskell to write 'normal' programs.
- yakshaving_jgt 3y ago
  I've heard this idea many times over the years, but it just hasn't been my experience. Most of the Haskell programmers I have worked with are programmers. Incidentally, they like writing software in Haskell.
  - dagw 3y ago
    It does match my experience though. Most Haskell programmers I've met are either working at Universities or within research groups at large organisations.
crote 3y ago
> If you don’t like Haskell, that’s fine. You don’t have to. That's the problem: I do like most parts of Haskell! It's a language I really want to use more often, as many parts of it are miles beyond most other languages. Just the fact that it has proper first-class support for tagged unions makes programming an absolute joy. All the "introduction to Haskell"-level stuff made me fall in love with the language, and I basically wanted to rewrite all my code into Haskell. But then I started trying to actually write production-level code and engage with the larger ecosystem, and I basically drowned into a marsh of incomprehensible language extensions which were somehow required for pretty much every single library - and more than once I ran into severe project-breaking design limitations only after investing dozens of hours into the library. There are plenty of languages I really can't give a rat's arse about, but I like Haskell too much to just ignore it. To me Haskell is the one that got away, and I am eagerly waiting for someone - like this project - to essentially create a "Haskell for programmers".