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

Post by pmontra » Tue, Jan 20, 2026, 7:22 AM UTC

spicybright wrote: post #3

One novel part here is every function is required to have tests that run at compile time. 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.

  fn process_order {
    ... 
  } 
  shadow process_order {
    assert test_process_order
  }

Post by nemo1618 » Tue, Jan 20, 2026, 7:27 AM UTC

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.

Post by shakna » Tue, Jan 20, 2026, 7:53 AM UTC

deepsquirrelnet wrote: post #56

kamaal wrote: post #44

Earlier quoted context omitted.

>>new ways to create specifications. Thats again programming languages. Real issue with LLMs now is it doesn't matter if it can generate code quickly. Some one still has to read, verify and test it. Perhaps we need a need a terse programming language. Which can be read quickly and verified. You could call that specification.

Yes, essentially a higher level programming language than what we currently have. A programming language that doesn't have strict syntax, and can be expressed with words or code. And like any other programming language, it includes specifications for the tests and expectations of the result. The programming language can look more like code in parts where the specification needs to be very detailed. I think people can…

Post by cloogshicer » Tue, Jan 20, 2026, 8:01 AM UTC

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…

Post by PunchyHamster » Tue, Jan 20, 2026, 8:09 AM UTC

adastra22 wrote: post #30

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 frame…