I notice that assembly language is not on this list. I've been working on a modern syntax for assembler, with C-like types[0], something of a successor to qhasm. I've written a race-the-beam renderer[1], which is a good fit because of its incredibly tight performance constraints. I've been doing a combination of coding by hand and Opus 5.5. Anecdotally, I find Claude can code in it just fine, something I'd like to make more quantitative.
Dan Luu has done that kind of evaluation[2], and found that LLMs do well in a range of languages, but do underperform in assembler. My hypothesis is that expressing programmer intent clearly, and having the compiler verify things like consistent placement of variables in registers, will fix the problems that hold LLMs back.
This has been a hobby project, but it feels ready to break containment. I'm open to a research opportunity where I'd be able to work on it for real - get in touch.
This "symbolasm" looks exactly like what Blackfin did.
I think it's a very promising approach - it makes assembly a lot more intuitive, especially to people with background in higher level languages. It makes listings far more immediately readable, even without memorizing every instruction mnemonic. But it just came in too late. By the time Blackfin happened, coding in assembly was firmly an afterthought.
I'd like it to succeed, but I have my doubts that it will.
Blackfin is one of the things I looked at. I go quite a bit farther, with named variables, richer types (struct fields are named), block syntax, and generally capturing as much programmer intent as possible while maintaining an almost 1-1 mapping between statements and assembler instructions.
Time is a circle. Assembler could come back if it's an appealing target for LLMs. Currently it's not, but that's my hypothesis.
It is an appealing target for LLMs? Well, LLMs do make "handroll your hot paths in assembly for better performance" much more viable.
But that's a bit of a problem too?
Because, unlike humans, LLMs have no trouble whatsoever recalling all the mnemonics. Hell, they can often recall all the opcodes and encodings too and disassemble from hex "manually".
So if the primary advantage of this syntax is better human-readability and human-understandability? The need for it in a future where low level assembly routines are written by LLMs in a perf evaluation loop isn't that great.
The main difference is that it primarily targets 8-bit chips, so often has to expand a statement into multiple instructions, while I'm targeting ARM, which can get quite a lot done in a single instruction. But I absolutely will cite it as precedent.
Until recently leaving, somebody at Nvidia was working on a really cool PTX assembler with a pleasant syntax that had support for generic routines and types. I'm a bit sad that's seemingly abandoned now.
Symbolasm looks interesting. Without having tried it, the first thing that comes to my mind is that it would be a bit more complex for debugging, because you are using two different representations to do the same thing (one for writing code, one for reading it back). Not sure if this is an issue in practice.
Of course, the same issue exist in any compile language, say C, but you don’t expect to see C in a disassembly. Here you are working at the assembly level.
By "low-resource" they seem to mean "not much training data". I wonder if the fix for this was generic generalization ability, or just making a lot of training data for the specific languages involved. This distinction matters a lot for the question of whether new programming languages can be developed without having LLMs be bad at them.
TBH not that different than humans. A good programmer can work in a new language in principle, but in practice the code will not be idiomatic, and it will need frequent access to a reference manual.
So, Lingo is the programming language for Director / Shockwave. Most LLMs know very little about it, since its been MIA for a while, however, there's a niche community of people reverse engineering games and the entire Shockwave runtime for years now, and LLMs are accelerating these efforts.
In fact, because of these niche Shockwave communities, and they've admitted to it, the Habbo Origins client was able to be made. That effort was spearheaded by a player who reverse engineered their backend for years, and eventually built up a decompiler for Shockwave, and made their own game client run as a stand-alone EXE (Projector Mode for Shockwave iirc) which is what Origins did.
More recently, a project named "Shockless" emerged that took the Shockwave client for Habbo Origins, and rebuilt it in JS w/ PixiJS (I think?) in order to be a more special-purpose Shockwave runtime. Some months later (this month I think), Sulake released Keystone a new Origins client, essentially doing the same thing, itself coded in C++ but it looks like it took a very closely similar approach. Really fascinating seeing LLMs push reverse engineering communities forward to help preserve old tech and games, and in some cases, niche games forward from the grave.
I think the frontier LLMs have finally gotten to the point they can sort of pick up the syntax on the fly.
I made my own .NET based language using Opus 4.6 and it knew how to write code for it, since the rules were in the context window. I havent gone back to that project, since I've been trying to build other more ambitious projects, but its impressive how much LLMs can pull off as of early this year.
It is funny to me they mention Visual Basic, I've been on and off experimenting with rebuilding the VB6 IDE and eventually its compiler with a modern runtime using Claude, I've got a good chunk of the IDE, and I can load forms, I can even call VB6.exe to compile if you have it installed, but I had to pause since my old college copy of VB6 is kinda busted (I misconfigured something somewhere and it keeps crashing when I open a project).
Niche languages are fascinating, they recall a world that is disappearing, where it was necessary to think before writing, also because resources in terms of CPU and memory were scarce. I worked on IBM 3090 and the PL/1 language and I still remember the difficulty of getting print reports where you also had to calculate the number of columns needed to print a number. Now the arrival of data centers, and the birth of more modern languages like C# and Rust are replacing that world. Today speed is a fundamental element, and AI agents will end up replacing those who write code. But it is not the end, it is just the world changing. You are not a typist, but the one who thinks of new solutions.
I thought LLMs had been good at this for a while? I vibed a language out and the LLM could write in it pretty well. I even got Qwen 3.8 to write it (though it was pretty slow, it managed to get it done)
In my brief test, it did OK but I'm not sure I set it up for success very well. I have a bunch of skills[1][2][3], and I don't think I set those up in OMP for deepseek to use first. Claude uses all 3 a lot so they're probably part of the reason it works.
All the tested languages, outside of COBOL, tested within a narrow margin. I'm sure nobody will be porting their codebase to PHP from these results. This shows that language choice doesn't really matter for LLMs.
Or does it? Why did COBOL lag so much?
I suppose I would like to see tests on a wider assortment of languages now. I'd especially like to see it tested on more esoteric ones.
It's kind of insane that one of OpenAI's internal test tasks is now "reimplement SQLite from scratch, preserving binary compatibility with existing database files".
There's nothing insane about writing a de/serializer for an open source format with tests telling you every time you get it wrong to fix in a loop. Insane would be if they were willing to entrust critical production data to their vibecoded replacements (in multiple ways).
Most of the SQLite test suite, TH3, is not open source or available to the public. You need to pay an undisclosed amount of money to access it, which would seem to defeat the already dubious proposition of vibe-coding a SQLite clone.
> which would seem to defeat the already dubious proposition of vibe-coding a SQLite clone.
For an individual, but for OpenAI this would be a trivial marketing expense. The purpose is not actually to replace SQLite but to be able to claim your software is capable of it, to perpetuate the ongoing mania.
If you had told me five years ago that OpenAI was going to be able to do this at all, much less that they were going to do it routinely as a test of new AI models, I would have thought you were being so unrealistically optimistic that I might have suggested that you up your dosage of antipsychotic drugs.
I mean, if you had said they definitely would not be able to do this, I would also have thought you were probably kind of stupid. But we're definitely on the path that looks like AIs keep getting smarter with no limit in sight.
Extrapolating from a one-day change from zero to one: "As you can see, by late next month you'll have over four dozen husbands. Better get a bulk rate on wedding cake."
You cannot seriously think that this is relevant. You're just enacting an unthinking conditioned response of replying with that comic to cases where people can't tell when an increasing quantity is going to stop increasing, even though you can't tell either.
What's wild is that these AI-psychosis people will be running with the "no end in sight" and "exponential improvements" take for years and even decades to come. Even as LLM technology goes through an economic bust and stagnation.
Have they released this publicly? This seems about on the same order of difficulty to anthropic’s C compiler project, which ultimately failed. I’m surprised if they can do SQLite they wouldn’t show up Anthropic with a real working C compiler.
It's compiling a much more tractable language, and most of the complexity in a production C compiler is in the optimizations. C being a lower-level language might make it easier to write a bad compiler for, but it makes it harder to write a good compiler. Take a look at a SQLite query plan sometime and compare it to the assembly output of gcc -O.
Of course, this wasn't just "hey Claude, write me a compiler, make it rad, yo" - it's been a 6-month long slog, albeit miniscule in comparison to doing it without the LLM.
Not at all, it has traditional shell abilities, it also integrates with COM and DLLs, and as for the syntax, some of us actually like it instead of cryptic shells.
There is a reason many folks rather use fish shell or Xonsh, instead of classic UNIX shells.
I hope someone runs multilangbench for other models. I really want to see how open models in particular do on it. Benchmaxxing by focusing on the top 5 languages seems an easy
I’ve already worked with AI in niche languages without issue. AI is also very good at porting, so I expect to see more like the Bun and Ladybird rewrites.
I would not be surprised if a much larger volume of Clojure source code is in publicly-visible repositories. I’ve not met too many COBOL or Fortran hobbyists.
I suspect the frontier models have a more fundamental sense of programming logic and aren't limited to surface syntax. Has this been proven? I feel like the papers that have come out suggest this, but I haven't read one specifically testing it.
I'm surprised it did so poorly on COBOL.
How does it do on other esoteric languages or a newly made up one?
Re: Clojure, this test does show it performs about as well with Common Lisp as the others. I would expect it can handle other Lisps as well. They can all generally be thought of as extensions of a proto-Lisp.
It is such a ridiculously cool thing that we're reaching an era where the programming language you chose is as temporary a choice as the name of a variable.
How can that signal anything other than improper planning. You prefer a changing codebase over something that has evolved and is being tested over a long period of time?
I can think of many reasons.... "we were using python to quickly explore the space and rewrote to rust once we figured out the interface and started to focus on speed and safety", or "the original authors wrote this software in smalltalk but we'd rather it be golang because this simplifies deployment"
> You prefer a changing codebase over something that has evolved and is being tested over a long period of time?
As long as the test-cases are there, why would I care what language software is written in?
Yes but can you plan anything properly in advance? How many unknown unknowns aren't being accounted for? Maybe it's best to plan for improper planning. What to do when (not if) critical decisions start falling apart?
You go back to the design. A few critical changes in the requirements, that's expected. A codebase in which the critical parts change often, that's a red flag
This is equivalent to arguing that tech debt signals poor planning
I would much prefer it to be easy to change a codebase and for people to make lots of changes to their codebase than for people to stick with whatever they built up front
It can also signal very good planning. If a program is properly specified and all the business logic correct then implementation language is basically as afterthought.
I'm reminded of the software for the Gemini spacecraft. Does it still exist? We don't have any assembly or machine code. But much like today in the '60s the designers of the flight software, considered the assembly output to be an intermediate stage - a kind of temporary mapping from the real program. The real program was designed in "Math Flow 7" - a visual flowchart language for expressing logic. We still have the charts. Does that mean we still have the software? Is the set of charts the software?
If you see magazines and computing TV shows from the 1980s, this is exactly what people expected computers to be able to do by the year 2000: Everyone would have a computer and write their own app for whatever they needed in a language close to plain English.
The fragmentation between programming languages and proprietary operating systems is exactly what hindered that optimism from coming true.
As it should be. Foundational principles between languages are the same, I don’t understand why positions are gatekeeped based on implementation trivia.
Except for platform constraints, like needing to use JS or Swift/Kotlin, why would I use anything else than Rust? I can’t even properly read it, but the agents somehow make it work well and the code doesn’t look particularly cluttered; and it’s so fast.
Because you don’t have an infrastructure to test all platforms and want to actually execute your code instead of waiting a decade until compiler is done?
> COBOL supports more than 40% of online banking systems, 80% of in-person credit card transactions and 95% of ATM transactions, while Fortran is used in weather forecasting and nuclear reactor safety analysis.
Can we not vibe code foundational bank infrastructure and nuclear reactor safety software? Pretty please?
When the last senior COBOL developer dies off and you need to update the bank's code to comply with this year's changes in banking regs, it might be good for the new people to have LLM support to at least understand what the existing code does.
No, I don't want vibe-coded bank infrastructure. Yes, I do want LLMs that can work with COBOL.
Like all software, vibe coding is not the hard part. Maintaining it is. I'm sure there there 100 times the number of people wanting to vibe code this in Rust vs wanting to maintain someone else's vibe coded Rust. So, usually the natural state is keep running the show as-is until it is the next guy's problem.
As far as I know, critical systems like reactor control software is mathematically proven first and verified after implementation. I don’t think you can go beyond that.
I notice that assembly language is not on this list. I've been working on a modern syntax for assembler, with C-like types[0], something of a successor to qhasm. I've written a race-the-beam renderer[1], which is a good fit because of its incredibly tight performance constraints. I've been doing a combination of coding by hand and Opus 5.5. Anecdotally, I find Claude can code in it just fine, something I'd like to make more quantitative.
Dan Luu has done that kind of evaluation[2], and found that LLMs do well in a range of languages, but do underperform in assembler. My hypothesis is that expressing programmer intent clearly, and having the compiler verify things like consistent placement of variables in registers, will fix the problems that hold LLMs back.
This has been a hobby project, but it feels ready to break containment. I'm open to a research opportunity where I'd be able to work on it for real - get in touch.
[0]: https://github.com/raphlinus/symbolasm
[1]: https://github.com/raphlinus/vic-2350
[2]: https://danluu.com/pl-tokens/
This "symbolasm" looks exactly like what Blackfin did.
I think it's a very promising approach - it makes assembly a lot more intuitive, especially to people with background in higher level languages. It makes listings far more immediately readable, even without memorizing every instruction mnemonic. But it just came in too late. By the time Blackfin happened, coding in assembly was firmly an afterthought.
I'd like it to succeed, but I have my doubts that it will.
Blackfin is one of the things I looked at. I go quite a bit farther, with named variables, richer types (struct fields are named), block syntax, and generally capturing as much programmer intent as possible while maintaining an almost 1-1 mapping between statements and assembler instructions.
Time is a circle. Assembler could come back if it's an appealing target for LLMs. Currently it's not, but that's my hypothesis.
It is an appealing target for LLMs? Well, LLMs do make "handroll your hot paths in assembly for better performance" much more viable.
But that's a bit of a problem too?
Because, unlike humans, LLMs have no trouble whatsoever recalling all the mnemonics. Hell, they can often recall all the opcodes and encodings too and disassemble from hex "manually".
So if the primary advantage of this syntax is better human-readability and human-understandability? The need for it in a future where low level assembly routines are written by LLMs in a perf evaluation loop isn't that great.
> time is a circle
Or it is a self-similar fractal with significant and interesting variations
For those who might wonder, Blackfin is a CPU architecture with an assembly language thas has a more pseudo-codeish syntax [1]:
[1]: https://en.wikipedia.org/wiki/Blackfin#Core_featuresCheck out Wiz too: https://github.com/wiz-lang/wiz
People have ported Atari 2600 games to it with the resulting ROM being byte-exact.
Oooh, I hadn't seen that. It's very cool.
The main difference is that it primarily targets 8-bit chips, so often has to expand a statement into multiple instructions, while I'm targeting ARM, which can get quite a lot done in a single instruction. But I absolutely will cite it as precedent.
Also check out: https://github.com/catseye/SixtyPical
Assembly with an effect system and flow typing.
Until recently leaving, somebody at Nvidia was working on a really cool PTX assembler with a pleasant syntax that had support for generic routines and types. I'm a bit sad that's seemingly abandoned now.
Symbolasm looks interesting. Without having tried it, the first thing that comes to my mind is that it would be a bit more complex for debugging, because you are using two different representations to do the same thing (one for writing code, one for reading it back). Not sure if this is an issue in practice.
Of course, the same issue exist in any compile language, say C, but you don’t expect to see C in a disassembly. Here you are working at the assembly level.
I haven't implemented debugging yet, but I expect the situation to be good, for the following reasons:
* It's possible to embed variable names into the debug info, so your debugger inspects those rather than just numbered registers.
* Optimizing compilers can do transformations which highly obscure the relationship between source and binary code. Here they closely match.
Thanks for your interest!
By "low-resource" they seem to mean "not much training data". I wonder if the fix for this was generic generalization ability, or just making a lot of training data for the specific languages involved. This distinction matters a lot for the question of whether new programming languages can be developed without having LLMs be bad at them.
TBH not that different than humans. A good programmer can work in a new language in principle, but in practice the code will not be idiomatic, and it will need frequent access to a reference manual.
So, Lingo is the programming language for Director / Shockwave. Most LLMs know very little about it, since its been MIA for a while, however, there's a niche community of people reverse engineering games and the entire Shockwave runtime for years now, and LLMs are accelerating these efforts.
In fact, because of these niche Shockwave communities, and they've admitted to it, the Habbo Origins client was able to be made. That effort was spearheaded by a player who reverse engineered their backend for years, and eventually built up a decompiler for Shockwave, and made their own game client run as a stand-alone EXE (Projector Mode for Shockwave iirc) which is what Origins did.
More recently, a project named "Shockless" emerged that took the Shockwave client for Habbo Origins, and rebuilt it in JS w/ PixiJS (I think?) in order to be a more special-purpose Shockwave runtime. Some months later (this month I think), Sulake released Keystone a new Origins client, essentially doing the same thing, itself coded in C++ but it looks like it took a very closely similar approach. Really fascinating seeing LLMs push reverse engineering communities forward to help preserve old tech and games, and in some cases, niche games forward from the grave.
I think the frontier LLMs have finally gotten to the point they can sort of pick up the syntax on the fly.
I made my own .NET based language using Opus 4.6 and it knew how to write code for it, since the rules were in the context window. I havent gone back to that project, since I've been trying to build other more ambitious projects, but its impressive how much LLMs can pull off as of early this year.
It is funny to me they mention Visual Basic, I've been on and off experimenting with rebuilding the VB6 IDE and eventually its compiler with a modern runtime using Claude, I've got a good chunk of the IDE, and I can load forms, I can even call VB6.exe to compile if you have it installed, but I had to pause since my old college copy of VB6 is kinda busted (I misconfigured something somewhere and it keeps crashing when I open a project).
Wild that a niche shockwave rebersing Community ended up being the traning graund that made a habbo Origins ckient passibe
Niche languages are fascinating, they recall a world that is disappearing, where it was necessary to think before writing, also because resources in terms of CPU and memory were scarce. I worked on IBM 3090 and the PL/1 language and I still remember the difficulty of getting print reports where you also had to calculate the number of columns needed to print a number. Now the arrival of data centers, and the birth of more modern languages like C# and Rust are replacing that world. Today speed is a fundamental element, and AI agents will end up replacing those who write code. But it is not the end, it is just the world changing. You are not a typist, but the one who thinks of new solutions.
I thought LLMs had been good at this for a while? I vibed a language out and the LLM could write in it pretty well. I even got Qwen 3.8 to write it (though it was pretty slow, it managed to get it done)
Yeah GPT and Claude both write my language really well[1]. GLM and Kimi did OK as well, but I haven't tried Qwen.
[1] https://march-lang.org/
what about deepseek?
In my brief test, it did OK but I'm not sure I set it up for success very well. I have a bunch of skills[1][2][3], and I don't think I set those up in OMP for deepseek to use first. Claude uses all 3 a lot so they're probably part of the reason it works.
[1] https://github.com/march-language/march/blob/main/.claude/sk...
[2] https://github.com/march-language/march/blob/main/.claude/sk...
[3] https://github.com/march-language/march/blob/main/.claude/sk...
> Our second evaluation asks models to migrate COBOL programs to C++, Java, Kotlin, Python, or Rust while preserving what each program does.
Reminds me of how Wall Street Raider [0] just simulates the original code instead of rewriting it.
[0]: https://news.ycombinator.com/item?id=46954696
All the tested languages, outside of COBOL, tested within a narrow margin. I'm sure nobody will be porting their codebase to PHP from these results. This shows that language choice doesn't really matter for LLMs.
Or does it? Why did COBOL lag so much?
I suppose I would like to see tests on a wider assortment of languages now. I'd especially like to see it tested on more esoteric ones.
> MultiLangBench
These models have the entirety of the SQLite source, and likely history, in their pre-training corpus (and possibly in other training phases too).
Benchmarks shine when they ask LLMs to color outside of the lines, for example: https://www.scbench.ai/
'modernizing' is an interesting choice of word
It's kind of insane that one of OpenAI's internal test tasks is now "reimplement SQLite from scratch, preserving binary compatibility with existing database files".
There's nothing insane about writing a de/serializer for an open source format with tests telling you every time you get it wrong to fix in a loop. Insane would be if they were willing to entrust critical production data to their vibecoded replacements (in multiple ways).
Most of the SQLite test suite, TH3, is not open source or available to the public. You need to pay an undisclosed amount of money to access it, which would seem to defeat the already dubious proposition of vibe-coding a SQLite clone.
https://sqlite.org/th3.html
I would think OpenAI licensed the tests, their availability might have been a reason for picking sqlite for this "benchmark" in the first place
> which would seem to defeat the already dubious proposition of vibe-coding a SQLite clone.
For an individual, but for OpenAI this would be a trivial marketing expense. The purpose is not actually to replace SQLite but to be able to claim your software is capable of it, to perpetuate the ongoing mania.
OpenAI paid $15 mil to solve a math problem
If you had told me five years ago that OpenAI was going to be able to do this at all, much less that they were going to do it routinely as a test of new AI models, I would have thought you were being so unrealistically optimistic that I might have suggested that you up your dosage of antipsychotic drugs.
I mean, if you had said they definitely would not be able to do this, I would also have thought you were probably kind of stupid. But we're definitely on the path that looks like AIs keep getting smarter with no limit in sight.
> with no limit in sight
https://xkcd.com/605/
Extrapolating from a one-day change from zero to one: "As you can see, by late next month you'll have over four dozen husbands. Better get a bulk rate on wedding cake."
You cannot seriously think that this is relevant. You're just enacting an unthinking conditioned response of replying with that comic to cases where people can't tell when an increasing quantity is going to stop increasing, even though you can't tell either.
What's wild is that these AI-psychosis people will be running with the "no end in sight" and "exponential improvements" take for years and even decades to come. Even as LLM technology goes through an economic bust and stagnation.
It's like a doomsday cult in reverse.
Have they released this publicly? This seems about on the same order of difficulty to anthropic’s C compiler project, which ultimately failed. I’m surprised if they can do SQLite they wouldn’t show up Anthropic with a real working C compiler.
Maybe C compilers are actually harder?
SQLite at its core is a compiler, and a higher level one than C, so I don’t think that’s likely.
It's compiling a much more tractable language, and most of the complexity in a production C compiler is in the optimizations. C being a lower-level language might make it easier to write a bad compiler for, but it makes it harder to write a good compiler. Take a look at a SQLite query plan sometime and compare it to the assembly output of gcc -O.
They don’t have to produce an optimizing compiler to claim a win though.
gcc -O0 can't compile a bootable Linux kernel, which was their goal
[blatant plug]
I'd point you here: https://news.ycombinator.com/item?id=50151160 for a real C compiler that autovectorises onto the GPU. Or multiple GPUs, or a network of multiple GPUs.
Of course, this wasn't just "hey Claude, write me a compiler, make it rad, yo" - it's been a 6-month long slog, albeit miniscule in comparison to doing it without the LLM.
And they do it in powershell
And if you thought that was ridiculous, consider that the "best" implementation is the SQL database it wrote in PHP.
Isn’t powershell just a C# (.Net) with an ugly syntax?
Not at all, it has traditional shell abilities, it also integrates with COM and DLLs, and as for the syntax, some of us actually like it instead of cryptic shells.
There is a reason many folks rather use fish shell or Xonsh, instead of classic UNIX shells.
I meant relative to C#, not shell.
Well, you can now write scripts in C#, yet I doubt it got any adoption among DevOps folks.
https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-...
You missed the "solve unsolved math problem, because all other are too easy" tasks
I hope someone runs multilangbench for other models. I really want to see how open models in particular do on it. Benchmaxxing by focusing on the top 5 languages seems an easy
I’ve already worked with AI in niche languages without issue. AI is also very good at porting, so I expect to see more like the Bun and Ladybird rewrites.
Haskell got left out :(
And Clojure. Perhaps these aren't considered low resource. I had good results in Clojure over a year ago.
I would not be surprised if a much larger volume of Clojure source code is in publicly-visible repositories. I’ve not met too many COBOL or Fortran hobbyists.
I suspect the frontier models have a more fundamental sense of programming logic and aren't limited to surface syntax. Has this been proven? I feel like the papers that have come out suggest this, but I haven't read one specifically testing it.
I'm surprised it did so poorly on COBOL.
How does it do on other esoteric languages or a newly made up one?
Re: Clojure, this test does show it performs about as well with Common Lisp as the others. I would expect it can handle other Lisps as well. They can all generally be thought of as extensions of a proto-Lisp.
Haskell community will be overjoyed.
"avoid success at all costs"
Functions in Haskell have no side effects because nobody runs them.
SQLite is not pure, it has side effects - the .sqlite file on disk
You can use the ST monad
It's too good.
https://xkcd.com/1312/
Whow, didn't knew that GPT 5.6 Sol is soo bad compared to Terra or 6.1 It was my company goto model.
I need to see SQLite implemented in PowerShell
> I need to see SQLite implemented in PowerShell
I would be much more interested in seeing an implementation in Nock ([1], see also [2]).
---
[1] https://docs.urbit.org/nock/what-is-nock
[2] https://en.wikipedia.org/wiki/Urbit
That's easy mode.
In .BAT
They needed to test what it would cost each model to make the tests pass at 100%.
It is such a ridiculously cool thing that we're reaching an era where the programming language you chose is as temporary a choice as the name of a variable.
That's.. not..
How can that signal anything other than improper planning. You prefer a changing codebase over something that has evolved and is being tested over a long period of time?
I can think of many reasons.... "we were using python to quickly explore the space and rewrote to rust once we figured out the interface and started to focus on speed and safety", or "the original authors wrote this software in smalltalk but we'd rather it be golang because this simplifies deployment"
> You prefer a changing codebase over something that has evolved and is being tested over a long period of time?
As long as the test-cases are there, why would I care what language software is written in?
Yes but can you plan anything properly in advance? How many unknown unknowns aren't being accounted for? Maybe it's best to plan for improper planning. What to do when (not if) critical decisions start falling apart?
You go back to the design. A few critical changes in the requirements, that's expected. A codebase in which the critical parts change often, that's a red flag
This is equivalent to arguing that tech debt signals poor planning
I would much prefer it to be easy to change a codebase and for people to make lots of changes to their codebase than for people to stick with whatever they built up front
Yes, and, many many billions (trillions?) of dollars have been lost because the programming language couldn't be changed. Both things can be true.
New languages do in fact come out, and old languages get better, and old codebases are thing some people have to maintain.
It can also signal very good planning. If a program is properly specified and all the business logic correct then implementation language is basically as afterthought.
I'm reminded of the software for the Gemini spacecraft. Does it still exist? We don't have any assembly or machine code. But much like today in the '60s the designers of the flight software, considered the assembly output to be an intermediate stage - a kind of temporary mapping from the real program. The real program was designed in "Math Flow 7" - a visual flowchart language for expressing logic. We still have the charts. Does that mean we still have the software? Is the set of charts the software?
If you see magazines and computing TV shows from the 1980s, this is exactly what people expected computers to be able to do by the year 2000: Everyone would have a computer and write their own app for whatever they needed in a language close to plain English.
The fragmentation between programming languages and proprietary operating systems is exactly what hindered that optimism from coming true.
That is expected. We already throw away a lot of "don't do". NIH ? In this company we(claude) invent everything, DRY ? Who care, as long as it work.
As it should be. Foundational principles between languages are the same, I don’t understand why positions are gatekeeped based on implementation trivia.
+1 ! We might actually have to rethink what are costly decisions for the post Agentic world. Truly sci-fi stuff
Except for platform constraints, like needing to use JS or Swift/Kotlin, why would I use anything else than Rust? I can’t even properly read it, but the agents somehow make it work well and the code doesn’t look particularly cluttered; and it’s so fast.
I believe these words capture the zeitgeist of the 2020s.
> why would I use anything else than Rust?
Because you don’t have an infrastructure to test all platforms and want to actually execute your code instead of waiting a decade until compiler is done?
Y'all are going to cause some big disasters
I bet the language with the best metaprogramming will win out.
Does "Visual Basic" in OpenAI's list also include VBA?
> COBOL supports more than 40% of online banking systems, 80% of in-person credit card transactions and 95% of ATM transactions, while Fortran is used in weather forecasting and nuclear reactor safety analysis.
Can we not vibe code foundational bank infrastructure and nuclear reactor safety software? Pretty please?
When the last senior COBOL developer dies off and you need to update the bank's code to comply with this year's changes in banking regs, it might be good for the new people to have LLM support to at least understand what the existing code does.
No, I don't want vibe-coded bank infrastructure. Yes, I do want LLMs that can work with COBOL.
It's a nuclear reactor, Michael. What's the worst that could happen? A meltdown?
Like all software, vibe coding is not the hard part. Maintaining it is. I'm sure there there 100 times the number of people wanting to vibe code this in Rust vs wanting to maintain someone else's vibe coded Rust. So, usually the natural state is keep running the show as-is until it is the next guy's problem.
You forgot flight computers.
OpenAI is already working on fixing F-35 avionics.
https://en.technosotnya.com/2026/10/openai-55-ai-models-f35....
those are ada. Don't worry, they'll forget about ada until the defense contractors pay them to remember
oh man ada. I wrote a terrible Ada compiler in university.
> Can we not vibe code foundational bank infrastructure and nucelear reactor safety software? Pretty please?
How can you power the "rogue" AI infrastructure and mistakenly funnel the funds needed for the operation otherwise?
Matrix needs energy, Matrix needs money.
VIBE CODE ALL THE TIHNGS! /s
Soon enough, it'll be 'Could we not entrust our safety critical systems to those emotional error prone humans? Pretty Please?'
I feel that we have to mention Stanislav Petrov now.
https://en.wikipedia.org/wiki/Stanislav_Petrov
As far as I know, critical systems like reactor control software is mathematically proven first and verified after implementation. I don’t think you can go beyond that.
[flagged]
Mildly offended that Forth didn’t get mentioned once in the article. /s
there are dozens of us! dozens!
Agreed.