Live data from Hacker News

Nerd: A language for LLMs, not humans

nerd-lang.org

31–40 of 110 posts

Re: Nerd: A language for LLMs, not humans

#31

tokens are tokens, shorter or larger, they are tokens in that sense I don't see how this is more succinct than phyton it is more than typescript and c#, of course, but we need to compete with the laconic languages in that sense you will end up with Cisc vs Risc dilemma from the cpu wars. you will find the ability to compress even more is adding new tokens to compress repetitive tasks like sha256 being a single token.…

Because llm tokens don't map cleanly to what the compiler sees as a token. If coding is all LLMs will be good for this will surely change

Re: Nerd: A language for LLMs, not humans

#32

Would it make more sense to instead train a model and tokenise the syntax of languages differently so that white space isn’t counted, keywords are all a single token each and so on?

After watching models struggle with string replacement in files I've started to wonder if they'd be better off in making those alterations in a lisp: where it's normal to manipulate code not as a string but as a syntax tree.

Re: Nerd: A language for LLMs, not humans

#33
post #13

> Do you debug JVM bytecode? V8's internals? No. You debug at your abstraction layer In the fullness of time, you end up having to. Or at least I have. Which is why I always dislike additional layers and transforms at this point. (eg. when I think about react native on android, I hear "now I'll have to be excellent at react/javascript and android/java/kotlin and C++ to be able to debug the bridge; not that "I can get…

Exactly yes, that's what I was going to comment. You sometimes need to debug at every layers. All abstractions end up leaking in some way. It's often worth it, but it does not save us from the extra cognitive load and from learning the layers underneath.

I'm not necessarily against the approach shown here, reducing tokens for more efficient LLM generation; but if this catches on, humans will read and write it, will write debuggers and tooling for it, etc. It will definitely not be a perfectly hidden layer underneath.

But why not, for programming models, just select tokens that map concisely existing programming languages ? Would that not be as effective ?

Re: Nerd: A language for LLMs, not humans

#34

I can’t be alone in this, but this seems like a supremely terrible idea. I reject whole heartedly the idea that any sizeable portion of one’s code base should specifically /not/ be human interpretable as a design choice. There’s a chance this is a joke, but even if it is I don’t wanna give the AI tech bros more terrible ideas, they have enough. ;)

Some people are only capable of learning the hard way

Re: Nerd: A language for LLMs, not humans

#35
post #7

Creator here. This started as a dumb question while using Claude Code: "Why is Claude writing TypeScript I'm supposed to read?" 40% of code is now machine-written. That number's only going up. So I spent some weekends asking: what would an intermediate language look like if we stopped pretending humans are the authors? NERD is the experiment. Bootstrap compiler works, compiles to native via LLVM. It's rough, probably…

> 40% of code is now machine-written How did you arrive at that number?

The same way LLMs arrive at things? :)

Re: Nerd: A language for LLMs, not humans

#36
the real question isn't "should AI write readable code" but "where in the stack does human comprehension become necessary?" we already have layers where machine-optimized formats dominate (bytecode, machine code, optimized IR). the source layer stays readable because it's the interface where human judgment enters.

maybe AI should write better readable code than humans. more consistent naming, clearer structure, better comments. precisely because humans only "skim". optimize for skimmability and debuggability, not keystroke efficiency.

Re: Nerd: A language for LLMs, not humans

#38
If you're going to set TypeScript as the bar, why not a bidirectional transpile-to-NERD layer? That way you get to see how the LLM handles your experiment, don't have to write a whole new language, and can integrate with an existing ecosystem for free.

Re: Nerd: A language for LLMs, not humans

#39
Seems like engagement bait or a thought exercise more than a realistic project.

> "But I need to debug!"

> Do you debug JVM bytecode? V8's internals? No. You debug at your abstraction layer. If that layer is natural language, debugging becomes: "Hey Claude, the login is failing for users with + in their email."

Folks can get away without reading assembly only when the compiler is reliable. English -> code compilation by llms is not reliable. It will become more reliable, but (a) isn’t now so I guess this is a project to “provoke thought” (b) you’re going to need several nines of reliability, which I would bet against in any sane timeframe (b) English isn’t well specified enough to have “correct” compilation, so unclear if “several nines of reliability” is even theoretically possible.

Re: Nerd: A language for LLMs, not humans

#40
This is a 21st-century equivalent of leaving short words ("of", "the", "in") out of telegrams because telegraph operators charged by the word. That caused plenty of problems in comprehension… this is probably much worse because it's being applied to extremely complex and highly structured messages.

It seems like a short-sighted solution to a problem that is either transient or negligible in the long run. "Make code nearly unreadable to deal with inefficient tokenization and/or a weird cost model for LLMs."

I strongly question the idea that code can be effectively audited by humans if it can't be read by humans.

Post reply on HN