zlacker

[return to "Nanolang: A tiny experimental language designed to be targeted by coding LLMs"]
1. deepsq+br[view] [source] 2026-01-20 01:01:48
>>Scramb+(OP)
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 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.

◧◩
2. ronces+uL[view] [source] 2026-01-20 04:26:08
>>deepsq+br
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.

◧◩◪
3. gritzk+Ib1[view] [source] 2026-01-20 08:56:25
>>ronces+uL
I am working on that https://github.com/gritzko/librdx Conflictless merge and overlay branches (ie freely attachable/detachable by a click). That was the pie-in-the-sky of the CRDT community for maybe 15 years. My current approach is RDX tree CRDT effectively mapping to the AST tree of the program. Like CRDT DOM for the AST, because line based diffs are too clumsy for that.

Back in the day, JetBrains tried revision-controlling AST trees or psi-nodes in their parlance. That project was cancelled, as it became a research challenge. That was 10 years ago or so. At this point, things may work out well, time will tell.

◧◩◪◨
4. mike_h+Rl1[view] [source] 2026-01-20 10:12:14
>>gritzk+Ib1
Was it cancelled? I thought MPS works that way.
◧◩◪◨⬒
5. gritzk+ku1[view] [source] 2026-01-20 11:24:14
>>mike_h+Rl1
I meant specifically revision control. JetBrains' school of thought is very much AST-centric, yes.
◧◩◪◨⬒⬓
6. mike_h+AI1[view] [source] 2026-01-20 13:22:57
>>gritzk+ku1
I think MPS stores projects as serialized ASTs and can do VCS merging.
◧◩◪◨⬒⬓⬔
7. gritzk+lQ1[view] [source] 2026-01-20 14:16:57
>>mike_h+AI1
Great. But MPS is not a revision control system.
[go to top]