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

Original Article ↗ Hacker News Discussion ↗

Project concept

  • Nanolang is presented as a tiny, experimental language aimed at LLM code generation: minimal syntax, prefix operators, transpiles to C, and requires a test block (“shadow”) per function.
  • Some see it as “simplified Rust/C with s-expressions,” others as a “Frankenstein” mix of C-like declarations and Lisp-like bodies.
  • Several commenters doubt that inventing a new language offsets the lack of training data versus using Python, Rust, Lua, etc., with linters and enforced tests.

Compile-time tests & “shadow” blocks

  • Per-function mandatory tests are viewed as the main novel idea.
  • Supporters like tests being first-class and enforced, similar to some teaching languages.
  • Critics worry about real-world files becoming bloated with boilerplate tests, or people gaming the compiler with trivial “shadow” functions that assert other test files.
  • A few speculate about stronger requirements (e.g., mandatory 100% path coverage), which would force design changes and possibly require mocking and dependency injection features.

LLMs, training data, and bootstrapping

  • One camp argues LLM effectiveness correlates strongly with training data volume; new languages will underperform compared to established ones.
  • Others counter that LLMs learn grammars quickly from a spec + examples, especially with compiler/tool feedback and agentic loops; extensive pretraining in the new language isn’t strictly necessary.
  • There’s debate over whether RL can realistically bootstrap a novel language with little code; some say it’s feasible given a grammar and verifiable tooling, others see it as hand-wavy.
  • A concrete experiment shows an LLM failing on first try with only one doc, then successfully learning Nanolang when allowed to read more docs, browse examples, and run the compiler.

Syntax & ergonomics

  • Prefix notation and nested if/else chains are polarizing: some find the language clear and “cond-like,” others see it as awkward and missing obvious constructs like switch/case or direct indexing.
  • Several note that if the language is for LLMs, human readability and terseness (including token efficiency) should be explicitly evaluated, but the repo lacks clear metrics or benchmarks.
  • Some suggest a strongly typed Lisp or even direct AST-like forms might serve LLMs better.

Alternatives & broader perspectives

  • Many argue the real need isn’t new languages but:
    • Better specification languages or pseudo-code that LLMs compile into existing languages.
    • Notebook-like, safe, small languages for agents’ scratch work.
    • Diff/AST-based “spec as sequence of modifications” instead of code snapshots.
  • Others propose using existing languages plus linters/testing conventions to enforce clarity and test discipline, rather than inventing a new ecosystem.

Reception

  • Overall response skews skeptical: people question the “LLM-optimized” claim, token inefficiency, and lack of rigorous evals against Python/Rust baselines.
  • A minority explicitly welcome it as a valuable thought experiment and applaud exploratory language design in the LLM era.
  • The author characterizes Nanolang as a “fever dream” and deliberate experiment rather than a polished, principled design.