Skip to content

Instantly share code, notes, and snippets.

View rberenguel's full-sized avatar

Ruben Berenguel rberenguel

View GitHub Profile

Introduction

I was recently asked to explain why I felt disappointed by Haskell, as a language. And, well. Crucified for crucified, I might as well criticise Haskell publicly.

First though, I need to make it explicit that I claim no particular skill with the language - I will in fact vehemently (and convincingly!) argue that I'm a terrible Haskell programmer. And what I'm about to explain is not meant as The Truth, but my current understanding, potentially flawed, incomplete, or flat out incorrect. I welcome any attempt at proving me wrong, because when I dislike something that so many clever people worship, it's usually because I missed an important detail.

Another important point is that this is not meant to convey the idea that Haskell is a bad language. I do feel, however, that the vocal, and sometimes aggressive, reverence in which it's held might lead people to have unreasonable expectations. It certainly was my case, and the reason I'm writing this.

Type classes

I love the concept of type class

@vil1
vil1 / 🏳️.md
Last active September 8, 2019 00:05

This is a witch hunt.

When you exclude a relentless innovator from a conference, when this exclusion results in excluding the young woman from North-Africa who was supposed to share the stage with him, it has nothing to do with promoting innovation and inclusivity. It is a witch hunt.

When you bar someone from contributing to a FLOSS project based on alleged aggressive communication without providing any concrete example of the said behavior nor explaining what you did to make this behavior stop before taking such extreme decision, it has nothing to do with making your community a better place. It is a witch hunt.

Witch hunts are bad. Not because they burn people with no fair trial and that some of the burnt people may not have been witches in the first place.

Witch hunts are bad because they burn people. Period.

@cb372
cb372 / io-and-tf.md
Last active June 5, 2023 16:16
IO and tagless final

TL;DR

We should use a type parameter with a context bound (e.g. F[_]: Sync) in library code so users can choose their IO monad, but we should use a concrete IO monad in application code.

Abstracting over IO

If you're writing a library that makes use of effects, it makes sense to use the cats-effect type classes so users can choose their IO monad (IO, ZIO, Monix Task, etc).

So instead of