4 ms·

> 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 ju

> 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".
- tome 3y ago
  > I basically drowned into a marsh of incomprehensible language extensions which were somehow required for pretty much every single library I also see this a lot, but do you really have to understand language extensions? These days one just enables GHC2021 as though it were the "language" and completely forgets that technically there are "extensions" behind it. Haskell (or rather GHC) has really suffered from trying to be a good citizen. It gates new features behind `LANGUAGE` pragmas and rather than saying "oh, that's very polite behaviour, let me just do some simple busywork to get access to the new features" people say "oh no, these language extensions are scary and confusing things". They're really not! Mostly they're just about removing unnecessary restrictions from the older standard. > and more than once I ran into severe project-breaking design limitations only after investing dozens of hours into the library. Could you give an example?
  - crote 3y ago
    > do you really have to understand language extensions? You do when your code doesn't compile and you're trying to figure out what the error message means, or when the library you want to use makes heavy use of it for even basic functionality. > These days one just enables GHC2021 My experience was pre-GHC2021. I basically had to enable at a minimum 5-6 language extensions in every single file. > Mostly they're just about removing unnecessary restrictions from the older standard. Yeah, those ones are usually fine. I have zero objection to things like FlexibleInstances or DeriveFoldable. > Could you give an example? I believe I was trying to implement Central Authentication Service using Servant. However, that required returning a custom HTTP status code. There has been an open Github issue for this since 2017, but it seems to require basically rewriting the entire framework: https://github.com/haskell-servant/servant/issues/732 https://github.com/haskell-servant/servant/issues/732 Looking back at it now Servant does have "ServerError", but that basically requires giving up all the advantages Servant claims to have and I believe it was not a viable option at the time. Looking at the timeline I was probably also on Servant 0.15, and there seems to have been a rewrite since then. I vaguely recall running into a similar issue trying to interact with a database, but I can't remember the details of that.

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".

tome 3y ago
> I basically drowned into a marsh of incomprehensible language extensions which were somehow required for pretty much every single library I also see this a lot, but do you really have to understand language extensions? These days one just enables GHC2021 as though it were the "language" and completely forgets that technically there are "extensions" behind it. Haskell (or rather GHC) has really suffered from trying to be a good citizen. It gates new features behind `LANGUAGE` pragmas and rather than saying "oh, that's very polite behaviour, let me just do some simple busywork to get access to the new features" people say "oh no, these language extensions are scary and confusing things". They're really not! Mostly they're just about removing unnecessary restrictions from the older standard. > and more than once I ran into severe project-breaking design limitations only after investing dozens of hours into the library. Could you give an example?
- crote 3y ago
  > do you really have to understand language extensions? You do when your code doesn't compile and you're trying to figure out what the error message means, or when the library you want to use makes heavy use of it for even basic functionality. > These days one just enables GHC2021 My experience was pre-GHC2021. I basically had to enable at a minimum 5-6 language extensions in every single file. > Mostly they're just about removing unnecessary restrictions from the older standard. Yeah, those ones are usually fine. I have zero objection to things like FlexibleInstances or DeriveFoldable. > Could you give an example? I believe I was trying to implement Central Authentication Service using Servant. However, that required returning a custom HTTP status code. There has been an open Github issue for this since 2017, but it seems to require basically rewriting the entire framework: https://github.com/haskell-servant/servant/issues/732 https://github.com/haskell-servant/servant/issues/732 Looking back at it now Servant does have "ServerError", but that basically requires giving up all the advantages Servant claims to have and I believe it was not a viable option at the time. Looking at the timeline I was probably also on Servant 0.15, and there seems to have been a rewrite since then. I vaguely recall running into a similar issue trying to interact with a database, but I can't remember the details of that.