
Haskell Mini-Patterns Handbook - gluegadget
https://kowainik.github.io/posts/haskell-mini-patterns
======
whateveracct
This is great. I can say I've used and encountered literally all of these
techniques many times in every Haskell codebase I've joined and built.

The concise cost/benefit analysis very helpful.

------
misja111
This is a gem. I have been looking for this kind of clear and to the point
explanations of common Haskell patterns for a long time.

------
chrischen
These patterns are not only applicable to Haskell but FP and programming in
general. I am using them with a Typescript codebase.

------
mlazos
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.

~~~
chriswarbo
I introduced phantom types to a codebase recently, although it was Scala
rather than Haskell. The code was using arrays of bytes, where:

\- Some contain plaintext, some contain ciphertext

\- Some contain keys, some contain data

\- The keys themselves exist in plaintext and ciphertext forms (data keys
generated by AWS KMS)

\- Some keys were used for signing/verifying, some were used for
encrypting/decrypting

\- Some arrays contain Base64 data (for embedding in JSON), some contain
unencoded data

Using 'Array[Byte]' would work, but would be error-prone. Using distinct types
or wrappers like 'Base64[Plaintext[Key[Signing]]]' would require lots of extra
definitions, and wrapping/unwrapping scattered around the code. Phantom types
let me use type signatures with the right amount of specificity and
polymorphism as needed, whilst the code itself was the 'straightforward'
version without wrapping/unwrapping.

------
jbawn
Thanks for this. The tasks are a nice touch!

------
hackingthenews
Anyone else have trouble with the page on firefox? I get a giant "kowainik"
written on the forefront of the page, and I don't know how to close it.

~~~
jjjbokma
I am using Firefox and it works without problems. 79.0 on macOS Mojave.

------
johnisgood
I do not write Haskell, but this is a neat site.

------
gowld
This is a beautiful start but much more content. Send PRs to kowainik.

------
johndoe42377
The most deadly sin with Haskell is introducing unnecessary redundant
abstractions to impress other people.

Imagine aircraft engineers will do that.

Up to (but not including) NonEmpty lists everything was fine.

~~~
whateveracct
> Up to (but not including) NonEmpty lists everything was fine.

"but not including" how in the world is NonEmpty redundant abstraction?

------
glutamate
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
better to do?

~~~
ljm
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.

