zlacker

>>tehnub+(OP)
I'm biased by my preferred style of programming languages but I think that pure statically typed functional languages are incredibly well suited for LLMs. The purity gives you referential transparency and static analysis powers that the LLM can leverage to stay correctly on task.

The high level declarative nature and type driven development style of languages like Haskell also make it really easy for an experienced developer to review and validate the output of the LLM.

Early on in the GPT era I had really bad experiences generating Haskell code with LLMs but I think that the combination of improved models, increased context size, and agentic tooling has allowed LLMs to really take advantage of functional programming.

>>solomo+sk
I'm inclined to agree with you in principle, but there's much, much less Haskell examples in their training corpus than for JavaScript or Python.

>>eru+bl
True for now, but probably not a durable fact. Synthetic data pipelines should be mostly invariant to the programming language, as long as the output is correct. If anything the additional static analysis makes it more amenable to synthetic data generation.

>>energy+ju
> Synthetic data pipelines should be mostly invariant to the programming language, as long as the output is correct.

Well, you can adapt your PHP producing pipeline to produce Haskell code that is correct in the sense of solving the problem at hand, but getting it to produce idiomatic code is probably a lot harder.

>>eru+Du
I think the trick with Haskell is that you can write types in such a way that the APIs that get generated are idiomatic and designed well. The implementations of individual functions might be messy or awkward, but as long as those functions are relatively small—which is how I tend to write my non-AI-based Haskell code anyhow!—it's not nearly as important.