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.

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.

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

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.

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?

I'm still skeptical of the value add having to teaching a custom language to an LLM instead of using something like lua or python and applying constraints like test requirements onto that.

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.

Summary:

- Co-created FreeBSD.

- Led UNIX technologies at Apple for 13 years

- iXSystems, lead FreeNAS

- idk something about Uber

- Senior Director for GPU Compute Software at NVIDIA

For whatever it’s worth.

I might accidentally summon a certain person from Ork.

Quick reaction:

1. Nanolang is a total thought experiment. The key word its description is "experimental" - whether it's a Good experiment or a Bad experiment can be argued either way, especially by language purists!

2. Yes, it's a total Decorator Crab of a language. An unholy creation by Dr Frankenstein, yes! Those criticisms are entirely merited. It wasn't designed, it accreted features and was a fever dream I couldn't seem to stop having. I should probably take my own temperature.

3. I like prefix notation because my first calculator was an HP calculator (the HP 41C remains, to this day, my favorite calculator of ALL TIME). I won't apologize for that, but I DO get that it's not everybody's cup of tea! I do, however, use both vi and emacs now.

Umm. I think that about covers it. All of this LLM stuff is still incredibly young to me and I'm just firing a shotgun into the dark and listening to hear if I hit anything. It's going to be that way for a while for all of us until we figure out what works and what does not!

- jkh

``` #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.

  context("Loading configuration from {file}")

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.

I am using a variation of spec-driven development.

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.

1. https://www.linkedin.com/in/johubbard/

NanoLang solves three problems:

LLM Code Generation - Unambiguous syntax reduces AI errors Testing Discipline - Mandatory tests improve code quality

particularly the first.

LLM Code Generation - Unambiguous syntax reduces AI errors

Testing Discipline - Mandatory tests improve code quality

Simple & Fast - Minimal syntax, native performance

Design Philosophy:

Minimal syntax (18 keywords vs 32 in C)

One obvious way to do things

Tests are part of the language, not an afterthought

Transpile to C for maximum compatibility

ehh. i dont think the overhead of inventing a new language makes up for the lack of data around it. in fact if you're close enough to rust/c then llms are MORE likely to make up stuff from their training data and screw up your minimal language.

(pls argue against this, i want to be proven wrong)

so like Go?

> Key Features; Prefix Notation

wow

NEXT!