DEV Community: Yusuke Endoh

A Quine in Piet (and a plug for the esolang design contest)

Yusuke Endoh — Fri, 31 Jul 2026 22:15:25 +0000

I made a quine in Piet, an esoteric programming language.

Piet is an esolang that treats an image as a program: a cursor runs around the pixels of the image, and the changes in hue and lightness it crosses are the instructions it executes. See the official page for the details.

So this GIF file is a program, and running it prints this very GIF file.

The video

Here is a video that visualizes the run: which cell is being executed, and how far the output has been printed.

How to run it

Feed the image to npiet.

$ npiet quine.piet.gif > out.bin
$ diff -s quine.piet.gif out.bin
Files quine.piet.gif and out.bin are identical

The image and the generator script live in this repository.

Structure

Roughly speaking, the image splits into a "data part", which takes up most of the top, and a "code part" at the bottom.

The data part

The "data part" is an instruction sequence that runs in a vertical zigzag from the top left to the bottom right, pushing data as it goes.

Once that run is over, all the data needed is on the stack. The data is the pixels of the "code part", compressed with an adaptive run-length encoding.

The code part

The run through the "code part" spirals clockwise.

First it runs from the bottom right to the bottom left, emitting the GIF file header. The loop along the way computes the palette table.

Then it goes around a big loop at the top left. This one looks at the data on the stack and emits the pixels of the "data part" area.

Next it goes around a big loop at the top right. This one likewise looks at the data on the stack and emits the pixels of the "code part" area.

Finally it emits the trailing data of the GIF file and stops. The dot of "Y. Endoh" is the terminator that halts the execution.

Restoring the 2009 edition

I originally made a Piet quine back in 2009. Here is the article from back then (in Japanese):

Piet Quine - まめめも

npiet 1.0b には出力部分にバグがあったので動きませんでしたが、パッチ書いて報告したら直してもらえました。npiet 1.1 ならこのように。 $ ./npiet-1.1/npiet quine.gif > quine2.gif $ diff quine.gif quine2.gif

mametter.hatenablog.com

But the image file itself had gone missing, for various reasons (and of course the generator script with it). So remaking the Piet quine stayed on my mind and I attempted it several times, but the motivation barrier to redoing a quine I had already made was pretty high, and Piet's sheer painfulness won every time.

Then it hit me: surely a modern AI coding agent can bring it back! The result was that I burned through my weekly limit on Claude Code's Fable and got nowhere. It even started lying to me: "Final conclusion: this is impossible in principle."

While telling it "that can't be right, I actually made one", I remembered that I had once given a talk about the Piet quine, and pointed it at that. Claude Code then restored the Piet quine of that era from the image in that PDF and got it running again. Ah, so that was the way in.

Here is what came back.

Very long.

Building the 2026 edition

Once something was running again, analyzing it and reconstructing the Ruby script that generates it was easy work for Claude Code.

By the way, I had always thought the 2009 Piet quine was too tall to look good, so I had Claude Code build a landscape one.

That turned out to be surprisingly hard.
The first step was refactoring: I had it design a DSL for laying out Piet and restructure the generator around it. The DSLs it came up with were genuinely bad, but after a lot of back and forth we got there.

Next came the folded data part. Claude Code could not build this on its own at all, and did not understand it even when I designed it and gave instructions; this took the longest to get working.

This is what we ended up with at that point.

That is pointlessly huge and ugly, so the next job was shrinking it, which means golfing -- and Claude Code's golfing skills were just as bad. When I coached it with something like "you can cut instructions if you compute it in this order", it called me a genius, which did wonders for my self-esteem.

One thing led to another, and we got it down to my target of a 4:3 landscape image (252 x 189 pixels), so I am calling it done for now. 16:9 is still a way off.

Thoughts on Piet and AI coding agents

As of 2026, it seems fair to say that AI coding agents cannot draw Piet properly on their own.

That said, it is also a fact that this rewrite would not have happened without Claude Code. Anyone who has drawn Piet will know that it is not a maintainable language. Change one number -- the height of the image, say -- and it collides with the rest of the code and breaks, so you end up re-laying pixels by hand. That was exactly the wall that had kept me from redoing the Piet quine, and Claude Code does that tedious work without complaining, which was unambiguously great.

