Live data from Hacker News

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

github.com

61–70 of 210 posts

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

#61
post #57

Author has a Wikipedia page about him linked from his GitHub profile: https://en.wikipedia.org/wiki/Jordan_Hubbard 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.

a.k.a. jkh. That's a blast from the past. Back in the early FreeBSD days, Jordan was fielding mailing list traffic and holding the project together as people peppered the lists with questions, trying to get their systems running with their sundry bits of hardware. I wondered when he slept.

Apparently he did as well[1]: "The start of the 2.0 ports collection. No sup repository yet, but I'll make one when I wake up again.. :)" Submitted by: jkh Aug 21, 1994

[1] https://github.com/freebsd/freebsd-ports/commit/7ca702f09f29...

Interesting commit starting Ports 2.0. Three version of bash, four versions of Emacs, plus jove.

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

#62

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…

I think this confuses two different things:

- LLMs can act as pseudocode to code translators (they are excellent at this)

- LLMs still create bugs and make errors, and a reasonable hypothesis is at a rate in direct proportion to the "complexity" or "buggedness" of the underlying language.

In other words, give an AI a footgun and it will happily use it unawares. That doesn't mean however it can't rapidly turn your pseudocode into code.

None of this means that LLMs can magically correct your pseudocode at all times if your logic is vastly wrong for your goal, but I do believe they'll benefit immensely from new languages that reduce the kind of bugs they make.

This is the moment we can create these languages. Because LLMs can optimize for things that humans can't, so it seems possible to design new languages to reduce bugs in ways that work for LLMs, but are less effective for people (due to syntax, ergonomics, verbosity, anything else).

This is crucially important. Why? Because 99% of all code written in the next two decades will be written by AI. And we will also produce 100x more code than has ever been written before (because the cost of doing it, has dropped essentially to zero). This means that, short of some revolutions in language technology, the number of bugs and vulnerabilities we can expect will also 100x.

That's why ideas like this are needed.

I believe in this too and am working on something also targeting LLMs specifically, and have been working on it since Mid to Late November last year. A business model will make such a language sustainable.

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

#63

Earlier quoted context omitted.

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…

> 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 isn't even true today. Source: heavy user of claude code and gemini with rust for almost 2 years now.

I have no problems with rust and Claude Code, and I use it on a daily basis.

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

#64

Seems like a simplified Rust with partial prefix notation (which the rationale that is better for LLMs is based on vibes really) that compiles to C. Similar language posted here not too long ago: Zen-C => more features, no prefix notation / Rue => no prefix notation, compiles directly to native code (no C target). Surprisingly compared to other LLM "optimized" languages, it isn't so much concerned about token efficie…

I find Polish or Reverse Polish notation jarring after a lifetime of thinking in terms of operator precedence. Given that it's fairly rare to see, I wonder what about it would be more LLM-friendly. It does lend itself better to "tokenization" of a sort - if you want to construct operations from lots of smaller operations, for example if you're mutating genetic algorithms (a la Eureqa). But I've written code in the pa…

>It does lend itself better to "tokenization" of a sort - if you want to construct operations from lots of smaller operations [...]

That's an educated assumption to make. But therein lies the issue with every LLM "optimized" language, including those recent ones posted here oriented toward minimizing tokens. Assumptions, that are unvalidatable and unfalsifiable, about the kind of output LLMs synthesize/emit when that output is code (or any output to be real).

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

#66
post #65

> tiny … language designed to be targeted by coding LLMs so like Go? > Key Features; Prefix Notation wow NEXT!

Every new language pet project these days claims to be "designed for LLM's", lol. Don't read too much into it. The only language that's really designed for LLM is COBOL, because it was written to read just like English natural language and LLM's are trained by reading lots of English language books.

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

#67
opus is currently the only one that can code rust, but if you give it symbol resolution there is quite literally nothing better. The type system in rust is incredibly powerful and llms are great (just opus for now) at utilizing it.

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

#68

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 series of instructions (like compilers), or say different "environmental factors" (e.g. the database or cloud provider that's available). It's as if the codebase itself is no longer the important artifact, the sequence of prompts is. You would also use this sequence of prompts to generate a testing suite completely independent of the codebase.

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

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

> My understanding/experience is that LLM performance in a language scales with how well the language is represented in the training data.

This isn't really true. LLMs understand grammars really really well. If you have a grammar for your language the LLM can one-shot perfect code.

What they don't know is the tooling around the language. But again, this is pretty easily fixed - they are good at exploring cli tools.

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

#70
Thanks for all of the comments!

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

Post reply on HN