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

Haskell Mini-Patterns Handbook

kowainik.github.io

Post reply on HN
Print view View original

11–20 of 34 posts

Re: Haskell Mini-Patterns Handbook

#11

Post by glutamate »

uryga wrote: post #9
glutamate wrote: post #7

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…

do you have any criticisms with actual substance? why do you consider those techniques "navel gazing"?

I really feel that too many rules like this lead beginners astray and focus on issues that make very little difference in delivering a product.

If beginners see a list like this, and start re-factoring the code to remove "Boolean blindness", that's likely not the best way for them to spend their time and the code may become more verbose in the process.

I prefer not to dwell on negativity about code, as long as it does the job and is implemented in a reasonably simple manner. I think in the Haskell community sometimes there can be an unhealthy tendency to nitpick the implementation details.

Re: Haskell Mini-Patterns Handbook

#13

Post by ffreire »

glutamate wrote: post #11
uryga wrote: post #9

Earlier quoted context omitted.

do you have any criticisms with actual substance? why do you consider those techniques "navel gazing"?

I really feel that too many rules like this lead beginners astray and focus on issues that make very little difference in delivering a product. If beginners see a list like this, and start re-factoring the code to remove "Boolean blindness", that's likely not the best way for them to spend their time and the code may become more verbose in the process. I prefer not to dwell on negativity about code, as long as it doe…

I wouldn't consider them rules inasmuch as they're things to keep in mind when working in a Haskell codebase, in much the same way GoF has been useful for OO programmers for decades.

Can you write code without using a pattern from GoF? Sure. Will it work? Probably. Does that make GoF useless? No, I'd think not. This type of content is immensely valuable for beginner and practitioner alike because it starts to build a shared language with which to talk about how codebases are organized :)

Re: Haskell Mini-Patterns Handbook

#14

Post by ookdatnog »

glutamate wrote: post #7

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 recommend reading this article that's linked in the evidence section: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

Re: Haskell Mini-Patterns Handbook

#15

Post by alephu5 »

glutamate wrote: post #11
uryga wrote: post #9

Earlier quoted context omitted.

do you have any criticisms with actual substance? why do you consider those techniques "navel gazing"?

I really feel that too many rules like this lead beginners astray and focus on issues that make very little difference in delivering a product. If beginners see a list like this, and start re-factoring the code to remove "Boolean blindness", that's likely not the best way for them to spend their time and the code may become more verbose in the process. I prefer not to dwell on negativity about code, as long as it doe…

As a beginner you're just trying to keep your head above water and get the damn thing to compile. For me at least I cared more about that than making the code pretty.

Moreover I don't see much harm refactoring your code with these patterns and maybe losing time, because most people learn haskell off the job.

Re: Haskell Mini-Patterns Handbook

#16

Post by ljm »

glutamate wrote: post #7

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.

Re: Haskell Mini-Patterns Handbook

#17

Post by Gajurgensen »

glutamate wrote: post #7

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…

That's an awfully long-winded and confusing way to say you think "Boolean blindness" is too nitpicky. Personally, it seems like a pretty valid idea to keep in mind, especially as developers transition from a conventional imperative language to Haskell. Making frequent boolean checks is pretty normal in that space, and pattern matching is less common, which might lead new Haskell programmers to write unidiomatic code.

Re: Haskell Mini-Patterns Handbook

#18

Post by mrkeen »

glutamate wrote: post #7

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…

Avoiding boolean blindness is not just a Haskell concept.

https://martinfowler.com/bliki/FlagArgument.html

https://medium.com/@amlcurran/clean-code-the-curse-of-a-bool...

Post reply on HN