2 ms·

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

by 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.
  - tome 3y ago
    Thanks for your reply! I'm in a tricky position because I'm spending quite a lot of effort trying to improve the Haskell ecosystem, and although people report a lot of difficulty with language extensions I don't actually understand why. I suspect the problem is with something else, but it gets attributed to "language extensions" because that's the element that was most visible when the problem occurred. Anyway, I don't mean to badger you, so feel free to ignore me if it's not a good use of your time, but I do have more thoughts and questions. > I basically had to enable at a minimum 5-6 language extensions in every single file. Sure, but I don't see a problem with that, per se. I routinely enable 20 language extensions in a single file! They're mostly just removing restrictions, as I said. It gets a bit tedious but nothing more than that. > I believe I was trying to implement Central Authentication Service using Servant Aha! Servant uses a style of programming (often called "type level" but I'm not really completely sure that's accurate) that I find rather inflexible. I would be very hesitant to use Servant myself, personally. Is it possible that the problems you experienced were actually to do with the inflexibility with Servant itself, but the problems have been attributed to language extensions, since you were required to add them to make Servant work?

by crote 3y ago

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.
- tome 3y ago
  Thanks for your reply! I'm in a tricky position because I'm spending quite a lot of effort trying to improve the Haskell ecosystem, and although people report a lot of difficulty with language extensions I don't actually understand why. I suspect the problem is with something else, but it gets attributed to "language extensions" because that's the element that was most visible when the problem occurred. Anyway, I don't mean to badger you, so feel free to ignore me if it's not a good use of your time, but I do have more thoughts and questions. > I basically had to enable at a minimum 5-6 language extensions in every single file. Sure, but I don't see a problem with that, per se. I routinely enable 20 language extensions in a single file! They're mostly just removing restrictions, as I said. It gets a bit tedious but nothing more than that. > I believe I was trying to implement Central Authentication Service using Servant Aha! Servant uses a style of programming (often called "type level" but I'm not really completely sure that's accurate) that I find rather inflexible. I would be very hesitant to use Servant myself, personally. Is it possible that the problems you experienced were actually to do with the inflexibility with Servant itself, but the problems have been attributed to language extensions, since you were required to add them to make Servant work?