Champion coder Yusuke Endoh has been flexing their esoteric programming muscles on social media. Their latest confection is a Piet Quine – a GIF image that prints itself. In other words, the GIF is both the code and the precise result after running the code.

If you haven’t quite grasped the enormity of this feat from the title, it is worth breaking down the respective definitions of both Piet and Quine in a computer programming context. Piet is an esoteric programming language in which programs look like complex, colorful, tiled artwork. Inventor David Morgan-Mar named it after Piet Mondrian, the famous founder of the neoplasticism artistic movement. Such artwork is immediately recognizable with its bold squares and rectangles bordered by heavy black lines. Smaller Piet GIFs look a bit more Mondrian-y to me, but also look more like colorful QR codes than paintings.

Endoh has created a Quine, graphically. In computer coding, a Quine is a program that produces a copy of its own source code without any external input. This can be quite a tricky feat, even when confined to the world of ASCII text. A requirement of this coding art is that the output is a character-for-character identical representation of the input. It must not simply read its own file to do the duplication task.

When merging the two ideas above, together, things get a whole lot more complicated. However, the top-linked blog and the embedded video shine a light on the task at hand and how Endoh succeeded. Specifically, the video shows Piet Quine running. The Piet interpreter scans the source GIF image in a ‘load data’ phase, followed by a read of the GIF file header and palette info. The challenge here, raising the task above text Quines, is that the GIF folds in binary data, compression, and an awkward flow – they must all be handled deliberately to end up with the desired result.

A key thing to understand about the source image is that it includes a separately interpreted data part, compressed with an adaptive run-length encoding, and a code part. Endoh says that they managed to actually first achieve this way back in 2009, but the GIF was very tall, so not ideal for visual appreciation. The developer decided to ask Claude Code to analyze and reconstruct the original script and build a ‘landscape’ Piet Quine. Even with AI's help, it wasn’t easy to refine the design to the compact finished GIF seen in this article and video. Only after much work on shrinking the visuals and coaching Claude was the GIF shoehorned into the finished 4:3 landscape image (252 x 189 pixels).

Finally, Endoh reveals that a driving force behind their Piet Quine development efforts was the wish to raise awareness of the 2026 Obfuscated Programming Language Design Contest, which is running right now. If you can, please design an esoteric programming language and submit it! Endoh is one of the judges, and you have until October 1 to make your submission(s).

Running the 1992 Doom on the most random piece of hardware around has become probably the most common unofficial programming challenge. We've seen the game running on anything from toasters to an Anker charger, and even a pregnancy test. Enterprising coders also get it running on the weirdest software possible, and just recently Artem Lytkin got it running in regular expressions.

Developers in the audience are probably recoiling in horror, as that sentence is definitely cursed. You see, regular expressions (regexes) are a utility language used in programs for finding and replacing text. They're incredibly powerful, but the syntax is often said to be write-only, as it looks just like gibberish. For example, /.*(\d{4}).*/g would find the "2026" in "Tom's Hardware 2026 articles." They can be exceedingly complicated, as they include conditional statements, elaborate character-jumping, and substitution rules. However, this also means they fulfill all the technical requirements to be a programming language.

Leveraging those capabilities, Lytkin created a 96 MB plain-text string that contains sections for the virtual CPU's registers, some RAM, a video output (framebuffer), the game's WAD data, plus I/O and other bits and bobs. Once it's all started, the regex will start text-matching and substituting characters in the string to pretend they're the numbers in each processor's register, then accessing and writing to the "memory," so on and so forth.

As you can imagine, this is spectacularly slow, and Lytkin says that it takes around 180 seconds to produce a single frame of game output. Each of those needs nearly 14 million substitutions, though (a) it actually works and (b) Lytkin claims it's byte-identical to the actual Doom output running. You can even control the game with the keys, but as the daring coder poignantly illustrates, playing it "is closer to correspondence chess with a shotgun than to a twitch shooter."

Particularly nerdy devs will be happy to know how Lytkin wrote the memory access part: essentially a binary tree, by jumping from "branch" to branch using standard regex character-jump instructions. This avoids having to scan the entire 96 MB of text repeatedly just to find the "#M" marker bookending it. Lytkin notes the challenge was not about whether it could be done, but whether the game would run "before the heat death of the universe," as the engine fires up 80,000 text substitutions per second.

The doom-regex repository is here, and you can download a demo to run it on your own computer. The project's website demonstrates how the regex machine runs in both visual and text format, and it's mesmerizing to watch. It's quite reminiscent of the time we spent watching defragging utilities do their thing when we were young'uns.