Burn

This article is not detailed enough and needs to be expanded. If you think that the esolang has something that hasn't been discussed and answered yet, you can discuss it in the Burn's "Discussion" tab!

Burn is an esoteric programming language written by User:ais523 in the past. Unfortunately, they forgot the details, but the language may be reverse-engineerable from the following program (the only one ever written, which has minimal comments):

;Colours given as BG, levels 0-3.

00 00 01 00 00 00
10 11 01 01 01 11
03 20 11 00 00 11
00 00 11 11 11 11
00 00 00 00 00 11
10 10 10 10 10 11
00 00 10 00 00 12
00 02 11 00 00 11
11 11 11 11 11 11
00 00 30 00 00 21
00 00 01 01 01 01

That's a rule 110 interpreter, by the way. Anyone who can figure out how it works, please help...

User:ais523 later remembered a few more things:

Some other notes I remembered that may help people reconstruct the language:

• Upon loading the program, it's used to tile an entire infinite plane (possibly disrupted slightly; I can't remember); the program was the initial state for a certain algorithm for updating cells (making it a cellular automaton).
• Cell updates were irreversible; if a cell were ever changed, it was never changed back to its original value (although it might be changed again).

Unfortunately, that's not much to go on.

and a few more, but these are vague memories and might possibly be incorrect (it was well over 10 years ago now):

• As the comment suggests, the two-digit numbers in the example program represent the values of two individual colour channels (the language allowed for three but only two were used in the example program). Although I'm not sure, I think the algorithm was symmetrical between colours (i.e. you could swap the digits of every number in the example program and it would still work).
• The algorithm for updating cells mostly depended on the differences between values of colour channels between adjacent cells. I very vaguely remember that small differences (±1?) were treated differently from large differences, but that might be totally wrong. It was possible for the difference in one colour channel to affect what happened in the other colour channel.
• I think the irreversibility was implemented via requiring each colour channel of each cell to only ever decrease (or maybe only ever increase, but decreasing seems more likely). There was definitely a part of the original program which was immutable and never changed over the lifetime of the program, and I think it was the 00s.
• The example program would frequently undergo "flood fill"-style events, where a whole connected line of the same colour would change colour (at the rate of one cell per cellular automaton update), thus turning from one solid colour into a different solid colour. If I remember correctly, this was not directly part of the definition of the language, but rather a consequence of the way that the update rule was defined.
• When writing the example program, I designed it mostly out of wires that would update flood-fill style, and placed cells with particular values near the intersections in order to affect what would happen when the two wires connected. The 02 in the second column and eighth row is an example of a cell that looks like it was intended for this purpose.
• When a cell changed value, the new value for each channel would be somewhere within the range of values for that channel which existed among that cell and its neighbours (it wouldn't be larger than the largest such value, or smaller than the smallest such value).
• The language had no I/O.

It's worth noting that there was never an interpreter, so the example program was never tested and thus could be incorrect.

See also

• Burnlike