Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kotlin creator's new language: talk to LLMs in specs, not English

codespeak.dev

Post reply on HN
Print view View original

291–300 of 304 posts

Re: Kotlin creator's new language: talk to LLMs in specs, not English

#291

Post by jason_oster »

reverius42 wrote: post #266
discreteevent wrote: post #243

Earlier quoted context omitted.

> It IS a compiler. What are you talking about? If an LLM is a compiler, then I'm a compiler. Are we going to redefine the meaning of words in order not to upset the LLM makers?

Originally, the word "computer" referred to a human being. See https://en.wikipedia.org/wiki/Computer_(occupation) Over time, when digital computers became commonplace, the computing moved from the person to the machine. At this time, arguably the humans doing the programming of the machine were doing the work we now ask of a "compiler". So yes, an LLM can be a compiler in some sense (from a high level abstract langu…

I don't know, having done a lot of completely pointless time-wasting staring at hex dumps and assembly language in my youth was a pretty darned good lesson. I say it's a worthwhile hobby to be a compiler.

But your point stands. There is a period beyond which doing more than learning the fundamentals just becomes toil.

Re: Kotlin creator's new language: talk to LLMs in specs, not English

#292

Post by jason_oster »

CWIZO wrote: post #174
vbezhenar wrote: post #111

Earlier quoted context omitted.

Compiler is not 100% deterministic. Its output can change when you upgrade its version, its output can change when you change optimization options. Using profile-guided optimization can also change between runs.

If you change inputs then obviously you will get a different output. Crucially using the same inputs, however, produces the same output. So compilers are actually deterministic.

This is irrelevant over the long run because the environment changes even if nothing else does. A compiler from the 1980's still produces identical output given the original source code if you can run it. Some form of virtualization might be in order, but the environment is still changing while the deterministic subset shrinks.

Having faith that determinism will last forever is foolish. You have to upgrade at some point, and you will run into problems. New bugs, incompatibilities, workflow changes, whatever the case will make the determinism property moot.

Re: Kotlin creator's new language: talk to LLMs in specs, not English

#293

Post by mike_hearn »

CWIZO wrote: post #174
vbezhenar wrote: post #111

Earlier quoted context omitted.

Compiler is not 100% deterministic. Its output can change when you upgrade its version, its output can change when you change optimization options. Using profile-guided optimization can also change between runs.

If you change inputs then obviously you will get a different output. Crucially using the same inputs, however, produces the same output. So compilers are actually deterministic.

Many compilers aren't deterministic. That's why the effort to make Linux distros have reproducible builds took so long and so much effort.

The reason is, it's often more work to be deterministic than not deterministic, so compilers don't do it. For example, they may compile functions in parallel and append them to the output in the order they complete.

Re: Kotlin creator's new language: talk to LLMs in specs, not English

#294

Post by mike_hearn »

rebolek wrote: post #78
davedx wrote: post #35

Earlier quoted context omitted.

My process has organically evolved towards something similar but less strictly defined: - I bootstrap AGENTS.md with my basic way of working and occasionally one or two project specific pieces - I then write a DESIGN.md. How detailed or well specified it is varies from project to project: the other day I wrote a very complete DESIGN.md for a time tracking, invoice management and accounting system I wanted for my free…

AGENTS.md is nice but I still need to remind models that it exists and they should read it and not reinvent the wheel every time.

Are you sure? If so then your harness is doing something wrong. AGENTS.md doesn't need to be read deliberately by the model, it forms part of the starting prompt.

Re: Kotlin creator's new language: talk to LLMs in specs, not English

#295

Post by uoaei »

raw_anon_1111 wrote: post #207
xpe wrote: post #192

Earlier quoted context omitted.

It seems like ^ and ^^ agree to me. Am I missing something?

I don’t know. I’m making a point that the only people whose sole responsibility is code that they personally write are mid level ticket takers. I don’t review every line of code by everyone whose output I’m responsible for, I ask them to explain how they did things and care about their testing, the functional and non functional requirements and hotspots like concurrency, data access patterns, architectural issues etc…

The difference is that you have theory of mind of your human counterparts -- you can trust that their reasoned explanations are consistent with what you know about them.

I have not encountered an agent yet that I can trust in the same way.

Re: Kotlin creator's new language: talk to LLMs in specs, not English

#296

Post by raw_anon_1111 »

uoaei wrote: post #295
raw_anon_1111 wrote: post #207

Earlier quoted context omitted.

I don’t know. I’m making a point that the only people whose sole responsibility is code that they personally write are mid level ticket takers. I don’t review every line of code by everyone whose output I’m responsible for, I ask them to explain how they did things and care about their testing, the functional and non functional requirements and hotspots like concurrency, data access patterns, architectural issues etc…

The difference is that you have theory of mind of your human counterparts -- you can trust that their reasoned explanations are consistent with what you know about them. I have not encountered an agent yet that I can trust in the same way.

