{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidjrirltoalq6rume7kvxqpki5z2hpjqjatvyqlfrg7pq3ajjzug4",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mgrqsk2uywx2"
  },
  "path": "/t/yet-another-opinion-on-llms-hasufells-blog/13775#post_4",
  "publishedAt": "2026-03-11T08:21:24.000Z",
  "site": "https://discourse.haskell.org",
  "tags": [
    "gemini.md · GitHub"
  ],
  "textContent": "lortabac:\n\n> These tools (especially the most advanced models) can be incredibly helpful, not just for mechanical tasks. They can also help with reasoning, find subtle bugs, analyze data to spot patterns and correlations, brainstorm…\n\nYesterday I was investigating a bug in the GHC bindist configure and ran across an m4 macro:\n\n\n    # FPTOOLS_OVERRIDE_PLATFORM_FROM_BOOTSTRAP(platform,Platform)\n    # ----------------------------------\n    # Per the comment in FPTOOLS_OVERRIDE_PLATFORM_FROM_BOOTSTRAP's body, we\n    # need to sometimes replace inferred platforms with the bootstrap\n    # compiler's target platform.\n    AC_DEFUN([FPTOOLS_OVERRIDE_PLATFORM_FROM_BOOTSTRAP],\n    [\n        if test \"$bootstrap_target\" != \"\"\n        then\n            $1=$bootstrap_target\n            echo \"$1 platform inferred as: [$]$1\"\n        else\n            echo \"Can't work out $1 platform\"\n            exit 1\n        fi\n\n        $2[Arch]=`echo \"[$]$1\" | sed 's/-.*//'`\n        $2[Vendor]=`echo \"[$]$1\" | sed -e 's/.*-\\(.*\\)-.*/\\1/'`\n        $2[OS]=`echo \"[$]$1\" | sed 's/.*-//'`\n    ])\n\n\nAnd the call site:\n\n\n        if test \"$host_alias\" = \"\"\n        then\n            FPTOOLS_OVERRIDE_PLATFORM_FROM_BOOTSTRAP([host], [Host])\n        else\n            GHC_CONVERT_PLATFORM_PARTS([host], [Host])\n        fi\n\n\nSo if you don’t pass `--host` to configure it will infer it from `ghc +RTS --info`. But then it doesn’t synchronize it with the autoconf variables `host_os`, `host_cpu` and `host_vendor`, leading to subtle issues.\n\nMy first version of a patch had a bug:\n\n\n    --- a/m4/fptools_set_platform_vars.m4\n    +++ b/m4/fptools_set_platform_vars.m4\n    @@ -89,6 +89,13 @@ AC_DEFUN([FPTOOLS_OVERRIDE_PLATFORM_FROM_BOOTSTRAP],\n         $2[Arch]=`echo \"[$]$1\" | sed 's/-.*//'`\n         $2[Vendor]=`echo \"[$]$1\" | sed -e 's/.*-\\(.*\\)-.*/\\1/'`\n         $2[OS]=`echo \"[$]$1\" | sed 's/.*-//'`\n    +\n    +       # synchronize with the autotools variables, e.g.\n    +       # target_cpu = TargetPlatform\n    +       # etc.\n    +       $1[_cpu]=$2[Arch]\n    +       $1[_vendor]=$2[Vendor]\n    +       $1[_os]=$2[OS]\n     ])\n\n     # FPTOOLS_SET_PLATFORM_VARS(platform,Platform)\n\n\nKudos if you can spot it right away. I couldn’t, so I went ahead and asked Gemini what the problem with this patch is.\n\nIt kept telling me that `$1[_cpu]` doesn’t work, but `$2[Arch]` is fine on the left-hand side of these assignments, suggesting it’s actually the underscore that trips up the parser or whatever.\n\nHere’s an excerpt from the prompt: gemini.md · GitHub\n\nThis was utter nonsense. It also kept suggesting obscure solutions that involve `eval` and other things. It clearly doesn’t know basic m4 syntax and has no way of actually reasoning about it.\n\nThe problem with the patch was simply that it was missing an escaped dollar sign, so instead of `$1[_cpu]=$2[Arch]` I needed `$1[_cpu]=[$]$2[Arch]`. My brain was on autopilot, because I hate m4 and didn’t want to think about it. Then I wasted 15 minutes of my time arguing with Gemini and demanding an explanation why it thinks the underscore is the issue. It was extremely confident about it.\n\nlortabac:\n\n> The truth is, if you want to get useful results you need to sweat.\n\nYes, people keep telling me that I simply don’t know how to use LLMs correctly.\n\nMy guess is that most users would just have copy pasted the obscure code from Gemini and moved on instead of questioning why it came up with said code. And maybe it would have even worked.\n\nNo, I don’t think there’s any depth about interacting with LLMs.\n\nlortabac:\n\n> Your post dismisses all these capabilities a little too hastily.\n\nI don’t think so, because I provide criteria for what is “good use of LLMs”:\n\n  1. when you can trivially verify the output, or\n  2. when you have superior domain knowledge, or\n  3. when you don’t need precise answers\n\n\n\nIn my experience though, this is not how people use them, because this indeed takes effort. And then the gains are not as big anymore.",
  "title": "Yet another opinion on LLMs · Hasufell's blog"
}