4 ms·
> 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 l
by 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 agoThanks 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?