I'm already doing almost all my LLM-assisted programming in Haskell, all the devops in check-heavy Nix, and starting to move everything into Dhall.

There's no way that Python written by LLMs will survive contact with Haskell written by LLMs in a standup competition.

One imagines the scope for this sort of thing goes very high in formality.

> There's no way that Python written by LLMs will survive contact with Haskell written by LLMs in a standup competition.

That's likely true for formal correctness.

But what about the disparity between python's large and mature ecosystem compared the skimpiness of Haskell's libraries? How is an LLM going to compensate for Haskell's lack of math, AI/ML, graphics, web, and other key infrastructures?

An LLM writing Haskell must produce new code where production-grade libraries don't exist, and that Haskell app will be bigger than python's. That Haskell app will be relatively unverified compared to an LLM-written python app, simply because all that missing library code is brand new and hasn't proven itself the real world.

What about the disparity in LLM training data across many application domains? Given little Haskell training data, an LLM will be more likely to hallucinate and will require more human iterations before producing a production-ready app.

> One imagines the scope for this sort of thing goes very high in formality.

Haskell's type system is great, but only as far as it goes.

Yeah, it makes me sad that the skill of LLMs at a language is directly proportional to the popularity of a language, which is itself inversely proportional to the formal guardrails placed on the language by a type system.

Serious question: Why not have it generate assembly?