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

11–20 of 210 posts

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

#11

Post by measurablefunc »

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

easy enough to solve with RL probably

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

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

#12

Post by whimsicalism »

measurablefunc wrote: post #11
whimsicalism wrote: post #7

Earlier quoted context omitted.

easy enough to solve with RL probably

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

not even wrong

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

#13

Post by simonw »

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/MEMORY.md \
    'Build me a mandelbrot fractal CLI tool in this language' 
   > /tmp/fractal.nano
Here's the transcript for that. The code didn't work: https://gist.github.com/simonw/7847f022566d11629ec2139f1d109...

So I fired up Claude Code inside a checkout of the nanolang and told it how to run the compiler and let it fix the problems... which DID work. Here's that transcript:

https://gisthost.github.io/?9696da6882cb6596be6a9d5196e8a7a5...

And the finished code, with its output in a comment: https://gist.github.com/simonw/e7f3577adcfd392ab7fa23b1295d0...

So yeah, a good LLM can definitely figure out how to use this thing given access to the existing documentation and the ability to run that compiler.

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

#15

Post by nodja »

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…

I think you need to either feed it all of ./docs or give your agent access to those files so it can read them as reference. The MEMORY.md file you posted mentions ./docs/CANONICAL_STYLE.md and ./docs/LLM_CORE_SUBSET.md and they in turn mention indirectly other features and files inside the docs folder.

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

#16

Post by sheepscreek »

Really clean language where the design decisions have led to fewer traps (cond is a good choice).

It’s peculiar to see s-expressions mixed together with imperative style. I’ve been experimenting along similar lines - mixing s-expressions with ML style in the same dialect (for a project).

Having an agentic partner toiling away with the lexer/parser/implementation details is truly liberating. It frees the human to explore crazy ideas that would not have been feasible for a side/toy/hobby project earlier.

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

#17

Post by simonw »

nodja wrote: post #15
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…

I think you need to either feed it all of ./docs or give your agent access to those files so it can read them as reference. The MEMORY.md file you posted mentions ./docs/CANONICAL_STYLE.md and ./docs/LLM_CORE_SUBSET.md and they in turn mention indirectly other features and files inside the docs folder.

Yeah, I think you're right about that.

The thing that really unlocked it was Claude being able to run a file listing against nanolang/examples and then start picking through the examples that were most relevant to figuring out the syntax: https://gisthost.github.io/?9696da6882cb6596be6a9d5196e8a7a5...

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

#18

Post by fizlebit »

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: Loading configuration from .config because: couldn't open file .config because: file .config does not exist.

It shouldn't be harder than a context command in functions. But somehow Rust conspires to require all this error type conversion and question marks. It it is all just a big uncomfortable donkey game, especially when you have nested closures forced to return errors of a specific type.

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

#19

Post by Zigurd »

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.

It's not just how well the language is represented. Obscure-ish APIs can trip up LLMs. I've been using Antigravity for a Flutter project that uses ATProto. Gemini is very strong at Dart coding, which makes picking up my 17th managed language a breeze. It's also very good at Flutter UI elements. It was noticeably less good at ATProto and its Dart API.

The characteristics of failures have been interesting: As I anticipated it might be, an over ambitious refactoring was a train wreck, easily reverted. But something as simple as regenerating Android launcher icons in a Flutter project was a total blind spot. I had to Google that like some kind of naked savage running through the jungle.

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

#20

Post by jmward01 »

Just scanning through this, looks interesting and is totally needed, but I think it is missing showing future use-cases and discussions of decoding. So, for instance, it is all well and good to define a simple language focused on testing and the like, but what about live LLM control and interaction via a programming language? Sort of a conversation in code? Data streams in and function calls stream out with syntax designed to minimize mistakes in calls and optimize the stream? What I mean by this is special block declarations like:

``` #this is where functions are defined and should compile and give syntax errors ```

:->r = some(param)/connected(param, param, @r)/calls(param)(yeah, ugly but the idea is there) The point being that the behavior could change. In the streaming world it may, for instance, have guarantees of what executes and what doesn't in case of errors. Maybe transactional guarantees in the stream blocks compared to pure compile optimization in the other blocks? The point here isn't that this is the golden idea, but that we probably should think about the use cases more. High on my list of use cases to consider (I think)

- language independence: LLMs are multilingual and this should be multilingual from the start.

- support streaming vs definition of code.

- Streaming should consider parallelism/async in the calls.

- the language should consider cached token states to call back to. (define the 'now' for optimal result management, basically, the language can tap into LLM properties that matter)

Hmm... That is the top of my head thoughts at least.

Post reply on HN