Earlier quoted context omitted.
I am waiting for a llm entusiast to create something like MicroQuickJS from scratch.
Fabrice Bellard, who developed MicroQuickJS, is a user of LLMs.
The port I couldn't ship
81–90 of 101 posts
Re: The port I couldn't ship
#82Funny 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…
Re: The port I couldn't ship
#83Earlier quoted context omitted.
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?
It's a very weird and uncomfortable way of working - I've said in the past that I don't like a single line of unreviewed AI-generated code in anything beyond a prototype, and now here I am with 13,000+ lines of mostly unreviewed Python written by Claude Opus 4.5.
I'm leaving the alpha label on it until I'm a whole lot more comfortable with the codebase!
I do however know that the tests are pretty comprehensive because I had the model use TDD from the very start - write a test, watch it fail, then implement code to make it pass.
I was able to keep an eye on what it was doing on my phone while it worked and the TDD process seemed to be staying honest.
Here's one example from the full transcript, showing how it implemented closures: https://static.simonwillison.net/static/2025/claude-code-mic...
Re: The port I couldn't ship
#84Earlier quoted context omitted.
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...
I see that you're no longer copying and pasting from the terminal, I remember those two gnarly code sessions to get a previous transcript. How are you generating that transcript now? I'd certainly like to use that for my own record keeping.
It only works with Claude Code for the web sessions at the moment but I expect I'll get it working for local sessions too.
Re: The port I couldn't ship
#85Earlier quoted context omitted.
I see that you're no longer copying and pasting from the terminal, I remember those two gnarly code sessions to get a previous transcript. How are you generating that transcript now? I'd certainly like to use that for my own record keeping.
It's a new tool I built yesterday (because for this particular JavaScript interpreter project publishing the full transcript was essential): https://github.com/simonw/claude-code-publish It only works with Claude Code for the web sessions at the moment but I expect I'll get it working for local sessions too.
Re: The port I couldn't ship
#86Is that confidence of or positivity? I hope I will find out in the future, here on HN.
Re: The port I couldn't ship
#87Earlier quoted context omitted.
I feel like we’ve been hearing this for 4 years now. The improvements to programming (IME) haven’t come from improved models, they’ve come from agents, tooling, and environment integrations.
> The improvements to programming (IME) haven’t come from improved models, they’ve come from agents, tooling, and environment integrations. I disagree. This almost entirely model capability increases. I've stated this elsewhere: https://news.ycombinator.com/item?id=46362342 Improved tooling/agent scaffolds, whatever, are symptoms of improved model capabilities, not the cause of better capabilities. You put a 2023-era…
My personal opinion is that there was a threshold earlier this year where the models got basically competent enough to be used for serious programming work. But all the major on the ground improvements since then has gone from the agents, and not all agents are equal, while all sota models are effectively.
Re: The port I couldn't ship
#88Re: The port I couldn't ship
#89> The port I couldn't ship It turns out that having a "trainer" to "coach" you is not a coincidence: these two words evolved together from the rail industry to the gym. Do "port" and "ship" have a similar history, evolving together from the maritime industry to software?
The etymological roots are quite interesting, though. We aren't quite sure where the word "ship" comes from — Etymonline hazards
> Watkins calls this a "Germanic noun of obscure origin." OED says "the ultimate etymology is uncertain." Traditionally since Pokorny it is derived from PIE root *skei- "to cut, split," perhaps on the notion of a tree cut out or hollowed out, but the semantic connection is unclear. Boutkan gives it "No certain IE etymology."
The word "port" goes back to the PIE root "*per-" meaning "forward", and thus as a verb "to lead". It seems to have emerged in Latin in multiple forms: the word "portus" ("harbor"), verb "portare" (to carry or bring). I was surprised to learn that the English "ferry" does not come from the other Latin verb with the sense of carrying (the irregular "ferre"), but from Germanic and Norse words... that are still linked back to "*per-".
Basically, transportation (same "port"!) has been important to civilization for a long time, and quite a bit of it was done by, well, shipping. And porting software is translating the code; the "lat" there comes from the past participle of the irregular Latin verb mentioned above, about which
> Presumably lātus was taken (by a process linguists call suppletion) from a different, pre-Latin verb. By the same process, in English, went became the past tense of go. Latin lātus is said by Watkins to be from *tlatos, from PIE root *tele- "to bear, carry" (see extol), but de Vaan says "No good etymology available."