Hacker News Reader

Comment by Wowfunhappy | Hacker News Reader

I think a more interesting (and significant) question is whether there can ever be a new programming language.

Like, if you really believe that in the future 95% of code will be written by LLMs, then there can never be a Python 4, because there would be no humans to create new training data.

To me, this is evidence that LLMs won’t be writing 95% of code, unless we really do get to some sort of mythical “AGI” where the AI can learn entirely from its own output and improve itself exponentially. (In which case there would still wouldn’t be a Python 4, it would be some indecipherable LLM speak.) I’ll believe that when I see it.

View on HN

My hunch is that existing LLMs make it easier to build a new programming language in a way that captures new developers.

Most programming languages are similar enough to existing languages that you only need to know a small number of details to use them: what's the core syntax for variables, loops, conditionals and functions? How does memory management work? What's the concurrency model?

For many languages you can fit all of that, including illustrative examples, in a few thousand tokens of text.

So ship your new programming language with a Claude Skills style document and give your early adopters the ability to write it with LLMs. The LLMs should handle that very well, especially if they get to run an agentic loop against a compiler or even a linter that you provide.

Isn't that what Geoff did: https://ghuntley.com/cursed/

OK, it wasn't a Claude Skill, but it was done using Claude.

That's slightly different - that's draining and implementing a new language from scratch, not just using LLMs to help onboard new language users.

That said, part of what he did with Cursed was get LLMs to read its own documentation and use that to test and demonstrate the language.

It is not pseudocode? It doesn't have to be something with strict syntax or very limited keywords, but maybe the compiler/linter (llm) could point out when you are being ambiguous or not defining how something should be done if several alternatives are possible.

> Most programming languages are similar enough to existing languages that you only need to know a small number of details to use them: what's the core syntax for variables, loops, conditionals and functions? How does memory management work? What's the concurrency model?

I think that’s correct in terms of the surface-level details but less true for the more abstract concepts.

If you’ve tried any of the popular AI builders that use Supabase/PostgREST as a backend, for instance Lovable, you’ll see that they are constantly failing because of how unusual PostgREST is. I’m sure these platforms have “AI cheat sheets” to try to solve this, but you still see constant problems with things like RLS, for instance.

When LLMs write and maintain code, does the programming language they use even matter? Anyway, the inputs to LLMs are all in natural language, and what we get is what we wanted built.

Is it better to specify the parameters and metrics —aka non-functional requirements —that matter for the application, and let LLMs decide? For that matter, why even provide that? Aren't the non-functional requirements generally understood?

It is the specifics that would change—scale to 100K monthly users, keep infrastructure costs below $800K, or integrate with existing Stripe APIs.

Reply on news.ycombinator.com