HN Distilled

Essential insights from Hacker News discussions

Death to type classes

Original Article

Hacker News Discussion

This Hacker News discussion revolves around a technical article, likely about Haskell and functional programming concepts, and the perceived accessibility of its content. Several key themes emerge:

Gatekeeping and Assumed Knowledge

A significant portion of the discussion centers on the article's difficulty for readers who are not already familiar with functional programming (FP) languages, particularly OCaml and Haskell, and their specific module systems. Some users feel the article assumes too much prior knowledge, making it inaccessible.

  • "I feel like this article would be much more approachable if it didn't assume readers already know OCaml and Haskell and their module system," stated SkiFire13.
  • nine_k responded, "Indeed so, but that would require a few months worth of work from the reader, unfortunately."
  • 4ad voiced a different perspective, arguing, "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."
  • nesarkvechnep countered this, asking, "Yeah, it’s better to not assume anything and be stuck in the basics forever, right?"
  • wk_end offered a nuanced view on audience reception: "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'."
  • Adding to this, wk_end also noted, "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."
  • In contrast to wk_end's take on audience expectation, solomonb argued, "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."

Specific Technicalities: Backpack and Type Classes

The discussion delves into the specifics of Haskell's "Backpack" extension and its relationship with "type classes," which are core concepts for Haskell developers but less known to others. It's revealed that the article might be about Backpack, an extension to OCaml's module system that was ported to Haskell, and its potential to replace type classes for achieving ad-hoc polymorphism.

  • fweimer clarified a potential misconception: "Haskell knowledge doesn't actually help because this isn't using the (very barebones) Haskell module system, but the Backpack extension: [link]."
  • kccqzy explained the experimental nature of the technology discussed: "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)."
  • acomar further elaborated on Backpack's limited adoption: "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."
  • wavemode provided a more detailed explanation of Backpack's utility in this context: "The article requires familiarity with Haskell, as well as the concept of Backpacks: [link]. 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: [link] 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.)."
  • jerf touched upon a historical debate within the Haskell community: "Grumbling about how typeclasses could just be normal datatypes has been an undercurrent in the Haskell world for a long time, particularly as a way to solve the orphan instances problem. However, the syntactic grease provided by typeclasses is pretty appealing, and in the end I think this may have died down because people developed engineering solutions to the orphan instances problem (mostly "don't") that mitigated the theoretical problems enough that even most Haskellers don't care anymore... but I guess a few do still somewhat, because such things never truly go away. (And yes, I recognize the quoted sentence as being humorous and labeling the entire article as not entirely serious... my point is that it is not entirely unserious either. The idea has been kicking around seriously for a while.)"
  • marcosdumay expressed difficulty with the article's premise: "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."

Humor, Memes, and Abstraction

The discussion frequently veers into lighthearted commentary, memes, and attempts to explain complex FP concepts through analogies, often highlighting the difficulty of making these concepts understandable to a wider audience.

  • nine_k shared a personal anecdote about explaining FP concepts: "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 quoted E. B. White: "'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.'" This sentiment resonates with the difficulty of explaining abstract or humorous technical concepts.
  • DaiPlusPlus and dagurp humorously questioned the visual interpretation of the lambda symbol: "> a lambda in a circle \nHow often do people think you're a Half-Life fan instead?" / "or Aphex Twin"
  • nine_k then clarified the visual distinctions: "Likely never. The Half-Life has the lambda with the top crooked, neatly inscribed in a circle [link]. 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."
  • The difficulty of understanding FP concepts is highlighted by professor_v's succinctly dense definition: "'A monad is just a monoid in the category of endofunctors'".
  • dist-epoch offered a simpler, if equally abstract, analogy: "I heard it's just like a burrito." WJW added, "Burrito's compose surprisingly well."
  • uncircle responded humorously, "Unlike your 's". WJW acknowledged this with, "Fair point's's, I'll use my standard excuse of not being a native speaker. :)"
  • mindcrime's comment, "'You just made those words up right now'," captures a common feeling when encountering highly abstract technical jargon.
  • esafak's excited "flatMap that s**!" suggests an appreciation for functional programming constructs.
  • DaiPlusPlus and pyrale engaged in a playful exchange related to list comprehensions and sequence generation: '"Hello I would like x<-[1,2..] apples please"' / "And I'll take 3 of those."
  • uncircle connected the article to a meme about the abstract nature of mathematical concepts: "This is in reference to a meme ([link]) and made relevant by the first paragraph of the post > Have you ever seen a Number grazing in the fields? Or a Functor chirping in the trees? No? That’s because they’re LIES. LIES told by the bourgeoisie to keep common folk down."
  • test6554 made a pop-culture reference to the character Charlie Kelly from "It's Always Sunny in Philadelphia," known for his convoluted and often nonsensical theories, implying the technical concepts felt similarly bewildering.
  • 12_throw_away sarcastically dismissed core FP concepts: '"Functors" "Monads" "Typeclasses" <- concepts dreamed up by the utterly deranged'
  • mrkeen offered a critique of specific Haskell syntax and idioms: '"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.'

The Evolution of Hacker News and FP Discussion

A few users commented on how the nature of discussions on Hacker News, particularly regarding functional programming, has changed over time.

  • platz observed a shift in the HN audience: "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."
  • pyrale disagreed with the historical assessment: "Maybe in 2010, but you have an idealized view of 2020 HN."
  • platz further specified, "peak FP debate was 2015/2016-ish."

Code Reusability and Alternatives

Some comments touch on practical aspects of programming, like code reusability, and explore alternative programming paradigms.

  • vjerancui pondered code reusability with the presented module trick: "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." The user then drew a parallel to Python's design.
  • leethomas provocatively suggested a simpler solution: "Orrrrr just use a lisp?"

Defending the Exploration of New Ideas

Despite the critiques and confusion, some users defended the value of exploring novel technical approaches, even if they are niche or difficult to grasp immediately.

  • solomonb questioned the high standard for technical blog posts: "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?"
  • mrkeen also expressed support for experimental approaches: "But overall I like the approach of trying something radically new."

The "ApplicativeDo" Extension

A sub-discussion emerged specifically about Haskell's ApplicativeDo extension, its purpose, and its usability for parallel execution.

  • mrkeen noted, "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." and "This is a bit rough for usability (not to mention also undermines the point above)."
  • kccqzy explained its function: "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."
  • ambicapter questioned its ergonomic implications: "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."
  • kccqzy defended the design: "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."