Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nanolang: A tiny experimental language designed to be targeted by coding LLMs

github.com

Post reply on HN
Print view View original

101–110 of 210 posts

Re: Nanolang: A tiny experimental language designed to be targeted by coding LLMs

#101

Post by _flux »

The required-test-per-function is sort of interesting. But it's not enforced that the test does anything useful, is it?

So I wonder how exhausting would it be to write in a language that required, for all functions, that they are tested with 100% path coverage.

Of course, this by itself wouldn't still be equivalent to proving the code, but it would probably point people to the corner cases of code quite rapidly. Additionally it would make it impossible to have code that cannot be tested with 100% path coverage due to static relationships within it, that are not (or cannot be) expressed in the type system, e.g. if (foo) { if (!foo) {..} }.

And would such a language need to have some kind of dynamic dependency injection mechanism for mocking the tests?

Re: Nanolang: A tiny experimental language designed to be targeted by coding LLMs

#102

Post by [deleted] »

nemo1618 wrote: post #94
thorum wrote: post #6

Developed by Jordan Hubbard of NVIDIA (and FreeBSD). My understanding/experience is that LLM performance in a language scales with how well the language is represented in the training data. From that assumption, we might expect LLMs to actually do better with an existing language for which more training code is available, even if that language is more complex and seems like it should be “harder” to understand.

Blackpill is that, for this reason, the mainstream languages we have today will be the final (human-designed) languages to be relevant on a global scale. Eventually AIs will create their own languages. And humans will, of course, continue designing hobbyist languages for fun. But in terms of influence, there will not be another human language that takes the programming world by storm. There simply is not enough time…

[deleted]

Re: Nanolang: A tiny experimental language designed to be targeted by coding LLMs

#103

Post by measurablefunc »

thorum wrote: post #97
measurablefunc wrote: post #11

Earlier quoted context omitted.

There is no RL for programming languages. Especially ones w/ no significant amount of code.

Go read the DeepSeek R1 paper

Why would I do that? If you know something then quote the relevant passage & equation that says you can train code generators w/ RL on a novel language w/ little to no code to train on. More generally, don't ask random people on the internet to do work for you for free.

Re: Nanolang: A tiny experimental language designed to be targeted by coding LLMs

#104

Post by e12e »

antonvs wrote: post #81
e12e wrote: post #42

Earlier quoted context omitted.

Oh, wow. I thought the control flow from the readme was a little annoying with the prefix -notation for bigger/smaller than; # Control flow if (> x 0) { (println "positive") } else { (println "negative or zero") } But that's nothing compared to the scream for a case/switch-statement in the Mandelbrot example... # Gradient: " .:-=+*#%@" let gradient: string = " .:-=+*#%@" let gradient_len: int = 10 let idx: int = (/ (…

> scream for a case/switch-statement Maybe I’m missing some context, but all that actually should be needed in the top-level else block is ‘gradient[idx]’. Pretty much anything else is going to be longer, harder to read, and less efficient.

True, with early return - there's no need to actually nest with else.

Logically this still would be a case/switch though...

Re: Nanolang: A tiny experimental language designed to be targeted by coding LLMs

#106

Post by fragmede »

keepamovin wrote: post #62
deepsquirrelnet wrote: post #25

At this point, I am starting to feel like we don’t need new languages, but new ways to create specifications. I have a hypothesis that an LLM can act as a pseudocode to code translator, where the pseudocode can tolerate a mixture of code-like and natural language specification. The benefit being that it formalizes the human as the specifier (which must be done anyway) and the llm as the code writer. This also might e…

I think this confuses two different things: - LLMs can act as pseudocode to code translators (they are excellent at this) - LLMs still create bugs and make errors, and a reasonable hypothesis is at a rate in direct proportion to the "complexity" or "buggedness" of the underlying language. In other words, give an AI a footgun and it will happily use it unawares. That doesn't mean however it can't rapidly turn your pse…

Say you have this new language, with only a tiny amount of examples of there. How do the SOTA labs train on you're language? With sufficient examples, it can generate code which gets compiled and then run and that gets fed into a feedback loop to improve upon, but how do you get there? How do you bootstrap that? Nevermind the dollar cost, how does it offer something above having an LLM generate code in python or JavaScript, then having it rewrite it in golang/rust/c++ as needed/possible for performance or whatever reason?

