Evil Haskell Tips

Some things are too evil even for me

RT @mwotton:

Ugh, wish I’d have thunk of this one

@defnotbeka @CarlHedgren 🔥 Now I want a dialect of Haskell written this way. Gruntskell?

@CarlHedgren @EvilHaskellTips treely

“Semigroup” and “Monoid” are exclusionary terminology. Prefer “smashy-smashy” and “smashy-smashy-with-extra-nothing”.

Create a Brobdingnagian monstrosity of 1.2m lines of Haskell. That way, the tooling you create to make working on it tolerable will be practically instant on codebases that don’t need 18 lanes for a 3 point turn. (With love and appreciation, @mercury)

@yandereidiot The account isn’t called @preciseandcarefulhaskelltips Emily

@CarlHedgren Frankly in my day to day as a Haskell dev I don’t call it anything at all

@EvilHaskellTips But what do you call a magma then?

@kerckhove_ts This does have the flavour of “an ethical engineer would never write a procedure ‘destroyBaghdad’ - it should take a city as a parameter”

@EvilHaskellTips Can't be evil if you don't write your evil code correctly :P

Tired of probabilistic correctness guarantees? instance Arbitrary UUID where … shrink uuid = case UUID.toWords uuid of (a,b,c,d) -> [UUID.fromWords a' b' c' d' | a' <- sw a, b' <- sw b, c' <- sw c, d' <- sw d] where sw w = take 10 $ iterate (`div` 2) w

@kerckhove_ts True. And if we must be evil, we ought to at least be efficient.

@EvilHaskellTips This will generate an unreasonable number of the same UUID values for small word values. You want to filter out the extra zero values in `sw`, I think.

Do as thou wilt shall be the whole of the Law, and the type system is really just a suggestion.

Performance tip: s/sequence/mapConcurrently/g Good code can be run in any order.

The great thing about using Haskell with LLMs is that you can be absolutely precise about the nonsense you are ingesting and emitting.

@DRMacIver has pointed out that Hypothesis will report all the assertions that fail rather than just the first. A decadent affordance to be avoided by the faithful.

Yes, it will be extremely difficult to follow what's going on as the counterexample-finding algorithm dances between the different assertions. This is by design, and will help you back into the divine light of Writing Correct Code The First Time.

Testing is for programmers lacking the moral fibre to prove every useful property about their code in the type system.

If you're writing a parser for some type t, one fun thing to omit is a way to turn it back into a string. Easy visualisation, canonicalisation and roundtrip properties are for people who insist on putting bugs in their code and there is no reason to coddle them.