Piet: Programming language in which programs look like abstract paintings (2002)(dangermouse.net)
dangermouse.net
Piet: Programming language in which programs look like abstract paintings (2002)
https://www.dangermouse.net/esoteric/piet.html
72 comments
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/
[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 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.
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
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.
> 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.
> 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
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
https://www.cise.ufl.edu/~manuel/obfuscate/pi.c
If I remember correctly, this program also calculates pi more precisely the larger the circle.
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.
> 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/
> 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".
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.
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.
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?
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.
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.
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.
Piet is a milestone experiment among the esoteric programming languages, but I believe that it falls short of achieving its goal to make programs look like Mondrian paintings unless the developer really intends to do so.
I wish the language structure were designed in a way that anything that’s “written” with it would look like a Mondrian painting.
I wish the language structure were designed in a way that anything that’s “written” with it would look like a Mondrian painting.
Yes well unfortunately Mondrian only really used the primary colours so that would be rather limiting
But FWIW Mondrian also showed how to convert a more conventional style into his signature style. This can be seen in Still Life with Gingerpot, numbers 1 and 2.
It could be done. The FizzBuzzLang esolang uses only the words FIZZ, BUZZ and FIZZBUZZ.
Could encode more operators into shape ratios / proportions, line thickness etc.
just have to make them really big
This has always raised a question to me:
>What does an algorithm look like?
Is there a real-world possibility of creating something like to _The Glass Bead Game_ from Herman Hesse's novel (originally published as _Magister Ludi_)?
As a visually oriented person, I'd like to think so, and have actually tried to use such tools:
https://community.carbide3d.com/uploads/default/original/3X/...
but the danger has been, for want of an unambiguous answer to the afore-mentioned question, they always run the risk of:
https://blueprintsfromhell.tumblr.com/
https://scriptsofanotherdimension.tumblr.com/
and it's hard striking a balance between visual expressiveness and modularity (which all-too readily results in the wall of text which one is presumably trying to avoid).
>What does an algorithm look like?
Is there a real-world possibility of creating something like to _The Glass Bead Game_ from Herman Hesse's novel (originally published as _Magister Ludi_)?
As a visually oriented person, I'd like to think so, and have actually tried to use such tools:
https://community.carbide3d.com/uploads/default/original/3X/...
but the danger has been, for want of an unambiguous answer to the afore-mentioned question, they always run the risk of:
https://blueprintsfromhell.tumblr.com/
https://scriptsofanotherdimension.tumblr.com/
and it's hard striking a balance between visual expressiveness and modularity (which all-too readily results in the wall of text which one is presumably trying to avoid).
> What does an algorithm look like?
Writing Piet by hand is a fun way to explore this. Sergei Lewis[1] and I[2] have each written tools to generate Piet code. Sergei's assembler makes much nicer looking code than my Piet backend. All you can really see from my compiler's output is that I'm really lazy and used a trampoline[3]
[1] http://www.toothycat.net/wiki/wiki.pl?MoonShadow/Piet
[2] https://github.com/boothby/repiet/
[3] https://en.wikipedia.org/wiki/Trampoline_(computing)
Writing Piet by hand is a fun way to explore this. Sergei Lewis[1] and I[2] have each written tools to generate Piet code. Sergei's assembler makes much nicer looking code than my Piet backend. All you can really see from my compiler's output is that I'm really lazy and used a trampoline[3]
[1] http://www.toothycat.net/wiki/wiki.pl?MoonShadow/Piet
[2] https://github.com/boothby/repiet/
[3] https://en.wikipedia.org/wiki/Trampoline_(computing)
I have a belief that there is a 1 to 1 relationship between any algorithm, or even any mental conception, and a visual representation. I got this idea reading one of Steven's pink book, in which he says that any abstract word can be broken down into simpler words which in the end describe some spatial relationship. For example to "rekindle" is to "bring two things back together".
It is easy similarly to say that a for loop is the mental conception of "one thing going over a bunch of other things", which has a visual representation like "100" -> "010" -> "001".
I wonder then if its possible to create a language where one defines these constructs purely as visual transformations.
It is easy similarly to say that a for loop is the mental conception of "one thing going over a bunch of other things", which has a visual representation like "100" -> "010" -> "001".
I wonder then if its possible to create a language where one defines these constructs purely as visual transformations.
That reminds me of some thinking I did regarding the primordial gods one finds across many cultures: The penis and vagina symbolism, the first physical objects representing ontology as building blocks.
From there, we spatialize and logicize concepts like "mine," "like me," "unlike me," "other," "in front," "back," and "forward."
Additionally, at the risk of igniting flames, I find it interesting to ponder the significance of gender in the current zeitgeist. Could attacking gender at a political level be a form of assault on sense-making, tugging at the roots of ontological logic centers in the brain? Might this destabilize civilization centers deemed as enemies by some? Feels like the right exploit from a hacker mentality.
From there, we spatialize and logicize concepts like "mine," "like me," "unlike me," "other," "in front," "back," and "forward."
Additionally, at the risk of igniting flames, I find it interesting to ponder the significance of gender in the current zeitgeist. Could attacking gender at a political level be a form of assault on sense-making, tugging at the roots of ontological logic centers in the brain? Might this destabilize civilization centers deemed as enemies by some? Feels like the right exploit from a hacker mentality.
> any abstract word can be broken down into simpler words which in the end describe some spatial relationship
What if my computing model rely on quantum phenomenon ? Maybe some of them don't have good visual representation. But it's a guess. I don't know...
Regarding the global idea of your comment: what about languages such as J it APL or BQN ? In such languages each character is an atomic part of algorithms (in j, two characters are used to implement dynamic IF for instance. One character only is used to define the dimensional depth of each part of algorithms). In this way, iversonnian languages can be seen as general and pure visual representation of algorithms once you consider each J or APL character as an arbitrary glyph.
What if my computing model rely on quantum phenomenon ? Maybe some of them don't have good visual representation. But it's a guess. I don't know...
Regarding the global idea of your comment: what about languages such as J it APL or BQN ? In such languages each character is an atomic part of algorithms (in j, two characters are used to implement dynamic IF for instance. One character only is used to define the dimensional depth of each part of algorithms). In this way, iversonnian languages can be seen as general and pure visual representation of algorithms once you consider each J or APL character as an arbitrary glyph.
Well consider this: There is some set of words which describe quantum physics perfectly.
If what I am saying is true (that human language maps to transformations of space-time) then this theoretical computer should be able to represent quantum phenomena.
Im not familiar at all with APL or BQN but I think I understand what youre saying. I think the main point here isnt simply that you can represent programs visually, but that the visuals do exactly what you see. A "combine" instruction for example would literally be the visual of two objects with empty space transforming to the two objects being together.
If what I am saying is true (that human language maps to transformations of space-time) then this theoretical computer should be able to represent quantum phenomena.
Im not familiar at all with APL or BQN but I think I understand what youre saying. I think the main point here isnt simply that you can represent programs visually, but that the visuals do exactly what you see. A "combine" instruction for example would literally be the visual of two objects with empty space transforming to the two objects being together.
I love yout idea regarding language. I would check more deeply this idea. If so, I should examine 1) if language denote reality (maybe language is something else, like mutuallity of inner representation of reality, wich is different thant reality itself). If so, 2) if language can describe reality (maybe it will always miss some part). If so, 3), the sign (the written language) has to be able to fit to language (I don't know if we have the proof that language is 100% reductible to written language - think about written irony who let the reader sometime in absolutely indecidable choice, while in spoken situation it's clearly irony). It's a very vast subject ! Thank you for all the questions you raised in my mind.
Its been a wild ride thinking about this. Start paying attention to how many times you use spatial relations to talk about abstract things that seemingly have nothing to do with physical reality. Even in programming we often use language like "Run x THROUGH y, if it COMES OUT as z GO BACK to...". One can imagine a visual representation where x,y,z are just differently colored balls representing some other structure in space/time, with the x ball going through the y ball, and coming out as some other ball which moves back to something in the opposite direction.
Everything that happens happens in space and time, so it makes total sense that we have this common denominator of reasoning spatially that ties together images, written language, and sound.
I don't make a distinction between "reality" and the mental conception of reality. By all pragmatic takes, my mental experience IS reality. Anything beyond the means of observation may as well not exist.
Now as to the question of whether language can represent any mental conception, I am not so sure, but merely being enough to represent any physical system is plenty, and of this ability I am sure. Surely if I show you a video of any random thing happening, you can describe in some words EXACTLY what is happening such that another person can recreate that state perfectly. Without any abstractions you could give a description of every single object/pixel in your view, and with "higher" level abstractions like "everything is moving" you can create a lossy representation (which is often enough depending on as depending on the purpose, we don't always care about the actually state of the exact state of system, but rather that it possesses some property. "Something is moving" vs "nothing is moving").
Everything that happens happens in space and time, so it makes total sense that we have this common denominator of reasoning spatially that ties together images, written language, and sound.
I don't make a distinction between "reality" and the mental conception of reality. By all pragmatic takes, my mental experience IS reality. Anything beyond the means of observation may as well not exist.
Now as to the question of whether language can represent any mental conception, I am not so sure, but merely being enough to represent any physical system is plenty, and of this ability I am sure. Surely if I show you a video of any random thing happening, you can describe in some words EXACTLY what is happening such that another person can recreate that state perfectly. Without any abstractions you could give a description of every single object/pixel in your view, and with "higher" level abstractions like "everything is moving" you can create a lossy representation (which is often enough depending on as depending on the purpose, we don't always care about the actually state of the exact state of system, but rather that it possesses some property. "Something is moving" vs "nothing is moving").
For simple programs you can also imagine just implementing a Turing machine where the symbols are colors.
This is the type of thing, I'd expect to show up in a (crime) thriller, stumping the protagonist / investigators until someone deduces it's a code.
And we all thought QR codes were useful...
And we all thought QR codes were useful...
This person made a quine in Piet: http://mamememo.blogspot.com/2009/10/piet-quine.html?m=1. The image there is broken, but there's a copy here: https://codegolf.stackexchange.com/a/23255/103045.
Discovering Piet is a special moment of awe and confusion and wonder. Mine was captured in this chat with my friend Oz in our Computer Science podcast “The CS Primer Show”: https://show.csprimer.com/episodes/e2-dont-let-a-gpt-have-al...
We had a small course in university on esoteric programming language. Each of us had to select a language (Brainfuck, Piet and a few others) and play around with it. I chose Piet and had a lot of fun with it, but to be honest, my small example application was not really aesthetically pleasing. I guess you have to be a Piet expert to make art with it.
The samples page is amazing. You can see the evolution of the canvases, becoming more and more sophisticated and beautiful to took at.
https://www.dangermouse.net/esoteric/piet/samples.html
https://www.dangermouse.net/esoteric/piet/samples.html
> Note that "light" is considered to be one step "darker" than "dark"
Now that's deep.
Now that's deep.
It would be cool if you could build an autoencoder that took code in python or another less esoteric language and learned to output it into piet. Then you could do something like stable diffusion and get random algorithms.
> I would have liked to call the language Mondrian, but someone beat me to it with a rather mundane-looking scripting language.
I'm dating myself with this reference, but some of us old data fogeys might be wondering (well, I am, at any rate) when Piet came out compared to Pentaho's OLAP engine called Mondrian (https://mondrian.pentaho.com/documentation/olap.php)...
I'm dating myself with this reference, but some of us old data fogeys might be wondering (well, I am, at any rate) when Piet came out compared to Pentaho's OLAP engine called Mondrian (https://mondrian.pentaho.com/documentation/olap.php)...
Apparently, the exact same year.
This is so cool! I wonder if it is possible to get a Piet piece together, where the program returns a certain text given. Like a Piet code generator...
Would make for a great present as print!
Would make for a great present as print!
I did one of those for a codegolf challenge once, it was fun! DMM links to it on the examples page; I'm somewhat amazed that it's still up on pastebin.
https://pastebin.com/zxc9V3UX
https://pastebin.com/zxc9V3UX
Very cool! Thank you! :)
I ran into this in university and burned a late night writing a simple program. It was a really fun experience that I would recommend people try at some point!
I loved this talk about building an implementation of Piet by one of the jruby maintainers https://m.youtube.com/watch?v=uKGecSc-r1o
> This is probably the first time in history that a graphic artist has painted a functionally workable computer program by accident.
More accurately, a programmer accidentally came up with a language that can run on real world paintings
More accurately, a programmer accidentally came up with a language that can run on real world paintings
It would be interesting to relax the color requirements such that you could encode a program into what looks like image noise. Sort of like steganography, but instead of hidden data, it's a hidden executable program.
Piet is from 2009, at least. Although this page was last updated in 2018 with some new links i don't know if having the (2018) title makes sense, it feels kinda misleading
Needs a (1990) in the title?
It's 2001 according to the esolangs wiki. https://esolangs.org/wiki/Piet
I don't think it's that old, but it's way older than 2018
Can Dall-E or Midjourney paint Piet programs?
Related. Others?
Simplified Piet interpreter written in Python - https://news.ycombinator.com/item?id=33130954 - Oct 2022 (2 comments)
Piet, a programming language in which programs look like abstract paintings - https://news.ycombinator.com/item?id=21913483 - Dec 2019 (19 comments)
Piet – A programming language in which programs look like abstract paintings - https://news.ycombinator.com/item?id=13503841 - Jan 2017 (12 comments)
Sample programs in the Piet programming language - https://news.ycombinator.com/item?id=11342442 - March 2016 (27 comments)
Piet – visual programming language - https://news.ycombinator.com/item?id=11266653 - March 2016 (1 comment)
Piet Program Gallery - https://news.ycombinator.com/item?id=7727702 - May 2014 (4 comments)
Enterprise Piet - https://news.ycombinator.com/item?id=4698737 - Oct 2012 (39 comments)
Piet: programming with pixels - https://news.ycombinator.com/item?id=2430357 - April 2011 (3 comments)
Piet is a programming language, whose programs look like abstract art. - https://news.ycombinator.com/item?id=1166462 - March 2010 (28 comments)
Piet: a programming language in which programs look like abstract paintings - https://news.ycombinator.com/item?id=235975 - July 2008 (1 comment)
And you thought BrainFk was hard to understand... - https://news.ycombinator.com/item?id=139872 - March 2008 (2 comments)
---
Bonus:
Mondrian painting has been hanging upside down for 75 years - https://news.ycombinator.com/item?id=33370228 - Oct 2022 (71 comments)
Simplified Piet interpreter written in Python - https://news.ycombinator.com/item?id=33130954 - Oct 2022 (2 comments)
Piet, a programming language in which programs look like abstract paintings - https://news.ycombinator.com/item?id=21913483 - Dec 2019 (19 comments)
Piet – A programming language in which programs look like abstract paintings - https://news.ycombinator.com/item?id=13503841 - Jan 2017 (12 comments)
Sample programs in the Piet programming language - https://news.ycombinator.com/item?id=11342442 - March 2016 (27 comments)
Piet – visual programming language - https://news.ycombinator.com/item?id=11266653 - March 2016 (1 comment)
Piet Program Gallery - https://news.ycombinator.com/item?id=7727702 - May 2014 (4 comments)
Enterprise Piet - https://news.ycombinator.com/item?id=4698737 - Oct 2012 (39 comments)
Piet: programming with pixels - https://news.ycombinator.com/item?id=2430357 - April 2011 (3 comments)
Piet is a programming language, whose programs look like abstract art. - https://news.ycombinator.com/item?id=1166462 - March 2010 (28 comments)
Piet: a programming language in which programs look like abstract paintings - https://news.ycombinator.com/item?id=235975 - July 2008 (1 comment)
And you thought BrainFk was hard to understand... - https://news.ycombinator.com/item?id=139872 - March 2008 (2 comments)
---
Bonus:
Mondrian painting has been hanging upside down for 75 years - https://news.ycombinator.com/item?id=33370228 - Oct 2022 (71 comments)
Holy shit! Ive been trying to do something just like this for ages.
Wish the sample programs were shown in action.
Wish the sample programs were shown in action.
https://sanguinel.github.io/PietPlus/
Save the image of the program and import it (e.g. https://www.toothycat.net/~sham/fizzbuzz.png ). You can then step through it.
There are several other implementations listed at https://esolangs.org/wiki/Piet
Save the image of the program and import it (e.g. https://www.toothycat.net/~sham/fizzbuzz.png ). You can then step through it.
There are several other implementations listed at https://esolangs.org/wiki/Piet
Neat, thanks. This really needs an automatic stepper though, or just a gif maker.
What were you trying ?
Still trying, but a programming language for visuals where one can define some primitive transformations like two blocks being added, a block moving through space, etc and use transformations to create bigger transformations and so on.
WHat have you come up with so far? Sounds interesting. I'd be happy to give ideas and bounce stuff. Just sounds cool.
In the very very first iteration (before I was thinking about this deeply at all), I made this. https://github.com/ando818/creativegen/blob/master/moldpiece...
Basically you have some basic shapes like lines, rectangles and you can "weld" them together to form a mold, which could be joined together with other molds.
Then I created a pattern sequence with some basic transitions, like swapping positions or colors. https://github.com/ando818/creativegen/blob/master/pattern.p...
The program would then draw all the molds, and every 4,8,16, or whatever beats apply the transition from the pattern sequence. Ie every 4 beats swap, every 8 bits change colors. The idea was that you could form the pattern sequence quite easily and create interesting visuals that synced with music. I have some videos somewhere of this thing running, just not sure where they are.
Then I started thinking rectangles are really just composition of lines, lines are just composition of points. Transitions are just compositions of other transitions and I wanted to make everything out of the same thing. 4 years later honestly I don't have much to show for it. Its proven incredibly difficult and my ideas are all over the place. I've created literally 10-20 different implementations and started all over again. This is one of them.
https://pastebin.com/4J8dgAWu The idea is that each node (pixel, object, or whatever) is a "transformer" which has a start and end which themselves are transformers with a start, end, next. Following a transformer's start transformer's next pointer should lead to its End (think input, transformation sequence, output). We run a transformer A with an instance of a different transformer B. We iterate through the nexts of A's transformer and Bs transformer concurrently, at each step we apply the transformation from the A sequence to the B sequence. So for example, image B.start = 0, B.start.next = 1. And A.start = SameTransformer (copies the same value to the output) -> Diff Transformer(flips the bit). So running A.run(B) = a new transformation that takes the sequence 0,1, and returns 0,0. This new transformer C could then of course be used elsewhere as a part of another transformation sequence. So to transform 0,0,0,0, one could simply apply C,C to get transformer whose output is 0,1,0,1.
Its both linear and hierarchical, so one has the ability to jump over large steps (by immediately accessing the output, and not running through Start->End) of transformations if one is only interested in the outputs and not the computational steps that lead to that output. The hierarchy also allows the sequence to be treated as a single node as part of another sequence (hence applying Same to a subsequence can call same on everything below to copy it).
Ive used 0s and 1s here but instead imagine 0=Right and 1=Up. Then you can have a sequence of nexts that is something like right->up->right-up->up and run this as the input to a transformer that simply applies Same, Diff, replicating the sequence, and then copying the last value to get right->up->right-up->up->up.
So now imagine we make a transformer that flips the current bit, and the next bit (Diff, diff) and run it through the sequence 1,0,0,0,0,0. If we look at the output at each transformation step, we get 0,1,0,0,0 -> 0,0,1,0,0,0... But since were simply following the next path of any arbitrary sequence, this transformer could be run over the right-up->right->-up->up sequence, producing a visual with each of these nodes changing color one at a time.
The bigger idea is to generate abstract sequences that make stuff bigger and bigger, or rotate them, or pull them apart, or replicate them in some projection etc.
Of course there is a simple way to do this in existing languages that would take short of 10 seconds :->
There's still plenty to think about it. If that's confusing welcome to my world.
Basically you have some basic shapes like lines, rectangles and you can "weld" them together to form a mold, which could be joined together with other molds.
Then I created a pattern sequence with some basic transitions, like swapping positions or colors. https://github.com/ando818/creativegen/blob/master/pattern.p...
The program would then draw all the molds, and every 4,8,16, or whatever beats apply the transition from the pattern sequence. Ie every 4 beats swap, every 8 bits change colors. The idea was that you could form the pattern sequence quite easily and create interesting visuals that synced with music. I have some videos somewhere of this thing running, just not sure where they are.
Then I started thinking rectangles are really just composition of lines, lines are just composition of points. Transitions are just compositions of other transitions and I wanted to make everything out of the same thing. 4 years later honestly I don't have much to show for it. Its proven incredibly difficult and my ideas are all over the place. I've created literally 10-20 different implementations and started all over again. This is one of them.
https://pastebin.com/4J8dgAWu The idea is that each node (pixel, object, or whatever) is a "transformer" which has a start and end which themselves are transformers with a start, end, next. Following a transformer's start transformer's next pointer should lead to its End (think input, transformation sequence, output). We run a transformer A with an instance of a different transformer B. We iterate through the nexts of A's transformer and Bs transformer concurrently, at each step we apply the transformation from the A sequence to the B sequence. So for example, image B.start = 0, B.start.next = 1. And A.start = SameTransformer (copies the same value to the output) -> Diff Transformer(flips the bit). So running A.run(B) = a new transformation that takes the sequence 0,1, and returns 0,0. This new transformer C could then of course be used elsewhere as a part of another transformation sequence. So to transform 0,0,0,0, one could simply apply C,C to get transformer whose output is 0,1,0,1.
Its both linear and hierarchical, so one has the ability to jump over large steps (by immediately accessing the output, and not running through Start->End) of transformations if one is only interested in the outputs and not the computational steps that lead to that output. The hierarchy also allows the sequence to be treated as a single node as part of another sequence (hence applying Same to a subsequence can call same on everything below to copy it).
Ive used 0s and 1s here but instead imagine 0=Right and 1=Up. Then you can have a sequence of nexts that is something like right->up->right-up->up and run this as the input to a transformer that simply applies Same, Diff, replicating the sequence, and then copying the last value to get right->up->right-up->up->up.
So now imagine we make a transformer that flips the current bit, and the next bit (Diff, diff) and run it through the sequence 1,0,0,0,0,0. If we look at the output at each transformation step, we get 0,1,0,0,0 -> 0,0,1,0,0,0... But since were simply following the next path of any arbitrary sequence, this transformer could be run over the right-up->right->-up->up sequence, producing a visual with each of these nodes changing color one at a time.
The bigger idea is to generate abstract sequences that make stuff bigger and bigger, or rotate them, or pull them apart, or replicate them in some projection etc.
Of course there is a simple way to do this in existing languages that would take short of 10 seconds :->
There's still plenty to think about it. If that's confusing welcome to my world.
No I like this line of thinking very much. I share in it. I too, often think about the primordial structures of things. It appears that there’s a shape to all things, especially thought. I very much enjoy what you’re trying to pull off here. It reminds me of a few things I’ve had percolating in my head or seen across others. If I could help in any way, I’d be happy to. Just bounce ideas you need feedback on!
Thatd be great. Is there somewhere I can message you?
[deleted]
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