Live data from Hacker News

Death to type classes

jappie.me

71–78 of 78 posts

Re: Death to type classes

#71

Delightfully weird and niche article. And I wouldn't be surprised if there were more retired left handed surgeons in their 50s living in rural Switzerland than people who understand what he's talking about.

The article requires familiarity with Haskell, as well as the concept of Backpacks: https://blog.ezyang.com/2016/10/try-backpack-ghc-backpack/ The author then uses Backpacks to achieve ad-hoc polymorphism without typeclasses. There is a well-known article from a long time ago which was conceptually similar: https://www.haskellforall.com/2012/05/scrap-your-type-classe... Which highlighted the fact that typeclasses can…

This was a wonderful comment that added a lot of value to the article for me. I have a random curiosity if this was generated by a model or human written. I'm hoping for the later as this seems too well processed to be a LLM, but I'd like to check my assumption.

Re: Death to type classes

#72
post #71

Earlier quoted context omitted.

The article requires familiarity with Haskell, as well as the concept of Backpacks: https://blog.ezyang.com/2016/10/try-backpack-ghc-backpack/ The author then uses Backpacks to achieve ad-hoc polymorphism without typeclasses. There is a well-known article from a long time ago which was conceptually similar: https://www.haskellforall.com/2012/05/scrap-your-type-classe... Which highlighted the fact that typeclasses can…

This was a wonderful comment that added a lot of value to the article for me. I have a random curiosity if this was generated by a model or human written. I'm hoping for the later as this seems too well processed to be a LLM, but I'd like to check my assumption.

All human lol. I was very into Haskell when I was in college, and Scrap Your Typeclasses was always one of my favorite articles.

There has always been a sort of fascination with effect systems and dependency inversion in the Haskell community. You cannot throw a stone in any discussion board without hitting someone currently noodling on the problem of "man, typeclasses are cumbersome and don't compose well. What if we had something better?"

Transformers and mtl were the name of the game for a long time. Then for a while there was a LOT of hype around free monads and algebraic effect systems. When I was deeply into Haskell, at the time it sometimes felt like a new effect system library was being released every week.

Then there was also this counter-movement of people going "all this new-fangled stuff is overly complicated. Why don't we just use plain functions?" (see [0]).

And there were also a lot of people saying "well, if you just write your whole application in ReaderT IO, you can get 90% of the effects juice for only 10% of the complexity squeeze" (see [1]).

Meanwhile, this whole time we have had distant voices in the back pointing out that OCaml has already solved this problem, and Haskell should just introduce a feature for first-class modules. Well, now it's here, and it's called Backpack.

[0]: https://www.simplehaskell.org/

[1]: https://academy.fpblock.com/blog/2017/06/readert-design-patt...

Re: Death to type classes

#73
post #50

I see a lot of critical comments on here. The blog post is an exploration of an alternative way to structure code in Haskell. Why is the bar such that Haskell blog posts have to either demonstrate something clearly better then the status quo or that they need to explain the fundamentals of the language?

The audience is going to meet the article where they're at. It's fine for, say, a blog post aimed at Haskellers to assume Haskell knowledge, but when posted on a board largely consisting of people without Haskell knowledge, it's natural that you're going to get at least a few people saying, "hey, I don't understand this". But I'll be honest - I'm familiar with Haskell and the ML module system and the underlying conce…

Death? cryOfUprising? Why be weird? Is the article supposed to communicate something or is it an entry in the author's personal diary that got out? Sheesh. ... I know language profs try hard to teach people to write. It wouldn't kill to listen.

Re: Death to type classes

#74
post #57

Earlier quoted context omitted.

> The audience is going to meet the article where they're at. I hear you on this point but anyone can post anything on this forum. The burden should not be on the author to write a post that aligns with whatever forum their blog might get posted onto.

The author is free to ignore any and all complaints they consider unfounded. It’s not even like the author is recieving any complaints personally; they have to come here to see any. And if they come here, they will get to read the viewpoint visible from here.

Bingo- post to hn ... you'll get per review. Thats the deal.

Re: Death to type classes

#75
post #71

Earlier quoted context omitted.

This was a wonderful comment that added a lot of value to the article for me. I have a random curiosity if this was generated by a model or human written. I'm hoping for the later as this seems too well processed to be a LLM, but I'd like to check my assumption.

All human lol. I was very into Haskell when I was in college, and Scrap Your Typeclasses was always one of my favorite articles. There has always been a sort of fascination with effect systems and dependency inversion in the Haskell community. You cannot throw a stone in any discussion board without hitting someone currently noodling on the problem of "man, typeclasses are cumbersome and don't compose well. What if w…

> there were also a lot of people saying "well, if you just write your whole application in ReaderT IO, you can get 90% of the effects juice for only 10% of the complexity squeeze"

I think 90% is an overestimate because you don't get any encapsulation. Maybe 50% is a more reasonable number. If you want 99% of the effects juice for 1% of the complexity squeeze, my effect system, Bluefin0[1], as well as the effectful[2] effect system

My recent talk "A History of Effect systems"[3] explains this in more detail, as does the "Why even use an effect system"[4] section of the latest Bluefin documentation.

[1] https://hackage-content.haskell.org/package/bluefin

[2] https://hackage-content.haskell.org/package/effectful

[3] https://www.youtube.com/watch?v=RsTuy1jXQ6Y

[4] https://hackage-content.haskell.org/package/bluefin-0.0.17.0...

Re: Death to type classes

#76
post #56

Earlier quoted context omitted.

Maybe if the post title used the word "Haskell" it wouldn't attract the opinions of people not interested in Haskell? Pretty obvious stuff.

It contains "type class".

Those are not exclusive to Haskell.

Personally, just from reading the title, I was hoping for an article about the design of type systems in programming languages in general.

Re: Death to type classes

#78
post #71

Earlier quoted context omitted.

This was a wonderful comment that added a lot of value to the article for me. I have a random curiosity if this was generated by a model or human written. I'm hoping for the later as this seems too well processed to be a LLM, but I'd like to check my assumption.

All human lol. I was very into Haskell when I was in college, and Scrap Your Typeclasses was always one of my favorite articles. There has always been a sort of fascination with effect systems and dependency inversion in the Haskell community. You cannot throw a stone in any discussion board without hitting someone currently noodling on the problem of "man, typeclasses are cumbersome and don't compose well. What if w…

Super helpful. Thank you again for even more context here. I'm curious now to dig into Backpack.
Post reply on HN