I enjoyed this, hadn't used backpack and this is a nice tutorial
Death to type classes
61–70 of 78 posts
Re: Death to type classes
#62As 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…
Thank you for such a concise summary. I had no idea that types in ocaml are that powerful.
Re: Death to type classes
#63I feel like this article would be much more approachable if it didn't assume readers already know Ocaml and Haskell and their module system
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/...
Thanks, I scanned through all the comments/links but this is the actual resource one wants to read to get familiar with Backpack.
Re: Death to type classes
#64I 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.
It contains "type class".
Re: Death to type classes
#65Earlier 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…
"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.
Contemporary rephrasing:
" can be dissected, like a frog. It turns out that nobody is very interested and the frog dies of it."
Re: Death to type classes
#66Earlier 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…
"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.
Unexplained humour dies over time. Think of the classic 'a dog walks into an inn and says "I think I'll open the other one"'.
Re: Death to type classes
#67Delightfully 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.
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.
Re: Death to type classes
#68Earlier quoted context omitted.
Maybe if the post title used the word "Haskell" it wouldn't attract the opinions of people not interested in Haskell? Pretty obvious stuff.
It contains "type class".
... which won't mean much to someone who doesn't know Haskell. The kind of person who might click on this link thinking "types and classes are the same thing, what does he mean 'type class'".
(don't @ me with your pedantic bullshit about how types and classes are different, I don't care).
Re: Death to type classes
#69Earlier quoted context omitted.
"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.
Unexplained humour dies over time. Think of the classic 'a dog walks into an inn and says "I think I'll open the other one"'.
Some 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.p... [1] https://knowyourmeme.com/memes/no-take-only-throw
Re: Death to type classes
#70[dead]