Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

The last program on the examples page⁰ truly is amazing:

A guy (called Piet!) saw an artwork that reminded him of Piet (the lang) and tried executing it¹.

> It ran! [...] This is probably the first time in history that a graphic artist has painted a functionally workable computer program by accident.

[0]: https://www.dangermouse.net/esoteric/piet/samples.html [1]: https://gitlab.fabcity.hamburg/hofalab/piet-get-together



If you relax the "functionally" condition enough, it has been already shown that most paint splatters (including art pieces) are actually valid Perl [1].

[1] https://www.mcmillen.dev/sigbovik/


I think the issue in this case is that the Perl programs were "really" created by OCR hallucinations, not graphic artists. Piet, on the other hand, is really executing the painting itself.


I think in both cases some amount of interpretation was required:

- for Perl, OCR to a character set

- for Piet, manual “convert[ion] into a clean image file using close colours from the Piet palette”


For the second case, is there an argument that this process was unambiguous and objective in terms of a fairly wide range of metrics over color spaces?

I don't actually have much idea of how far, numerically, colors vary due to different illumination, or due to different digitization processes.


In this case, the Piet palette uses about 8 different colors and 3 different "steps" of luminance, so it seems hard to mess it up too much even if it's based more on a human understanding of colors then a mathematic one (orange -> orange, light blue -> light blue, dark blue -> dark blue, white -> white, etc).

It's also interesting to note that, for Piet, the colors themselves don't have any particular meaning, the instructions are encoded by the differentials between one color and the "next" color in the program direction, with blocks of continuous colors encoding noops. So moving from red to light red is a [0,-1] change, (no hue, 1 step lightness), and moving from blue to dark red is a change of [4,1] (4 steps of hue, 1 step of darkness). So the exact colors don't matter too much


and yet, I can write a line of Perl today that I will not remember how/why it does what it does tomorrow. I don't know if this says more about me or the language other than I don't do it enough any more. However, the fact that paint splatters are better than I am is just proof that it is not the language for me


> Piet J. (yes, that's his real name) was browsing art in a small gallery and saw a work which reminded him of a Piet program. He spoke to the artist, who claimed to know nothing about the language. Piet took a photo of the artwork (left), converted it into a clean image file using close colours from the Piet palette (right), and tried running it.

> It ran! The code executes an infinite loop which reads in ASCII characters and prints out the corresponding numerical ASCII values.

Get out of town. Get right out of town.


I did enjoy the one which computes π;

> Naturally, a more accurate value can be obtained by using a bigger program.

I think that's a first for me.


Isn't there an obfuscated C or Perl competition program that also estimates pi by measuring its own code in some way?

Edit: Oh yes, it's "westley" from 1988: https://www.ioccc.org/years-spoiler.html#1988_westley


I made a JavaScript port, that might be easier to decipher if you are more familiar with js than C: https://quaxio.com/pi.html


Do you mind me asking, what does the last calculation do: pi=(pi * 100 | 0 ) / 100;

EDIT: Ah, nvm. It's truncating the result to 2 decimal places.


|0

There are just too many ways in JS to say Math.floor


https://www.cise.ufl.edu/~manuel/obfuscate/pi.c

If I remember correctly, this program also calculates pi more precisely the larger the circle.


That's originally westley.c from IOCCC 1988. As that site says:

> Unless otherwise indicated, the code comes from the International Obfuscated C code contest.


Sadly, that depends on a discrepency between npiet and the current Piet spec:

> The interpreter now begins sliding from its current white codel, in the new direction of the DP, until it either enters a coloured block or encounters another restriction.

The npiet interpreter, instead, rewinds its position to the last colored codel upon peeking through whitespace. One of these days, I intend to add that behavior as an option to the lexer in my Piet compiler[1], but I haven't bothered yet.

Following the spec, the program is a trivial nonhalting loop because the extreme corners of almost all blocks are white-adjacent. Writing complex Piet programs to target multiple interpreters and compilers is quite the challenge, as they've all got subtly different undocumented interpretations of the spec. I think that the output of my Piet backend is more or less interpreter-agnostic, but I've only dug into the details of three or four other interpreters.

[1] https://github.com/boothby/repiet/


I wonder what the chances are that a simple painting like this (a few large rectangular blocks) is a valid program. From skimming the documentation, I tend to think even that every such image would run without error, given that "Any operations which cannot be performed (such as popping values when not enough are on the stack) are simply ignored, and processing continues with the next command."

However, another question is how many of such random images would actually do something "meaningful".


> It ran! [...] This is probably the first time in history that a graphic artist has painted a functionally workable computer program by accident.

I think this truly deserves a CS Ig Nobel Prize, if there were one, for making people laugh and then making people think.


> This is probably the first time in history that a graphic artist has painted a functionally workable computer program by accident

While impressive organically, it sounds easy when targeted; we could design a programming language where an image of Mona Lisa prints "hello world" - and claim a similar feat.

Perhaps the reverse is more interesting - programmers accidentally wrote a language that could treat real world abstract art as valid input.


> Perhaps the reverse is more interesting - programmers accidentally wrote a language that could treat real world abstract art as valid input.

Isn't that what happened here?


That’s what I’m saying.

I.e. that “programmers accidentally wrote a language that could treat real world abstract art as valid input” - and to me it’s more interesting than what grand-grandparent is describing.


Not just valid, but does a not-nonsense task.

I think in this case, there is a coincidence on both sides? Like, the language or the painting could have been different such that the painting would run, but what it would do wouldn't be a recognizable task.


Was it an accident though? Seems like they were targeting the same style of art so of course some would become valid input


update: actually we have perl, https://www.mcmillen.dev/sigbovik/


I just read that ... incredible. I mean the language itself is just bizarre, but that story tops everything.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: