Live data from Hacker News

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

codespeak.dev

301–304 of 304 posts

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

#301

Earlier quoted context omitted.

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.

I was commenting from that perspective, basically any thing we consider today to be “the way it’s done” was once something only crazy people did. I think maybe it was pg who said something like if you’re only working on safe things you’ll never have a breakthrough because if breakthroughs came from safe ideas then there would be more of them. I’m not saying every crazy idea changes the world but if you want to change the world you need a crazy idea.

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

#302
post #255

Earlier quoted context omitted.

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

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

The computational limits imposed on program verification are independent of the logical theory used, and depend only on its expressive strength. Many if not most interesting program properties require interleaved properties (forall-exists or forall-exists-forall etc.) which are intractable to verify.

> But CodeSpeak doesn't have formal specifications, so this is irrelevant.

The lack of formalism also doesn't matter to the limitations on correctness. If you wish to know, with certainty, that a program satisfies some property, that knowledge has a cost. But both humans and LLMs write programs at least in part based on inductive rather than deductive reasoning, which cannot be rigorously given a level of confidence. That may not be what we want, but that's what computational complexity says we can have, so we're forced to work in this way.

We should complain about what we don't have, but demanding things we can't have isn't going to help. There's no fundamental reason why AI shouldn't, someday, be able to program as well as humans, but there are fundamental limitations to producing the software we wish we had. Humans can rigorously use deductive methods, with mechanical help, and AI could possibly use it, too. But there's no reason to believe AI could break the size barrier of such problems. People have been able to rigorously verify only very small programs, and maybe AI could do a little better if only because of its tenacity, but if we expect to produce perfect programs by any means, we'll be waiting for a long time.

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

#303
There's an interesting set of ideas here!

If we look at the history of programming languages, we see the idea of Templating occuring over and over again, in different contexts, i.e., C's macros, C++ Templates, embedding PHP code snippets into an otherwise mostly HTML file, etc., etc.

Templating can involve aspects of meta-code (code about the code), interpretation proxying (which engine/compiler/system/parser/program/subsystem/? is responsible for interpreting a given section of text), etc., etc.

Here we see this idea as another level of proxied/layered abstraction/indirection, in this case between an AI/LLM and the underlying source code...

Is this a good idea?

Will all code be written like this, using this pattern or a similar one, in the future?

I for one don't know (it's too early to tell!) but one thing is for sure, and that's that this new "layer" certainly contains an interesting set of ideas!

I will definitely be watching to see more about how this pattern plays out in future software development...

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

#304

Earlier quoted context omitted.

Kotlin is generally considered a bit of a dud in the modern programming language space.

It's a blessing when you're in the native Android / React Native / Flutter space.

True. Not having to write Java for native modules anymore makes me really happy. Shame they haven’t replaced gradle yet though
Post reply on HN