Live data from Hacker News

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

codespeak.dev

131–140 of 304 posts

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

#132
post #49

This doesn't make too much sense to me. * This isn't a language, it's some tooling to map specs to code and re-generate * Models aren't deterministic - every time you would try to re-apply you'd likely get different output (without feeding the current code into the re-apply and let it just recommend changes) * Models are evolving rapidly, this months flavour of Codex/Sonnet/etc would very likely generate different co…

Models aren't deterministic - every time you would try to re-apply you'd likely get different output (without feeding the current code into the re-apply and let it just recommend changes) If the result is always provably correct it doesn't matter whether or not it's different at the code level. People interested in systems like this believe that the outcome of what the code does is infinity more important than the co…

That if at the beginning of your sentence is doing a whole lot of work. Indeed, if we could formally and provably (another extremely loaded word) generate good code that'd be one thing, but proving correctness is one of those basically impossible tasks.

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

#135

"Shrink your codebase 5-10x" "[1] When computing LOC, we strip blank lines and break long lines into many"

I don't think this is the gotcha you think it is...

I imagine this is before and after- not just after.

As in, they aren't just making lines long and removing whitespace (something models love to do when you ask it to remove lines of code)

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

#137
post #49

This doesn't make too much sense to me. * This isn't a language, it's some tooling to map specs to code and re-generate * Models aren't deterministic - every time you would try to re-apply you'd likely get different output (without feeding the current code into the re-apply and let it just recommend changes) * Models are evolving rapidly, this months flavour of Codex/Sonnet/etc would very likely generate different co…

Models aren't deterministic - every time you would try to re-apply you'd likely get different output (without feeding the current code into the re-apply and let it just recommend changes) If the result is always provably correct it doesn't matter whether or not it's different at the code level. People interested in systems like this believe that the outcome of what the code does is infinity more important than the co…

Besides, you can deterministically generate bad code, and not deterministically generate good code.

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

#139
post #128

This doesn't make too much sense to me. * This isn't a language, it's some tooling to map specs to code and re-generate * Models aren't deterministic - every time you would try to re-apply you'd likely get different output (without feeding the current code into the re-apply and let it just recommend changes) * Models are evolving rapidly, this months flavour of Codex/Sonnet/etc would very likely generate different co…

If what you're after is determinism, then your solution doesn't offer it. Both the formal specification and the code generated from it would be different each time. Formal specifications are useful when they're succinct, which is possible when they specify at a higher level of abstraction than code, which admits many different implemementations.

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).

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

#140
post #127

Earlier quoted context omitted.

If you are a “programmer” you are going to be the kids in the sweatshop. On the enterprise dev side where most developers work, it’s been headed in that direction for at least a decade where it was easy enough to become a “good enough” generic full stack/mobile/web etc dev. Even on the BigTech side being able to reverse a btree on the whiteboard and having on your resume that you were a mid level developer isn’t enou…

What do you think programmers in offshoring consulting shops are? Sadly.

Exactly. I work in a consulting company as a customer facing staff consultant - highest level - specializing in cloud + app dev. We don’t hire anyone less than staff in the US. Anything lower is hired out of the country.

That’s exactly my point. “Programming” was clearly becoming commoditized a decade ago.

Post reply on HN