It sounds like your plan is for it to write fewer bugs in NewLang, but, well, that seems a bit hard to achieve in the abstract. From bugs I've fixed in generated code, early LLM, it was just bad code. Multiple variables for the same thing, especially. Recently they've gotten better at that, but it still happens.

For a concrete example, any app dealing with points in time. Which sometimes have a date attached but sometimes do not. And also, what are timezones. The complexity is there because it depends on what you're trying to do. An alarm clock is different than a calendar is different than a pomodoro timer. How are you going to reduce the bugged-ed-ness of that without making one of those use cases more complicated than need be, given access to various primitives.

Re: Nanolang: A tiny experimental language designed to be targeted by coding LLMs

#107

Post by Surac »

as i already wrote in an other comment. Where are the millions lines of code needed to train LLM in this Nanolang? LLM are like parrots. if you dont give them data to extract the statistic probability of the next word, you will not get any usefull output. LLM do not think, they can't learn without training data

Re: Nanolang: A tiny experimental language designed to be targeted by coding LLMs

#108

Post by trklausss »

deepsquirrelnet wrote: post #25

At this point, I am starting to feel like we don’t need new languages, but new ways to create specifications. I have a hypothesis that an LLM can act as a pseudocode to code translator, where the pseudocode can tolerate a mixture of code-like and natural language specification. The benefit being that it formalizes the human as the specifier (which must be done anyway) and the llm as the code writer. This also might e…

Ah, people are starting to see the light.

This is something that could be distilled from some industries like aviation, where specification of software (requirements, architecture documents, etc.) is even more important that the software itself.

The problem is that natural language is in itself ambiguous, and people don't really grasp the importance of clear specification (how many times I have repeated to put units and tolerances to any limits they specify by requirements).

Another problem is: natural language doesn't have "defaults": if you don't specify something, is open to interpretation. And people _will_ interpret something instead of saying "yep I don't know this".

Re: Nanolang: A tiny experimental language designed to be targeted by coding LLMs

#109

Post by gritzko »

roncesvalles wrote: post #68
deepsquirrelnet wrote: post #25

At this point, I am starting to feel like we don’t need new languages, but new ways to create specifications. I have a hypothesis that an LLM can act as a pseudocode to code translator, where the pseudocode can tolerate a mixture of code-like and natural language specification. The benefit being that it formalizes the human as the specifier (which must be done anyway) and the llm as the code writer. This also might e…

What we need is a programming language that defines the diff to be applied upon the existing codebase to the same degree of unambiguity as the codebase itself. That is, in the same way that event sourcing materializes a state from a series of change events, this language needs to materialize a codebase from a series of "modification instructions". Different models may materialize a different codebase using the same s…

I am working on that https://github.com/gritzko/librdx Conflictless merge and overlay branches (ie freely attachable/detachable by a click). That was the pie-in-the-sky of the CRDT community for maybe 15 years. My current approach is RDX tree CRDT effectively mapping to the AST tree of the program. Like CRDT DOM for the AST, because line based diffs are too clumsy for that.

Back in the day, JetBrains tried revision-controlling AST trees or psi-nodes in their parlance. That project was cancelled, as it became a research challenge. That was 10 years ago or so. At this point, things may work out well, time will tell.

Re: Nanolang: A tiny experimental language designed to be targeted by coding LLMs

#110

Post by vidarh »

thorum wrote: post #6

Developed by Jordan Hubbard of NVIDIA (and FreeBSD). My understanding/experience is that LLM performance in a language scales with how well the language is represented in the training data. From that assumption, we might expect LLMs to actually do better with an existing language for which more training code is available, even if that language is more complex and seems like it should be “harder” to understand.

I mostly agree, and I think a combination of good representation and tooling that lets it self-correct quickly will do better than new language in the short term.

In the long term I expect it won't matter - already GPT3.5 was able to reason about the basic semantics of programs in languages "synthesised" zero-shot in context by just describing it as a combination of existing languages (e.g. "Ruby with INTERCAL's COME FROM") or by providing a grammar (e.g. simple EBNF plus some notes on new/different constructs) reasonably well and could explain what a program written in a franken-language it had not seen before was likely to do.

I think long before there is enough training data for a new language to be on equal grounds in that respect, we should expect the models to be good enough at this that you could just provide a terse language spec.

But at the same time, I'd expect the same improvement to future models to be good enough at working with existing languages that it's pointless to tailor languages to LLMs.

Post reply on HN