upvote
I'm wondering the inverse, actually. That LLMs can make regular haskell programming (e.g. typing in code, not english that LLMs convert to code) powerful enough to prefer. Can we have LLMs do enough of the grunt work on building type machinery, dealing with compiler errors, looking up exact types and conversion systems, to make the APIs presented to us preferable?

So, I could write what I want in haskell, and it's faster for me than to have an LLM do it. The haskell would be high-level enough and precise enough to describe what I want the program to do with less iterations than I'd have with an LLM writing code, finding its own bugs, fixing them, then having me ask it what it did, tell it what to do differently, etc.

Direct control is very powerful. LLMs take that away from us, in exchange for a great speedup. But perhaps we can use LLMs to give it back to us by making our actual programming languages more powerful.

reply
Yeah, I think this is roughly where things are headed. Or at least, it's part of what I'm working on these days, though I'd characterize myself as "generally kind of bad at things," so maybe that's anti-signal.

But I think this is actually in the design of many languages already, especially in languages like Lean, where you can prove that the presentable API is correct.

Here's one rough example that is related to this direction:

A common convention in Lean is to write essentially two versions of a function, with a theorem proving their equality or correspondence.

So you can write a more demonstrative version that is more easily understood, which you can treat sort of as a spec that all other implementations must satisfy. And then you can set the agent loose to do whatever nastiness it wants to do to improve performance.

Here's a fun write up from someone doing just this with zip file compression: https://kim-em.github.io/blog/2026-7-24-why-lean-is-faster-t...

reply
> I think you're spiritually correct that there are lots of reasons to use extremely strict languages with AI

> With dynamic languages where the model has a ton of training data, like Python, the agents are really good at writing code that just works.

I'm confused how the former supports the latter here.

Surely, you mean that LLMs are not the right kind of "AI". Languages like Haskell expose how fundamentally porous LLMs are with information.

I wouldn't even say it's the dynamic nature of Python that leads to good results, but the consistency. Javascript is the obvious counterexample. There's far more javascript out there to train on than any other programming language, yet LLMs are terrible at writing it too.

reply
Just reading chain of thought traces for Agda (I'm using Qwen 3.8-Flash-Next) and it's struggling so hard with just the syntax, long before it can struggle with semantics or type errors.

Admittedly I'm not much better, Agda has some crazy scoping rules at times and its operators are a mess, so much worse than Haskell, but at least I don't have to re-learn from scratch after every compaction.

reply
Yeah I know this pain. I actually have had some success by giving the agent a style guide for Lean that is strictly not conventional. The nice syntactic shortcuts and different modes that make Lean more ergonomic for humans, in my experience, actually make it easier for an agent to trip itself up.
reply