I wonder how well Claude would do at porting Heimdal's ASN.1 compiler to Rust, Swift, Java, etc. I wonder how well it would do at porting Heimdal's lib/hx509. I think the latter would be much easier than the former. But I'd expect that porting the krb5 code would be much harder still.
The port I couldn't ship
61–70 of 101 posts
Re: The port I couldn't ship
#62Funny to see this show up today since coincidentally I've had Claude code running for the past ~15 hours attempting to port MicroQuickJS to pure dependency-free Python, mainly as an experiment in how far a porting project can go but also because a sandboxed (memory constrained, to us time limits) JavaScript interpreter that runs in Python is something I really want to exist. I'm currently torn on whether to actually…
You should release it, it'd be quite useful.
https://pypi.org/project/micro-javascript/ - https://github.com/simonw/micro-javascript
Here's the transcript showing how I built it: https://static.simonwillison.net/static/2025/claude-code-mic...
Re: The port I couldn't ship
#63As always, the answer is "divide & conquer". Works for humans, works for LLMs. Divide the task into as small, easy to verify steps as possible, ideally steps you can automatically verify by running one command. Once done, either do it yourself or offload to LLM, if the design and task splitting is done properly, it shouldn't really matter. Task too difficult? Divide into smaller steps.
Well, ideally we teach the AIs how to divide-and-conquer. I don't care, whether my AI coding assistant is multiple LLMs (or other models) working together.
They already know how to. But you have to tell them that's the way you want them to operate, tell them how to keep track of it, tell them how to determine when each step is done. You need to specify what you want both in terms of final result but also in terms of process.
The AI's are super capable now, but still need a lot of guiding towards the right workflow for the project. They're like a sports team, but you still need to be a good coach.
Re: The port I couldn't ship
#64Earlier quoted context omitted.
Well, ideally we teach the AIs how to divide-and-conquer. I don't care, whether my AI coding assistant is multiple LLMs (or other models) working together.
They already know how to. But you have to tell them that's the way you want them to operate, tell them how to keep track of it, tell them how to determine when each step is done. You need to specify what you want both in terms of final result but also in terms of process. The AI's are super capable now, but still need a lot of guiding towards the right workflow for the project. They're like a sports team, but you sti…
> They already know how to. But you have to tell them that's the way you want them to operate, tell them how to keep track of it, tell them how to determine when each step is done. You need to specify what you want both in terms of final result but also in terms of process.
I found Google Antigravity (with the current Gemini models) to be fairly capable. If I had to guess, it seems like they set up their system to get that divide-and-conquer going. As you suggest, it's not that hard: they just have to put the instructions in their equivalent of the system prompt.
Well, when I say 'not that hard', I mean it's an engineering problem to get the system and tooling working together nicely, not really an AI problem.
Re: The port I couldn't ship
#65I won't deny OP learned something in this process, but I can't help but wonder: if they spent the same time and effort just porting the code themselves, how much more would they have learned? Specially considering that the output would be essentially the same: a bunch of code that doesn't work.
I guess it depends on well people want to know things like "Perl (and C) library to web" skills. Personally, there are languages I don't want to learn, but for one reason or another, I have to change some details in a project that happen to use that language. Sure, I could sit down and learn enough of the language so I can do the thing, but if I don't like or want to use that language, the knowledge will eventually a…
I think the specific language in question - perl - is really the source of OP's frustration. Perl is kind of like Regular Expressions - much easier to write than it is to read. I would expect LLMs to struggle with understanding perl. It's one of the best languages for producing obfuscated code by hand. There are many subtleties and context-dependence in perl, and they aren't immediately apparent from the raw syntax.
Edit: I totally agree with your point about not wanting to learn a language. That's definitely a situation where LLMs can excel and almost an ideal use case for them. I just think that Perl, in particular, will be hard to work with, given the current capabilities of LLM coding tools and models. It might be necessary to actually learn the language, and even that might not be enough.
Re: The port I couldn't ship
#66Funny to see this show up today since coincidentally I've had Claude code running for the past ~15 hours attempting to port MicroQuickJS to pure dependency-free Python, mainly as an experiment in how far a porting project can go but also because a sandboxed (memory constrained, to us time limits) JavaScript interpreter that runs in Python is something I really want to exist. I'm currently torn on whether to actually…
But why Python? Why not a JVM like Graal? I would think that would yield faster code. Or why not run MicroQuickJS under Fil-C? It's ideal since it has not dependencies.
I build and distribute software in Python. My ideal solution is something that installs cleanly via pip so I can include it as a regular dependency of my other projects.
Re: The port I couldn't ship
#67Funny to see this show up today since coincidentally I've had Claude code running for the past ~15 hours attempting to port MicroQuickJS to pure dependency-free Python, mainly as an experiment in how far a porting project can go but also because a sandboxed (memory constrained, to us time limits) JavaScript interpreter that runs in Python is something I really want to exist. I'm currently torn on whether to actually…
How many tests do other JS runtimes like V8 have? ~400 tests sounds reasonable for a single data structure, but orders of magnitude off for a language runtime.
MicroQuickJS has 7, kind of: https://github.com/bellard/mquickjs/tree/main/tests
Though if you look in those files some of them run a ton of test functions and assertions.
My new Python library executes copies of the tests from that mquickjs repo - but those only count as 7 of the 400+ other tests.
Re: The port I couldn't ship
#68As always, the answer is "divide & conquer". Works for humans, works for LLMs. Divide the task into as small, easy to verify steps as possible, ideally steps you can automatically verify by running one command. Once done, either do it yourself or offload to LLM, if the design and task splitting is done properly, it shouldn't really matter. Task too difficult? Divide into smaller steps.
Judging from this an approach might have been to port the 28 modules individually and check that everything returns the same data in Perl and TS versions:
"I took a long-overdue peek at the source codebase. Over 30,000 lines of battle-tested Perl across 28 modules. A* pathfinding for edge routing, hierarchical group rendering, port configurations for node connections, bidirectional edges, collapsing multi-edges. I hadn’t expected the sheer interwoven complexity."
Re: The port I couldn't ship
#69Earlier quoted context omitted.
But why Python? Why not a JVM like Graal? I would think that would yield faster code. Or why not run MicroQuickJS under Fil-C? It's ideal since it has not dependencies.
I build and distribute software in Python. My ideal solution is something that installs cleanly via pip so I can include it as a regular dependency of my other projects.
It's analogous to asm.js, the precursor to WebAssembly, which was written in js, in that it ran virtual machines in pure js, which is a huge win in portability. The mquickjs readme explains it in a much lower level way than the quickjs readme. There's also more emphasis on the bytecode. In a way it's like a tiny WebAssembly plus garbage collection extension vm that can run compile to js languages, going beyond that and compiling them to bytecode. The overhead of porting it to a dynamic language wouldn't always be that bad depending on the use case. Its memory savings could be maintained.
Re: The port I couldn't ship
#70Earlier quoted context omitted.
How many tests do other JS runtimes like V8 have? ~400 tests sounds reasonable for a single data structure, but orders of magnitude off for a language runtime.
MicroQuickJS has 7, kind of: https://github.com/bellard/mquickjs/tree/main/tests Though if you look in those files some of them run a ton of test functions and assertions. My new Python library executes copies of the tests from that mquickjs repo - but those only count as 7 of the 400+ other tests.
Were the tests generated by an AI then? How do you know whether they are really comprehensive?