7 ms·
Death to type classes
- semiinfinitely 1y agoeven 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"
- seanparsons 1y agoI'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.
- kccqzy 1y agoIt'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).
- acomar 1y agoit'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.
- SkiFire13 1y agoI feel like this article would be much more approachable if it didn't assume readers already know Ocaml and Haskell and their module system
- nine_k 1y agoIndeed 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".)
- codebje 1y ago"Humor can be dissected, as a frog can, but the thing dies in the process and the innards are discouraging to any but the pure scientific mind." - E. B. White.
- Supermancho 1y agoContemporary rephrasing: "<InsertSubject> can be dissected, like a frog. It turns out that nobody is very interested and the frog dies of it."
- tmtvl 1y agoUnexplained humour dies over time. Think of the classic 'a dog walks into an inn and says "I think I'll open the other one"'.
- snackbroken 1y agoSome observational humor is timeless. Consider this entry from the same collection of Sumerian proverbs: "The dog understands 'Take it!', but it does not understand 'Put it down!'"[0] later repopularized as "No Take, Only Throw"[1]. [0] https://etcsl.orinst.ox.ac.uk/proverbs/t.6.1.05.html#t6105.p81 https://etcsl.orinst.ox.ac.uk/proverbs/t.6.1.05.html#t6105.p... [1] https://knowyourmeme.com/memes/no-take-only-throw https://knowyourmeme.com/memes/no-take-only-throw
- DaiPlusPlus 1y ago> a lambda in a circle How often do people think you're a Half-Life fan instead?
- dagurp 1y agoor Aphex Twin
- tialaramex 1y agoThe 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
- actionfromafar 1y agoYeah... meanwhile, in lesser languages, type classes is all we have.
- fweimer 1y agoHaskell 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/2016/07/backpack.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...
- chombier 1y agoThanks, I scanned through all the comments/links but this is the actual resource one wants to read to get familiar with Backpack.
- 4ad 1y agoIt would also be a useless article. It's fine to write for an audience, if you're not in the target audience, move on.
- Vosporos 1y agoIt's okay not to know things
- nesarkvechnep 1y agoYeah, it’s better to not assume anything and be stuck in the basics forever, right?
- whateveracct 1y agoUh so? There's a lot of value in articles that don't rehash the basics for the noob reader.
- test6554 1y agoI just picture Charlie from “It’s Always Sunny in Philadelphia” connecting the dots.
- 12_throw_away 1y ago[flagged]
- skrebbel 1y agoIt's okay not to know things
- professor_v 1y ago"A monad is just a monoid in the category of endofunctors"
- dist-epoch 1y agoI heard it's just like a burrito.
- WJW 1y agoBurrito's compose surprisingly well.
- williamcotton 1y agoA Burrito is a Monad: https://williamcotton.com/articles/a-burrito-is-a-monad https://williamcotton.com/articles/a-burrito-is-a-monad
- b_e_n_t_o_n 1y agoif err !== nil { return err }
- ioasuncvinvaer 1y agoHow does this compose iterators?
- indigoabstract 1y agoDelightfully 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.
- wavemode 1y agoThe article requires familiarity with Haskell, as well as the concept of Backpacks: https://blog.ezyang.com/2016/10/try-backpack-ghc-backpack/ 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-classes.html 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.)
- throwaway81523 1y agoI think Oleg Kiselyov also has a post somewhere explaining how you can use Ocaml modules to do something similiar to Haskell typeclasses.
- jadbox 1y agoThis 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.
- wavemode 1y agoAll 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/ https://www.simplehaskell.org/ [1]: https://academy.fpblock.com/blog/2017/06/readert-design-pattern/ https://academy.fpblock.com/blog/2017/06/readert-design-patt...
- mrkeen 1y agoIn 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 Functor or Monad we’re importing, and you can’t have do notation for different Monads in the same module. This is a bit rough for usability (not to mention also undermines the point above). But overall I like the approach of trying something radically new. [1] https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/applicative_do.html https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/appl...
- kccqzy 1y agoApplicativeDo 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.
- ambicapter 1y agoDoes that mean it may or may not run the code in parallel once compiled? Doesn't seem very ergonomic to the developer if true.
- kccqzy 1y agoWhy isn't it ergonomic? You just read the documentation or source for the Applicative class in question to find out. If the Applicative class chooses to decide randomly whether to run in parallel, that's the class's fault, not the language or the compiler's problem.
- platz 1y agoIn 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.
- pyrale 1y agoMaybe in 2010, but you have an idealized view of 2020 HN.
- platz 1y agopeak FP debate was 2015/2016-ish
- marcosdumay 1y agoThe 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.
- ghc 1y agoThere are still dozens of us!
- vjerancrnjak 1y agoHow to reuse `readFile` `writeFile` program with this module trick? Assuming `IO.readFile` and `IO.writeFile` is replaced by HTTP requests. I can define `writeFile` and `readFile` in a type class and then implement the effect for HTTP variant, hiding the HTTP client beneath. Is it just wiring it up in mixins, cabal file? I think general conclusion is that there's no need for dependency injection, environment objects, or similar tricks if module system is rich enough. For a long time I questioned why Python needs anything but `async def` or `def` (async should be achievable through module or `yield` usage) and `import` statements, to achieve maximal reuse, given dynamic nature of language and modules. We could ignore all object-oriented features, decorators, replace them with modules. Would be flatter and readable compared to bloated feature set.
- leethomas 1y agoOrrrrr just use a lisp?
- solomonb 1y agoI 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?
- wk_end 1y agoThe 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.
- solomonb 1y ago> 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.
- edem 1y agoAs someone who has zero OCaml knowledge...can someone explain what's going on?
- wk_end 1y agoOCaml (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 https://www.cl.cam.ac.uk/~jdy22/papers/modular-implicits.pdf
- 1y ago
- yuppiemephisto 1y agoI enjoyed this, hadn't used backpack and this is a nice tutorial
- justincredible 1y ago[dead]
- rurban 1y agoIn the real world we'd do that with our MOP (Meta Object Protocol), no need for that crazy FP naming conventions. The principles are trivial