Hacker News Reader

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

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.

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.

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.

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.

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

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.

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.

It does match my experience though. Most Haskell programmers I've met are either working at Universities or within research groups at large organisations.

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

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

> 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

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.

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?

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