I’m finishing several esolangs for the first artist’s monograph of programming languages, out in Sept: https://mitpress.mit.edu/9780262553087/forty-four-esolangs/ including a hands-free (and not dictated) language.

I recently completed Valence: a language with polysemantic programs https://danieltemkin.com/Esolangs/Valence on GitHub: https://github.com/rottytooth/Valence

Older work includes Folders: code written as a pattern of folders: https://github.com/rottytooth/Folders , Entropy: where data decays each time it’s read from or written to: http://entropy-lang.org/ and Olympus: where code is written as prayer to Greek gods, who may or may not carry out your wishes: https://github.com/rottytooth/Olympus (a way to reverse the power structure of code, among other things).

I have three more to complete in the next few months.

The glyph start marker ╵ also marks a block of code; if several consecutive glyphs start with the same number of them, they are part of the same block.

When the question strand executes, it looks at whether a list element (or entire list) is zero or below. If so, the entire block is rolled back to its previous state.

So all branching is done as rollbacks. And loops end by rolling back their last iteration.

Hi, I created this language as part of a series of experiments with bringing aspects of natural language into code. My previous language, Valence (https://danieltemkin.com/Esolangs/Valence), dealt with semantic ambiguity — this one with calligraphy. It avoids an overly logical syntax in favor of compactness and expressiveness.

I’m completing a book of these esolangs for MIT Press this fall including this; not much info yet online yet but here’s the link: https://mitpress.mit.edu/9780262553087/forty-four-esolangs/

This is beautiful, genuinely (the SVGs are lovely bits of artwork) and it's a fun puzzle to read, and I've shared with friends that like esolangs, including your book (good luck on publishing!).

In the "Data Strands" -> "Value Strands" section, you describe it as "Value strands (and other data strands), begin with a hook that points up (as in the third strand below) or to the left (as in the first two)" for the following example:

  1 ╵╰──╮╭──╯╶╮
  2    ─┘└─   └─╮
  3               
  5              ╷

but the way I was parsing it was that the hook is '╰' or '╯', in which case both of those are hooks pointing up? It looks like a fairly innocuous typo, but I'm never sure with an esolang so wanted to ask.

Yes, that's a typo: the first two strands have hooks pointing up, the third to the left.

I forgot to mention that you can run the interpreter with -p to convert the program to pseudo-code. This makes it much easier to tweak the examples and experiment. I'll add that to the readme, along with more pseudo-code for the example programs.

And thanks so much!! Very excited to publish (Sept 2025).

Thanks, as I said, easy to fool yourself into thinking you're wrong when esolangs are involved.

The CLI tool is fantastic. I never thought that I'd see an esolang where "ergonomics of using it" was something the author would work on. I'll play around with that some more later, thanks again!

Don't see how this will work without checking for control characters, surrogates and chars above 0x10000 (try 𝄞 for instance)

Thanks -- added an issue for the linear search https://github.com/rottytooth/rot8000/issues/2 -- will place a limit on chars in that textbox as well

For reference, I created an optimized implementation and tested it with a string containing all characters from U+0000 to U+FFFF in order and got the following times. The original implementation took 5202.766 ms, the optimized implementation took 0.079 ms for a speed-up of about 65858. That this is pretty close to 65536 is probably a reflection of the cost for the linear search through almost that number of characters and the test pattern I choose but I am not entirely sure, intuitively I would have expected a factor of 0.5 in there to account for the average case. But I am too lazy right now to do the math.

I've updated it to use a hashtable and the tests run quite a lot faster

I took the array approach which should be still faster because it avoids the hash calculations. Just build an array Char[65536] containing at every index i the character the character i should be mapped to. Rotator.Rotate() then simply becomes the following where Rotator.map is the precomputed array. Probably very similar to an implementation using a hash table. I also got rid of the string builder but did not profile the difference. If one uses a string builder it would most likely help to specify the capacity in the constructor call so that the internal array does not have to be resized repeatedly as the result is constructed and grows in length.

  public static String Rotate(String input)
  {
    var result = new Char[input.Length];

    for (var index = 0; index < input.Length; index++)
    {
      result[index] = Rotator.map[input[index]];
    }

    return new String(result);
  }

Limiting the text box will protect you against the most naive DoS attacks, but you need some kind of limit at the API level (request size, etc.). Never trust the client.

Speaking of which, the image for this article has code in a variation of brainfuck

I like that idea too (I'm the developer), but it does mean that string data would be an enormous number of folders

I put in a fix for CJK and the result is: nearly everything that's not CJK now rotates into it and back out; CJK is an huge section of the Basic Multilingual Plane. The fix invalidates rotations done with rot8000 before the fix, unfortunately.

CJK support is fixed now.

It's using 0x8000, which is half of 0x10000 (the size of the basic multilingual plane). It doesn't extend out of BMP