{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreieczdu7paumj7fgstiewtac23i6sxhxxcsr6cy5yofpuqg6igiibu",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mlaupojsbda2"
  },
  "path": "/t/is-there-an-idiomatic-haskell/14042#post_6",
  "publishedAt": "2026-05-07T09:10:50.000Z",
  "site": "https://discourse.haskell.org",
  "tags": [
    "Parse, don’t validate",
    "Three Layer Haskell Cake",
    "Kowainik’s guide"
  ],
  "textContent": "I’ll share some things we kept in mind or adhered to in the last Haskell job I had.\n\nFirst of all, the following are (almost) required reading for anyone starting serious Haskell projects:\n\n  * Parse, don’t validate: Parse, don’t validate\n  * Three-layer Haskell cake: Three Layer Haskell Cake\n\n\n\nKeep in mind that these are obviously not rules set in stone, you should adapt to your situation.\n\n* * *\n\nWhen working with other (Haskell) programmers on the same project, having a set of guidelines makes everyone’s life easier. The point is not to please everyone, but to have the code be predictable for everyone.\n\n  * Use a style guide (e.g. we used Kowainik’s guide with our own tweaks)\n  * Decide on an automatic formatter (doesn’t matter which, just pick one. We used `fourmolu`)\n    * Maybe even enforce the format in your CI/CD (but do make sure everyone uses the same version in that case)\n\n\n\nNot much else I can add; great thing about strong typing is that you can refactor “relatively” easily, so if you change your mind or the requirements change, refactoring isn’t such a set-back.\n\n* * *\n\nAll in all, I wish you the best of luck in your endeavors, and when in doubt just ask fellow Haskellers more specific questions. Like, “which package should I use [in my current situation] to achieve [insert specific goal]?”",
  "title": "Is there an idiomatic Haskell?"
}