Ask HN: Do we need a language designed specifically for AI code generation?

4 pointsbaijum9mo ago9 comments

Let's run a thought experiment. If we were to design a new programming language today with the primary goal of it being written by an AI (like Copilot) and reviewed by a human, what would its core features be?

My initial thoughts are that we would trade many of the conveniences we currently value for absolute, unambiguous clarity. For example:

- Would we get rid of most syntactic sugar? If there's only one, explicit way to write a `for` loop, the AI's output becomes more predictable and easier to review.

- Would we enforce extreme explicitness? Imagine a language where you must write `fn foo(none)` if there are no parameters, just to remove the ambiguity of `()`.

- How would we handle safety? Would features like mandatory visibility (`pub`/`priv`) and explicit ownership annotations for FFI calls become central to the language itself, providing guarantees the reviewer can see instantly?

- Would such a language even be usable by humans for day-to-day work, or would it purely be a compilation target for AI prompts?

What trade-offs would you be willing to make for a language that gave you higher confidence in the code an AI generates?

9 comments

dtagames9mo ago

LLMs don't work the way you think. In order to be useful, a model would have to be trained on large quantities of code written in your new language, which don't exist.

Even after that, it will exhibit all the same problems as existing models and other languages. The unreliability of LLMs comes from the way they make predictions, rather than "retrieve" real answers, like a database would. Changing the content and context (your new language) won't change that.

baijumOP9mo ago

That's a very fair and critical point. You're right that we can't change the fundamental, probabilistic nature of LLMs themselves.

But that makes me wonder if the goal should be reframed. Instead of trying to eliminate errors, what if we could change their nature?

The interesting hypothesis to explore, then, is whether a language's grammar can be designed to make an LLM's probabilistic errors fail loudly as obvious syntactic errors, rather than failing silently as subtle, hard-to-spot semantic bugs.

For instance, if a language demands extreme explicitness and has no default behaviors, an LLM's failure to generate the required explicit token becomes a simple compile-time error, not a runtime surprise.

So while we can't "fix" the LLM's core, maybe we can design a grammar that acts as a much safer "harness" for its output.

dtagames9mo ago

I would say we have this language already, too. It's machine code or its cousin, assembler. Processor instructions (machine code) that all software reduces down to are very explicit and have no default values.

The problem is that people don't like writing assembler, which is how we got Fortran in the first place.

The fundamental issue, then, is with the human language side of things, not the programming language side. The LLM is useful because it understands regular English, like "What is the difference between 'let' and 'const' in JS?," which is not something that can be expressed in a programming language.

To get the useful feature we want, natural language understanding, we have to accept the unreliable and predictive nature of the entire technique.

FloatArtifact9mo ago

What I've always been confused on, why can't we train LLMs to code without ever seeing source code?

If it understands human language enough, it should be able to understand the logic laid out in the documentation mapped to symbols to construct code.

dtagames9mo ago

We have this already. You can ask Cursor to go read the doc on syntax it may not have ever seen and write something that conforms. I used this recently to support a new feature in Lit which I'd never seen before and I doubt is in the training set much, if at all.

You can also describe your own app's syntax, architecture, function signatures, etc. in markdown files or just in chat and Cursor will write code that conforms to your desired syntax, which definitely doesn't exist in the training set.

2 more replies

theGeatZhopa9mo ago

What's needed is a formalization and that formalization to been trained on. In not sure if systemprompt alone is powerful enough to check and enforce input as definite and exact formalized expression(s).

I don't think it will work out easily like "a programming language for LLM" - but you can always have a discussion with ol' lama

muzani9mo ago

Generally they work better with words that are more easily readable by humans. They have a lot of trouble with JSON and do YAML much better, for example. Running through more tokens doesn't just increase cost, it lowers quality.

So they'd likely go the other way. It's like how spoken languages have more redundancies built in.

j / k navigate · click thread line to collapse

Ask HN: Do we need a language designed specifically for AI code generation?

4 pointsbaijum9mo ago9 comments

My initial thoughts are that we would trade many of the conveniences we currently value for absolute, unambiguous clarity. For example:

- Would we get rid of most syntactic sugar? If there's only one, explicit way to write a `for` loop, the AI's output becomes more predictable and easier to review.

- Would we enforce extreme explicitness? Imagine a language where you must write `fn foo(none)` if there are no parameters, just to remove the ambiguity of `()`.

- Would such a language even be usable by humans for day-to-day work, or would it purely be a compilation target for AI prompts?

What trade-offs would you be willing to make for a language that gave you higher confidence in the code an AI generates?

9 comments

dtagames9mo ago

LLMs don't work the way you think. In order to be useful, a model would have to be trained on large quantities of code written in your new language, which don't exist.

baijumOP9mo ago

That's a very fair and critical point. You're right that we can't change the fundamental, probabilistic nature of LLMs themselves.

But that makes me wonder if the goal should be reframed. Instead of trying to eliminate errors, what if we could change their nature?

So while we can't "fix" the LLM's core, maybe we can design a grammar that acts as a much safer "harness" for its output.

dtagames9mo ago

The problem is that people don't like writing assembler, which is how we got Fortran in the first place.

To get the useful feature we want, natural language understanding, we have to accept the unreliable and predictive nature of the entire technique.

FloatArtifact9mo ago

What I've always been confused on, why can't we train LLMs to code without ever seeing source code?

If it understands human language enough, it should be able to understand the logic laid out in the documentation mapped to symbols to construct code.

dtagames9mo ago

2 more replies

theGeatZhopa9mo ago

I don't think it will work out easily like "a programming language for LLM" - but you can always have a discussion with ol' lama

muzani9mo ago

So they'd likely go the other way. It's like how spoken languages have more redundancies built in.

j / k navigate · click thread line to collapse