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

21–30 of 210 posts

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

#21

Post by cmrdporcupine »

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.

Not my experience, honestly. With a good code base for it to explore and good tooling, and a really good prompt I've had excellent results with frankly quite obscure things, including homegrown languages.

As others said, the key is feedback and prompting. In a model with long context, it'll figure it out.

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

#22

Post by wazzaps »

fizlebit wrote: post #18

Looks a bit like Rust. My peeve with Rust is that it makes error handling too much donkey work. In a large class of programs you just care that something failed and you want a good description of that thing: context("Loading configuration from {file}") Then you get a useful error message by unfolding all the errors at some point in the program that is makes sense to talk to a human, e.g. logs, rpc error etc. Failed:…

You just described how the popular "anyhow" and "snafu" crates implement error handling

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

#23

Post by cadamsdotcom »

There’s both efficacy and token efficiency to consider here.

Seems unlikely for an out-of-distribution language to be as effective as one that’s got all the training data in the world.

Really needs an agent-oriented “getting started” guide to put in the context, and evals vs. the same task done with Python, Rust etc.

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

#24

Post by rocha »

cmrdporcupine wrote: post #21
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.

Not my experience, honestly. With a good code base for it to explore and good tooling, and a really good prompt I've had excellent results with frankly quite obscure things, including homegrown languages. As others said, the key is feedback and prompting. In a model with long context, it'll figure it out.

But isn't this inefficient since the agent has to "bootstrap" its knowledge of the new language every time it's context window is reset?

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

#25

Post by deepsquirrelnet »

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 enable lower resource “non-frontier” models to be more useful. Additionally, it allows tolerance to syntax mistakes or in the worst case, natural language if needed.

In other words, I think llms don’t need new languages, we do.

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

#26

Post by jll29 »

JamesTRexx wrote: post #2

So, then if I want to use a certain terminal text editor to create a clone of it in nanolang, I'd end up typing nano nano.nano on the command line. I might accidentally summon a certain person from Ork.

Make sure to create a "Getting Started" video with Nano Banana.

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

#27

Post by hahahahhaah »

simonw wrote: post #13

I went looking for a single Markdown file I could dump into an LLM to "teach" it the language and found this one: https://github.com/jordanhubbard/nanolang/blob/main/MEMORY.m... Optimistically I dumped the whole thing into Claude Opus 4.5 as a system prompt to see if it could generate a one-shot program from it: llm -m claude-opus-4.5 \ -s https://raw.githubusercontent.com/jordanhubbard/nanolang/refs/heads/main/MEMOR…

But are you losing horsepower of the LLM available to problem solving on a given task by doing so?

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

#28

Post by adastra22 »

rocha wrote: post #24
cmrdporcupine wrote: post #21

Earlier quoted context omitted.

Not my experience, honestly. With a good code base for it to explore and good tooling, and a really good prompt I've had excellent results with frankly quite obscure things, including homegrown languages. As others said, the key is feedback and prompting. In a model with long context, it'll figure it out.

But isn't this inefficient since the agent has to "bootstrap" its knowledge of the new language every time it's context window is reset?

No, it gets it “for free” just by looking around when it is figuring out how to solve whatever problem it is working on.

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

#29

Post by jll29 »

fizlebit wrote: post #18

Looks a bit like Rust. My peeve with Rust is that it makes error handling too much donkey work. In a large class of programs you just care that something failed and you want a good description of that thing: context("Loading configuration from {file}") Then you get a useful error message by unfolding all the errors at some point in the program that is makes sense to talk to a human, e.g. logs, rpc error etc. Failed:…

I like your "context" proposal, because it adds information about developer intention to error diagnostics, whereas showing e.g. a call stack would just provide information about the "what?", not the "why?" to the end user facing an error at runtime.

(You should try to get something like that into various language specs; I'd love you to success with it.)

EDIT: typo fixed.

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

#30

Post by adastra22 »

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 don’t think that assumption holds. For example, only recently have agents started getting Rust code right on the first try, but that hasn’t mattered in the past because the rust compiler and linters give such good feedback that it immediately fixes whatever goof it made.

This does fill up context a little faster, (1) not as much as debugging the problem would have in a dynamic language, and (2) better agentic frameworks are coming that “rewrite” context history for dynamic on the fly context compression.

Post reply on HN