Death to Type Classes

Indeed so, but that would require a few months worth of work from the reader, unfortunately.

(I have a t-shirt with a lambda in a circle, reminiscent of the anarchist emblem, and words "no class, no state". It's definitely possible to explain to a passer-by who never studied FP what it refers to, but not in such a way that the joke remained funny. Possibly the same deal is with the bumper sticker saying "my other car is cdr".)

Haskell knowledge doesn't actually help because this isn't using the (very barebones) Haskell module system, but the Backpack extension: https://www.microsoft.com/en-us/research/wp-content/uploads/...

Yeah... meanwhile, in lesser languages, type classes is all we have.

Uh so? There's a lot of value in articles that don't rehash the basics for the noob reader.

It's okay not to know things

It would also be a useless article. It's fine to write for an audience, if you're not in the target audience, move on.

Yeah, it’s better to not assume anything and be stuck in the basics forever, right?

How does this compose iterators?

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.

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

it's experimenting with a feature that was added to Haskell but just never caught on. it's theoretically very powerful but it's far enough from idiomatic Haskell that it sees basically zero usage in the wild as the cost for using it is that very few people can understand what you've done.

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 basically be thought of as an additional vtable argument passed to every function that has typeclass constraints. (And, indeed, thinking about them this way often allows one to avoid typeclasses entirely and achieve the same kind of polymorphism in simpler and more flexible ways.)

Backpacks can achieve something similar, except by declaring an abstract "signature" for your dependency, rather than a function argument. (Backpacks can also be used to do a lot more than this, of course, but that's outside the scope of the OP article.)

I'm a pretty average programmer/ex-programmer/hn-commenter in this context. I have never programmed in Haskell though in college I programmed with the language "fp" that is naturally functional.

I can tell this is article is about a common, wide debate in CS; should languages have "strict" structures like type class or loose structures like "objects". This related-to but not the same as the debate on whether to have pure functional languages or ad-hoc imperative languages.

I know in programming practice, everything ad-hoc has won but programming language "theory", everything strict has won.

Now in this context, I understand the post as advocating a certain kind of loose data typing with the strict-world of Haskell. Which I'd imagine won't make any ideologue happy. But seems like an OK contribution to the debate.

To add my own takes on everything, as hners must do, I think the strict structures of functional programming have quite a bit of merit for various purposes. BUT - they aren't intuitive/the-easy-way-to-everything-once-you-know/etc. AND they aren't a way to solve the software crisis.

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.

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

The problem is that this is not only about Haskell's fundamentals. It's about them being extended with backpack, an extension that very few people use.

And honestly, I don't see the point there either. I know that backpack is meant to solve some problem everybody has, but I haven't been able to fully understand what that problem is. Specifically on this article, I don't see the gain over using a type class.

There are still dozens of us!

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 concept (that typeclasses and modules are roughly equivalent in some sense), but I'm unfamiliar with Backpack so I still struggled to follow it a little. The target audience is an extremely narrow niche. So I think it's just somewhat poorly written; it doesn't feel like the author really had an audience in mind, other than themselves. There's probably ways of writing this - without spending too much time regurgitating the basics - that would be more palatable to more people.

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

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