yayimhere's dream-inspired work uncovers subtle anomalies and contradictions in the strict logic of minimalist systems.
» How did you discover esolangs and drew you to this form in the beginning?
I only partly remember how I got into esolanging itself. I think the reason was Malbolge. It was so interesting to me, that you could make something so hard to use! Because of that, my first esolangs (now deleted, since I don't even remember how they work anymore) were goto-based, and self-modifying in one way or the other.
[See also: interview with Ben Olmstead, creator of Malbolge]
» Tell me about your approach to esolanging / esoprogramming. You seem to have many languages that relate in some way to Minsky machines. Could you explain what a Minsky machine is and why you are drawn to that architecture?
Most of my esolangs are made along the lines of:
- Read another esolang, and highly overthink one very very specific feature, quote, or programming method from it.
- Come up with a half concept for something using that.
- In my sleep make the precise command set
- And wake up in the morning, with a whole programming language!
Which I think you can see in languages like hexad, which is a strange self modifying language where reading and writing basically is impossible. This originated from a single quote on the WUUI page: "It is currently unclear whether such a memory structure can be reliably set up under WUUI's rules". This then made me wonder, is it possible to make every structure unreliable. And after a while, I had a language.
Now onto Minsky machines.
Minsky machines are a type of counter machine.
Counter machines are generally just an FSA's hooked up to one or two counters. One of these is the Minsky Machine, which comes up a lot in my esolangin'. A Minsky Machine can "increment" and "decrement and check if zero, if yes jump one place, if no jump another".
I'm probably drawn to these out of circumstance. Many of the languages i like are proven Turing Complete, via proof by a Minsky machine. And also many languages are derived from them. They truly aren't the most interesting machines.
» You seem to be an avid esoprogrammer as well as esolanger. What esolangs by others have you spent the most time with? What's your usual approach when you're experimenting with a new esolang; do they mostly run in your head, or do you do significant programming in existing languages to understand them?
Thanks! Most esolangs I work with sort of run in my head until I eventually try and type it out, to look what might be wrong. Then I do that again, until I've created something. I usually trust my mind quite a bit when doing this.
I've spent a lot of time with brainfuck, as well as Topple (which I was first to prove Turing Complete). Others are SUBLEQ, Underload, Sike, Unlambda, and the non-esoteric lambda calculus. I've also spent quite a bit on ErrorBucket, but not in writing programs.
I think from this point, it's a good jumping off point to talk about my favorite esolangs, how I got to them, and how I make esolangs.
The story of how I got here, to my "style" of today will lead me to mention one of my esolangs, called Bring to another.
The unique thing about Bring to another is that no-one knows how it works because I forgot. However, me and another person tried to solve it, and found it to use sub stacks, which as such lead me to make another language, called A Question of Protocol. This is a language where the only data forms are stacks/arrays nested within other stacks. This led to my main four styles: self modification, string rewriting, functional programming, and counter machines.
And for the ones who don't know what the heck those are, I should probably describe these shortly. String rewriting systems are just systems where strings of characters are rewritten, like the Bitwise Cyclic Tag, which I've used a lot for proofs of turing completeness, and I've also made quite a lot myself. Functional programming is programming based only, or at least mainly, around functions. The purest of these is probably lambda calculus, which languages like Unlambda are built upon.
But how can a sub-stack language lead to all this? Well, during AQOP's (A Question Of Protocol) development, I was speaking to a whole lot of other esolangers. And this showed me different cool concepts to add to the language, like for example, macros! This led me down the path of self modification and functional programming, which then led me to the SKI combinator calculus, and Underload, the latter a language of Ais523 [Ed NOTE: interviewed here and here], who is a big inspiration of mine. This then led me down the path of string rewriting, where I got a love for strange ways to change a string (what a strange thing to love). But where do the counter machines come in you may ask! Well, the Minsky Machine came in for the proof of Turing Completeness, because I proved AQoP's Turing Completeness via compilation/translation from a Minsky Machine.
These influences lead to me discovering some of my favorite languages, all of which influenced me. Underload, a self-interpreting stack based language (which I mentioned before), Emmental, a language that modifies its own interpreter(!), Unlambda, a pretty strange functionally pure (ignoring IO), and, probably most importantly, An Odd Rewriting System, which is the string rewriting system to me, because still have no idea how it works. And I guess there's also P", which isn't really a language but… oh well, it’s brainfuck but formal.
This then led to the Do Minsk Family. This is a family of varying esolangs, with one very simple connection: They are proven turing complete by Minsky Machine compilation (and have inspired each other). However the languages themselves are very different. I'm going to name four languages from this family. These are Karvity, The Last Question (yes, named after the Isaac Asimov story) or TLQ, Goto tag, and Combine and continue. Karvity is a modified version of a Minsky machine, which was created as a "church numeral" version. Church numerals is a form of numbers made in lambda calculus. If you pass any function to a church numeral (remember, in lambda calculus everything is a function), it gets repeated by the numerals value. In Karvity, each line is a loop over the rest of the program. Karvity is important because it showed me that new things can be done with a counter machine, like what Karvity is (in my opinion).
This inspired two other languages, TLQ and Combine and continue. TLQ is basically a language where every goto affects one of the two counters. It was actually made because of my disappointment with another language, called infinite goto. Infinite goto is similar, but every "goto number" has an associated command (or perhaps the jump lengths). I was a little sad that these goto's weren't generalized to every value however, so I changed that! I think this shows something about my esolangs. Almost all of them is just a process running on some given memory again and again, or something similar. This is what TLQ does, it jumps around the program, while decrementing and incrementing two counters, which is very uniform. I like generalizing, basically. Now, TLQ eventually wasn't good enough for my want of this "perfect" goto only language, which led me to the Goto tag! Every time a goto happens, it is added to a list. This list will then, when longer than the program, be run. And we just do that forever, similar to the Bitwise Cyclic Tag.
Now, onto Combine and Continue (I've lost track of the capitalizing for this language). Its idea was, what if I took these church numerals from Karvity, and let it repeat instructions on the stack, Underload-style. It was pretty fun to make, and shows pretty well how the Do Minsky Family developed. I extracted something from one of the languages that came up inside of it, and put it directly into a new system that also fascinated me. This made it a very fun process.
Now, since we are talking about minsky machines n’ all that, i want to bring up my Short Minsky Machine Notation, which further leads me to something interesting. SMMN was made purely out of necessity. Along those lines, all intermediate languages are middle men between two languages, for compilation. I am always so fascinated by these languages, because I have no idea how someone could come up with them, and hearing their back stories is so cool. For example, ErrorBucket is an intermediate language between a sort of Cyclic tag system, and the I/D machine. It was so interesting to hear about how it was come up with! It happens that in the cases where I would need one are very rare. And in the case where I would need one (like Uncompetition, which is one of the most cursed language ever), it usually ends up being too hard for me.
» Are sub stacks simply "stacks/arrays nested within other stacks" (as you describe AQoP)?
I'd say they are just nested arrays (but they could probably be expanded, like nested stacks and queues). But you can do a lot more with them than with normal stack without this nesting, data wise (which I'll talk about in a bit), or at least more easily. But I think I'm drawn to them in a less programming way and more "symbolic" or art-sy way. It's similar to fractals. Infinitely nesting within themselves again and again and again, and so on. It's artful, in some way or the other, and I think that subconsciously, my goal is to create something artful or beautiful with my esolangs (which is why I also like language like Malbolge, because they look like art, just random characters, but they actually mean something!). I've slowly begun realizing this goal more consciously, credit to esoteric.codes for that. But also, computationally, they are interesting, because it lets you keep lots of different data in different places. It's probably, to me, one of the more complex data structures, because you can build a lot of things. I will also probably make a whole new language based on this data structure in the future, maybe even one more useful and less esoteric (if I'm able to do that).
» Your main styles: string rewriting, combinators, self-modification etc, are all minimalist in a way (most lead to languages with small lexicons, for instance). Also, "running on some given memory again and again," has its own strange efficiency (also, btw, is that part of what you find fascinating in Malbolge?). Is the minimalism of language definition itself important to you or is there something else these concepts all have in common for you? (Also, have you experimented with OISCs at all?)
I do like the simplicity, and find some level of importance in having it. One part of it is a frustration with most actual programming languages, because they all have these closed systems that can't interact with each other, or at least have a hard time doing so. You don't have like, a universal stack, or similar. You don't have this big thing linking everything. It's all over the place, and I think this draws me away from most languages, which probably, again in my subconscious, led me to esolangs. So as said, there is some importance to me of having a simple system (though, to be honest, some of my esolangs are only simple if you look at it from the perspective of the creator). But there's another thing that draws me to these systems, and it is, what strange programming method that may come up with this hyper simple language, because you are restricted to such simple systems(which especially happens with that concept of data repeatedly being manipulated by the same process). But I'm also slightly drawn to those systems because they can have very interesting interactions, if you just throw away all logic of using them. This especially happens with lambda calculus, because you can for example, take the square root of the pair creating function. Here, I bring up the first language of this long response, a language of mine called Utral, which does computation, using only a null value, and negation. But it's based in lambda calculus, and all of a sudden it actually works/makes sense, and I've been able to program lots of different functions with it. Now that you mention it, Utral is probably the closest I've gotten to an OISC. To answer your question on OISC's, I've never really experimented with them, but sometimes, I end up accidentally reducing my language to an OISC, or very very near OISC. But, back on topic, I like most of these systems because they are simplistic, yet lead to a strange, almost magical feeling, to a person without knowledge on how it works, on how this language can do what it does. This is of course similar to that want of an artful language I mentioned before.
» Utral speaks of an un-neutral, the negation of the null, where null is ordinarily understood as neither positive or negative. Also, it offers parentheses to wipe out mention of a parameter. Is it primarily a language of emptiness and deletion? What inspired the language, and does it have specific influences?
I think it's quite funny that you noticed the parenthesis thing. I think it's one of those things I just do, because I think parameters look ugly. On the topic of "how something looks",
-(-()-())Which already resembles how utral looks. The only thing I had to do from that point was figure out how to negate a null. The obvious way to me was just to implement it in lambda calculus. And then, I found a negation function, and implemented a null.
I hadn't actually thought of it as being empty, but it is one of deletion, and in fact, it's the only way to achieve… Well, anything at all. But it probably is pretty "empty" (in fact, I've found every possible function is affine, every input has one or less instance in the output).
Inspiration-wise, it's actually quite the isolated esolang, with the only influence being Unlambda's `, which is replaced with the prefix version ".".
One strange feature of -null, is that double negation doesn't return to its original value. The reason for this is obvious: a lambda function cannot naturally return nothing. But it does show an observation that I think we need to recognize, and some probably already do: The weirder a value gets, the less and less we can trust what we think is always true. And even less can we trust what we think is impossible.
» How do you make decisions about which esolangs to implement? Are there languages of yours that you feel can be "solved" by discovering its capabilities (or computational class), apart from the actual act of writing programs for it directly?
The reason why I usually don't implement my languages are for two reasons: 1. I'm terrible at interpreting syntax, and more interestingly 2. That my languages are strange. And when I say strange I don't just mean that it uses a tape and no variables, for example. I mean, that they function in a way that just is really hard to describe in context of another language. Take Turtle just want to dig for example. It's a pretty simple 2d language, but behaves pretty strangely, even stranger than Befunge, because of the movement mechanics. As such, it would be pretty hard to implement. This leads me onto a point that, to this day, still fascinates me. Most formal systems–and esolangs–do "simple behaviour". But a lot of that behaviour isn't easily describable to a computer. One could perhaps even define esolangs as languages hard to define to a computer, but easy to define to a human (though I don't think we should adopt this, since a lot of languages would be excluded). And I think maybe this is why esolanging is an art. It defies how a computer should operate, for something that instead is for humans. And, just perhaps, implementing them, defies that, even though slight? I'm not here to argue for or against that, and I am one to try and get better at implementing, but, food for thought!
» Could you expand on how Karvity does something new with counter machines?
Oh karvity, the second child nobody wanted (Lul). karvity is one of those languages that are hard to describe to a computer. It's also one of the few languages I've made that is kind of hard to explain. This however comes from it packing a lot of different functions into a single control flow operator. That control flow operator basically calls the whole program following the operator, with one extra command added onto it, and then we repeat this called code as many times as the current counter. You could, in principle, write this as pseudo-code:
While I<=cur_count:
Apply call extra_com
I++(Note: giving a program as an argument to and instruction in an imperative language, is basically just appending that command to the end of the program, since reverse polish notation.)
As you can see, this is quite the strange construct for an imperative language, since a call/cc command is more common to functional programming languages. You could even, if you "convert" the counter value to a church numeral, write this as:
Apply church(cur_count) (call extra_com)Which is, once again, quite the strange construct of a conditional for an imperative language! This actually brings me to a thing I've been thinking about doing recently. I see in more and more of my esolangs, a mix of imperative constructs and functional constructs coming up as commands. As such, I had the idea to make a mix of the two, using some more basic imperative and functional operators, instead of the highly strange ones that come up when they build within me only subconsciously blending imperative and functional.
There is something I want to bring up with this. I think that this constant subconscious influence happening is very similar to art. You'll make it at the time and find you just took some choices without any real thought behind them. But then you come back later, and find some meaning in those choices. As you can see, this is the exact same thing happening to me!
» What do you remember of creating Bring to another? You have apparently many example programs to work from but somehow the language itself is lost! What is the story of its creation and attempted recovery?
Bring to another is a language that to this day mystifies me, both in the way of "how does it work?" (or you could say, Waduzitdo?), and "How did I forget this?". However I am quite surprised how complex it is, and it originates from many concepts I use now (as I mentioned at the start of the interview). But it's really just a question, and I don't have much to say! Sadly, we just still don't know that much yet. Hopefully, this is a call to someone here to try and solve it. I've personally abandoned it though, and I more so look at it for new ideas sourced from our theories on the language. Hopefully it inspires others as well.
» UnCompetition reminds me a bit of Chris Pressey's You are Reading the Name of this Esolang, in how they bring another aspect of computation into the act of writing code. Could you expand on what is a "solution" to an UnCompetition (sub-)program, and what is the experience of writing code in the language?
I hadn't heard of You are Reading the Name of this Esolang before! I do see the similarity. Now, what is the solution to an UnCompetition program? I think this is best explained by an analogy. Say you give a student a writing task, with a few rules. These rules are the conditions defined in an UnCompetition program, and what the student writes, is one of the generated programs. Now we just give this to a bunch of students, until they've made all the unique ones. Every one of the things written is a solution. Then we simply take each written piece, and put it as the conditions, and do this until the conditions become too strict, and it's impossible to write any more. This of course leads to a process of writing programs, that barely is programming and is… It's actually more similar to twisting the knobs on an AI system. You change the conditions again and again, until you just find what you want. A brute force method is probably the most effective. From what few programs I've made, it's very hard. The biggest thing to achieve is constants, and variables, etc. I did make a single program that was the constant 1, which is:
~!Here, ! means "Solution must be different", and ~ is a logical negation of the condition. As such the program says "The solution must not be different".
But overall, it's very difficult to program in, and I'm actually still working on figuring it out.
» Could you explain language 2I1IF in simple terms? Does it require infinitely large programs?
2I1IF is a family of languages, with the property that they can either be thought of as a universal function operating on some data, or, a potentially infinite set of functions that has one universal input. One of these languages is Uncompetition. The universal function could be the "solver" which finds all the solutions. But you could also consider each program as a function, with the input simply triggering it to find the solutions and then send the next triggers. There are three stricter subsets, called Sinistry, 2M1, and Metastry, the last of which is a combination of the first two.
In Sinistry, an infinite amount of outputs must be possible. Uncompetition falls in this category.
In 2M1, standing for Meta 2I1IF, the program can modify the universal function/input during runtime, requiring a way to switch between the two.
Then Metastry just combines the two requirements of Sinistry and 2M1.
2I1IF originated from my search of a Turing Completeness proof of Uncompetition, in which I found out both these interpretations existed. Then I realized that it's something probably pretty common. And as such, I described it! But to answer your question, it doesn't require infinite programs. Which is great!
» The Apraxia lang, named for brain damage, takes on the "pattern based esolang," a descriptor often misused (in a sense, all code is pattern based, but usually the lexicon is not really a pattern). What was your approach to this language? Is it true that any string is valid code in the language?
My approach was really just, come up with a concept, then generalize it for all strings and symbols. The biggest challenge was, "how do I modify and define data when there's no way to differentiate those two actions". I needed to be able to do that, because I had the secondary of being Turing complete(another open question to one of the readers).
In fact, I did tell the truth, Apraxia can interpret any string… IF it's >1 character in length. That's the only issue with that statement (but I do say it in the article).
But I do actually have a call to everyone. Stop calling everything pattern based. Most languages aren't. I can only name two that truly are, which is Apraxia, and Incident (which was the inspiration). So, Stop!!! Lol.
» Are there programs yet for languages of yours that surprised you or made you understand the language in a new way?
There are two specific cases (languages, not programs). First there is the infinite loop in Apraxia:
XCYCCWhich was so very surprising that it worked! It’s so short, and works very simply. Also, if you want it to look cooler, here’s one using greek characters (which also uses a very slightly cooler definition):
εωσεωVery cool maths I know (lol).
I have discovered that Apraxia very often gets into that type of loop.
I was also quite surprised by the copying function(defined as :(x)=c((x)(x))), which can be produced simply by an empty variable:
:c(Note that the c must end the program)
Next is is the program:
:/They aren't made by me btw (credit to Kaveh Yousefi on the esolangs wiki, who made an implementation and made the examples).
This program uses my language ;;;. It writes a 1 to one cell of memory, then moves onto the next one. It really surprised me how the commands behave, but they behave very well together. : is an increment, and moves to the right, and / decrements 0, which goes to the start of the program.
But yea, I'm very happy to find that my languages actually produce interesting programs.
» What advice do you have for people starting out with esolangs?
To any new esolanger designer, don't make what seems useless or funny, or whatever, to everyone else. Make the esolang you would have wished to be in the light. And don't focus too much on being the next new giant thing, nor making an implementation. Just go out there and do it.