Live data from Hacker News

Death to type classes

jappie.me

31–40 of 78 posts

Re: Death to type classes

#31

even for someone moderately interested in FP, this one goes above my head and the only take-away I can get from it is "maybe use ocaml instead of haskell"

I'm reasonably versed in Haskell and my response would be that it shouldn't make that much difference to you what they've written in here. I've yet to see any code in the wild using the backpack extension.

Re: Death to type classes

#32
post #29

In the 2010-2020 era, readers of Hacker News used to know how to read Haskell and had strong opinions (pro and con) of it. That era is now over.

Maybe in 2010, but you have an idealized view of 2020 HN.

Re: Death to type classes

#34
post #23

Earlier quoted context omitted.

> a lambda in a circle How often do people think you're a Half-Life fan instead?

or Aphex Twin

The CS understanding of "No class, no state" is just about at the edge of something Aphex Twin might care about. But the stylized A really isn't that similar to a Lambda

Re: Death to type classes

#35

even for someone moderately interested in FP, this one goes above my head and the only take-away I can get from it is "maybe use ocaml instead of haskell"

It's more of an experiment: what if we take this beloved feature from OCaml to port it to Haskell (backpack), and see if it can replace a different beloved Haskell feature (type classes).

Re: Death to type classes

#36
post #32
post #29

In the 2010-2020 era, readers of Hacker News used to know how to read Haskell and had strong opinions (pro and con) of it. That era is now over.

Maybe in 2010, but you have an idealized view of 2020 HN.

peak FP debate was 2015/2016-ish

Re: Death to type classes

#37
post #30
post #26

In this case that’s the >>= from Maybe.Monad. As long as you satisfy the signature, it’s happy . do has nothing to do with Monads! Who lied to you? Could have been a stronger point by using a non-monadic >>=. I've been doing a lot of parsing lately and I find I don't need to reach all the way for monad (applicative is usually enough). But I guess that's what ApplicativeDo[1] is for. We’ve got to be explicit now which…

ApplicativeDo can be thought of as a compile-time transformation that turns sequential code into possibly parallel* code just by analyzing the way variables are used. Once I've had that realization I really appreciated it more. *: By "possibly parallel" I mean the blocks of code are known to be independent from each other. They could be actually executed in parallel if the Applicative instance does so.

Does that mean it may or may not run the code in parallel once compiled? Doesn't seem very ergonomic to the developer if true.

Re: Death to type classes

#38

[flagged]

This is in reference to a meme ( https://knowyourmeme.com/memes/stop-doing-math ) and made relevant by the first paragraph of the post. > Have you ever seen a Number grazing in the fields? Or a Functor chirping in the trees? No? That’s because they’re LIES. LIES told by the bourgeoisie to keep common folk down.

Grumbling about how typeclasses could just be normal datatypes has been an undercurrent in the Haskell world for a long time, particularly as a way to solve the orphan instances problem. However, the syntactic grease provided by typeclasses is pretty appealing, and in the end I think this may have died down because people developed engineering solutions to the orphan instances problem (mostly "don't") that mitigated the theoretical problems enough that even most Haskellers don't care anymore... but I guess a few do still somewhat, because such things never truly go away.

(And yes, I recognize the quoted sentence as being humorous and labeling the entire article as not entirely serious... my point is that it is not entirely unserious either. The idea has been kicking around seriously for a while.)

Post reply on HN