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

271–280 of 304 posts

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

#271

Post by antonvs »

James_K wrote: post #239
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…

import Mathlib def Goldbach := ∀ x : ℕ, Even x → x > 2 → ∃ (y z: ℕ), Nat.Prime y ∧ Nat.Prime z ∧ x = y + z A short specification for the proof of the Goldbach conjecture in Lean. Much harder to implement though. Implementation details are always hidden by the interface, which makes it easier to specify than produce. The Curry-Howard correspondence means that Joel's position here is that any question is as hard to ask…

    theorem goldbach : Goldbach := *message truncated*

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

#272

Post by pjmlp »

ekropotin wrote: post #263
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…

I’m actually start seeking at work how people are writing skills in a very procedural manner. Something like: First, collect the following information from user: …. Second, send http request to the following endpoint with the certain payload…. If server returned error - report back to user. It makes me crack every time I see that kind of stuff. Why on Earth you won’t just write a script for that purpose? 10x faster,…

Because then you cannot meet the KPIs of using AI tools on the job. /s

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

#273

Post by akvadrako »

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 don't see how it's different. You could always describe what you want to a team lead or consultant and pay them to build it.

That's still the best way to turn a spec into a program and comes with all the downsides it entails.

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

#274

Post by pjmlp »

discreteevent wrote: post #242
abreslav wrote: post #209

Earlier quoted context omitted.

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 predic…

>Human engineers are not deterministic yet people pay them Human carpenters are not deterministic yet they won't use a machine saw that goes off line even 1% of the time. The whole history of tools, including software, is one of trying to make the thing do more precisely what is intended, whether the intent is right or not. Can you imagine some machine tool maker making something faulty and then saying, "Well hey, hu…

They do it all the time with their EULAs.

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

#275

Post by xigoi »

dwohnitmok wrote: post #108
bigwheels wrote: post #80

Earlier quoted context omitted.

LLMs are not deterministic: 1.) There is typically a temperature setting (even when not exposed, most major providers have stopped exposing it [esp in the TUIs]). 2.) Then, even with the temperature set to 0, it will be almost deterministic but you'll still observe small variations due to the limited precision of float numbers. Edit: thanks for the corrections

> but you'll still observe small variations due to the limited precision of float numbers No. Floating number arithmetic is deterministic. You don't get different answers for the same operations on the same machine just because of limited precision. There are reasons why it can be difficult to make sure that floating point operations agree across machines, but that is more of a (very annoying and difficult to make co…

> No. Floating number arithmetic is deterministic. You don't get different answers for the same operations on the same machine just because of limited precision. There are reasons why it can be difficult to make sure that floating point operations agree across machines, but that is more of a (very annoying and difficult to make consistent) configuration thing than determinism.

Float addition is not associative, so the result of x1 + x2 + x3 + x4 depends on which order you add them in. This matters when the sum is parallelized, as the structure of the individual add operations will depend on how many cores are available at any given time.

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

#276

Post by xigoi »

orbital-decay wrote: post #152
rco8786 wrote: post #121

Earlier quoted context omitted.

Yes, if you had each programmer rewrite the code from scratch each time you updated the spec.

In reality you give the same programmer an update to the existing spec, and they change the code to implement the difference. Which is exactly what the thing in OP is doing, and exactly what should be done. There's simply no reason to regenerate the result. The entire thing about determinism is a red herring, because 1) it's not determinism but prompt instability, and 2) prompt instability doesn't matter because of t…

> your inputs lack formal syntax, and that's fine

It’s not fine. I program using formal syntax precisely because I want the computer to do exactly what I tell it to.

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

#277

Post by liampulles »

I think I want to know exactly what SQL ends up hitting the DB, and I want to fine tune it precisely.

This is the same issue I've had with ORMs - I get that they make it easier to generate functionality at speed, but ultimately I want control over the biggest performance lever I have available to me.

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

#278

Post by orbital-decay »

xigoi wrote: post #276
orbital-decay wrote: post #152

Earlier quoted context omitted.

In reality you give the same programmer an update to the existing spec, and they change the code to implement the difference. Which is exactly what the thing in OP is doing, and exactly what should be done. There's simply no reason to regenerate the result. The entire thing about determinism is a red herring, because 1) it's not determinism but prompt instability, and 2) prompt instability doesn't matter because of t…

> your inputs lack formal syntax, and that's fine It’s not fine. I program using formal syntax precisely because I want the computer to do exactly what I tell it to.

Then program, instead of telling someone else (humans, LLMs) to do it.

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

#279

Post by xigoi »

orbital-decay wrote: post #278
xigoi wrote: post #276

Earlier quoted context omitted.

> your inputs lack formal syntax, and that's fine It’s not fine. I program using formal syntax precisely because I want the computer to do exactly what I tell it to.

Then program, instead of telling someone else (humans, LLMs) to do it.

I am doing so, but I keep seeing people say that LLMs have completely removed the need for writing code.

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

#280

Post by redwolf2 »

ModernMech wrote: post #260
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.

Isn't that how it always goes? First its just the crackpots. Then it's a fringe. Soon it's the way things have always been done.

Might look like it, might also just be survivorship bias. Alot of crackpot ideas hit the wall instead of beeing a success. We only notice the successors and might think of them as the default, not the exception.
Post reply on HN