Hacker News Reader

Comment by tombert | Hacker News Reader

The concurrency design in Haskell is cool, though I gotta admit that I don't find it much fun to write.

It's not because the language is "hard". I remember when I first learned Haskell a million years ago I thought it was the coolest thing ever because I had never seen anyone work at that abstract of a level before, especially in a compiled language. I got to understand the theory well enough and I know how to write a program with it, but the entire language kind of feels slapped together to me. Every time I've written anything in Haskell, I feel like I have to do a million compiler extensions, or rely on third party libraries' liberal use of Template Haskell (e.g. Lens) to make the language feel anywhere near "modern".

Yes yes yes, I know this is a complaint about GHC, not "Haskell", but given that GHC is basically the only Haskell compiler that gets serious use I don't think it's weird to conflate the compiler and the language.

View on HN

Template Haskell is actually pretty cool. Using it to generate lenses in a type is a perfectly fine use case (of course hand-writing lenses is just one line anyways). Running computation at compile time is really a great feature; people rave about comptime in Zig but of course Haskell has had it earlier.

I don't dispute the coolness of any given Haskell feature. Haskell does have a lot of really neat features, but that doesn't mean that the language is fun to use.

C++ also has a lot of really cool features but I also do not enjoy writing it, actually for similar reasons as Haskell (though I don't think Haskell is nearly as irritating as C++).

> of course hand-writing lenses is just one line anyways

The lenses themselves aren't hard to write; I was referring to the annoying quirk of Haskell where records couldn't have the same field names. Lens has a nice helper macro `makeFields` so that you could more or less automatically have the generated lenses have the clashing names.

To be fair it actually always worked fine for me but it always felt janky until `DuplicateRecordFields` was released.

> the entire language kind of feels slapped together to me

The slogan "avoid success at all costs" definitely is accurate for Haskell

I honestly don't think that that's why the language is annoying though.

"Avoid success at all costs" has always meant (in my mind) to mean "we will prioritize doing things the 'right' way instead of doing things to appeal to corporations". That's fine, I'm all for doing things correctly, but I think a lot of Haskell's bullshit isn't because of that.

It's a common complaint but it's common for a reason: the fact that records couldn't contain the same field names was really stupid. Apparently in the 90's the Haskell devs couldn't fathom two different types both having a field called "ID" or "name". How does allowing multiple objects to have an overlapping field name affect purity? Plenty of other languages, some of which are even more mathy than Haskell, have managed to pull this off (e.g. TLA+). Could it be because records/structs are really just a shitty hack around tuples tacked onto the language? Yes, Lens fixed hat particular problem with Template Haskell, and now there's yet another GHC extension to more or less work around it, but doesn't change the fact that I think it was something actively bad and it wasn't because of "purity" reasons.

> Apparently in the 90's the Haskell devs couldn't fathom two different types both having a field called "ID" or "name".

I think it's simply that making field names become functions that select from the record was a simple design that worked, and didn't require anything new to be added to the language.

My interpretation is more that changes solely for the purpose of wider adoption were explicitly "out of scope" for the language. Warts aren't undesirable, but in a certain sense actively embraced in my reading of the slogan.

It makes perfect sense when you think about the order of doing name lookup and type checking. In Haskell name lookup happens strictly before type checking. In more conventional 90s languages like C++ that’s obviously impossible because to compile `foo->bar()` the compiler must first know the type of `foo` before it can begin the name lookup for `bar` in the class hierarchy; in fact in C++ `bar(foo)` also requires knowing the type of `foo` before being able to look up `bar` due to the amazing feature of ADL. In Haskell the type checking was meant to be a research playground for new ideas, such as the idea of type classes, so naturally it was a bad idea to couple name lookup with type checking.

I’m not a historian but that’s just my thought.

Reply on news.ycombinator.com