Live data from Hacker News

Haskell Mini-Patterns Handbook

kowainik.github.io

21–30 of 34 posts

Re: Haskell Mini-Patterns Handbook

#21

The whole "this code is problematic because... " section on Boolean blindness reminds me of the worst caricatures of left-wing narratives of oppression based on PhD-level Critical Theory. Look, a lot of the other patterns are interesting but I really think that if you are getting into criticising code because it has "Boolean blindness" you are probably getting a bit lost in navel gazing. Do you really have nothing be…

I work at a Haskell shop, and the overuse 'boolean blindness' issue has come up. The common understanding is that booleans are fine to use when the problem calls for it, just don't don't be afraid to use a more expressive data structure if that could make the code concise or understandable.

I think the real "boolean blindless" is something that happens in beginners, who don't yet understand that ADTs can be a rich modeling language, and instead use (Bool, Bool, Bool, Bool) when some combination of product and sum types is better.

Re: Haskell Mini-Patterns Handbook

#23
post #16

The whole "this code is problematic because... " section on Boolean blindness reminds me of the worst caricatures of left-wing narratives of oppression based on PhD-level Critical Theory. Look, a lot of the other patterns are interesting but I really think that if you are getting into criticising code because it has "Boolean blindness" you are probably getting a bit lost in navel gazing. Do you really have nothing be…

Hearty lol here. How do you associate some advice to use the type system to explain the meaning of your booleans to left-wing narratives of oppression? Or are you conflating booleans with black/white and arguing for colour blindness because All Bools Matter or something? I can't really make sense of this.

[deleted]

Re: Haskell Mini-Patterns Handbook

#25
This is a great post, I’ve seen a lot of those patterns before and it’s nice to have them in one place! One criticism I have though is I’m not sure about the advantage of phantom types, it seems like boilerplate to me. I feel like generalized algebraic data types are a strictly better pattern to follow to solve the issue of restricting type variable bindings to specific types.

Re: Haskell Mini-Patterns Handbook

#27
post #25

This is a great post, I’ve seen a lot of those patterns before and it’s nice to have them in one place! One criticism I have though is I’m not sure about the advantage of phantom types, it seems like boilerplate to me. I feel like generalized algebraic data types are a strictly better pattern to follow to solve the issue of restricting type variable bindings to specific types.

Phantom types can be useful when modelling currency: the "implementation" stays the same but you want to avoid summing two different currencies by mistake.

https://ren.zone/articles/safe-money

Post reply on HN