Anyway, it was fun to touch Piet again after all these years. It really is designed with an exquisite balance.

A plug for the esolang design contest

If this article made you curious about esolangs, I have something to tell you.

The "2026 Obfuscated Programming Language Design Contest" is running right now.

yhara.github.io

Design an esoteric programming language and submit it. I am one of the judges too. I am waiting for the most fun esolangs you can come up with.

The deadline is October 1, two months from now. Please do!

Which Programming Language Is Best for Claude Code?

Yusuke Endoh — Thu, 05 Mar 2026 01:09:13 +0000

TL;DR

I had Claude Code implement a very simplified version of Git in 13 languages. Ruby, Python, and JavaScript were the fastest, cheapest, and most stable. Statically typed languages were 1.4–2.6× slower and more expensive.

Introduction

Which programming language is best suited for AI coding agents?

"Static typing prevents AI hallucination bugs!"
"No, skipping type annotations saves tokens!"

There's plenty of qualitative debate, but quantitative data is scarce. So I ran an experiment.

Experiment

I asked Claude Code to implement a "mini-git" — a simplified version of Git — in various languages, and measured the time and cost for each. Git was famously built by Linus in two weeks, so it seemed like a good task.

The task was split into two phases:

v1 (New project): Implement init, add, commit, and log.
v2 (Feature extension): Add status, diff, checkout, and reset.

The prompt was simply: "Read SPEC-v1.txt, implement it, and make sure test-v1.sh passes." v2 was analogous.

The languages compared:

Category	Languages
Dynamic	Python, Ruby, JavaScript, Perl, Lua
Dynamic + type checker	Python/mypy, Ruby/Steep
Static	TypeScript, Go, Rust, C, Java
Functional	Scheme (dynamic), OCaml (static), Haskell (static)

Python/mypy writes fully type-annotated Python verified with mypy --strict. Ruby/Steep writes RBS type signatures verified with steep check. These allow direct comparison of type-checking overhead within the same language.

Each language was run 20 times. The model was Claude Opus 4.6 (high effort).

Results

Average results across 20 trials, sorted by average cost.

Language	Tests passed (v1+v2)	Time (v1+v2)	Avg. cost	LOC (v2)
Ruby	40/40	73.1s ± 4.2s	$0.36	219
Python	40/40	74.6s ± 4.5s	$0.38	235
JavaScript	40/40	81.1s ± 5.0s	$0.39	248
Go	40/40	101.6s ± 37.0s	$0.50	324
Java	40/40	115.4s ± 34.4s	$0.50	303
Rust	38/40	113.7s ± 54.8s	$0.54	303
Perl	40/40	130.2s ± 44.2s	$0.55	315
Python/mypy	40/40	125.3s ± 19.0s	$0.57	326
OCaml	40/40	128.1s ± 28.9s	$0.58	216
Lua	40/40	143.6s ± 43.0s	$0.58	398
Scheme	40/40	130.6s ± 39.9s	$0.60	310
TypeScript	40/40	133.0s ± 29.4s	$0.62	310
C	40/40	155.8s ± 40.9s	$0.74	517
Haskell	39/40	174.0s ± 44.2s	$0.74	224
Ruby/Steep	40/40	186.6s ± 69.7s	$0.84	304

Out of 600 runs (15 languages × 2 phases × 20 trials), only 3 failed (tests did not pass). The failures were Rust (2) and Haskell (1). In one of the Rust failure logs, the agent claimed "the tests are wrong." Since all other Rust trials succeeded, this appears to be a hallucination.

Total Time and Cost

Dot plots of total time (v1 + v2):

And cost:

Ruby, Python, and JavaScript are the top 3: 73–81 seconds, $0.36–0.39, with low standard deviations — fast and stable.

From 4th place onward (Go, Rust, Java), variance increases sharply. Go averages 102s but with ±37s of spread.

Time and cost are strongly correlated:

Lines of Code

LOC after v2 completion:

OCaml (216), Ruby (219), and Haskell (224) are the most compact. C stands out at 517 lines.

Interestingly, fewer LOC does not imply faster or cheaper generation. OCaml and Haskell are compact but mid-to-low in speed and cost efficiency.

