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

gritzko

So is it basically Markdown? The landing does not articulate, unfortunately, what the key contribution is.

pjmlp

I think stuff like Langflow and n8n are more likely to be adopted, alongside with some more formal specifications.

ljlolel

Getting so close to the idea. We will only have Englishscripts and don’t need code anymore. No compiling. No vibe coding. No coding. Https://jperla.com/blog/claude-electron-not-claudevm

lich_king

We built LLMs so that you can express your ideas in English and no longer need to code. Also, English is really too verbose and imprecise for coding, so we developed a programming language you can use instead. Now, this gives me a business idea: are you tired of using CodeSpeak? Just explain your idea to our product in English and we'll generate CodeSpeak for you.

cesarvarela

Instead of using tabs, it would be much better to show the comparison side by side. Also, the examples feel forced, as if you use external libraries, you don't have to write your own "Decode RFC 2047"

roxolotl

This doesn't seem particularly formal. I still remain unconvinced reducing is really going to be valuable. Code obviously is as formal as it gets but as you trend away from that you quickly introduce problems that arise from lack of formality. I could see a world in which we're all just writing tests in the form of something like Gherkin though.

theoriginaldave

I for one can't wait to be a confident CodeSpeak programmer /sarc Does this make it a 6th generation language?

h4ch1

You can basically condense this entire "language" into a set of markdown rules and use it as a skill in your planning pipeline. And whatever codespeak offers is like a weird VCS wrapper around this. I can already version and diff my skills, plans properly and following that my LLM generated features should be scoped properly and be worked on in their own branches. This imo will just give rise to a reason for people to make huge 8k-10k line changes in a commit.

amelius

I want to see an LLM combined with correctness preserving transforms. So for example, if you refactor a program, make the LLM do anything but keep the logic of the program intact.

whalesalad

https://en.wikipedia.org/wiki/Literate_programming

tonipotato

The problem with formal prompting languages is they assume the bottleneck is ambiguity in the prompt. In my experience building agents, the bottleneck is actually the model's context understanding. Same precise prompt, wildly different results depending on what else is in the context window. Formalizing the prompt doesn't help if the model builds the wrong internal representation of your codebase. That said curious to see where this goes.

kleiba

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 stand reading the contents. Unfortunately, this site does not have an obvious way of reading it black-on-white, short of looking at the HTML source (CTRL+U), which - in fact - I sometimes do.

xvedejas

We already have a language for talking to LLMs: Polish https://www.zmescience.com/science/news-science/polish-effec...

the_duke

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 code from last months * Text specifications are always under-specified, lossy and tend to gloss over a huge amount of details that the code has to make concrete - this is fine in a small example, but in a larger code base? * Every non-trivial codebase would be made up of of hundreds of specs that interact and influence each other - very hard (and context - heavy) to read all specs that impact functionality and keep it coherent I do think there are opportunities in this space, but what I'd like to see is: * write text specifications * model transforms text into a *formal* specification * then the formal spec is translated into code which can be verified against the spec 2 and three could be merged into one if there were practical/popular languages that also support verification, in the vain of ADA/Spark. But you can also get there by generating tests from the formal specification that validate the implementation.

jajuuka

We created programming languages to direct programs. Then created LLM's to use English to direct programs. Now we've create programming languages to direct LLM's. What is old is new again!

mft_

Conceptually, this seems a good direction. The other piece that has always struck me as a huge inefficiency with current usage of LLMs is the hoops they have to jump through to make sense of existing file formats - especially making sense of (or writing) complicated semi-proprietary formats like PDF, DOC(X), PPT(X), etc. Long-term prediction: for text, we'll move away from these formats and towards alternatives that are designed to be optimal for LLMs to interact with. (This could look like variants of markdown or JSON, but could also be Base64 [0] or something we've not even imagined yet.) [0] https://dnhkng.github.io/posts/rys/

fallkp

"Coming soon: Turning Code into Specs" There you have it: Code laundering as a service. I guess we have to avoid Kotlin, too.

oytis

Then of course we are going to ask LLMs to generate specifications in this new language

kittikitti

The intent of the idea is there, and I agree that there should be more precise syntax instead of colloquial English. However, it's difficult to take CodeSpeak seriously as it looks AI generated and misses key background knowledge. I'm hoping for a framework that expands upon Behavior Driven Development (BDD) or a similar project-management concept. Here's a promising example that is ripe for an Agentic AI implementation, https://behave.readthedocs.io/en/stable/philosophy/#the-gher...

Brajeshwar

So, back to a programming language, albeit “simplified.”