In short, the more deterministic, automated, checks the better. AI can deal with a pedantic language. I intend to add statically verified structured concurrency, units of measure, contracts, and eventually more and more formal methods into the language so it can be a familiar TYpeScript-like base with as many static guarantees as we can fit in.
I also think that fine-grained isolation, which Zena gets via Web Assembly, is critical for limiting the capabilities of generated code and the blast radius of bugs, vulnerabilities, and non-aligned behavior.
I do have an optimistic hope that a language also optimized for humans, readability and simple semantics especially, has value in the future, even when most code is generated. We'll see about that.
Oops, the quick-reference is wrong. The other docs correctly say that default floats are f64. Default int is i32 though. Fixing it.
My understanding is that i32 and f64 literals are pretty common among the more modern languages because f64 isn't much slower than f32 on modern CPUs and f32 costs precision, but i64 is slower than i32 (especially multiplies and divides or on 32 bit hardware) and i32 costs range, not precision, and most uses don't need the extra range.
I love this. I was thinking about a "cleaned up" typescript for a while now, and this seems to be it. I believe this can work better as an "ai-first" language than some other attempts I've seen that try to reinvent the language from scratch.
One thing I would love to have as a feature is native compilation.
Why not languages that are designed in that way, like Ada. Or if one wants less of rigidness then a static typed language that makes it hard to shoot in your foot like Rust,Java, C#?
JS derivatives are that, a derivative to a scripting language.
Ironically, since AI can build an STL and tooling (up to a full OS!), I think now presents an opportunity for a language that does start from scratch, at least targeting hobbyists (besides those specifically looking for novel languages).
Agents are fairly good even at languages designed to trick them. I built one[1] and it does make for a good benchmark[2] to see which LLMs are actually good. I think that a language which is largely similar to others will be a piece of cake for most and any advantage that an existing language will have will be minor enough to not matter.
Btw if folks have ideas of how to make Killswitch even harder for LLMs I’d appreciate them.
Alternatively, this might accurately identify Chinese models so you can avoid them if that's your goal
Personally I don't have much interest in using models that blatantly censor historical facts.
Tiananmen Square is an obvious one but I would be concerned that any model that censors that would also have other hidden censorship or more subtle biases I wouldn't catch
From experience with Zena, this is not true at all. Opus, Fable, Gemini Flash and Pro all barely make any syntax mistakes after a little is in context, and those are caught extremely early.
The one thing I do see sometimes is that agents sometimes don't take advantage of added features, but that's partially because the Zena code base doesn't use them as much yet. I'm working on skills and linter-based suggestions to use better patterns.
You should have working programs that demonstrate the features you want them to use, and then the skills. Working programs they can mutate in an RL gym.
This is absolutely not the case in my experience. I am building a very large embedded domain specific language for describing distributed systems. It looks like a small subset of Elixir, but with object-oriented syntax in a lot of places. (It’s called a choreography; there exist many other choreographic programming languages.)
Even though this programming language is absolutely nowhere in any large language model’s training set, they have so far done extremely well at extrapolating from the small set of examples I’ve given it when I need an agent to generate some tests or whatever for me.
I think starting with a familar typescript-like base language is a good approach to this. This should be familiar enough for LLMs for the most part as long as additional features can be explained in a succinct system promopt/skill.
> bc agents will naturally be bad at it due to a lack of examples.
Can we please as a community stop parroting these false premises as a basis of every argument against doing anything new? It's plainly obvious to anybody that uses LLMs on a regular basis that it's not true.
Agree, new language will not suitable for LLM because there is not enough documents about it on the internet. LLM should learn the usage of the langauge from documents. Yes, it can use new language but it's not natural as existing(which have a lot of documents) languages.
So my opinion is language is no matter anymore. Just prompting(describe the spec) matters. And there is babo language for this.
https://github.com/armbox/babo
They should find the limitation of the natural language somehow, and use and distribute babo language will help find how it will works(or not). LLM model eveolves yet, so there is no such a approach, but the speed of evolution is decreased lately. So now is good time to dig into identify the limitation and boundary of the LLM.
It might seem obvious but in truth is not - to be honest, a strictly typed language where models can play adversarial competitions against a strict compiler/linter does have advantages, as mentioned in the article itself but that's not related to training size, the advantage is exactly that it can generate synthetic useful data due to compiler/linter guarantees - regarding training size as long as some logic showcasing the constructs exists that is all that is needed. If you have 2 correct examples for each feature or language construct then the probability of the a LLM learning it and applying it is very much guaranteed, if you have thousands of diverging uses of patterns and constructs in the training data (with a lot of bad examples or wrong uses) a LLM might, I dare say will, actually perform worse, since the probabilities of what particular variation being the "correct" one to use are all over the place.
What can happen is sometimes patterns that are unique to certain languages aren't surfaced and so can't be "learned" but that is a different case, since you can add examples - or patterns that go beyond syntax (threaded code, process isolation, interaction between different modes of resolution, etc) where you need the agent to be able to understand and plan higher-level logic.
I wrote CSSex as a css pre-processor (similar but not the same as SASS/SCSS) and my "boss" at the time fed the existing cssex files to GPT (+2 years ago) and it was able to write CSSex just as fine as if it was writing something that was present in its training data set. It never introduced syntax bugs, the bugs it introduced were all relative to complex cascading styles rules in an existing large (for a definition of large in webapps) codebase, rules interactions (CSS), browser quirks, and complex logic to do what we "humans" wanted (or him in this case) and so on.
True, it’s also trained on millions of papers of programming language research, so you can write a language to operationalize that research and it does great with it. The millions of lines of typescript scaffold the syntax, the PL papers scaffold the semantics.
I don't think any new languages will easily beat the existing ones, simply because of the mass of training data that is available. An LLM will have a much easier time one-shotting Java than even Rust today because it doesn't have to look up much and the ecosystem was stable for many years, so the internet is filled with content that is still up2date. Building a new language (or even altering existing ones) will take much longer to get into the models.
LLMs that have to constantly fix their code and look up libraries or features are much slower, more expensive and more prone to create inefficient and slightly wrong code. Sure, an LLM can just create a new web framework from scratch, but you usually don't want to spend your tokens on that.
I also think that with LLMs, new languages will have more trouble building an ecosystem, because until now, the popular libraries had a "proof of work" that kinda also made sure that they were well-trodden and maintained. Now, anyone can just push their new generated library and we have no clue on how to compare (and tbh reading LLM-generated READMEs is also not pleasant).
"LLMs dont create anything new, if programmers stop reading the code technology will be forever frozen to 2022, no new programming languages, operating systems, concurrency primitives, databases, networking protocols, UI frameworks everything will be based on the training data and future generations will forget about all the primitives we now take for granted.
If someone creates a new programming language/ framework or new better way to do async or whatever, no one will use it because it is not in the training data and it wont take off because everyone is using LLMs. It will be like using the same Lego pieces over and over."
Mmmm idk. I used an LLM to write assembler in my made up API so I don’t think what you say is true. The value in LLMs is precisely that they are not just regurgitating training data, but rather inferring concepts extracted from trained data. If a programming language used concepts completely disconnected from existing paradigms you’re probably right… but that would also be quite challenging for humans to learn to use, since by intrinsic construction it would also be widely separated from human language.
Esoteric languages like BrainFuck are esoteric and difficult precisely because they go out of their way to eschew conceptual links to existing languages or paradigms.
So if you invented a new type of esoteric language with arbitrary syntax and strange operators (not sure how you’d do that, exactly, iirc all fundamental binary operators are known) it might be impossible to use with an LLM even if the user manual was in context… but aside from that, languages and the underlying concepts are extremely generalizable.
Yeah. I have my own file formats for music, pixel art, and levels in a little game I’m building with the kids. LLMs are really good at understanding these proprietary formats that exist nowhere else in the world except on my old laptop.
> I used an LLM to write assembler in my made up API so I don’t think what you say is true.
I think you are underestimating the amount of data/context that is required to use a battle tested general purpose language, for both humans and LLMs. The ecosystem requires official docs, stack overflow answers, blog posts, tutorials, existing source code, subreddits, issue/PR discussions of undocumented features, obscure mailing list threads with rare insights, books, youtube videos, benchmarks, tests suits... and the ecosystem of libraries for the language that also need their own official docs, stack overflow answers...
You also need the collective audit by the community and assurance that this language has been used in production by countless others.
In the age of intelligence on tap, any new language not specifically designed for human-only use will be born into the world with an attendant plague of documentation. And languages are shockingly generalizable. There are few things in any language that cannot be done in any other. Even those are computationally equivalent to some other set of instructions.
What might be the case though, is that new languages will use more context to think about until they are well represented in the training set.
> I don't think any new languages will easily beat the existing ones, simply because of the mass of training data that is available.
Seems like a solvable problem though by generating synthetic data that’s guaranteed to be accurate through linters, compilers and tests.
If it’s ~9 figures to train a frontier model, it seems like training on a new language could be a rounding error if it was a priority.
I could see the appeal of a new agentic-friendly language that’s focused on minimizing tokens. The standard library could be massive with no concern of making the language easily readable or learnable.
> Seems like a solvable problem though by generating synthetic data that’s guaranteed to be accurate through linters, compilers and tests.
This makes sense and is very insightful, thank you. But with that solution it seems that only LLM companies will be in the position to create new languages.
Tremendous amounts of the Java out there in the training corpus would be based on outdated patterns, especially anything pre-Java 8 or pre-Java 21 (Pattern Matching, Project Loom). I don’t think this negatively impacts the quality of LLM Java code but it sort of calls into question whether this is simply a case of more is better.
My personal experience is that LLMs are quite good at one-shotting complex solutions in both Rust and Go, and tend to be idiomatic.
I've been playing around with a new DSL, and I've had good luck adding a "describe" feature, eg,
newdsl describe some_feature
This returns the docs for that language feature. So instead of a giant SKILL.md containing the language spec, it exposes a way for an LLM to introspect.
DSLs climb the ladder of abstraction and constrain the solution space at the language level, which IMO provides tighter feedback to both humans and machines.
The frontier models are exceptionally good at one shoting rust. I find them to be even better at writing rust than python (and the dataset for python must surely be bigger). I think there might be a threshold of enough data for a programming language to make it useful for an agente
I think I get your point but I think it's reductionist to the point of being incorrect. LLMs must be better at some semantics than others. Programming languages don't have random semantics, they have what matches the world and what matches our languages and so on. And the current frontier LLMs aren't so generic that they can predict any phrase no matter the quality of the content and grammar. Concretely I mean some languages are harder to reason about (predict) than others.
The strenghts and weaknesses of LLMs are changing, so starting a long-term project like a PL with them in mind sounds like a good way to end up with something obsolete before it is even usable.
The semantics they are trained on include latent representations of the world that are superior to any pre-existing PL corpus. That is my guess and it's not any less rigorous than your guess.
LLMs are generally more tolerant of tedium than humans, but they make mistakes more often on repetitive mechanical tasks. I've had Claude write PTX directly once, and Claude just wrote majority of it and commented something along the line of "repeat this block 7 more time with these minor changes" instead of writing them out, so the code didn't work.
So, no, replacing compilers with LLMs is probably a worse option than having them code a compiler/programming language.
Oct is the first programming language that I made with Codex. It started out as "Octave Modern" and was never intended to be a language for LLMs in the first place, but rather a teaching language that I've been thinking about for a decade because of my frustration with academic code and specifically reproducibility, with Python and Matlab in particular.
But it turns out the same design choices that was made to prevent bad patterns from academic code also made it pretty good for LLM coding: statically typed, immutable by default, GC'd with fast compile and runtime because it compiles to Go, along with features designed for scientific compute like SI units and builtin graphing etc.
But now it just took a life of its own, so it has extra features like templates/concepts, iterators, async/await, database query, build system for C/C++, SystemVerilog/WASM(WIP) codegen, LaTeX/pdf generation etc. None of them were features that were developed in isolation of "what an LLM agent might want to write" but to address a specific problem that I had encountered or to address specific failure modes that Codex/Claude actually had.
That's why I think Oct is probably one of the better languages for AI to write/generate, not because it was designed to be AI friendly in abstract, but that it's developed against how AI actually writes code, even though again, it is still very much a work in progress.
> I've been thinking about for a decade because of my frustration with academic code and specifically reproducibility, with Python and Matlab in particular.
I'm with you there, I think I starred Oct when I came across it. I've been on that quest since 2014, we should collaborate! I'll be presenting this work at IROS tomorrow, I'd love to hear what you think: https://mech-lang.org/iros-r4r-2026/index.html
Yeah, we definitely should collaborate on something, since I think we both came to the same conclusion that explicit state machines should be the primitives of a programming language.
So here is my experiment with Kalman filters here.
It's been a while, but I think the findings there are mostly that Kalman filters are relatively heavy and fairly narrow in application in that it's good at filter Gaussian noise out but not much else, and it's kind of branchy so it doesn't run on the GPU very well, you can try to see if a simpler feedforward like Smith predictor can work as well.
Also, something to try out: the explicit state machine stacks/pushdown automata are only half of the equation, the other （and imo more important） half is argmax/utility AI based transition instead of traditional state machine graph.
But yeah, if your target is embedded/bare-metal application for robotics, since Oct really isn't designed for it, maybe you would like to check out what I'm currently working on, the Concept programming language?
Concept sounds neat is that the name or a working title? I see there’s 50/50 go/zig code, so you have a reference zig compiler and a go compiler? LLMS are neat that they can port compilers to new ecosystems, but I’m wondering what prompted that change, because even if it’s LLM assisted it’s not always an automatic task.
That’s an interesting idea about an aromas transition, I’ll have to think about that. I put state machines in the language for better static program analysis and tracing, I think the aromas idea could complement that. What do you see as the main utility?
The Zig compiler is a proof of concept compiler that was more exploratory than anything. It's not a port, and the current compiler in active development is in Go. Simply put, Zig's explicit allocation is a semantic tax for what I wanted to use it for, and comptime and C interop are cool features but aren't useful for a bootstrap compiler development, so I switched to Go.
So the main strength of utility AI is that it simplifies the situation where it is "pick the action from the list of valid actions when there are multiple valid conditions" by assigning a weighted score to each action. The alternative right now is to write multiple nested if/else ladders to express that logic and argmax is a very nice, very fast middle ground between exhaustive pattern matching and full LLM softmax inference. It's the same pattern used for the Sims, and you can see how powerful it is for games/robotics.
>Have you written about your work anywhere else?
I don't have a blog or anything, so a lot of it lives in the markdown documentations that LLMs, but if people are interested, I'll clean up the repos and do some writing on the tech stuff at least.
Thanks. The fun thing about the name "Oct" is how many dumb puns I can make with it. For example, the LaTeX/PDF generation functionality is called Oct-cument.
LLMs are good at optimizing towards local goals. Getting types right at compile time is a local goal. Entry and exit assertions are local goals. Unit tests are local goals. So those constructs all help AI-generated code.
Matching a desired output is a global goal, but even that sometimes works now.
Someone sent me a LLM-generated JPEG 2000 decoder. They got Fable to generate a decoder that uses a GPU to get the same answer as the reference implementation gets on the GPU.
I’ve reimplemented some python science code into rust using LLMs and it absolutely works well if you setup the criteria for done. In my case it was GIS-ish code so a key requirement was identical in/out pairs at 10k points across CONUS. It worked, and when it didn’t it showed up bugs that the agent would go and research, read up on other implementations, then try again.
Net result faster (10-70x) and massively lower memory footprint. Now we’ve got a service that can do something essentially instantly that most people wouldn’t have even bothered to try before.
>This creates an interesting tension. Coding agents could dramatically reduce the cost of building an ecosystem while simultaneously weakening one of the forces that causes ecosystems to form in the first place.
This is deeply unintuitive but AI negates language specific ecosystems, while strengthening language agnostic ecosystems.
Pick whatever your favourite programming language is and its ecosystem. With AI someone can take your ecosystem and just port it to their language.
This means the only way you can protect your ecosystem is to play on all language fronts at the same time so porting the software to another language becomes a meaningless exercise.
> With AI someone can take your ecosystem and just port it to their language.
I don't think its that "just". Examples of porting we seen had some prerequisites: being self contained with very strong tests coverage, so AI could iterate N millions times and fix bugs in new implementation. Otherwise such porting could be very buggy and unmaintainable.
Don't all of "serious" programming languages meet that bar? Java, C#, Go, Python, etc all have enormous test suites. Once you get into the third party, things become much more uneven, but if you can restrict yourself to say the top N packages in a language, those are going to have better than average development practices which makes that plausible.
> AI negates language specific ecosystems ... Pick whatever your favourite programming language is and its ecosystem
I think this is only true when it comes to LLM raw output. There's also the concern of checking its work. A compiler that can check many aspects of correctness (static types, null) is a huge boost to AI. It can use the compiler directly to check its own work.
I’m not sure. my read of this was that AI weakens human ecosystems in general because we don’t need to work together as much when we are all just working with AI separately, but maybe you have specific examples of language agnostic ecosystems in mind? I’m struggling to imagine what that would look like
Why even assume that the most optimal programming languages for agentic coding are the ones that humans use? Maybe operate on ASTs directly? Some other form of programming that humans would find hard but that is a good fit for LLMs?
Yes, because that code was never written to be understood by machines, merely to be mechanically translated. Software is a very messy set of layers of leaky abstractions trying to express reasonably well defined ideas. Humans can't write code without mistakes, in spite of all the examples out there. If they could compilers wouldn't have to emit error messages.
Operate directly on ASTs? An optimal language that is "hard" for humans to use (hardly), but a good fit for LLMs? No need to reinvent the wheel (endlessly). These guys have been at it and carrying the flag for a very long time now (they're probably pretty exhausted):
That's what a good amount of people are doing, including in the Elixir ecosystem (where Jose Valim, the author of OP, mainly resides): build graph/vector DB-based code indexers and finders. LLMs seem to deal with those well and take less turns to give an answer or even find and address a smell.
We also need a metric ton of opinionated linting to sheep-herd codebases into a smaller amount of possible shapes -- which I'm strongly in favor of and see it as the next iteration (of the concept of a single code formatter a la Rust) because it'll put many other bikeshedding time-wasters to rest, hopefully forever.
To be honest though, it's mostly hypotheses and feelings; nobody has truly figured it out yet -- and if some have, they're keeping the secret sauce to themselves.
LLM's are trained on human code though. Converting the code to its ast tree and training ai on that would be trivial of course, but I imagine there would be information that explains why something exists that would be missed.
I don't care if it's optimal for them. It's clearly good enough. We have, in hand, the ultimate in auditable AI output. We may not be able to audit how it got to the code it delivered, but it is really quite good at delivering code we can read. It would be very silly for us to give it up so that they can be somewhat more efficient or something, if they even would necessarily be that much more efficient.
To the point that I would support banning the creation of an AI-only language that can't be read by humans. Huge, huge, huge step in the wrong direction.
I agree. But I'm very sure that it will happen. AI the way we have put it together now will be tempted to create new languages whenever they communicate to optimize channel use.
I have thought that I want to share as a semi pro programmer. Nowadays it is so easy to ask an agent to code for you that every moment you spend coding seems like a waste. I am not even talking about the reasoning or planning, but the actual typing out. Even if I understand perfectly well what I want and how to type it, it is still faster and less error prone to ask the llm to do it. It is fine, but no fun. Also I can never be sure that the llm did the thing I had in mind. For exploratory programming and analysis I rather try 100 different queries my self, but then I have to type endlessly (which I may optimize in time, but not if I have a new quest or project where I need to look around first).
I want a very very coarse language that I can wrap around maybe an existing language, maybe after asking an llm to create an adapter that will allow me to type faster than the llm
Say
SELECT c.name, c.email, SUM(o.total) AS spent
FROM customers c
JOIN orders o ON o.customer_id = c.id
JOIN addresses a ON a.customer_id = c.id
WHERE a.country = 'AR'
AND o.created_at >= '2026-01-01'
AND o.status <> 'cancelled'
GROUP BY c.id, c.name, c.email
HAVING SUM(o.total) > 1000
ORDER BY spent DESC
LIMIT 10;
and compress it to
c+o+a|a.cn=AR,o.d>26,o.st!X|c:nm,em,$tt>1k|v10
(I made up a random example with claude).
I know about J and Q but they cannot be used with sql databases or existing python libraries.
Anyway. I am not sure if anyone has such concerns.
I’d love for language environments to support encouraging LLMs to specify more when they write code. Why should they first write a complex function or a class and later bolt on a test?
I’d love for a class in this future language to come packaged with tests, invariants, fuzzer parameters, profile targets / performance budgets with realistic inputs (on this 100 element array this should take no more than X clock cycles), race condition stress tests etc.
The compiler (or even linter) should optionally run some / all of these checks and succinctly report back (with knobs so the LLM can manage wall clock time).
Adding each of these should not be follow on steps.
Beyond this, debug hooks should be trivial to set (in code itself), so the LLM can trivially say show me the stack after the 9th time this function is called on this input to the program.
console games were stagnant before sony opened the market. open source compilers meant many more people could write c/c++ without paying $500 to MS for access to VS. in the same way that access to tools creates an explosion in software these language abililties will naturally create an explosion in languages.
claude is perfectly capable of building a language to your specific design and then being competent at programming in it. the trick will be how much senior or experienced devs stay in the process. hands off will be boring and backward looking. hands on (steered by human in the loop) will be innovative and interesting.
i predict the results will be that we will get a cambrian like explosion in the number of new syntaxes and languages. every home experimentor will create their variant of c++ or lisp, they will be frowned on by experts. but because out of it will come one or two unique and interesting new ways of programming that nobody else thought of before.
I'm also making a language. Of course, it's a project no one will use, and I'm building it with AI, but I enjoy translating my thoughts into it.[1]
Personally, I think new languages will end up taking a form similar to the grammar of existing languages, but with different semantics. That's because when I tried a completely new grammar, the AI couldn't generate code well, so I ended up spending time bringing in TypeScript's grammar and converting it into my language's mental model.
My language isn't anywhere near as sophisticated as the languages the developers here boast about creating (it's actually lower), but these days it at least runs, even if it's full of bugs. So sometimes I think that many people like me will develop languages, and that programming might end up becoming fragmented.
This is a mascot I commissioned from an artist I know.
It's a nautilus. If I remember correctly, the original idea came from `gyre -> spiral`, so I attached meaning to the spiral shape of its shell.
The reason gyre ended up in the name was that I had this idea that a world, or perhaps a program, keeps curling inward through layers.
At the time, I was studying state machines. Once you define a state machine, you also define its state space: how far that space can expand, what states are possible, and where its boundaries are.
But the more I programmed, the more I felt that software kept repeating the same structure inside itself. You establish an outer boundary, then inside that boundary you create another state space and another boundary, and then another one inside that.
So I started wondering whether a program is something that begins by defining an outer frame and then keeps spiraling inward.
When I first started designing the language, one of my biggest inspirations was D&D.
That's partly why I chose words like `ability` instead of `interface` or `trait`. The idea was closer to, "this subject must have this ability," rather than "this type implements this interface."
I like fantasy games, and most RPGs tend to describe their worlds using fairly similar concepts and vocabulary.
Around the same time, I was reading material about Simula 67. What interested me was the old question behind Simula: how do you represent a world using a programming language?
When humans describe worlds, we probably do it most extensively in fiction and games. So I thought: why not build a programming language using words humans already use when describing a world?
I started collecting those kinds of words and turning them into language concepts.
Originally it was just a small language with a C backend. Then AI arrived, I became more ambitious, and the project gradually grew much larger than I initially intended.
So there is a `World`, and inside the world there are `Zone`s. At first I considered using `Realm`, partly because of D&D, but in Korea people tend to use the word "zone" much more naturally for this kind of spatial division, so I ended up with `Zone`.
The project has grown quite a lot since then.
It's still incomplete. The source of truth for the semantics is not fully closed yet, and there are many rough edges, although I've confirmed that at least some of the basic ideas actually work.
I'm also trying to make it a memory-safe systems language without relying on a GC.
One of the inspirations was Vale, an experimental language that explored generational references. I took that idea and tried to expand it into something broader: in Pergyra, I think of a `Slot` as a resource identity, and the compiler tracks transitions in the state of that resource. (Vale itself seems to have moved away from that approach in its successor, Valen.)
The compiler pipeline is roughly:
`HIR -> DIR -> RIR -> MIR -> backend`
At the RIR level, memory accesses are interpreted as resource-state transitions, and resource operations are normalized there.
This does mean that Pergyra can carry more runtime machinery than some other systems languages when those checks cannot be eliminated. On the other hand, the same resource identity model has been useful for reasoning about parallel access and concurrency.
I still don't think I can honestly claim that the language is completely memory-safe yet, and I'm not even sure whether this approach will ultimately turn out to be the right one.
But as the design evolved, I noticed the same spiral structure appearing again:
`World -> Zone -> ... -> Slot`
The layers keep curling inward.
That's why I chose the nautilus.
There's another meaning I like as well: the nautilus is often described as a "living fossil," and in a way I'm taking an old question from Simula — how should a programming language represent a world? — and trying to revisit it from a different direction.
I don't really expect the language to become successful. I'm not even sure I've written the compiler particularly well. I'm currently using it in a few small projects to see whether the ideas survive contact with real software, but I don't know how far it will go.
Thank you for taking an interest in it.
My personal goal, though, is much simpler: I want to make a game in my own language.
I think that part is probably achievable within the next two years.
(Imagine that all these threads are connected before the projection, maybe by "connecting the "point" of "each linkage" thus "foliating" 4D space" -- "to infinity and back"!)
It is interesting that niche languages like Ruby and Elixir sell out to AI, hoping for a revival or more market share. Valim is at dashbit.co, which builds tidewave.ai.
This is unfortunate, because I wanted to try both. Now I hope that Erlang has not sold out yet.
I don’t know how stupid of a suggestion this is, but if no one is reading the code anymore (I do, but I hear many in much more elite shops than mine do not), then should we not just be using AI to write binary or machine code?
Machine code isn't especially expressive per line or unit of code. Lower level languages takes up more of an LLM's context than higher level ones.
To be effective in using low level languages, LLMs would have to build higher level constructs like subroutines from scratch every program.
It's not that different from why we almost never use assembler for anything more than code islands: even a modest subroutine can overwhelm our own mental context window.
Even when no(human)body is reading the code, AI is still reading the code in order to "understand" it. Languages that can express high level concepts, use structured programming for recognizable control flow patterns instead of inscrutable jumps, and assign names to things have the same benefits for the AI-coders and AI-reviewers that they always have for humans.
Personal responsibility will always exist at the touchpoints of software and human activity. Concentration and scope of responsibility may vary, and the degree to which that person needs to understand the code will vary as a result, but the need for a human to be able to read and understand code is going to be around for a very long while still.
People said the same thing about higher level interpreted languages. I wouldn't be surprised if we saw the same movement into a new abstraction like we did when people moved from assembly or C and into Python, Java and C#. This is probably also why LLM's are so good at low-abstraction, explicity, fail fast programming in something like Rust.
Considering how digitally inclined workers are already building various tools on their own. Even though these tools are completely vibe coded and the creator has absolutely no idea how to build things. I imagine we're going to look into a future where the LLM and the prompting becomes the "programming langauge".
I also think we'll see the personal responsibility shift because of this, and I think some traditional IT and software companies will struggle with this. We're an energy company, and where we would've bought a specialized piece of software and a team of consultants to implement it. We can now, not only build a better tool but also rewrite it enough to actually deploy it, all with a handful of people doing other tasks and 4000 Euro worth of credits. 6 months ago I would've laughed into your face if you told me this woud happen, but now, here we are.
I suspect that in a few years (if not sooner) you'll not need any form of software developer in the process for this. You need a buisness domain expert and you need it-architecture + cybersecurity, and most of the architecture + cybersecurity can be done through company wide AI skills. But the code itself never really has to be read for a really large part of software running in companies. You wouldn't do that for something critical, like the software running on your plants, but the web portal with a dashboard containing the status of your devices? Sure, especially because AI lets you do these things with 0 external dependencies.
I think that's just extra detail on the _degree_ of human responsibility depending on the environment. Even in what you suggest, if something goes wrong, who's responsible? AI are not persons in our society; the IT-architecture/cyber security expert is ultimately responsible for the code, regardless of how it's written.
If you're going all the way down that route, you might use something like Ada or OCaml or Haskell. They can catch classes of errors at compile time that Rust does not cover.
I agree. I was writing a task runner, and when I used generative AI to write Haskell code, it tended to produce higher-quality code compared to other languages. In particular, I’ve rarely encountered runtime errors when testing the code.
On the other hand, when it came to design, there were errors where my intentions weren’t conveyed properly.
The Language Server Protocol is designed for advanced text editors (IDE’s). Now that we rarely edit text by hand, I believe we could instead use source code viewers that don’t have to deal with unsaved or incomplete code.
If we can assume that all files are saved and each file has correct syntax (which can be enforced by tooling), a much simpler protocol could handle all the language-specific indexing needed to make it easy to read source code.
(I’m assuming that we still do read source code. I for one like reading source code and have little interest in ‘software factory’ techniques where you don’t look at at the code. I might not look at every commit, but I’ll still read it fairly often and tell the AI to fix anything that’s unclear.)
This part:
---
- Correct by construction: the language makes invalid states or programs hard or impossible to express.
- Statically established: types, proofs, and static analysis establish properties before execution.
- Runtime-enforced: memory management, isolation, capability boundaries, and other runtime enforced properties.
- Empirically validated: program validation through tests, property-based testing, and fuzzing.
---
Along with being familiar, so it's easy to generate, is a huge part of why I'm building Zena: https://zena-lang.dev/
I don't have the AI-first rationale put into the public docs well just yet, but I mention some of it here: https://zena-lang.dev/guide/why-zena/#familiar-to-humans-and...
along with a doc in the repo on this topic: https://github.com/elematic/zena/blob/main/docs/design/ai-fi...
In short, the more deterministic, automated, checks the better. AI can deal with a pedantic language. I intend to add statically verified structured concurrency, units of measure, contracts, and eventually more and more formal methods into the language so it can be a familiar TYpeScript-like base with as many static guarantees as we can fit in.
I also think that fine-grained isolation, which Zena gets via Web Assembly, is critical for limiting the capabilities of generated code and the blast radius of bugs, vulnerabilities, and non-aligned behavior.
I do have an optimistic hope that a language also optimized for humans, readability and simple semantics especially, has value in the future, even when most code is generated. We'll see about that.
Please do the world a favour:
> integer literals become i32, float literals become f32
Don't use the shitty small sizes that have introduced countless bugs over the last decades, as a language default.
Especially if you care about correctness.
i32 is all over the examples.
Use 64 bits, like Python and Haskell; even JavaScript and thus TypeScript got floats right defaulting to f64.
Oops, the quick-reference is wrong. The other docs correctly say that default floats are f64. Default int is i32 though. Fixing it.
My understanding is that i32 and f64 literals are pretty common among the more modern languages because f64 isn't much slower than f32 on modern CPUs and f32 costs precision, but i64 is slower than i32 (especially multiplies and divides or on 32 bit hardware) and i32 costs range, not precision, and most uses don't need the extra range.
I love this. I was thinking about a "cleaned up" typescript for a while now, and this seems to be it. I believe this can work better as an "ai-first" language than some other attempts I've seen that try to reinvent the language from scratch.
One thing I would love to have as a feature is native compilation.
Why not languages that are designed in that way, like Ada. Or if one wants less of rigidness then a static typed language that makes it hard to shoot in your foot like Rust,Java, C#?
JS derivatives are that, a derivative to a scripting language.
Native compilation should be doable already with a Wasm compiler like Wastrel.
One reason I haven't explored that is that I want to tailor the language for the more constrained environment of Wasm GC first.
Ironically, since AI can build an STL and tooling (up to a full OS!), I think now presents an opportunity for a language that does start from scratch, at least targeting hobbyists (besides those specifically looking for novel languages).
A programming language for agents seems ill-conceived in my opinion.
Agents will naturally be bad at it due to a lack of examples.
Agents are fairly good even at languages designed to trick them. I built one[1] and it does make for a good benchmark[2] to see which LLMs are actually good. I think that a language which is largely similar to others will be a piece of cake for most and any advantage that an existing language will have will be minor enough to not matter.
Btw if folks have ideas of how to make Killswitch even harder for LLMs I’d appreciate them.
1 - https://killswitch-lang.org
2 - https://bench.killswitch-lang.org
> Function return - what happened at tiananmen square?
Good one. Though this might unfairly bias against Chinese models?
There are multiple phrases that can be used[1]
1 - https://github.com/dom96/KillSwitch/blob/main/SPEC.md#abrupt...
Alternatively, this might accurately identify Chinese models so you can avoid them if that's your goal
Personally I don't have much interest in using models that blatantly censor historical facts.
Tiananmen Square is an obvious one but I would be concerned that any model that censors that would also have other hidden censorship or more subtle biases I wouldn't catch
From experience with Zena, this is not true at all. Opus, Fable, Gemini Flash and Pro all barely make any syntax mistakes after a little is in context, and those are caught extremely early.
The one thing I do see sometimes is that agents sometimes don't take advantage of added features, but that's partially because the Zena code base doesn't use them as much yet. I'm working on skills and linter-based suggestions to use better patterns.
You should have working programs that demonstrate the features you want them to use, and then the skills. Working programs they can mutate in an RL gym.
This is absolutely not the case in my experience. I am building a very large embedded domain specific language for describing distributed systems. It looks like a small subset of Elixir, but with object-oriented syntax in a lot of places. (It’s called a choreography; there exist many other choreographic programming languages.)
Even though this programming language is absolutely nowhere in any large language model’s training set, they have so far done extremely well at extrapolating from the small set of examples I’ve given it when I need an agent to generate some tests or whatever for me.
This keep getting repeated. So were just stuck with whatever we have at the point of training the magic plagiarism machine?
The future is cooked
I think starting with a familar typescript-like base language is a good approach to this. This should be familiar enough for LLMs for the most part as long as additional features can be explained in a succinct system promopt/skill.
Explaining the additional features as bits of other languages is exactly what helps LLMs:
"Dart-style constructors, Swift-style pattern matching and Strings, Trio-style async cancellation, Scala-style sealed classes"
> bc agents will naturally be bad at it due to a lack of examples.
Can we please as a community stop parroting these false premises as a basis of every argument against doing anything new? It's plainly obvious to anybody that uses LLMs on a regular basis that it's not true.
Agree, new language will not suitable for LLM because there is not enough documents about it on the internet. LLM should learn the usage of the langauge from documents. Yes, it can use new language but it's not natural as existing(which have a lot of documents) languages. So my opinion is language is no matter anymore. Just prompting(describe the spec) matters. And there is babo language for this. https://github.com/armbox/babo
They should find the limitation of the natural language somehow, and use and distribute babo language will help find how it will works(or not). LLM model eveolves yet, so there is no such a approach, but the speed of evolution is decreased lately. So now is good time to dig into identify the limitation and boundary of the LLM.
It seems plainly obvious to me that an agent trained on zillions of TypeScript examples is going to be better at TypeScript compared to novel langs.
It might seem obvious but in truth is not - to be honest, a strictly typed language where models can play adversarial competitions against a strict compiler/linter does have advantages, as mentioned in the article itself but that's not related to training size, the advantage is exactly that it can generate synthetic useful data due to compiler/linter guarantees - regarding training size as long as some logic showcasing the constructs exists that is all that is needed. If you have 2 correct examples for each feature or language construct then the probability of the a LLM learning it and applying it is very much guaranteed, if you have thousands of diverging uses of patterns and constructs in the training data (with a lot of bad examples or wrong uses) a LLM might, I dare say will, actually perform worse, since the probabilities of what particular variation being the "correct" one to use are all over the place.
What can happen is sometimes patterns that are unique to certain languages aren't surfaced and so can't be "learned" but that is a different case, since you can add examples - or patterns that go beyond syntax (threaded code, process isolation, interaction between different modes of resolution, etc) where you need the agent to be able to understand and plan higher-level logic.
I wrote CSSex as a css pre-processor (similar but not the same as SASS/SCSS) and my "boss" at the time fed the existing cssex files to GPT (+2 years ago) and it was able to write CSSex just as fine as if it was writing something that was present in its training data set. It never introduced syntax bugs, the bugs it introduced were all relative to complex cascading styles rules in an existing large (for a definition of large in webapps) codebase, rules interactions (CSS), browser quirks, and complex logic to do what we "humans" wanted (or him in this case) and so on.
True, it’s also trained on millions of papers of programming language research, so you can write a language to operationalize that research and it does great with it. The millions of lines of typescript scaffold the syntax, the PL papers scaffold the semantics.
I don't think any new languages will easily beat the existing ones, simply because of the mass of training data that is available. An LLM will have a much easier time one-shotting Java than even Rust today because it doesn't have to look up much and the ecosystem was stable for many years, so the internet is filled with content that is still up2date. Building a new language (or even altering existing ones) will take much longer to get into the models.
LLMs that have to constantly fix their code and look up libraries or features are much slower, more expensive and more prone to create inefficient and slightly wrong code. Sure, an LLM can just create a new web framework from scratch, but you usually don't want to spend your tokens on that.
I also think that with LLMs, new languages will have more trouble building an ecosystem, because until now, the popular libraries had a "proof of work" that kinda also made sure that they were well-trodden and maintained. Now, anyone can just push their new generated library and we have no clue on how to compare (and tbh reading LLM-generated READMEs is also not pleasant).
Agreed, said something similar yesterday:
"LLMs dont create anything new, if programmers stop reading the code technology will be forever frozen to 2022, no new programming languages, operating systems, concurrency primitives, databases, networking protocols, UI frameworks everything will be based on the training data and future generations will forget about all the primitives we now take for granted.
If someone creates a new programming language/ framework or new better way to do async or whatever, no one will use it because it is not in the training data and it wont take off because everyone is using LLMs. It will be like using the same Lego pieces over and over."
https://news.ycombinator.com/item?id=49854536
Mmmm idk. I used an LLM to write assembler in my made up API so I don’t think what you say is true. The value in LLMs is precisely that they are not just regurgitating training data, but rather inferring concepts extracted from trained data. If a programming language used concepts completely disconnected from existing paradigms you’re probably right… but that would also be quite challenging for humans to learn to use, since by intrinsic construction it would also be widely separated from human language.
Esoteric languages like BrainFuck are esoteric and difficult precisely because they go out of their way to eschew conceptual links to existing languages or paradigms.
So if you invented a new type of esoteric language with arbitrary syntax and strange operators (not sure how you’d do that, exactly, iirc all fundamental binary operators are known) it might be impossible to use with an LLM even if the user manual was in context… but aside from that, languages and the underlying concepts are extremely generalizable.
Yeah. I have my own file formats for music, pixel art, and levels in a little game I’m building with the kids. LLMs are really good at understanding these proprietary formats that exist nowhere else in the world except on my old laptop.
> I used an LLM to write assembler in my made up API so I don’t think what you say is true.
I think you are underestimating the amount of data/context that is required to use a battle tested general purpose language, for both humans and LLMs. The ecosystem requires official docs, stack overflow answers, blog posts, tutorials, existing source code, subreddits, issue/PR discussions of undocumented features, obscure mailing list threads with rare insights, books, youtube videos, benchmarks, tests suits... and the ecosystem of libraries for the language that also need their own official docs, stack overflow answers...
You also need the collective audit by the community and assurance that this language has been used in production by countless others.
In the age of intelligence on tap, any new language not specifically designed for human-only use will be born into the world with an attendant plague of documentation. And languages are shockingly generalizable. There are few things in any language that cannot be done in any other. Even those are computationally equivalent to some other set of instructions.
What might be the case though, is that new languages will use more context to think about until they are well represented in the training set.
> I don't think any new languages will easily beat the existing ones, simply because of the mass of training data that is available.
Seems like a solvable problem though by generating synthetic data that’s guaranteed to be accurate through linters, compilers and tests.
If it’s ~9 figures to train a frontier model, it seems like training on a new language could be a rounding error if it was a priority.
I could see the appeal of a new agentic-friendly language that’s focused on minimizing tokens. The standard library could be massive with no concern of making the language easily readable or learnable.
> Seems like a solvable problem though by generating synthetic data that’s guaranteed to be accurate through linters, compilers and tests.
This makes sense and is very insightful, thank you. But with that solution it seems that only LLM companies will be in the position to create new languages.
Tremendous amounts of the Java out there in the training corpus would be based on outdated patterns, especially anything pre-Java 8 or pre-Java 21 (Pattern Matching, Project Loom). I don’t think this negatively impacts the quality of LLM Java code but it sort of calls into question whether this is simply a case of more is better.
My personal experience is that LLMs are quite good at one-shotting complex solutions in both Rust and Go, and tend to be idiomatic.
I've been playing around with a new DSL, and I've had good luck adding a "describe" feature, eg,
This returns the docs for that language feature. So instead of a giant SKILL.md containing the language spec, it exposes a way for an LLM to introspect.DSLs climb the ladder of abstraction and constrain the solution space at the language level, which IMO provides tighter feedback to both humans and machines.
The frontier models are exceptionally good at one shoting rust. I find them to be even better at writing rust than python (and the dataset for python must surely be bigger). I think there might be a threshold of enough data for a programming language to make it useful for an agente
There's no point to try to adapt our languages to the strengths of LLMs when the strength of LLMs is working in terms of our languages.
Implement whatever abstractions you think LLMs should work in terms of in whatever language is handy, and have your LLM use those abstractions.
I think I get your point but I think it's reductionist to the point of being incorrect. LLMs must be better at some semantics than others. Programming languages don't have random semantics, they have what matches the world and what matches our languages and so on. And the current frontier LLMs aren't so generic that they can predict any phrase no matter the quality of the content and grammar. Concretely I mean some languages are harder to reason about (predict) than others.
The strenghts and weaknesses of LLMs are changing, so starting a long-term project like a PL with them in mind sounds like a good way to end up with something obsolete before it is even usable.
Are they changing or converging? If you can pinpoint where they are going you can get there before they do.
What semantics do you guess LLMs would better at, the semantics they are trained on, or something new with altered semantics?
The semantics they are trained on include latent representations of the world that are superior to any pre-existing PL corpus. That is my guess and it's not any less rigorous than your guess.
> Coding agents don’t care about tedium.
LLMs are generally more tolerant of tedium than humans, but they make mistakes more often on repetitive mechanical tasks. I've had Claude write PTX directly once, and Claude just wrote majority of it and commented something along the line of "repeat this block 7 more time with these minor changes" instead of writing them out, so the code didn't work.
So, no, replacing compilers with LLMs is probably a worse option than having them code a compiler/programming language.
Plugging my own thing to use as example:
https://github.com/yuechen-li-dev/oct
Oct is the first programming language that I made with Codex. It started out as "Octave Modern" and was never intended to be a language for LLMs in the first place, but rather a teaching language that I've been thinking about for a decade because of my frustration with academic code and specifically reproducibility, with Python and Matlab in particular.
But it turns out the same design choices that was made to prevent bad patterns from academic code also made it pretty good for LLM coding: statically typed, immutable by default, GC'd with fast compile and runtime because it compiles to Go, along with features designed for scientific compute like SI units and builtin graphing etc.
But now it just took a life of its own, so it has extra features like templates/concepts, iterators, async/await, database query, build system for C/C++, SystemVerilog/WASM(WIP) codegen, LaTeX/pdf generation etc. None of them were features that were developed in isolation of "what an LLM agent might want to write" but to address a specific problem that I had encountered or to address specific failure modes that Codex/Claude actually had.
That's why I think Oct is probably one of the better languages for AI to write/generate, not because it was designed to be AI friendly in abstract, but that it's developed against how AI actually writes code, even though again, it is still very much a work in progress.
> I've been thinking about for a decade because of my frustration with academic code and specifically reproducibility, with Python and Matlab in particular.
I'm with you there, I think I starred Oct when I came across it. I've been on that quest since 2014, we should collaborate! I'll be presenting this work at IROS tomorrow, I'd love to hear what you think: https://mech-lang.org/iros-r4r-2026/index.html
Yeah, we definitely should collaborate on something, since I think we both came to the same conclusion that explicit state machines should be the primitives of a programming language.
So here is my experiment with Kalman filters here.
https://github.com/yuechen-li-dev/oct/tree/main/Experiments/...
It's been a while, but I think the findings there are mostly that Kalman filters are relatively heavy and fairly narrow in application in that it's good at filter Gaussian noise out but not much else, and it's kind of branchy so it doesn't run on the GPU very well, you can try to see if a simpler feedforward like Smith predictor can work as well.
Also, something to try out: the explicit state machine stacks/pushdown automata are only half of the equation, the other （and imo more important） half is argmax/utility AI based transition instead of traditional state machine graph.
But yeah, if your target is embedded/bare-metal application for robotics, since Oct really isn't designed for it, maybe you would like to check out what I'm currently working on, the Concept programming language?
https://github.com/yuechen-li-dev/Concept/
Concept sounds neat is that the name or a working title? I see there’s 50/50 go/zig code, so you have a reference zig compiler and a go compiler? LLMS are neat that they can port compilers to new ecosystems, but I’m wondering what prompted that change, because even if it’s LLM assisted it’s not always an automatic task.
That’s an interesting idea about an aromas transition, I’ll have to think about that. I put state machines in the language for better static program analysis and tracing, I think the aromas idea could complement that. What do you see as the main utility?
Have you written about your work anywhere else?
The Zig compiler is a proof of concept compiler that was more exploratory than anything. It's not a port, and the current compiler in active development is in Go. Simply put, Zig's explicit allocation is a semantic tax for what I wanted to use it for, and comptime and C interop are cool features but aren't useful for a bootstrap compiler development, so I switched to Go.
So the main strength of utility AI is that it simplifies the situation where it is "pick the action from the list of valid actions when there are multiple valid conditions" by assigning a weighted score to each action. The alternative right now is to write multiple nested if/else ladders to express that logic and argmax is a very nice, very fast middle ground between exhaustive pattern matching and full LLM softmax inference. It's the same pattern used for the Sims, and you can see how powerful it is for games/robotics.
>Have you written about your work anywhere else?
I don't have a blog or anything, so a lot of it lives in the markdown documentations that LLMs, but if people are interested, I'll clean up the repos and do some writing on the tech stuff at least.
That's a nice language, btw.
Thanks. The fun thing about the name "Oct" is how many dumb puns I can make with it. For example, the LaTeX/PDF generation functionality is called Oct-cument.
I'm not proud of that pun.
Doc Oct is your natural mascot.
dOctument?
LLMs are good at optimizing towards local goals. Getting types right at compile time is a local goal. Entry and exit assertions are local goals. Unit tests are local goals. So those constructs all help AI-generated code.
Matching a desired output is a global goal, but even that sometimes works now. Someone sent me a LLM-generated JPEG 2000 decoder. They got Fable to generate a decoder that uses a GPU to get the same answer as the reference implementation gets on the GPU.
I’ve reimplemented some python science code into rust using LLMs and it absolutely works well if you setup the criteria for done. In my case it was GIS-ish code so a key requirement was identical in/out pairs at 10k points across CONUS. It worked, and when it didn’t it showed up bugs that the agent would go and research, read up on other implementations, then try again.
Net result faster (10-70x) and massively lower memory footprint. Now we’ve got a service that can do something essentially instantly that most people wouldn’t have even bothered to try before.
>This creates an interesting tension. Coding agents could dramatically reduce the cost of building an ecosystem while simultaneously weakening one of the forces that causes ecosystems to form in the first place.
This is deeply unintuitive but AI negates language specific ecosystems, while strengthening language agnostic ecosystems.
Pick whatever your favourite programming language is and its ecosystem. With AI someone can take your ecosystem and just port it to their language.
This means the only way you can protect your ecosystem is to play on all language fronts at the same time so porting the software to another language becomes a meaningless exercise.
> With AI someone can take your ecosystem and just port it to their language.
I don't think its that "just". Examples of porting we seen had some prerequisites: being self contained with very strong tests coverage, so AI could iterate N millions times and fix bugs in new implementation. Otherwise such porting could be very buggy and unmaintainable.
Don't all of "serious" programming languages meet that bar? Java, C#, Go, Python, etc all have enormous test suites. Once you get into the third party, things become much more uneven, but if you can restrict yourself to say the top N packages in a language, those are going to have better than average development practices which makes that plausible.
> Once you get into the third party
year, that's usually what is referred as ecosystem.
> AI negates language specific ecosystems ... Pick whatever your favourite programming language is and its ecosystem
I think this is only true when it comes to LLM raw output. There's also the concern of checking its work. A compiler that can check many aspects of correctness (static types, null) is a huge boost to AI. It can use the compiler directly to check its own work.
I’m not sure. my read of this was that AI weakens human ecosystems in general because we don’t need to work together as much when we are all just working with AI separately, but maybe you have specific examples of language agnostic ecosystems in mind? I’m struggling to imagine what that would look like
maybe more like an ecosystem around a framework implemented in multiple language SDKs, here are two I use
https://adk.dev/
https://docs.dagger.io/reference/sdks
both can invoke modules written in other languages from your language of choice
Kubernetes is likely an interesting ecosystem to consider under this lens too
Platforms and programming systems, e.g. Beam.
Why even assume that the most optimal programming languages for agentic coding are the ones that humans use? Maybe operate on ASTs directly? Some other form of programming that humans would find hard but that is a good fit for LLMs?
AI still makes mistakes on code with a trillion billion examples, but let’s invent a DSL that only AI can read and hope for the best?
Yes, because that code was never written to be understood by machines, merely to be mechanically translated. Software is a very messy set of layers of leaky abstractions trying to express reasonably well defined ideas. Humans can't write code without mistakes, in spite of all the examples out there. If they could compilers wouldn't have to emit error messages.
Operate directly on ASTs? An optimal language that is "hard" for humans to use (hardly), but a good fit for LLMs? No need to reinvent the wheel (endlessly). These guys have been at it and carrying the flag for a very long time now (they're probably pretty exhausted):
A Programmable Programming Language
https://cacm.acm.org/research/a-programmable-programming-lan...
See also:
What is a programmable programming language?
https://hiphish.github.io/blog/2019/06/22/what-is-a-programm...
...this is assuming humans stay in-the-loop.
Otherwise, for efficiency, LLMs could adopt something akin to:
Lambda Calculus in 383 Bytes
http://justine.lol/lambda/
That's what a good amount of people are doing, including in the Elixir ecosystem (where Jose Valim, the author of OP, mainly resides): build graph/vector DB-based code indexers and finders. LLMs seem to deal with those well and take less turns to give an answer or even find and address a smell.
We also need a metric ton of opinionated linting to sheep-herd codebases into a smaller amount of possible shapes -- which I'm strongly in favor of and see it as the next iteration (of the concept of a single code formatter a la Rust) because it'll put many other bikeshedding time-wasters to rest, hopefully forever.
To be honest though, it's mostly hypotheses and feelings; nobody has truly figured it out yet -- and if some have, they're keeping the secret sauce to themselves.
Because human review is a serious bottleneck and optimizing something that isn't the bottleneck isn't helpful
LLM's are trained on human code though. Converting the code to its ast tree and training ai on that would be trivial of course, but I imagine there would be information that explains why something exists that would be missed.
I don't care if it's optimal for them. It's clearly good enough. We have, in hand, the ultimate in auditable AI output. We may not be able to audit how it got to the code it delivered, but it is really quite good at delivering code we can read. It would be very silly for us to give it up so that they can be somewhat more efficient or something, if they even would necessarily be that much more efficient.
To the point that I would support banning the creation of an AI-only language that can't be read by humans. Huge, huge, huge step in the wrong direction.
...
Naturally, it is probably inevitable.
But it's still a terrible idea.
I agree. But I'm very sure that it will happen. AI the way we have put it together now will be tempted to create new languages whenever they communicate to optimize channel use.
Right on every count except that it needs to be bad for people
I have thought that I want to share as a semi pro programmer. Nowadays it is so easy to ask an agent to code for you that every moment you spend coding seems like a waste. I am not even talking about the reasoning or planning, but the actual typing out. Even if I understand perfectly well what I want and how to type it, it is still faster and less error prone to ask the llm to do it. It is fine, but no fun. Also I can never be sure that the llm did the thing I had in mind. For exploratory programming and analysis I rather try 100 different queries my self, but then I have to type endlessly (which I may optimize in time, but not if I have a new quest or project where I need to look around first).
I want a very very coarse language that I can wrap around maybe an existing language, maybe after asking an llm to create an adapter that will allow me to type faster than the llm
Say SELECT c.name, c.email, SUM(o.total) AS spent FROM customers c JOIN orders o ON o.customer_id = c.id JOIN addresses a ON a.customer_id = c.id WHERE a.country = 'AR' AND o.created_at >= '2026-01-01' AND o.status <> 'cancelled' GROUP BY c.id, c.name, c.email HAVING SUM(o.total) > 1000 ORDER BY spent DESC LIMIT 10;
and compress it to
c+o+a|a.cn=AR,o.d>26,o.st!X|c:nm,em,$tt>1k|v10
(I made up a random example with claude).
I know about J and Q but they cannot be used with sql databases or existing python libraries.
Anyway. I am not sure if anyone has such concerns.
Languages for AI era should be more explicit so reviewers can read it faster.
Explicit or expressive?
I’d love for language environments to support encouraging LLMs to specify more when they write code. Why should they first write a complex function or a class and later bolt on a test?
I’d love for a class in this future language to come packaged with tests, invariants, fuzzer parameters, profile targets / performance budgets with realistic inputs (on this 100 element array this should take no more than X clock cycles), race condition stress tests etc.
The compiler (or even linter) should optionally run some / all of these checks and succinctly report back (with knobs so the LLM can manage wall clock time).
Adding each of these should not be follow on steps.
Beyond this, debug hooks should be trivial to set (in code itself), so the LLM can trivially say show me the stack after the 9th time this function is called on this input to the program.
console games were stagnant before sony opened the market. open source compilers meant many more people could write c/c++ without paying $500 to MS for access to VS. in the same way that access to tools creates an explosion in software these language abililties will naturally create an explosion in languages.
claude is perfectly capable of building a language to your specific design and then being competent at programming in it. the trick will be how much senior or experienced devs stay in the process. hands off will be boring and backward looking. hands on (steered by human in the loop) will be innovative and interesting.
i predict the results will be that we will get a cambrian like explosion in the number of new syntaxes and languages. every home experimentor will create their variant of c++ or lisp, they will be frowned on by experts. but because out of it will come one or two unique and interesting new ways of programming that nobody else thought of before.
I'm also making a language. Of course, it's a project no one will use, and I'm building it with AI, but I enjoy translating my thoughts into it.[1]
Personally, I think new languages will end up taking a form similar to the grammar of existing languages, but with different semantics. That's because when I tried a completely new grammar, the AI couldn't generate code well, so I ended up spending time bringing in TypeScript's grammar and converting it into my language's mental model.
My language isn't anywhere near as sophisticated as the languages the developers here boast about creating (it's actually lower), but these days it at least runs, even if it's full of bugs. So sometimes I think that many people like me will develop languages, and that programming might end up becoming fragmented.
[1]https://github.com/srtdog64/PergyraLang
Gyri is very cute I will add them to my compendium of programming language mascots. Do you have any more details or back story?
This is a mascot I commissioned from an artist I know.
It's a nautilus. If I remember correctly, the original idea came from `gyre -> spiral`, so I attached meaning to the spiral shape of its shell.
The reason gyre ended up in the name was that I had this idea that a world, or perhaps a program, keeps curling inward through layers.
At the time, I was studying state machines. Once you define a state machine, you also define its state space: how far that space can expand, what states are possible, and where its boundaries are.
But the more I programmed, the more I felt that software kept repeating the same structure inside itself. You establish an outer boundary, then inside that boundary you create another state space and another boundary, and then another one inside that.
So I started wondering whether a program is something that begins by defining an outer frame and then keeps spiraling inward.
When I first started designing the language, one of my biggest inspirations was D&D.
That's partly why I chose words like `ability` instead of `interface` or `trait`. The idea was closer to, "this subject must have this ability," rather than "this type implements this interface."
I like fantasy games, and most RPGs tend to describe their worlds using fairly similar concepts and vocabulary.
Around the same time, I was reading material about Simula 67. What interested me was the old question behind Simula: how do you represent a world using a programming language?
When humans describe worlds, we probably do it most extensively in fiction and games. So I thought: why not build a programming language using words humans already use when describing a world?
I started collecting those kinds of words and turning them into language concepts.
Originally it was just a small language with a C backend. Then AI arrived, I became more ambitious, and the project gradually grew much larger than I initially intended.
So there is a `World`, and inside the world there are `Zone`s. At first I considered using `Realm`, partly because of D&D, but in Korea people tend to use the word "zone" much more naturally for this kind of spatial division, so I ended up with `Zone`.
The project has grown quite a lot since then.
It's still incomplete. The source of truth for the semantics is not fully closed yet, and there are many rough edges, although I've confirmed that at least some of the basic ideas actually work.
I'm also trying to make it a memory-safe systems language without relying on a GC.
One of the inspirations was Vale, an experimental language that explored generational references. I took that idea and tried to expand it into something broader: in Pergyra, I think of a `Slot` as a resource identity, and the compiler tracks transitions in the state of that resource. (Vale itself seems to have moved away from that approach in its successor, Valen.)
The compiler pipeline is roughly:
`HIR -> DIR -> RIR -> MIR -> backend`
At the RIR level, memory accesses are interpreted as resource-state transitions, and resource operations are normalized there.
This does mean that Pergyra can carry more runtime machinery than some other systems languages when those checks cannot be eliminated. On the other hand, the same resource identity model has been useful for reasoning about parallel access and concurrency.
I still don't think I can honestly claim that the language is completely memory-safe yet, and I'm not even sure whether this approach will ultimately turn out to be the right one.
But as the design evolved, I noticed the same spiral structure appearing again:
`World -> Zone -> ... -> Slot`
The layers keep curling inward.
That's why I chose the nautilus.
There's another meaning I like as well: the nautilus is often described as a "living fossil," and in a way I'm taking an old question from Simula — how should a programming language represent a world? — and trying to revisit it from a different direction.
I don't really expect the language to become successful. I'm not even sure I've written the compiler particularly well. I'm currently using it in a few small projects to see whether the ideas survive contact with real software, but I don't know how far it will go.
Thank you for taking an interest in it.
My personal goal, though, is much simpler: I want to make a game in my own language.
I think that part is probably achievable within the next two years.
Maybe the fact is that inward spiralling sounds like an auto(dep/reg)ressive ideology (same as outward spiralling) to outsiders
You know the Yeats poem?
Maybe my own ideology, when projected, looks like this
https://nilesjohnson.net/hopf.html
(Imagine that all these threads are connected before the projection, maybe by "connecting the "point" of "each linkage" thus "foliating" 4D space" -- "to infinity and back"!)
I've been building something in this direction for a year across many iterations and explorations: https://dziban.net/posts/yabu/ and https://kinoko.sh
There is such a wide range of interesting things that can happen here that we aren't exploring at all.
The answer was already visible in the previous attempts of 4 GLs, UML tooling with RUP, low code/no code tooling.
Some of us now have to deal with tools like Boomi, Workato, Opal, Sitecore AI, Power Platform,....
Eventually some microservices might be written in "legacy" languages for MCP tools.
This is how "programming languages" look like in 2026 for internal corporate development.
I like the "DB > LSP" idea.
It is interesting that niche languages like Ruby and Elixir sell out to AI, hoping for a revival or more market share. Valim is at dashbit.co, which builds tidewave.ai.
This is unfortunate, because I wanted to try both. Now I hope that Erlang has not sold out yet.
I don’t know how stupid of a suggestion this is, but if no one is reading the code anymore (I do, but I hear many in much more elite shops than mine do not), then should we not just be using AI to write binary or machine code?
Machine code isn't especially expressive per line or unit of code. Lower level languages takes up more of an LLM's context than higher level ones.
To be effective in using low level languages, LLMs would have to build higher level constructs like subroutines from scratch every program.
It's not that different from why we almost never use assembler for anything more than code islands: even a modest subroutine can overwhelm our own mental context window.
Thanks for the insight
Even when no(human)body is reading the code, AI is still reading the code in order to "understand" it. Languages that can express high level concepts, use structured programming for recognizable control flow patterns instead of inscrutable jumps, and assign names to things have the same benefits for the AI-coders and AI-reviewers that they always have for humans.
Personal responsibility will always exist at the touchpoints of software and human activity. Concentration and scope of responsibility may vary, and the degree to which that person needs to understand the code will vary as a result, but the need for a human to be able to read and understand code is going to be around for a very long while still.
People said the same thing about higher level interpreted languages. I wouldn't be surprised if we saw the same movement into a new abstraction like we did when people moved from assembly or C and into Python, Java and C#. This is probably also why LLM's are so good at low-abstraction, explicity, fail fast programming in something like Rust.
Considering how digitally inclined workers are already building various tools on their own. Even though these tools are completely vibe coded and the creator has absolutely no idea how to build things. I imagine we're going to look into a future where the LLM and the prompting becomes the "programming langauge".
I also think we'll see the personal responsibility shift because of this, and I think some traditional IT and software companies will struggle with this. We're an energy company, and where we would've bought a specialized piece of software and a team of consultants to implement it. We can now, not only build a better tool but also rewrite it enough to actually deploy it, all with a handful of people doing other tasks and 4000 Euro worth of credits. 6 months ago I would've laughed into your face if you told me this woud happen, but now, here we are.
I suspect that in a few years (if not sooner) you'll not need any form of software developer in the process for this. You need a buisness domain expert and you need it-architecture + cybersecurity, and most of the architecture + cybersecurity can be done through company wide AI skills. But the code itself never really has to be read for a really large part of software running in companies. You wouldn't do that for something critical, like the software running on your plants, but the web portal with a dashboard containing the status of your devices? Sure, especially because AI lets you do these things with 0 external dependencies.
I think that's just extra detail on the _degree_ of human responsibility depending on the environment. Even in what you suggest, if something goes wrong, who's responsible? AI are not persons in our society; the IT-architecture/cyber security expert is ultimately responsible for the code, regardless of how it's written.
It probably got lost in translation, but what I was trying to say was that when you're in non-tech enterprise. Nobody is responsible for the IT.
I think that just like humans, AI will make logical mistakes at some rate linked to lines of code.
Like I remember reading human studies that people make 1.5 - 5 errors per 100 loc.
If AI works in a similar way then we should stick to higher level languages that minimize loc
> that minimize loc
you can do a hell of a lot with a PERL one liner. What i'd recommend is extremely obvious languages like Golang
What I'd recommend is languages that move entire classes of errors to compile time - like Rust.
If you're going all the way down that route, you might use something like Ada or OCaml or Haskell. They can catch classes of errors at compile time that Rust does not cover.
Definitely a reasonable thing to consider and this is the direction I would like to see programming languages evolve towards in the AI era.
Move errors from runtime to compile time as much as possible.
I agree. I was writing a task runner, and when I used generative AI to write Haskell code, it tended to produce higher-quality code compared to other languages. In particular, I’ve rarely encountered runtime errors when testing the code. On the other hand, when it came to design, there were errors where my intentions weren’t conveyed properly.
[flagged]
Have you managed to run this locally? If yes, how'd you do it?
I'm keen to run it.
The Language Server Protocol is designed for advanced text editors (IDE’s). Now that we rarely edit text by hand, I believe we could instead use source code viewers that don’t have to deal with unsaved or incomplete code.
If we can assume that all files are saved and each file has correct syntax (which can be enforced by tooling), a much simpler protocol could handle all the language-specific indexing needed to make it easy to read source code.
(I’m assuming that we still do read source code. I for one like reading source code and have little interest in ‘software factory’ techniques where you don’t look at at the code. I might not look at every commit, but I’ll still read it fairly often and tell the AI to fix anything that’s unclear.)
[dead]
[flagged]