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.
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'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: <a href="https://mech-lang.org/iros-r4r-2026/index.html" rel="nofollow">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.
YuechenLi · · focus · HN ↗
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:
<a href="https://github.com/yuechen-li-dev/oct" rel="nofollow">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.
adastra22 · · focus · HN ↗
YuechenLi · · focus · HN ↗
I'm not proud of that pun.
arcanemachiner · · focus · HN ↗
adastra22 · · focus · HN ↗
cmontella · · focus · HN ↗
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: <a href="https://mech-lang.org/iros-r4r-2026/index.html" rel="nofollow">https://mech-lang.org/iros-r4r-2026/index.html
YuechenLi · · focus · HN ↗
So here is my experiment with Kalman filters here.
<a href="https://github.com/yuechen-li-dev/oct/tree/main/Experiments/FmBrownNoiseKalman" rel="nofollow">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?
<a href="https://github.com/yuechen-li-dev/Concept/" rel="nofollow">https://github.com/yuechen-li-dev/Concept/
cmontella · · focus · HN ↗
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?
YuechenLi · · focus · HN ↗
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.