You give way too much credit to mid level developers and outsourced contractors….

Re: Kotlin creator's new language: talk to LLMs in specs, not English

#297

Post by nyrikki »

pron wrote: post #255
nyrikki wrote: post #208

Earlier quoted context omitted.

Even with classic compilation, it is only the semantic behavior that is preserved. What the Church–Rosser property/confluence is in term rewriting in lambda calculus is a possible lens. To have a formally verified spec, one has to use some decidable fragment of FO. If you try to replace code generation with rewriting things can get complicated fast.[2] Rust uses affine types as an example and people try to add petri-…

First, it's not a question of decidability but of tractability. Verifying programs in a language that has nothing but boolean variables, no subroutines, and loops at depth of at most 2 - far, far, from Turing-completeness - is already intractable (reduction from TQBF). Second, it's very easy to have some specs decided tractably, at least in many practical instances, but they are far too weak to specify most correctne…

I think there is a bit of the map territory relation here.

> First, it's not a question of decidability but of tractability

The question of decidability is a form of many-to-one, reduction. In fact RE-complete is defined by many-to-one reductions.

In a computational complexity sense, tractability is a far stronger notion. Basically an algorithm efficient if its time complexity at most PTIME for any size n input. A problem is "tractable" if there is an efficient algorithm that solves it.

You are correct, if you limit your expressiveness to PTIME, where because P == co-P, PEM/tight apartness/Omniscience principles hold.

But the problem is that Church–Rosser Property[0] (proofs ~= programs) and Brouwer–Heyting–Kolmogorov Interpretation[1] (Propositions at types) are NOT binary SAT, and you have concepts like mere propositions[3] that are very different than just BSAT.

But CodeSpeak doesn't have formal specifications, so this is irrelevant. Their example code output produced code with path traversal/resource exhaustion risks and correctness issues and is an example.

My personal opinion is that we will need to work within the limitations of the systems, and while it is trivial to come up with your own canary, I would recommend playing with [3] before the models directly target it.

Generating new code from a changed spec will be less difficult, specifically when the mess of real world specs comes into play. You can play with the example on CodeSpeak's front page, trying to close the various holes the software has with malformed/malicious input, giving the LLM the existing code base and you will see that "brown m&m"[3] problem arise quickly. At least for me if I prompt it to look at the changed natural language spec, generating new code it was more successful.

But for some models like the qwen3 coder next, the style resulted in far less happy path protections, which that model seems to have been trained on to deliver by default in some cases.

[0] https://calhoun.nps.edu/entities/publication/015f1bab-6642-4... [1] https://www.cs.cornell.edu/courses/cs6110/2017sp/lectures/le... [2] https://www.cambridge.org/core/journals/journal-of-functiona... [3] https://codemanship.wordpress.com/2025/10/03/llms-context-wi...

Re: Kotlin creator's new language: talk to LLMs in specs, not English

#298

Post by jasfi »

sethev wrote: post #226
stephbook wrote: post #221

> It’s one of those things that crackpots keep trying to do, no matter how much you tell them it could never work. If the spec defines precisely what a program will do, with enough detail that it can be used to generate the program itself, this just begs the question: how do you write the spec? Such a complete spec is just as hard to write as the underlying computer program, because just as many details have to be an…

Program generation from a spec meant something vastly different in 2007 than it does now. People can and are generating programs from underspecified prompts. Trying to be systematic about how prompts work is a worthwhile area to explore.

I've built an AI compiler that has my take on this: https://github.com/jfilby/intentcode

Re: Kotlin creator's new language: talk to LLMs in specs, not English

#299

Post by stephbook »

sethev wrote: post #226
stephbook wrote: post #221

> It’s one of those things that crackpots keep trying to do, no matter how much you tell them it could never work. If the spec defines precisely what a program will do, with enough detail that it can be used to generate the program itself, this just begs the question: how do you write the spec? Such a complete spec is just as hard to write as the underlying computer program, because just as many details have to be an…

Program generation from a spec meant something vastly different in 2007 than it does now. People can and are generating programs from underspecified prompts. Trying to be systematic about how prompts work is a worthwhile area to explore.

Why don't you simply point your agent to your Jira tickets? It's easier than paying another third party for their magic LLM incantation loop.

Re: Kotlin creator's new language: talk to LLMs in specs, not English

#300

Post by cindyllm »

stephbook wrote: post #299
sethev wrote: post #226

Earlier quoted context omitted.

Program generation from a spec meant something vastly different in 2007 than it does now. People can and are generating programs from underspecified prompts. Trying to be systematic about how prompts work is a worthwhile area to explore.

Why don't you simply point your agent to your Jira tickets? It's easier than paying another third party for their magic LLM incantation loop.

[dead]
Post reply on HN