Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Death to type classes

jappie.me

Post reply on HN
Print view View original

41–50 of 78 posts

Re: Death to type classes

#41

Post by marcosdumay »

platz wrote: 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.

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.

Re: Death to type classes

#42

Post by vjerancrnjak »

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

Re: Death to type classes

#43

Post by kccqzy »

ambicapter wrote: post #37
kccqzy wrote: post #30

Earlier quoted context omitted.

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.

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

Re: Death to type classes

#44

Post by nine_k »

DaiPlusPlus wrote: post #18
nine_k wrote: post #4

Earlier quoted context omitted.

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…

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

Likely never. The Half-Life has the lambda with the top crooked, neatly inscribed in a circle [1]. The anarchist version has everything straight, and with the three sticks protruding out of the circle (like the A would). The visual rhyme is obvious.

[1]: https://en.wikipedia.org/wiki/Gordon_Freeman#/media/File:Gor...

[2]: https://en.wikipedia.org/wiki/Anarchist_symbolism#/media/Fil...

Re: Death to type classes

#46

Post by solomonb »

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?

Re: Death to type classes

#48

Post by acomar »

semiinfinitely wrote: post #12

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

Re: Death to type classes

#49

Post by wavemode »

indigoabstract wrote: post #15

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

Re: Death to type classes

#50

Post by wk_end »

solomonb wrote: post #46

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

Post reply on HN