Live data from Hacker News

Death to type classes

jappie.me

51–60 of 78 posts

Re: Death to type classes

#51
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…

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

Re: Death to type classes

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

There are still dozens of us!

Re: Death to type classes

#56

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?

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

Re: Death to type classes

#57
post #50

Earlier quoted context omitted.

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…

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

Re: Death to type classes

#58

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…

I think Oleg Kiselyov also has a post somewhere explaining how you can use Ocaml modules to do something similiar to Haskell typeclasses.

Re: Death to type classes

#59

[flagged]

There is a really interesting interview with Simon Peyton-Jones referenced on HN yesterday.He talks a lot about why Haskell came about, and some of the thinking behind the design choices that were made. https://news.ycombinator.com/item?id=45242530

That was great, thank you

Re: Death to type classes

#60
post #52

As someone who has zero OCaml knowledge...can someone explain what's going on?

OCaml (also SML) has a really powerful module system; it's so powerful that to call it a "module" system is maybe misleading to the average developer. You might think of a "module" system as a way of dividing your program into different files, and the ML module system certainly subsumes that case, but it goes beyond that.

The key to this is that modules in ML are actually kind of a separate programming language. Not only can you define modules, you can define "functor modules" - modules that are kind of like functions; you can pass modules as arguments to functors to produce new modules. And there's a (structural!) type system here, too: the modules a functor can accept are specified to have a specific structure, and if you try to pass an incompatible module to a functor you get a type error.

(Incidentally: the naming of functors in the module system is really unfortunate here, because it overlaps with the name of functors in category theory/Haskell.)

This sounds extremely abstract and kind of insane; it's easier to understand it in practice. A typical example might be that you want to define a hash table, which requires some kind of hash operation for a key. What you'd do idiomatically in ML is define a HashTable functor which takes, as an argument, a module X consisting of a type t and and a hash function. This would generate a HashTable(X) module specialized to that particular key type.

What's interesting here is that there's an overlap here with things like interfaces in Java or typeclasses in Haskell, where your HashTable type would demand that the key type adheres to a Hashable interface. It turns out they're kind of (kind of!) just different takes on the same thing. There's even some interest in the OCaml world in trying to "close the gap" with a feature called "modular implicits" [0].

The other thing to know is that there's an esoteric feature of Haskell called "Backpack", which is an attempt to bring the ML module system to Haskell. It's not exactly widely used or anything like that, but it's there and been in GHC for several years now.

This article is basically just demonstrating how Backpack lets you use modules in much the same way as you'd traditionally use typeclasses in Haskell.

[0] https://www.cl.cam.ac.uk/~jdy22/papers/modular-implicits.pdf

Post reply on HN