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.

▲

wavemode a day ago | parent | next [-]

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

▲

throwaway81523 a day ago | parent | next [-]

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

▲

jadbox 20 hours ago | parent | prev [-]

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.

▲

wavemode 16 hours ago | parent [-]

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

	▲	tome 11 hours ago \| parent [-]
		> 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...

▲

joe_the_user 21 hours ago | parent | prev [-]

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.