In my second in a series of interviews with esolang developers, I speak with ais523. He provides an insider’s view of the esolang community, as an administrator of esolangs.org, and explores what makes esolangs interesting and challenging vs thematic and gimmicky. ais523 has created languages such as Underload and BackFlip and currently maintains C-INTERCAL, an implementation of the language that started it all.
>> Do you remember how you first found out about esolangs?
It was via 99-bottles-of-beer.net, which a friend of mine linked me to, knowing I was interested in programming. It’s a sort-of precursor to Rosetta Code, just featuring one program rather than many; and among the many “real languages” it has, there are also many esolangs. The site inspired me to find out more, so I looked up a few esolangs, and found first the entries on Wikipedia (specifically INTERCAL), and then to Esolang.
>> What drew you to create your own languages?
I’m not too sure, actually, although I think I was an esoprogrammer (that is, writing programs in esolangs and implementing existing esolangs) before I designed languages myself. To answer a related but slightly different question, which might go some way towards answering that one: the whole notion of concepts of programming interests me; some of my own languages are attempts to explore that (particularly Underload). There are only a few paradigms generally used in real languages (imperative, functional, object-oriented, and a few which are rarely used); but are there any others? That’s the really interesting question that I think make come out of esolang research.
>> How did you first get involved with esolangs.org?
I discovered it pretty much as soon as I discovered esolangs, and read it for a while; it was natural that I would help to update it as it made discoveries. My first edit there is this one, helping to fill in the article about INTERCAL; I think I was already maintaining C-INTERCAL at that point (although I’m not too sure on the dates around that period, I released C-INTERCAL 0.25 less than a month later, and I doubt I got it ready in under a month). I became an admin there rather later, because I was checking it regularly and more admins were needed to help deal with the spam problem. Esolang still gets a surprising amount of spam considering how small it is relative to most other wikis, but it isn’t particularly onerous cleaning it up.
>> I’m interested in your comment about esolangs addressing alternate paradigms of programming. Could you speak a bit about the approach that Underload takes? What is its paradigm?
It’s based on manipulating code the same way it manipulates data; instead of having separate flow control instructions like most languages do, instead fragments of program are constructed at runtime on the stack and converted into code to run. The paradigm’s used by some non-esoteric languages like Joy, but is hardly mainstream; it’s sometimes called “concatenative,” but that’s a more general term than the usage in Joy and Underload (referring to a particular property of program notation). It turns out that this is enough for a programming language by itself, providing enough power to construct things like arithmetic; I always like it when things like numbers can be constructed in a language from scratch rather than having to be added to it separately.
>> Are there other languages in particular that you feel present a really new approach to or perspective on programming?
Not very many; partly because new paradigms are hard to create, and partly because the ones that haven’t been explored yet are mostly completely awful to use. Sometimes a new niche can be found within an existing paradigm; Unlambda famously demonstrated that lambda calculus doesn’t actually need the lambdas, and the combinator-based style it represents is useful in some other languages too (Unlambda fails for practical use itself mostly due to lacking syntactic sugar and being deliberately insane, but some of the ideas are commonly used in, say, Haskell, although it’s unlikely to have picked them up from there!).
Some very simple Turing-complete languages are also interesting in the approach they take; cyclic tag, for instance (e.g. as expressed by the esolang Bitwise Cyclic Tag) is a very neat back-to-basics approach. It’s useful not for its power (or rather lack of it; it’s difficult to write in and slow to do calculations), but in that it is comparatively easy to implement in languages that would seem to be hopeless for implementing anything else.
>> Having been involved with esolangs for a while, and especially as an admin on esolangs.org, what is the activity like for esolang developers? Have you seen waves of interest in esolangs (and what do they seem to be in response to mostly), or is it pretty steady?
There are two main things that drive trends. One is people discovering esolangs from outside the community, and sharing them somehow (most commonly, finding esolangs.org, generally from Wikipedia which encourages people to post there in order to avoid cluttering Wikipedia itself up with useless pages on languages which only one person uses). People tend to explore from there, and will often see other languages in a newcomer’s light, often sparking interesting discussion. The other thing that happens is that sufficiently many people will get interested in an esolang simultaneously that discussion takes off and dominates a channel for days, weeks, or months; this is responsible for many of the long-term waves, as far as I can tell. Often, this happens as a result of someone starting a project, or sometimes as a result of a new person joining as explained before. Just general activity occurring increases the esolang activity even for unrelated projects, because it has a side-effect of increasing the proportion of the time #esoteric is on topic.
There’s an example going on at the moment, in fact; a revival of interest in BF Joust happened due to Lymia (a relatively new esoteric programmer) joining #esoteric on Freenode in order to test out FukYorBrane programs, prompting me to finally get around to fixing my demonstration that FukYorBrane was utterly broken (possibly an incorrect one, as Lymia had found a loophole in the @@ instruction I hadn’t…), reviving interest in competitive esoteric programming and eventually leading people to start competing the similar language BF Joust again. (It’s interesting to see the current leaderboard; some programs have been there over a year, others were added in the past week and seem to be doing fine.) That bump will likely be relatively small, and continue for just a few days before settling down again, but it’s already crowded out most of the offtopic discussion in #esoteric, leaving it mostly with BF Joust discussion, and people discussing their own esoprojects (at the moment, elliott with Shiro, a Funge-98 interpreter in Haskell, and me trying to improve my 1cnis interpreter). I think there’s something of a tendency to want to work on esolanging when everyone else is.
>> I was actually unaware of BF Joust. But looking at it now, it’s interesting how it is like brainfuck itself: a set of very simple rules that demand complex strategies. Do you see this type of clean minimalism as a design goal of your esolangs? Your languages often have very few commands (BackFlip, for example, with just two).
It’s not the only thing that inspires esolangs for me, but it’s common for me to make esolangs on that basis, and one of my favourite things to try to achieve. I suppose it’s more an issue of trying to find new ways to think about programming; and paring a language down to its minimums can help make it easier to think about, and to see how it differs from other conceptual models. (BackFlip itself was based on an idea on the now-defunct mailing list for adding procedures in a simple way to Befunge; it turns out that the procedure call mechanism itself was capable of lots of other interesting things too, like threading, and I decided to see just how far it could go.)
Minimizing languages only helps make them clearer up to a point, though. For instance, Unlambda has an i combinator that’s equivalent to ``skk, but the language is much mathematically neater with it included, and it feels like it should be part of the language. Something similar is true with many other esolangs; oerjan recently demonstrated that Underload is still Turing-complete without a, *, or !, which is an interesting result in its own right, but effectively a completely different language.
>> It also got me thinking about collaboration in esolangs, and this process of people building on others’ work to expand ideas in new directions. Esolangs are inherently collaborative (since to create one is to ask esoprogrammers to use it). Has this had a community-building effect (apart from the occasional waves of interest from others that you mentioned earlier)?
It helps to some extent, but I’m not sure if it’s as strong as an effect as I’d really like it to be. There are certainly interesting results that arise from people studying each other’s esolangs, but it tends to happen more in a vacuum, rather than with explicit communication involved; you normally get a language published online, then a few weeks or months later a result on the wiki, or an IRC comment, giving new information about the language, and often something that the original author hadn’t thought of. (For instance, this often happens with computational class proofs, especially as one of my hobbies is trying to gauge the computational class of new esolangs posted on the wiki. Normally it’s trivial, but sometimes it can be very interesting.) Another common situation is when people write interpreters for each other’s languages, but again there’s rarely collaboration between the author of the language and the people implementing it; in fact, you sometimes get the opposite, with the implementors trying to determine what the specification literally says, regardless of what the author actually meant! (This happens quite a lot with Funge-98, and has also happened somewhat with INTERCAL.)
>> It seems that brainfuck was an inspiration for many to first start exploring esolangs. Any opinion on what about brainfuck is responsible for this? Are there other languages that have also had a huge impact?
Brainfuck is interesting in that like Underload or Unlambda, it’s a distillation of a programming paradigm in a sense; but brainfuck is based on imperative programming, one of the most popular paradigms in “normal” computer use today. So not only is it low-level, but it’s low-level in a way that’s similar to what programmers are used to already, thus making it a rather accessible esolang. (Just compare the length of a typical brainfuck interpreter in C, to the length of a typical Unlambda interpreter in C, for an example of what I mean.) Likewise, it benefits from being reasonably close to machine code. It’s also the best kind of tarpit, having just a few instructions which are relatively simple rather than contrived to bring the instruction count down, or bloated to the extent of a practical programming language. This both makes it interesting to people not used to esolangs, and easy to memorise the “rules” (if not trivial to write), thus making for an interesting puzzle. So it combines three real strengths in an esoteric language in terms of accessibility to non-esotericers: interesting computational behaviour (close to minimal imperative programming), a useful tarpit-like nature, and ease of implementation (leading to the spam of uninteresting “brainfuck derivative” languages that people tend to make as their first esolangs).
We were having a discussion about the most impactful esoteric languages on #esoteric recently, in fact. elliott’s list was (I’ve alphabetised it because I can’t remember the order) Befunge, brainfuck, INTERCAL, Underload, Unlambda, and I think I mostly agree with that list. I’ve discussed the tarpits there (brainfuck, Underload, Unlambda) already, and they’re impactful for similar reasons (Underload and Unlambda maybe less so due to using paradigms that will be unfamiliar to many programmers, and being generally harder to implement).
Befunge is interesting in that it’s easily the most practical of esoteric languages; Funge-98 in particular is strikingly short on features designed to make programming difficult (IMO a good thing, but rare in esolangs), and has a lot of library support (almost unheard of in esolangs). However, its appeal probably comes more from the fact that the programming model is intuitively a very nice and interesting one; stack-based reverse-Polish is a relatively simple and understandable model also used by some non-esolangs like FORTH, and you can create loops in the program by drawing literal loops in the code, flowchart-style, which is quite nicely aesthetic. INTERCAL is mentioned mostly for its existing place in programming culture, predating most other esolangs by decades; I don’t think it’s inspired many people to become esoprogrammers (few people willingly read or write INTERCAL programs, although I admit I’m one of them), but on the other hand many programmers are aware of it and its general insanity, and get most of the jokes in the original manual.
I should also mention LOLcode, which has become pretty relevant as an esolang in the non-esolang community recently, much to the annoyance of most actual esolangers. It doesn’t have much intrinsic interest for most of the reasons people are interested in esolangs, being mostly a simple imperative language derivative with the keywords swapped out, just like there are a whole range of brainfuck derivatives too. However, it appeals for things like its visual appearance and general attitude, which although are IMO the least important aspect of an esolang, are one of the most immediately noticeable. (Having an amusing name helps too; I genuinely think that this helped out brainfuck, even if the swearword that makes up the name is unfortunate for various reasons.)
>> In addition to the joke languages (like LOLCode), it seems like puzzle languages also get a good amount of attention, which makes sense since enthusiasm for puzzle-solving is pretty common to programmers. But one thing joke languages and puzzle languages have in common is that they’re both fast to “get”: even if the puzzle takes a while to solve, it doesn’t really introduce a way of thinking that can’t be easily mapped to an existing one (a different paradigm, as you put it). Would you say you’re interested most in languages that are slow to experience (the way Underload is – I’m still trying to figure it out)? Is part of the value of these languages the way that they force us to reconsider existing paradigms even if the alternatives they offer aren’t necessarily practical?
Yep, to me languages are a lot more valuable if they require thought, rather than being just another synonym for simple imperative structures that programmers know so well already. Languages can be an interesting diversion if they just provide a weird set of primitives that can be mapped onto more “standard” ways of doing things with some thought; but it’s much more interesting if the point of view of the language is one that you can think in independently. I find this happens mostly to me with Underload and to some extent INTERCAL (which I think would be a really interesting language from a computational point of view if it added some more typical arithmetic and a goto statement, although that would obviously defeat the original point of the language); other people have reported it happening with brainfuck, which is a great language in a huge many ways. And yes, I don’t care too much about something like practicality, generally speaking, as it tends to get in the way of many of the things that make esolangs interesting; and it’s something that can often be “retrofitted” to a language afterwards, after the ideas are worked out.
>> Wiki Cyclic Tag reminds me of other types of translations from one system into another, in the way it repurposes MediaWiki software in a surprising way. In that way it resembles Piet (translating images into code) or even the P=NP problem translated into Minesweeper. Any thoughts on esolangs as interplay between systems? Is WikiCyclicTag about MediaWiki, or was that just the initial inspiration?
I suppose it’s just trying to make a point. Proving things that weren’t designed as programming languages to nonetheless be useful for programming was something I tried to do before I even discovered esolangs, and one of the best such demonstrations is to actually design a programming language around it. (Wiki Cyclic Tag is definitely “about” MediaWiki in that the syntax is deliberately aimed at getting MediaWiki to be able to parse it.) I don’t think most esolangs have this sort of system-dependency, with some of the most interesting ones living “in the abstract” (I tend to feel that syntax is mostly irrelevant except to give a way to feed a language to an interpreter), but it’s often interesting to see the occasional one that is. (On another note, cyclic tag seems to be by far the easiest computational model to implement in things that are naturally bad at computation; Minsky machines work well too, but only in systems that naturally have unbounded arithmetic.)
>> Do you have a programming background? Do you work as a programmer?
I was actually mostly a mathematician while at school (I was a reserve on the UK olympic maths team), and my degree was in electronic engineering. I’ve been interested in programming all that time, though; I think part of the reason I did electronic engineering rather than computer science was that the latter is much cheaper to study in your own time without university equipment to back you up. Nowadays, I have two jobs; teaching programming (mostly Java, which IMO is an awful first language to start learning programming with, but is what I’ve been told to teach, and picking up new languages is pretty easy for an experienced programmer…), and doing research for a computer science department.
(It’s esolang-related itself in a way; I’m studying the automatic generation of hardware from software, in a way combining my interests, and electronics can easily be considered an esolang in its own right.)
>> Has anyone figured out your Burn language? I love the challenge of reverse-engineering a language.
No, although I don’t think many people have tried. (Esolangs can be notoriously difficult to reverse-engineer from nothing but source code; I imagine it would be near-impossible for most of my languages except for maybe Forte, where the apparent obviousness of what’s going on is part of the joke.) I probably could figure it out with a few hours or maybe days of staring at it (having the advantage of having written the language in the first place, and perhaps remembering more details), but I haven’t really used what free time I have for that, with other esolanging projects having higher priority. (Perhaps it’s for the best that it’s left as a puzzle for others.)
>> Any advice for esolang developers first starting out?
Making new languages is fun, but it can help to implement existing languages and write programs in them in order to get practice and start thinking like an esoprogrammer (and I find that writing esoprograms is often more rewarding than creating languages, in fact). Don’t get hung up on syntax; what a language looks like is trivial to change simply with a find-and-replace, and it’s more important to have an interesting computational model. (If you do use an unusual syntax or appearance as your “gimmick”, a so-called “thematic” language, try tying it into the semantics of the language somehow; languages like Taxi and Haifu are good examples of this, and are much more interesting than thematic languages like LOLCode or the brainfuck-variant-of-the-week.) When implementing languages, don’t worry about implementing a language efficiently until after you’ve got an implementation working at all; and bear in mind that esolangs are typically easier to parse than ordinary languages, and so parsing libraries often aren’t really necessary (and the esolangs that this advice doesn’t apply to are generally so hard to parse that libraries can’t deal with them, I’m looking at you INTERCAL).
Interpreters are typically easier to write than compilers; for languages which are inherently easier to compile than interpret, target C or maybe a high-level language with the right sort of paradigm (such as Scheme for functional esolangs) rather than machine code and you’ll save yourself a lot of work.
