{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidprslnzop4ecgmdfxophmwgrxeoc2sfk4ua4ie2ehxtx5mhn5oqa",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mlioqtrkdmi2"
  },
  "path": "/t/is-there-an-idiomatic-haskell/14042#post_7",
  "publishedAt": "2026-05-10T11:35:13.000Z",
  "site": "https://discourse.haskell.org",
  "tags": [
    "this Java-to-Haskell case study"
  ],
  "textContent": "My first thought, as others have said, is there isn’t as much of a drama with Haskell as other languages. There’s no ‘design patterns’ compendium, for example.\n\nOTOH, there’s certainly newbie code I would (and have) described as unidiomatic. See Stackoverflow `[Haskell] {not |un}idiomatic`.\n\nTelltales include too much nested `if then else ` rather than `case | `guards; few curried definitions; over-use of Lists; …\n\nA useful discussion example might be this Java-to-Haskell case study. My feeling is both of the Haskell approaches seem too Java-y(?)\n\nThat the code is no shorter isn’t really the point. Using advanced List functions like `intersperse` is rather cheating (and `intercalate` smuggles in a `concat`, with embarrassingly bad performance).\n\nAlong the same lines as that Layer Cake piece, there isn’t clear separation of the ‘business logic’ (a triangular array) vs the human-readable prettifying vs the IO.",
  "title": "Is there an idiomatic Haskell?"
}