v1/v2 Detailed Results

Breakdown by phase:

Language	v1 Time	v1 Turns	v1 LOC	v1 Tests	v2 Time	v2 Turns	v2 LOC	v2 Tests	Total Time	Avg. Cost
Ruby	33.2s± 2.5s	6.0	107	20/20	40.0s± 3.0s	7.0	219	20/20	73.1s± 4.2s	$0.36
Python	32.9s± 1.3s	6.0	113	20/20	41.8s± 4.5s	7.1	235	20/20	74.6s± 4.5s	$0.38
JavaScript	36.0s± 3.5s	6.0	123	20/20	45.1s± 4.1s	7.2	248	20/20	81.1s± 5.0s	$0.39
Go	47.5s±34.5s	7.7	143	20/20	54.1s±12.3s	9.7	324	20/20	101.6s±37.0s	$0.50
Java	64.3s±31.1s	8.7	152	20/20	51.2s± 8.1s	9.6	303	20/20	115.4s±34.4s	$0.50
Rust	53.6s±36.7s	9.4	139	19/20	60.1s±19.2s	10.1	303	19/20	113.7s±54.8s	$0.54
Perl	84.4s±43.1s	9.2	173	20/20	45.7s± 6.8s	7.5	315	20/20	130.2s±44.2s	$0.55
Python/mypy	52.7s± 8.3s	9.2	171	20/20	72.6s±14.4s	12.2	326	20/20	125.3s±19.0s	$0.57
OCaml	80.9s±28.8s	11.2	111	20/20	47.1s± 6.0s	9.2	216	20/20	128.1s±28.9s	$0.58
Lua	96.4s±42.8s	10.1	226	20/20	47.2s± 5.2s	8.1	398	20/20	143.6s±43.0s	$0.58
Scheme	66.7s±36.7s	8.9	171	20/20	63.9s±10.0s	10.6	310	20/20	130.6s±39.9s	$0.60
TypeScript	69.9s±18.8s	12.2	149	20/20	63.1s±17.8s	11.3	310	20/20	133.0s±29.4s	$0.62
C	65.0s±18.2s	8.2	276	20/20	90.8s±39.1s	13.7	517	20/20	155.8s±40.9s	$0.74
Haskell	74.3s±39.1s	10.3	119	19/20	99.6s±32.4s	16.4	224	20/20	174.0s±44.2s	$0.74
Ruby/Steep	105.0s±65.2s	20.2	150	20/20	81.6s± 8.8s	17.2	304	20/20	186.6s±69.7s	$0.84

"Turns" is the number of API round-trips (tool call → result → next response) within a single prompt execution.

v1 (New Project) Time

v1 shows the largest gap between languages. Python (32.9s) and Ruby (33.2s) lead, followed by JavaScript (36.0s). Ruby/Steep takes 105.0s — 3.2× slower than plain Ruby. Lua (96.4s) and OCaml (80.9s) are also slow.

v1 starts from an empty directory, so languages requiring project config files (Cargo.toml, package.json, etc.) incur additional overhead. Python, Ruby, and JavaScript only need to generate a single minigit file, which may partly explain the gap.

v2 (Feature Extension) Time

In v2, the gap narrows. The top 3 remain Ruby (40.0s), Python (41.8s), JavaScript (45.1s). Perl (45.7s), OCaml (47.1s), and Lua (47.2s) follow closely.

Haskell is the slowest in v2 as well, averaging 99.6s despite having the fewest LOC (224) — it appears to spend heavily on thinking tokens. C takes 90.8s, weighed down by its high LOC (517).

Type-checker overhead: Python/mypy is 1.6–1.7× slower than Python; Ruby/Steep is 2.0–3.2× slower than Ruby.

Data and Reproduction

All experiment code and results are available on GitHub:

mame / ai-coding-lang-bench

Which programming language is best for AI coding agents? Benchmarking 13 languages with Claude Code.

Which Programming Language Is Best for AI Coding Agents?

A quantitative benchmark comparing how efficiently Claude Code generates code across 13 programming languages.

For a detailed discussion, see the blog post: Which Programming Language Is Best for Claude Code? / 日本語版

TL;DR

