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

201–210 of 304 posts

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

#201

Post by jbritton »

kleiba wrote: post #16

I cannot read light on black. I don't know, maybe it's a condition, or simply just part of getting old. But my eyes physically hurt, and when I look up from reading a light-on-black screen, even when I looked at only for a short moment, my eyes need seconds to adjust again. I know dark mode is really popular with the youngens but I regularly have to reach for reader mode for dark web pages, or else I simply cannot st…

I find dark mode much easier to read and far less eye strain. I guess it just shows that users should be the ones to set the preference. There are studies on monkeys showing light mode leading to myopia. Although lately I have come to learn there are lots of poorly done studies.

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

#202

Post by cube2222 »

This is actually... pretty cool?

Definitely won't use it for prod ofc but may try it out for a side-project.

It seems that this is more or less:

  - instead of modules, write specs for your modules
  - on the first go it generates the code (which you review)
  - later, diffs in the spec are translated into diffs in the code (the code is *not* fully regenerated)
this actually sounds pretty usable, esp. if someone likes writing. And wherever you want to dive deep, you can delve down into the code and do "microoptimizations" by rolling something on your own (with what seems to be called here "mixed projects").

That said, not sure if I need a separate tool for this, tbh. Instead of just having markdown files and telling cause to see the md diff and adjust the code accordingly.

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

#203

Post by jaredklewis »

THe HN title seems very misleading to me. How is this, in any sense of the word, "formal?" I don't see that particular word used to describe this tool on the web page itself.

The site does describe it as a "programming language," which feels like a novel use of the term to me. The borders around a term like "programming language" are inherently fuzzy, but something like "code generation tool" better describes CodeSpeak IMHO.

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

#204

Post by Garlef »

I think this is 100% the right direction:

Instead of imperatively letting the agents hammer your codebase into shape through a series of prompts, you declare your intent, observe the outcome and refine the spec.

The agents then serve as a control plane, carrying out the intent.

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

#206

Post by photios »

phyzix5761 wrote: post #198
photios wrote: post #195

> codespeak login Instant tab close!

Huh? I don't see a login. All the code examples and set up instructions are available to anyone visiting the page.

It's in the Quickstart article here:

https://codespeak.dev/blog/greenfield-project-tutorial-20260...

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

#207

Post by raw_anon_1111 »

xpe wrote: post #192
raw_anon_1111 wrote: post #175

Earlier quoted context omitted.

Are you as a developer 100% able to trust that you didn’t miss anything? Your team if you are a team lead who delegates tasks to other developers? If you outsource non business things like Salesforce integrations etc do you know all of the code they wrote? Your library dependencies? Your infrastructure providers?

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.

For instance, I haven’t done web development since 2002 except for a little copy and paste work. I completely vibe coded three internal web admin sites for separate projects and used Amazon Cognito for authentication. I didn’t look at a line of code that AI generated any more than I would have looked at a line of code for a website I delegated to the web developer. I cared about functionality and UX.

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

#208

Post by nyrikki »

pron wrote: post #143
vidarh wrote: post #139

Earlier quoted context omitted.

The point would presumably be to formalise it, then verify that the formal version matches what you actually meant . At which point you can't/shouldn't regenerate it, but you can request changes (which you'd need to verify and approve).

But the code produced from the formal spec would still be nondeterministic. And I believe CodeSpeak doesn't wish to regenerate the entire program with each spec change, but apply code changes based on the changes to the spec. Maybe there could be other benefits to formalisation in this case, but determinism isn't one of them.

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-nets[0] but in general petri-net reachability is Ackerman-complete [1]

It is just the trade off of using a context free like system like an LLM with natural language.

HoTT and how dependent types tend to break isomorphic ≃ equal Is another possible lens.

[0] https://arxiv.org/abs/2212.02754v3

[1] https://arxiv.org/abs/2212.02754v3

[2] https://arxiv.org/abs/2407.20822

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

#209

Post by abreslav »

newsoftheday wrote: post #77
abreslav wrote: post #56

Earlier quoted context omitted.

> The limitation seems to be that you can't modify the code yourself if you want the spec to reflect it Eventually, we'll end up in a world where humans don't need to touch code, but we are not there yet. We are looking into ways to "catch up" the specs with whatever changes happen in the code not through CodeSpeak (agents or manual changes or whatever). It's an interesting exercise. In the case of agents, it's very…

> Eventually, we'll end up in a world where humans don't need to touch code, but we are not there yet. Will we though? Wouldn't AI need to reach a stage where it is a tool, like a compiler, which is 100% deterministic?

Two things to mention here:

1. You are right that we can redefine what is code. If code is the central artefact that humans are dealing with to tell machines and other humans how the system works, then CodeSpeak specs will become code, and CodeSpeak will be a compiler. This is why I often refer to CodeSpeak as a next-level programming language.

2. I don't think being deterministic per se is what matters. Being predictable certainly does. Human engineers are not deterministic yet people pay them a lot of money and use their work all the time.

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

#210

Post by abreslav »

my_throwaway23 wrote: post #144
intrasight wrote: post #88

Earlier quoted context omitted.

We will and soon because it does not have to be deterministic like a compiler. It only has to pass all tests.

Who is writing the tests?

There are different kinds of tests:

* regression tests – can be generated

* conformance tests – often can be generated

* acceptance tests – are another form of specification and should come from humans.

Human intent can be expressed as

* documents (specs, etc)

* review comments, etc

* tests with clear yes/no feedback (data for automated tests, or just manual testing)

And this is basically all that matters, see more here: https://www.linkedin.com/posts/abreslav_so-what-would-you-sa...

Post reply on HN