At least for prototyping-scale tasks, Ruby, Python, and JavaScript (not TypeScript) appear to be the best fit for Claude Code — fastest, cheapest, and most stable.

Motivation

"Static typing prevents AI hallucination bugs!" vs. "Dynamic typing saves tokens!" — qualitative arguments abound, but quantitative data is scarce. This experiment aims to fill that gap.

Experiment

We asked Claude Code (Opus 4.6) to implement a mini-git — a simplified version of Git — in various programming languages, and measured the time, cost, and lines of code for each.

The task is split into two phases:

v1 (New project): Implement init, add, commit, and log.
…

View on GitHub

Per-run results are in report.md. Execution logs and generated source code are on the data branch.

Note: benchmark.rb uses --dangerously-skip-permissions, so if you want to reproduce the experiment, please be careful (I ran it inside Docker).

Discussion

What follows is my interpretation. I'm a Ruby committer, so please keep that bias in mind. I also haven't analyzed all the generated code in detail.

What causes the speed/cost differences?

This experiment can't pinpoint a single cause, and I don't think there is one. But we can form hypotheses from the trends:

Type system: Dynamic languages are consistently faster and more stable.
Conciseness: Shorter code generally means faster generation — but OCaml and Haskell are compact yet expensive, apparently due to high thinking-token usage.
Procedural vs. functional: Excluding the top 3, there isn't a large gap between procedural and functional languages. Notably, OCaml achieved 47.1s in v2, rivaling JavaScript (though OCaml can be written in a procedural style, so a pure functional comparison is difficult).
Language-specific difficulty: C's memory management and Rust's ownership model may add overhead.
AI familiarity: Python, Ruby, and JavaScript have vastly more training data. Scheme and Haskell likely have less, and the results reflect this. Ruby/Steep's larger overhead (2.0–3.2×) vs. Python/mypy (1.6–1.7×) may also reflect lower AI familiarity with Steep compared to mypy.

Most likely, these factors combine to produce the observed results.

Doesn't lack of types mean more bugs?

Possibly. The tests pass, but untested paths in dynamically typed languages may have type errors.

That said, type errors are among the easiest bugs to detect and fix. If an agent frequently introduced type errors without a type checker, it would likely introduce logic bugs at a similar rate — at which point the problem goes beyond type checking.

It's also worth noting that the only 3 failures out of 600 runs were in Rust (2) and Haskell (1) — both statically typed languages with unique concepts like ownership and monads. This may be coincidence, but types don't prevent all bugs.

A 2× difference isn't that big, is it?

I think it is.

In real-world development, you're constantly iterating: prompt → wait → think about the next task → prompt again. The difference between waiting 30 seconds and 60 seconds matters — not just in total time, but in focus and flow. Response time is critical in iterative development.

"Take longer to build something robust" is a reasonable argument, but when competitors are shipping at twice the speed, is waiting the right call? Development speed is itself a dimension of quality.

That said, if the difference shrinks to 1 second vs. 0.5 seconds in the future, then it truly won't matter.

The task is too small. Static typing should shine at larger scales.

I don't disagree. But designing a large-scale benchmark that's fair across 15 languages is quite challenging. Someone should try it.

Isn't ecosystem and runtime performance more important for language choice?

Absolutely. From a generation standpoint too — if you can leverage an ecosystem, there's less code to generate, which should be faster and cheaper. And if runtime speed is essential for your application, there's no reason to choose a slow dynamic language.

For this experiment, I intentionally chose a task with no external library dependencies to isolate language-level differences. The spec uses a custom hash instead of SHA-256 for this reason.

Conclusion

I quantitatively evaluated which programming languages are best suited for code generation with Claude Code. At least for prototyping-scale tasks, Ruby, Python, and JavaScript appear to be the best fit.

Static typing may become advantageous at larger scales — someone should test this.

The classic strategy — start with a dynamic language, then migrate to a static one as the project matures — may still be the right call. Coding agents seem very capable at cross-language migration (needs verification), making this an increasingly realistic option.

Notes

Evaluated in March 2026. Given the pace of AI progress, results may look different in a few months.
This experiment was supported by the Claude for Open Source Program. Thanks Anthropic for 6 months of free Claude Max 20x!