Future of Coding - Let's Take Esoteric Programming Languages Seriously
Episode Date: September 27, 2025One of the biggest goals of this show — our raisin detour, if you will — is to encourage people to look at computer programming differently. It's not just a job, or a way to make the compu...ter do what you want. Code isn't just the material you sculpt into apps and games and websites. The very act of programming itself, and the languages we make and use to do that programming, reflect who we are as people. Programming languages say something. Esolangs — esoteric programming languages — are programming languages created for these more self-reflective purposes. To some, they're defined by what they're not: not for serious use, not for education, not for efficiency. To others, they're a bunch of funny jokes that people can commiserate through after suffering the steep learning curve of becoming a programmer. A few find in them an opportunity to explore strange computational models, or baffling syntax designs. But is there more to them? Could there be? In this episode, we're discussing a preprint of the paper Let's Take Esoteric Programming Languages Seriously by Jeremy Singer and Steve Draper, and struggling with what it even means to give esoteric languages their due. Links $ Each of these episodes is a labour of love. If you appreciate that labour, slip us a five on Patreon. As is the norm, you'll get a second RSS feed with a bonus episode each and ev-er-y month. Except this month, there's actually two (2) bonus episodes, for the simple reason that this podcast swells with bubbles of hot waxy fluid that spill the container of my Ableton Live when they pop. The first pop is a half hour cut from this esolangs ep, the three of us brainstorming esolangs we'd enjoy, super casual and playful, perfect for building your parasocial podcast relationship, you'll love it. The second bonus, as I'm sure you've been expecting, is three hours of Jimmy and I relaying our experiences with Silksong, unpacking its few contentious design decisions, fawning over exquisite details, the good shit. So yeah, hand us one hundred nickles, help Ivan repair his basement, enjoy more of… whatever this is. Daniel Tempkin 🛌 😴💤😘 esoteric.codes Daniel's new book, Forty-Four Esolangs Joana Chicau The Less Humble Programmer Esolangs Wiki Entropy, an esolang by (total dreamboat) Daniel Tempkin Unnecessary, the 4:33 of esolangs, by Keymaker Turing Paint by Byron Knoll, which is similar to Brian Silverman's Wireworldand Lu's Cableworld Ivan's Visual Programming Codex, a collection of all the cool visual programming things Ivan has come across in his travels. Riskopoly — The Game of Capitalist Imperialism! Fanny#In_slang Brainfuck and Whitespace are two canonical esolangs. Our episode on Structure of a Programming Language Revolution, which includes extended discussion of Ivan's father-in-law's lookalike. Dreamberd is one of Lu's Esoteric programming languages, which has a (let's just say) "interesting" relationship with AI. The Story of Mel Piet, Befunge, and Malbolge are more classic, oft-cited esolangs. Fractran deserves special mention, since the language is comprised entirely of fractions, which is pretty neat. MarkovJunior also deserves special mention. Seriously, go look at the examples. Wild stuff. It's by Maxim Gumin, who also did the famous WaveFunctionCollapse project. We did an entire interview episode about Orca with creator Devine Lu Linvega, who more recently made Tote, a reversible rewriting sandbox. Reversible computing, something Ivan is particularly interested in. XKCD's comic X, about a programming language that uses fonts creatively. ArnoldC is one of those esolangs, like Shakespeare, Chef (which, actually, is kinda good actually if you actually have to eat whatever you code), or LOLCODE Wat; still hits. Bodyfuck Evil.css, "subtle and not-so-subtle CSS rules that will slowly drive people insane" Hest doesn't exist. Code golfing is the practice of making your code as succinct as possible, often at the expense of readability (though it leads certain people to write really good coffeescript). The International Obfuscated C Code Contest is related, in that it's about writing C code where unreadability is the goal. Jimmy would like to challenge y'all to write Fizz Buzz with no booleans, no conditionals, no pattern matching, or other things that are like disguised booleans. Arroost is a musical programming environment Lu made to NORMALIZE SHARING SCRAPPY FIDDLES. Inform is a natural programming language for interactive storytelling. PuzzleScript is a rewriting language for making tile-based puzzle games. Each of these sits at an interesting spot somewhere on the twisty boundary between the programming meaning of "expression" and the human meaning of "expression". The School for Poetic Computation occasionally runs a class called Digital Love Languages. Coming Out Simulator and other works by Nicky Case, and dys4ia by Anna Anthropy, are wonderful examples of the sort of deeply personal expression Lu and Ivan would like to see in programming tools. What music does Ivan listen to? Well… here's most of it. What music does Ivan make? Well… here's some of it. But Jimmy is fond of Diminished Fifth, an attempt to make some shrinking music with ClojureScript. It's no Merzbow. Zachtronics games, like exapunks — are they esolangs? A good number of recent videogames have included conlangs (constructed languages), such as 2023's fabulous Chants of Sennaar — but beware of spoilers, as some of these games might use the obscurity of the conlang to hide secrets in plain sight. Minecraft, natch, has a conlang for enchantments, and it's worth mentioning that redstone is an esolang of a sort. And then there's the Turing tarpit games, like Baba is You… the list goes on. Perhaps Tidal Cycles and Strudel are esolangs? Perhaps also the Game of Life? Hedy is an unabashed push to do something different! Jonathan Richman's He Gave Us The Wine To Taste It is probably my favourite of the various attempts artists have made to plead with their audiences: don't overthink this! (Friends of the show might be familiar with this one.) Isomorf let you view your program with your choice of syntax. It's like Hedy, but less humanitarian. Poe's Law is not Postel's law Music used in this episode: Two songs from Ivan's Organs. One from AG,BO. A slice of Diminished Fifth. The shortest track of this, the shortest track of that. The last song in the episode isn't on the internet, but the demo is. Jonathan Richman's He Gave Us The Wine To Taste It ! Send us email, join the FoC community, and find us on-line: Iv: 🐘 🦋 🌐 Jm: 🐘 🦋 🌐 Lu: 🐘 🦋 🌐 See you in dreamland~ https://feelingof.com/episodes/078/Support us on Patreon: https://www.patreon.com/feelingofcomputingSee omnystudio.com/listener for privacy information.
Transcript
Discussion (0)
Fuchsia
Red Cyrillian
Test
No, no, no, no, you have to say
The one I say
First,
Ack
And then you have to say a new one
Red Cyrillian
Well, it doesn't really matter
What you say, but sure, I'll do it
Chartreuse
Chartreuse
Crimson
Test
Crimson, periwinkle
Periwinkle
Blue
Test
Not Perrywinkle
All right, good
This is told
totally doable. This is workable.
Wait, wait, wait, wait, way, way, way, way.
Yeah, this is fun.
I'm helping.
Oh, good.
Great.
Yeah, just to give you more audio to try to deal with
if you decide to keep the segment at all.
Oh, okay.
I just select all delete for most of what you say.
Ha ha ha ha ha ha.
I had a dream about Daniel Temkin.
Do you two know who that is?
No.
Okay, so Daniel Temkin is referenced in the paper we're reading today.
So this is not actually a pre-segment.
This is the main segment.
Daniel Temkin, I don't think,
Daniel is in the
FOC Slack
Do we know what FOC stands for today?
Oh, the person who makes esoteric codes.
That's a weird abbreviation.
That is the abbreviation.
FOC stands for podcast
with no pronounceable acronym.
That old chestnut.
Oh, that's good.
That's good.
The listener can't see this,
but I said that with a big,
big old scowl on my face.
We heard the scowl, actually.
we heard it. It's all good.
I'm emotional.
Yeah, Daniel Temkin is a prominent figure in the world of Isolang's,
and for some reason I had a dream that I was sleeping in one of his four bedrooms.
That's what I'm bringing as opening material.
What have you all got?
Have you been to his house?
No, I've never talked to this person.
I don't know them from anything except that as soon as you start Googling Isolang stuff, they tend to turn up a lot.
They have a book coming out about Esolang's.
They have this website.
They're referenced in the paper a couple of times.
Yeah, sadly, the pre-order for this is a 403 forbidden because I was intending on pre-ordering it.
But I'm not allowed to.
Maybe it's just me.
Hmm. Yeah, I don't think I'll be trying that. Not after seeing the sorry state of this bedroom. That's not something in the cards.
So can I ask about this man whose bedroom you visited? So I don't know that name, but is it possible that I know some of Daniel's work?
So for the longest time, Daniel maintained this website called esoteric.comodes, that's the URL. And it is just a beautifully designed.
very expansive collection of interesting
ESOLANGs and unfortunately
I think maintenance on this website or like updates on it
in any meaningful way have kind of slowed down a lot
there used to be a lot of activity here but not so much anymore
but for anybody who is just hearing about this for the first time
it's a really cool website with a lot of weird ass
straight down the middle FOC programming stuff going on here
a lot of it quite visual a lot of visual languages
that I've never seen before.
Oh, nice.
I see Joanna Chikau here.
Body building the code performance.
She's from London.
I know her well.
That's cool.
Mm-hmm.
Mm-hmm.
I will dive into this website at a later time.
Let's dive in.
Very nice.
I did read Timkins' less humble programmer,
which, honestly, I wish we had read instead of this paper.
Oh, no.
What?
Well, the less humble programmer was very good.
And this paper mentions it as an exploration of esoteric languages.
And I think it was more insightful, more interesting, to be completely honest.
Oh, so it sounds like you were not a fan of this paper very much.
I didn't get this paper.
You didn't get it?
No, I didn't get it.
I don't know what it is.
Well, for one, it's a pre-print, and it's loaded with typos, and a lot of the arguments are underdeveloped.
And so I'm going to just assume that because it's a pre-print, they're still working on it, and that it will change a little bit after review or two is done.
The first time review or two is actually an uninvited podcast.
But I feel similarly that the paper is not very strong, but the thing that I do appreciate about this paper that I hope we'll find as we go through it,
is that it asks a lot of interesting questions and then doesn't really respond to those questions, but the questions are, I think, good things to reflect on and talk about.
So I don't imagine how much we'll be debating the arguments that the paper makes because they're a bit insubstantial, but coming with our own arguments might be a lot of fun.
This paper is the first one we've done on this podcast since I have now been a reviewer for other papers.
I had never been a reviewer before.
I'd only been a reviewie.
And it definitely has changed the way I approached this.
Which number did you get?
Are you reviewer one or two or three?
Which one are you?
I think I was number one in all cases.
But I can't tell if it's just the reviewer's software puts me at the top because it's me, you know.
Do you know my name?
Do you know my name?
Actually, I failed to do one of my assigned reviews.
So I ran out of time.
but I did two of them.
But I actually felt so bad about, not bad.
I felt really sensitive to, like, review in a positive way.
I was being so careful to do everything that was in the reviewer advice,
like make sure you, you know, to suggest appropriate other references to investigate
or like consider it in this context and blah, blah, blah.
and I was really worried I hadn't done enough
and then I realized I wrote like four times more
than any other reviewer on those two papers
and actually I think I think I did not enough
I think you know like I was kind of I'm kind of surprised
sometimes when I see how like sort of flippant some reviews can be
the one that did get accepted I think you know
I was a bit worried looking at the other reviews that it wouldn't get accepted
because they were a bit more lukewarm to it because maybe
similarly to this paper, it kind of touched on a lot of things without going into loads of detail
or even like not even answering some questions. But that really wasn't the point of the paper,
you know, like some papers are supposed to do that, some aren't. But we're getting very distracted.
This paper is called
Let's Take Esoteric Programming Languages
Seriously by Jeremy Singer and Steve Draper
And yeah, I mean, uh, the title.
I think the title actually does summarize what they're trying to do, which is to give an academic, like when I say academic, a computer science academic treatment for esoteric languages.
So this paper reads very much like you'd expect a paper at a computer science academic conference to read, where it's trying to walk through why people like esoteric.
languages, what the appeal of them is, why people create them, who create them, how they
could be useful in pedagogy, it's all those kinds of things. It's a very well-organized paper.
There's lots of different sections. It has great citations. That, I will say, without a doubt,
is one very strong part of this paper. It gives all sorts of interesting citations around
various things that have looked at S-O-Langs.
This paper came onto my radar because, now is it Alexander McLean or Alexander McLean?
I think it's McLean.
Yaxu.
Yaxu, I think he's called.
Yaxu.
Yaxu.
Yaxu.
Who shall remain nameless.
Shared this on the FOC Slack, which still says fear of clicking.
I need to update that.
And I read it and I thought, well, it's a pre-print.
So we'll probably get in trouble for doing this, but that's fine.
If we're not picking works that'll get us in trouble for some reason or
another that's not very punk rock so we should do it it's it's rough around the edges for sure and
and through the center but it does cover a bunch of material that i'm familiar with from my days
in university and being curious about what isolangs are and finding the isolings wiki and in this
slack a lot of people will share these weird isolings and there's there's a lot of interest in
esolings at least in the circles i travel but i don't know like we certainly haven't talked much
about them on the podcast, and we ought to, because really, if nothing else, like, this is
exactly what everybody in the Slack is supposed to do, and the fact that they aren't doing
it is a dereliction of duty, and so I'm going to start kicking people. Sorry, Jimmy, you were
going to say, yeah, Ivan, can you do me a favor? Yo. Can you read the title of the paper?
Let's take, oh, yeah, so we should talk about this. Is it ESOLANG or ESO-Lang?
No, just read the title first. Let's take esoteric programming languages seriously.
You would say esoteric?
I would say esoteric, yes.
I don't say esoteric.
You don't say esoteric.
You say esoteric.
Well, I code switch.
I say esoteric if it's in certain kinds of sentences.
Like, if I'm using it in one sense where it's like, oh, that's a really esoteric idea.
I would say esoteric.
But if it's programming languages, I will say esoteric.
Oh, no.
Why?
Language.
I was trying to figure out, is this a Canadian thing, but I don't think so.
Wait, wait, wait, wait.
What do you say, Jimmy?
Esoteric.
No.
No.
Do you say esoteric?
Wait, I need to say it both ways, and then I'll know, okay?
Let's take esoteric programming languages seriously.
Let's take esoteric.
No, esoteric, esoteric.
Yeah, but you know what?
It's one of those things that I don't usually say out loud.
So that is a British pronunciation.
Esoteric is the British pronunciation.
So it is a Canadian thing.
And esoteric is the U.S. pronunciation.
Right. And that explains why a code switch.
According to wictionary.org,
Canadian should say it esoteric.
Should.
They must.
Yep.
It is normative.
You must say it that way if you want to be a Canadian.
Which iso is it the one that's must should?
Oh, that's RFC 90, whatever, whatever.
No, it's ESO, actually.
Is it 2199?
It's ESO 2199, yeah.
That's fun.
Yeah, so what is this paper?
It looks at these things called ESOLANGs,
and it kind of defines what they are,
and we should probably do that as well.
And then it goes through, like, a bunch of kind of general questions.
Like, why do people make ESOLINGS?
Who makes ESOLANGs?
What are the different kinds of ESOLANGs?
That's fun, and we should do that.
And I didn't happen to,
but I thought about bringing a list of ESOLM.
lengths that I like that we can talk about, that would have been a fun thing for me to do,
but instead I'll just tell you that I thought about doing it, and then maybe we do it on the
fly.
I've got one.
Well, the paper itself gives us a whole list.
That's true.
You know, it gives us a lot.
Yeah.
But I want to hear Jimmy's one for sure.
Yeah, I've got one that I did discover during the, you know, other readings I was doing for
this paper.
I think it was in the less humble programmer, and that is entropy.
Oh, I don't know that.
Yeah, I thought this one was really cool.
Yes, it is in the less humble programmer.
So entropy looks like normal code.
It's like a mix of like C and Pascal,
completely normal looking code,
and it doesn't have any weird semantics,
like for the actual normal code execution.
You can write code very normally
with the one caveat.
When you access data,
it will slightly modify it every single time.
Cool.
Nice.
So if you try to do like 99 bottles of beer and you like re-reference a variable, it will like constantly go off by some.
97.003 bottles of beer on the wall.
Yes.
So every single time you access any variable, it will slightly alter the data of that variable.
That's good.
That's cool.
And Dave Ackley made this as retribution for people not doing robust first.
Yeah.
I was about to say this seems very much in the vein of.
of this, right?
So...
Does actually...
God damn.
I thought that was such an interesting one.
The other one that's also mentioned in this
less humble programmer is the language unnecessary.
Hmm.
And I'll just read what this paper says.
The language unnecessary by Keymaker has only one possible program,
and that's the program that doesn't exist.
If the program does not exist,
it will run and print its own source code to the screen,
which is nothing.
If one tries to run a different program, one that exists, the program will end in error.
Cool.
The fuck.
B-minus.
My favorite Esau-Langue.
It's called Turing Paint.
Have you ever heard of this?
Maybe.
It's a language that you code by basically using a program like Microsoft Paint to draw the program, hence it's called Turing Paint.
And depending on like the colors and the shapes that you use, it does different stuff.
But the kind of core primitive is you draw little blobs of different colors, like green means start, I think.
Red and blue mean various different things.
And then you draw little black lines between them.
and it's kind of node wire programming, but painting.
And I thought that was really nice.
Looks a bit like, is it Wireworld?
Is that the one that also kind of looks like this?
It's actually very similar to Cable World.
Cable World, there we go.
No, but that's a very niche reference.
So Cable World is my version of Wireworld that is way more robust
that lets you do sloppy drawing.
so in wire world you can't do very sloppy drawing like this but in cable world you can and in turing paint
it looks like you can also like there's a yeah because it's sort of painted with ms paint paint brush it looks
yeah but it's like stuff doesn't actually flow down it kind of just creates and like a syntax tree
from your drawing right yeah that the drawing is very much a source code and the execution is
happening somewhere else it looks like exactly yeah exactly yeah
Yeah. That's super cool. I like that. That is immediately going in the visual programming codex, which is my personal collection of any time I see a cool looking visual thing.
This paper, this paper, this paper, for me, screams as something where the authors wished this paper would exist. So they roast it.
And I know, maybe that's true for all papers. But like, I think it's like supposed to be a very,
helpful tool. Like, say I was writing a paper about Anisot-Lang or about Esolang's. This would be such a
helpful, like, signpost for researching things. Like, Jimmy said, it has loads of references. Like,
it has so many. But also, it can be something that you cite in your paper to kind of bring some
legitimacy to what you're doing, I think. You know, it's worth taking esoteric programming
languages seriously reference, you know, your first sentence, right? I would,
want to at some point talk about this whole notion of taking them seriously and I don't know where
this paper fits in this whole dialectic and why this kind of paper would need to exist or seem to need
to exist. I think that this is an interesting meta-conversation to have. Let's do it now. Screw the
ordinary format. We don't even get to read the paper. No quotes. We won't discuss it. Let's just have a
meta-reflective. We, we- Okay. Jimmy's having heart palpitations. I should say we can't make this
episode two esoteric because we already did that in intercal i'll just put that out there
we we already made our own esoteric podcast episode about esoteric languages where we do the weird thing
i don't know what you're talking about i don't remember anything like that yeah that was before
you were on the show oh yeah that's right yeah unfortunately for you jimmy this paper contains
a section on intercal including quotes from the intercal paper uh-huh which unfortunately
Fortunately, means this podcast episode is going to have to contain the entirety of the InterCal episode.
We need to talk about something that we can segue into actually talking about the thoughts that you had about the paper.
So you want like an intro topic?
Well, because that's what we usually do, right?
Is we're talking about some bullshit and then I pick a spot somewhere in the conversation.
Like, for instance, in the recently released out of the tar pit episode.
I haven't even, I'm sorry, I did listen to it.
You listened to it the way the canvas listens to the paintbrush, the audio medium of painting.
I have this way of picking a spot somewhere in our conversation that feels sort of funny.
And for the tar pit episode, we were doing something where we were joking about them being very cancelable takes and about having to cut them all out of the episode.
And I did cut them out of the episode, but I kept the bit about us talking.
about needing to cut them out. So the episode begins with us saying,
No, you can't segue off of something I'm cutting out of the show. That's not fair.
I know. I wasn't segueing. I was just, this is just a fact. You can't keep it.
It's like the B movie speeds up every single time they say B, but you have to do every time
it's overly indulgently self-referential.
B-movie edit where every time somebody says B, there's the entire future of coding
intercal episode. That's like Riskopoly. Have you heard about Riskopoly? Is it every time you do something
in Risk if to play a whole game of Monopoly? Yes, to determine who wins the battle. Great.
Oh, for God's sake. But Monopoly is so... Oh, so... So, Monopoly is not that bad if you actually
follow the real rules, but nobody does. No, it's still bad, actually. That takes... I mean, it's not good,
but like, it doesn't take 12 hours if you follow the real rules. But every house rule makes it take 12
hours.
Here's the thing.
Monopoly is kind of an esoteric board game, right?
How so?
It is.
How so?
It's clearly...
Okay, I may be just talking out my ass here.
Fanny?
Fanny?
No!
Can't say that.
Come on, man.
Oh, wait a sec, right, because for outside of Britain...
I don't say you know...
Fanny is the rear bum.
Oh, my God.
And in England, it's the other one, right?
The other one.
Jesus Christ.
Yeah.
Yes.
Oh, my God.
The game, Monopoly, and I quote from the publication Wikipedia,
The game is derived from the Landlords game,
created in 1903 in the United States by Lizzie Maggie, Maggie,
as a way to demonstrate that an economy rewarding individuals
is better than one where monopolies hold all the wealth.
It's also served...
I don't remember any of this.
I don't know. I don't know. I've just started reading the quote.
It was supposed to be an anti-capitalism game.
Yes. It wasn't supposed to be played, right?
And that's esoteric?
Or like, I don't know.
Yeah, it's a critique.
Made for reasons other than practical use. There you go.
Yeah, cool. All games are S.O. lengths because they are made for reasons other than practical use.
I don't buy that for a second. That's not even beginning to be true.
It's an S-O game, you know.
Are we actually going to meta talk about the whole serious?
Yes, let's actually.
Let's start with talking about what does the...
So actually, okay, okay, okay, okay, okay, one concession.
If you don't know what ESOLangs are, don't listen to this podcast.
Go listen to some other podcast that explains what ESOLANGs are and then come back.
We're going to assume that listeners...
Or we could just read the definition right now, right?
No, we can't do.
An ESOLLE...
It's right here.
It's very short.
It's very short.
It goes, an esoteric...
programming language, hereafter, contracted to Isolang following general convention, is
a programming language designed to experiment with weird ideas, to be hard to program in
or as a joke, rather than for practical use. Temkin, reference 55.
His bedroom was so...
tidy
bunk bed
and there were
pictures
Wait, wait, wait, wait, sorry
I just realized I read it wrong.
Temkin didn't say that.
Yeah, it's the beginning of the next sentence.
Whose bedroom is whatever?
Temkin.
Citation number 55
characterizes an esoteric programming language
as one that is intentionally unusable,
uncomputable, or conceptual.
Another definition is that
ESOLANGs are a class of languages
made for reasons other than practical use.
Which is what Jimmy was saying about monopoly.
Yeah, so if you've seen BF, I will not get...
We can say fuck on this podcast. It's okay.
We can say the proper name.
But you just censor it
I've stopped censoring everybody
except me and Lou at this point
I actually wait
I can't remember
I can't remember where we're at in the sequence
No you never censored me
I've never censored you
I didn't think so
Okay
I'd better start then
Oh fuck
But yeah if you've seen BF you know
Generally the kind of thing
White Space is also you know
A canonical example here
These are languages made
to be
not standard
to make them weird
and the whole
what I don't want
this to come across
as is that I'm
criticizing this paper
because I do think
these authors clearly
you know
have done their research
know their stuff
I'm criticizing
the fact
that this paper
needs to exist
at all
because you don't like
ESOlings
like you don't
think people
should make
languages for fun
or personal
exploration
or growth
or learning
or any of the
other reasons
no because I
because again
this is why I'm saying
I don't want to
criticize this paper
but I'm just going to say
what I want to say
this paper says
nothing
there's nothing new
there's nothing
insightful in this paper
at all
it is just a rehashing
of everything
that's already
been said about
S-O-Langs
it is something
that if you read
a blog post
it would say this
it's kind of
like common
folk knowledge
about S-O-Langs
anyone who's
in the scene
of S-O-Langs
would not think
that this
provided any new insight
Yeah.
What this is doing is writing about S-O-Langs in a quote-unquote serious fashion, and by that they mean in the style and expectations of an academic computer science conference journal, et cetera.
It's lifting that folk knowledge into a higher order realm, let's say, where we can apply different functions of analysis to it than we normally.
could. Neither of you were laughing. Never mind. I laughed. It's just the latency was so slow. I think,
you know, I agree with Jimmy that this isn't necessarily saying anything new. That was kind of what
I was getting at by saying this is a helpful signpost and collection. I think it is like
a valid work to do to collect all of that folk knowledge in a way and put it in a big list of
preferences. And I would also say that it covers this at a kind of resolution of detail that you
expect, I guess, in a more academic paper, right? Like the definition has, you know, like three and a
half four different citations on it so that you can be pointed to go looking further if you want.
And that sort of resolution is not something I would expect in a blog post, but I would love to,
but it's not something I would normally expect.
So I think there is some value in that,
but it's not necessarily like a,
hey, here's a brand new fresh take on ESail-Langs.
And that's okay.
That's okay by me.
So what would we expect this paper to do differently?
Would it suffice to just put forward more of a position
and make an argument about that position,
or would we want it to have a more obvious lens
that its curation is focused on,
or what kinds of things could this paper have done to better engage with this subject?
I think that's asking the wrong question.
Like, it's not up to the paper to fix the flaw here.
I'm pointing to like a cultural issue.
So I think of the same way that when we saw in the structure of a programming language revolution,
Richard Gabriel there talked about this Cook and Braca paper that was the first scientific paper about Mixins.
I see this is kind of in that similar vein, where it's taking something that's already been written about, lots. There's already citations, but that these things were not published in the right journals to be taken seriously. So the less humble programmer was published in the digital humanities quarterly. The less humble programmer is the kind of paper that actually dives into these issues in a very interesting way. It has this content.
with Dykstra, the humble programmer, and talks about, like, how esoteric languages are
flying in the face of exactly the advice that Dykstra gives to be a more humble programmer.
It turns out Dykstra is the real super villain of the show.
Yeah, I know, right?
I thought it was Gilad Braca and Cook.
Turns out, I don't think I showed this on the show.
I met Gilad Broca in Los Angeles at an Inken Switch thing, and he was hanging around there.
and he looks exactly, exactly to a T like my father-in-law.
And so from now on, whenever I see my father-in-law,
who I don't get along with very well, sorry, if you're listening to this.
Oh, Jesus.
He knows.
Oh, shit.
Yeah, they could not be more different kinds of people who look more identical.
So I'm just going to assume that my real father-in-law is Gilad Broca.
And that even though, actually, you know what, I didn't like his position in the revolution of,
programming languages in the 90s. So I guess they're both the same person. And that's...
Just let it all out, man. Just let it all out. You know, we're here for you. I haven't seen
his bedroom. That's my, that's my Broca story. That's, that's a fair point. I see, I think I see
what you're saying to me. Yeah, I think this paper is doing its job well. It is filling in a niche
that has been decided needs to exist by the systems we're in. But I think that's,
That's the very problem. The fact that these digital humanities are not considered reputable in the same way that this kind of style would be. And then instead of just being able to say, like, hey, everybody actually pay attention to the less humble programmer because there's interesting insights here, we have to like rehash a bunch of things that have already been said in a very bland, boring way in order to make them be taken seriously is the problem.
Right. So I'm not familiar with the less humble programmer and you keep referencing it. And you also reference a thing that it references. So it might help like is the less humble programmer a book? Is it a blog post? Is it a paper? It was a paper that's cited in here published in the Digital Humanities Quarterly. Okay. It's a 12-page paper. And it's doing what this paper is ostensibly doing of doing an analysis of ESO lengths. Yeah. But it's so much more interestingly written. It's,
looks at them in a deeper way, like, just like takes everything that's common knowledge and
puts it out there at the beginning and then explores deeper, whereas this whole paper
is just talking about all of the common knowledge of ESO-Langs for the whole paper.
I'm not saying don't read this paper. It just makes me sad that this is what academic
computer science papers are like, and this is why I don't always enjoy doing recent academic
computer science papers, because I find them to be very surface level.
Let me read to, you know, get off the meta discussion.
Let me read what this essay claims that it's doing, like what claims it's making, not that
what claims it's doing.
Yeah, yeah, but what claims it's making.
It's not the snarky version of that.
Yeah, yeah, sorry.
It sounded like I just said the words backwards.
I was not.
So the claim of this essay is that esoteric languages are inherently useful and deserve to be
studied in a serious manner.
The first question we seek to address is, what is the appeal of Esolings in general?
Our discussion will cover the following four high-level reasons for their popularity.
A sense of fun or playfulness, recalling a lost golden age of coding,
sense of cultic initiation, artistic value.
The second question we will address is,
What is the appeal of designing ESO languages in particular?
We'll explore the reasons of parody and comedy before moving on to consider the skills
of working with a very tight self-imposed constraints
and the attraction of creating a programming language of one,
one's own, as Virginia Woolf might have said.
And then there's a third question that they ask later down, which is, why is it beneficial
to expose learners to esoteric languages?
So is there some educational thing going on here?
So, yeah, those are the things that this explores.
Why do people make esolangs?
What esolings exist?
It talks about that a little bit.
Who is making these esolangs?
What are the different kinds of esolangs?
And that section is probably the one that I would.
left least satisfied about there. I'll join the bandwagon of dumping on the paper that we're
reading. It mentions this, this idea of a programming language of one's own, as Virginia Woolf might
have said. And I, much too likely Eli and everyone else's chagrin, haven't read Virginia
Wolf and was not familiar with that meaning of one's own. And so I asked chat GPT, my search engine
of choice. Oh, no. To tell me about a programming language of one's own and what that might
mean. And I just want to like very briefly paraphrase some of the conversation. So it does
just for the benefit of the reader. Here's what chat GPT told me, which I take at face value.
The idea of a room of one's own, and I quote, comes from her extended essay of the same
title. In it, Wolf argues that for women to write and create literature, they need both financial
independence and a literal and figurative private space. The phrase, a room of one's own has
since become a metaphor for the freedom and resources needed to create and think independently.
Is that fair? Are either of you familiar with the reference? Does that line up with it?
I've never read it, but that's how I understand the reference roughly. It seems to be
summarizing Wikipedia well. Great, cool. So I followed that up by asking the GPT.
What might it mean to create a programming language of one's own in that specific sense?
The sense of creating a programming language of one's own would be like carving out your own unique space in the world of technology.
Just like Wolf emphasized the importance of having a personal space for creativity,
having your own programming language means you can shape it exactly how you want,
reflecting your own ideas and priorities.
It's all about having the freedom and independence to create something truly your own.
So completely missing the cultural and historical context and the deeper meaning
and all of the subtlety and importance and vitality of Wolf's meaning here and just going like,
yeah, it's about like being your own free-spirited, creative kind of person.
And so I followed that up by asking GPT, and I swear this is going somewhere,
what would it do if it was going to create a programming language of its own in Virginia Woolf's sense?
And I was hoping that it would get something like, oh, yeah, I'm an AI.
I don't really have this sense of self-identity because I'm, you know, I'm in this sort of trapped position and maybe there could be some very interesting self-analysis to come out of this.
This is a great segment.
Questions about empowerment and independence and that sort of thing, which I don't mean to suggest that AIs have anything in common with the plight of women historically and their lack of independence and all of that cultural context.
And so I asked it, you know, what would it do if it was going to create a programming language
of its own? And it says, well, for me, it's all about supporting you in whatever creative or
innovative endeavors you want to pursue, whether it's helping you brainstorm ideas or solve
tricky coding challenges or just be a sounding board for your thoughts. I'm here to help you
carve out that space for yourself. Let me know how I can best support your journey.
And I, it could only, only ever answer this question of what would it do in terms of
saying that it would basically be subservient to me and my needs and my wishes and my whims.
And that, like, inability for the AI to do anything that wasn't obsequious and subservient and, you know, self-diminishing
smacked me so hard in the face because it's, I'm asking it, you know, to look at this,
this wolf quote that is about the entire opposite of that.
And it can't.
And so I, this, like, AI is, is pointless and doomed and it is useless and it basically
paraphrased Wikipedia and that's all it could do.
And any illusion that came about because of the fact that I was doing this as a voice chat
and it could sound like a real person is just, it's just trickery.
There's no depth or real intelligence here.
AGI is never going to happen.
That's what I got out of this conversation.
If you think this is off topic, the end of the paper asks, can LLM's write esoteric programs in existing esoteric languages?
And then it asks, can an AI create an ESOLANG?
And I will say those were very weak sections for anyone who, like, you know, they didn't try very hard, it doesn't seem.
But they answered no.
But they just like kind of one shot at something and saw that it was broken.
Well, I guess like this paper, you know, using that quote,
from Virginia Woolf.
It's really, I guess,
hinting that at Esolang
is a creative pursuit.
You know, one of their main points
is that it can have artistic value.
But even the other points
that aren't explicitly about that
hint towards it being a creative thing as well.
And that needs to involve
some relationship
between the author of
the Esau Lang and you.
You know, it's kind of a way
to say something. You know, when InterCal was made, it was made to say certain things and it
does various parody-like features to comment, you know, to be part of a dialogue. You know,
if there's no person behind that, I think it can feel a little bit cold and a little bit like
it's missing something. I occasionally asked ChatGPT to create new Dreambird features. Back when, like,
GPT was very early and very, very new. You know, I have no doubt that it can kind of mimic my
writing style for Dreambird. Dreambird is my esoteric programming language, or one of my esoteric
programming languages. You know, one of them. In fact, I truly believe all of my languages
are esoteric, but, you know, it's, it was very safe, you know, I think the fun, one of the fun
parts of Esau Lang's for me is that they all seem a little bit naughty, a little bit risky,
a little bit risque, you know, Indecal poked a lot of fun at things. Brain fuck has fuck in it.
And, you know, a lot of these, like, super low-level languages, they're very kind of dangerous
to write in in a sort of memory safety way, you know?
Yeah. I think one of the best parts of this paper is it's talking.
about, like, one of the things that esoteric languages are doing are embodying kind of the
cultural norms of programming, especially as those cultural norms are changing. And it mentions
this, you know, notion that programming ought to be hard. I have some big thoughts about this.
I have some big thoughts about this. Yes. Some of the first things it talks about is, like,
how the rise of these high-level languages made programming much easier for a lot of people.
and S.O. Langs are in some way this kind of nostalgia, at least some of them, are kind of this nostalgia for a time where programming was very hard for humans to do because these machines were so level. And it mentions this story, the story of Mel. And are you all familiar with the story of Mel?
No. Originally from Usenet, written by Ed Nather in, well, according to Brian Cantrell, this is not the original. It was originally on YouTube.
Newsnet, and I think it was gathered up in some anthology. But I do, I just do have to read the
first paragraph here of the story of Mel, because it is, it is nice, it's wonderful.
Real programmers write in Fortran, maybe they do now in this decadent era of light beer,
hand calculators, and user-friendly software. But back in the good old days, when the term
software sounded funny, and real computers were made out of drums and vans.
vacuum tubes, real programmers wrote in machine code, not Fortran, not rat four, not even
assembly language, machine code, raw, unadored, inscrutable, hexadecimal numbers directly.
So good.
Wow, Mel sounds like a real fun hang.
Jesus.
It was written as a, you know, as a kind of a joke on Usenet, right?
This kind of like poking fun.
But it does tell this story.
of Mel Kay
who was tasked with
making this
blackjack program cheat
because the salespeople
or people
wanted to have customers come up and use this
Royal MacB, LGP30,
and they had this blackjack program
and people kept losing.
And they wanted to be able to hit a switch
and make it just cheat so that the customer
would win. And Mel did not
enjoy this idea. He thought it was fundamentally
wrong. And so he finally went and did it. And it turns out by pure accident, he made it
go in and do the opposite. Every single time you hit the switch, the customer would lose
immediately. And the author here, Ed Nathar, was being tasked with going and fixing Mill's
program. And he discovers the beauty that is the program Mel wrote for this LGBT. L-G-P-30.
L-G-T-30. Yeah, it's a good story.
L-G-G-T
Yep, L-GP-30
Yep, I have doing it
L-GP-T-Q-I-A-plus
They should have changed
Chat-G-T to chat LGBT
Oh, Jesus, they would never do that
That's the
That's the Libre version of GPT
is LGBT
I got Jimmy, there we go
Okay, so just, I'm going to just read the headlines
of this paper, the headings
and we can dig into some of them because some of them are fun.
So there's a section on background
where they talk about a couple of different isolangs that exist.
They talk about Intercal.
They talk about Shakespeare chef, which I'd never heard of,
but it's this like cooking recipe-centric isolang
where you have to like use cooking terminology to manipulate data.
And this section, I think, is trying to identify
some of the different ways that esoteric languages
are esoteric.
The funny part is that intercal
just gets his own section.
Yeah.
It doesn't really have like a,
you know, like a description
or a heading. It's just intercal being intercal.
But I think that's one of the
disappointing parts for me of this
paper is like really digging into
why intercal is so
legendary in a way. But yeah,
some of the other reasons are
you know, natural language
using natural languages are really common.
way for esoteric languages, if you ask me, it's quite a boring approach, like Shakespeare. Quirky
syntax being another one, quirky computation model being another one. So quirky syntax would be like
brain fuck or white space or even Piet is used as an example where you use images. Quirky computation
model. Brain fuck is actually used as an example here, but I'm not sure it really fits.
into that section because it is really like just like it is a touring machine right it's pretty
unquarky in a way but maybe it's quirky to just code on a touring machine full stop
uh bifunge and mal bodge malborge that's a typo malbodge mal yes mal bodge also they say fractan
uh throughout the paper it's fract tran how do you know how do maybe there's another one so i think the
computational model section is also a little bit disappointing to me because I think there are much better examples. I think the examples here are, they're more like more quirky syntax examples. I think a better thing would be something like Markov Jr., which is this probabilistic language, or even like more node wiry things where the computation runs in front of you or something like Orca, where the
is running in front of you. I think there is
any, maybe
I'm being a bit harsh there, but I think
yeah, these read
more as quirky syntax to me.
Yeah, since we're citing a bunch of Deveen
things all back to back to back,
Deveen, Lou Linvega, a previous guest on the show.
Have you two seen Tote? No. Can I send
you a link to Tote? Tote's super cool.
Let me get you the URL. I'll just read it out so that people don't have to go
and look in the show notes. You'll read it out.
It's...
Wiki.X-I-I-V-V-com
slash site slash tott.
It's this visual environment where...
Oh, I know, Tote.
Yeah.
On the left, you have a bunch of...
kind of, let's just call them emojis,
but they're made out of like little pixel,
like fat bit pixel graphics,
but of like triangles and diamonds and squares,
and some of them are filled in and some of them are hollow.
And then you have next to that a list of sort of rules
that sort of a big long list where you say,
like hey if there's a triangle and a circle it turns into a square or if there's a square it turns
into two triangles and then to the right of that is this big open canvas and you can drag and drop
whatever these symbols into the canvas that you want and then and on this page that that that
little first image is actually a is a little interactive environment you can click and drag around the
things and play with it um so you could put in like a you know a square and a circle and then
you click the little step button which looks like a little arrow and then uh it evaluate
the rules in it in a kind of a deterministic way and it's a fun little language and then they
started using it to like implement games and like uIs with scroll bars and all sorts of other
little algorithms and and things out of it and it's quite quite deep and expressive but all
you're doing is just looking at like oh hey if the canvas on the right contains a triangle
in a circle replace it with a square you can run it backwards or forwards so it
it's a it's a reversible computation system which is a which is a like reversible um execution
is one of the more obscure kind of execution models the so i feel like this one is like a four
quadrant win as far as east of langs go 10 out of 10 it's like it does all the things the
syntax is weird it's funny it's uh hard to make things that are useful um and the computation model is
is wacky.
So that's that's tote.
That was one of the ones
I wanted to shout out.
Valid.
Yeah.
Piet, another one
that I wanted to touch on for a second
because this paper mentions
that it has this
and I've only ever seen Piet
like I've looked at Piet programs.
I haven't actually read
much text about Piet
that feels kind of, you know,
against the purpose of it.
But apparently it,
the way that they talk about
one of the concepts
and how it executes is that it has a direction pointer,
which they describe as a two-dimensional program counter.
So when you have a PIT program, it's a ping,
and you start at the top left pixel,
and then you start executing, I believe, to the right,
I can't remember,
and you kind of walk pixel by pixel through this image,
and any time you hit a pixel that's a different color,
that new color represents,
new operation that needs to take place depending on which color it is it's going to pick a
different operation and then and then the direction pointer might continue in that direction or it
might change direction but it it's this kind of abstract visual language that you can
rescale the pixels of the image without changing yeah the semantics of the program you can
scale the image up and it will do the same thing which i i think is a is a really wacky i
idea like what would it mean to make a textual language where you could scale up the text scale up
the text is that akin to changing the font size could we make an isolang like there's this x kcd
comic where it's like oh yeah every variable has to be named x but you tell them a part based
on which font that the letter x is written in you use the font to to differentiate the different
variables maybe that somebody should do an easelang where the font size has a has a semantic
meaning in the language. Anyways, yeah, Piet. I mean, Dreambird has, supports rich text now. So,
you know, you can embold, change font size. What does that do?
Fuck all. Well, so there you go. PR is welcome. Well, actually, if you emboldened everything,
you know, nothing happens, but you can have different variables, like one could be emboldened
foo, and the other one could be like, you know, italics foo. And you assign them
to different things.
No one's implemented that part yet.
I'm still waiting.
One clever thing about the semantics of Piet that I like is that it's not about the exact
colors.
It's about the change in colors.
You know, as the colors are changing, you look at the change between one and the other,
and that decides the operator that you're doing.
Oh, I didn't know that.
That's sick.
Yeah.
Which I think that's really, really a smart encoding, because otherwise, because it lets you, you know,
choose to have different color schemes,
etc., which I just think is smart to do this kind of setup.
So if you're going to do something visual,
letting people have some expressiveness in those things.
So, you know, if you just directly assign colors,
it gets a little boring.
And yeah, you can be like, oh, it's whatever the closest color is,
so it gets a little bit more.
But I like it that it's about change.
And it also makes it so that you kind of get this geometric structure
going on, which
you know, is
this, the whole language is a reference to
Mangriand, who did these
geometric paintings, so
it's very clever. So if the, if
it's actually the, like,
the change in color,
does that mean you get a much
bigger
space of, I'll call them
op codes out of fewer colors?
Because then it's like the product of all
of the different color combinations,
rather than just each color stands for one thing.
It's like each color paired with another color
when you switch from one to the other.
Yeah, they look at the lightness change and the hue
and look at how many steps have changed
and that gives you like a little table
of those two combinations to give you your operators.
That's sick. I had no idea.
Yeah. It's very clever.
So you could make an animated,
like you could have like a palette cycling Piet program that's...
Yeah, so that it stays the same program,
but it looks visually very different.
That's wild.
That's so much better than Chef and Shakespeare,
which are just like, you know...
It's the easiest thing.
May I compare the to the previous binding of the variable?
If you ask Chartip-T to make an ESO-Lang,
it makes something like Shakespeare.
That's all I'm saying.
That's all I'm saying.
I don't know.
Arnold C is art.
I don't know what you all are talking about.
I don't know what Arnold C is.
Tell me what Arnold C is.
For example,
when you end a method, you say,
Astila vista, baby.
Bad, this is bad.
And then if you assign a variable, you say,
This is a chabler!
You see, that's so, you know,
it's almost like in the ESO-lying world,
it's the Issa Lange's version of like a Christmas cracker joke?
Yeah.
Wait, do you even have those in America?
No, I idea what that is.
Are you serious?
No, you're just pulling my leg, right?
I don't know what a Christmas cracker joke is.
Oh, no!
The thing where you grab both ends and you pull apart and the joke is like just the stupidest, most banal.
A fortune cookie is what they're called in the United States.
No, it's a little...
Okay, that's what you just described.
When you open a fortune cookie, you don't get a terrible pun.
You do get a joke.
Those aren't jokes.
Those are life advice.
No, you do not.
There's both in some things.
There's like the thing and then a joke in them.
It's like, you will die within 72 hours.
Ha, that's so funny.
It's more common for it to be a, you know, a proverb.
Riches will await you.
Popsicle stick jokes would be the real example.
Right, right, right, right.
So something like Astel Vista, baby, it's like very obvious.
very low effort, but it's kind of like, oh, that's so bad, that's so stupid, you know.
It can be enjoyable in a different way.
It's not high art, not like dream, bud.
I don't know what you're talking about.
This is clearly high art.
This is actually an interesting angle that the paper doesn't get into.
So, right, if one of the reasons that you can make an iselang is for comedic value,
then that means that it's fair game for us to assess the quality of an easelang on the
quality of its comedy. Exactly. Right. If we're going to take S-O-Lang seriously, what that
means is criticizing some of them, talking about what makes for a good S-O-Lang, what makes for a bad
S-O-Lang, which ones are actually doing something unique and which ones are derivative.
And we can do that about any programming language, but specifically, like, I'm not going to
look at Java and go like, well, Java 6 is less funny than Java 5, so it's not a good programming
language but I might do that for lull code or something like that like lull code which is the i can
has cheeseburger version of one of these yeah it's just not it's just not funny like as a creative
work it's maybe personally fulfilling to the person who made it but you know it's not going to do
well at the fringe okay right let's let's uh let's rate how funny programming languages are
Scala, hilarious. Scala, like, low-key killer.
Yeah, I mean, some, like, mainstream languages are more funny than others, right? Or, like, have more potential for humor. Oh, my God, Pearl. Pearl is pretty funny. I'm pretty sure we've talked about Pearl.
Never. I don't think we've ever talked about. I love Pearl. I mean, PHP is pretty funny, but it's not necessarily trying to be funny.
It's trying hard to be taken seriously.
what's funny about it. JavaScript people think it's funny, but that's just because it's well
known, you know? JavaScript people think it's funny because it's different from what they expect,
and they're a bunch of jocks who laugh at languages for being different. That's why they laugh at
Ph.B. They're bullies. Right. You know, like the, the Watt talk. Yes. Yes, exactly. Yeah.
Yeah, leave JavaScript alone. Stop laughing at Jop.
JavaScript hasn't done anything wrong to you, you know. Maybe it has actually. Probably
has.
So there's body fuck?
Yeah, I saw that.
What?
Yeah, it's at the very bottom.
If you go to Daniel Temkin's messy bedroom and split.
It's dark.
When he speaks, I hear other voices inside his words like the mad quad.
Fire of the dead
When he speaks, I hear all the voices inside his words like the mouth fire on the dead.
It wasn't actually.
I'm looking at the same.
I don't want to take that there.
It wasn't actually messy.
It's just weird that it had a bunk bed.
If you scroll to the bottom of the page of esoteric.
So you just Google body fuck
Oh
Oh and it's a 44
All right
Perfect language
Body fuck for people who don't know
Is brain fuck
But you have to basically
Interpretive Dance
The whole thing
That's pretty funny
So you have a camera input
And it does gesture recognition
To figure out
Which thing to run
Which I think is fantastic
Yeah that's great
That's very good
Sadly all the videos
of the programs are gone because
Vimeo deleted
all of the stuff
if you didn't have paid accounts.
Vimeo funny. YouTube,
not funny. YouTube, not very funny.
Vimeo, really funny.
So, I think we need to talk
about, like, what is humor?
You know, what is comedy?
I've got some books on that.
Let's take comedy seriously.
We could totally read a philosophy of comedy.
I've done the fringe twice.
That's twice more than you two.
I've done many bad shows.
shows, many bad comedy shows. So I feel like I can say something about comedy. You could decide,
listener, you decide if I'm entitled to say this. But I think, you know, there's some of these
languages. They're like puns, right? If you get why something is funny, then you feel this shared
connection. You're like, in on the joke, like brain fuck. It's kind of like, huh, yeah, that would
be funny. That's ridiculous. I get why that's ridiculous.
And in fact, you know, you can sort of imagine someone trying to use it and laugh at the ridiculousness of it and relish in the challenge.
And that's funny.
I think some of them are very absurd, which is sort of the same thing, like the Asta Le Vista one.
It's kind of just, it's random, lull.
And you sort of get that it makes no sense.
But the funny that I'm most interested in is not those.
It's more like the ones like InterCal, which are very observational.
They are parodies, they are satirical, and they're saying something by pointing out how funny something is.
Intercal is funny, not because Intercal is ridiculous, but because it's pointing out other things that are ridiculous.
It's observing the state of computer science academia and the state of languages and instructional manuals for language.
as it's a parody. It is an instructional language. I think this is something that's not really covered in this paper, which is actually how comedy can be a tool for making a point. So, as we all know, InterCal was written by two students almost immediately after sitting their exams, who must have been, like, I don't know, had some certain feelings about the state of learning.
computer science within an institution.
And the thing I think this paper gets wrong is that it,
InterCal is saying that programming should be easier,
whereas this paper thinks that InterCal is enjoying the difficulty of programming.
Maybe something like BrainFuck is enjoying the difficulty, maybe,
but InterCal is certainly complaining
at the difficulty of programming
and we can sort of share that shared suffering together
by observing how ridiculous it is.
That's why I love InterCal
because it's so observational
of things that are true even today.
The paper walks right up to recognizing that point
and just barely misses it
because it talks about one of the reasons
that people would make an ESOLANG so hard is that it reminds them of this earlier time
when programming was harder. And maybe it's an earlier time in their career when they were just
learning and programming seemed mysterious and difficult and challenging. Or maybe it was an earlier
time when it was less corporatized and industrial and professionalized and it was more fringy
an experimental and new back in the earlier days of the industry. And the point that I think that
it just barely misses is that in basically all of these cases, it's hearkening back to a time
before programming was a job, back to a time when programming was something that you did
because you had this sort of personal passion for it or this personal like, like it meant
something deeper to you to be programming and to be exploring the space. And then eventually it
turned into something that you do because you have to because it's your job and you're trapped
by that. And I think that that's very different from how this paper takes it, which is that it
suggests that it's about participating in this cultish sort of vibe where you find kindred spirits
who also all appreciate the like dark soulsy challenge of programming and do things that are hard
just because they're hard. I think that that's a slightly superficial
read on it.
ESO lags tell us what kinds of hard programmers like and what kinds of hard programmers don't
like this sort of puzzle-solving technical challenge of something like BrainFuck, I think
many people enjoy.
So BrainFuck is a kind of fun celebration of that, whereas just fighting the compiler,
getting really unhelpful feedback, not being able to know if you've done the right number
of pleases in InterCal without any feedback on that at all, that's the kind of hard that
everyone hates. You know, InterCal really touches on the cultural aspects of that. Like,
it touches on how many programmers want to make things that are hard so they can feel better
about themselves, you know, as a sort of hierarchical thing. And that's the kind of hard that I think
intercal is saying we don't want. So I think it's too reductive to say that Esolang's state that
programming should be hard. Isolang's, in my opinion, state a certain kind of hardness
that is wanted, that is this kind of puzzle solving instead. There's another version of this
kind of Esolang thing, or maybe it's not even Esolang, maybe this is getting outside the
bounds of Isolang, but it's like doing the same thing for the same reason in a different way,
but that's things like evil.cSS, which is a style sheet that if you happen to put it on somebody's
website, it will really subtly
with the website in ways that get increasingly
deranged. It's literally like
this is a little prank that you can pull on people
via CSS, which is another
interesting way of doing this, where it's not
like expression through the creation of a
language, but expression through the perversion
of an existing language, which is another
of that kind of, like, I think that that is actually funny
in that same kind of observational way that
InterCal is funny. And part of it is that I think evil CSS has a bit of prankster spirit to it, but I think also part of it is that it's like a reaction to how people feel about CSS. The tagline is because CSS isn't evil enough already. Like there's this kind of feeling that CSS is not a very good programming language. I guess there's a line here where with ESOLANGs, people are making these languages and expecting that they're not really going to be used to do anything serious, right? That's a point that this essay kind of makes.
But it makes me wonder, like, has anybody used an ESOLANG to actually build something, like, substantial and serious, and not just using, like, Kodgen or whatever, but has anybody actually built something that qualifies as an ESOLANG and done serious work with it?
Like, for instance, if I'd ever finished Hess, I think that would qualify as an ESO lang, but the purpose of Hess was to, like, actually write real ass software with it.
So where's all those?
Where are all the ESOLANGs that people are making that are like, yeah, it's an ESO lane because it's like decidedly different from other mainstream programming languages, but I'm making it because I actually want to like...
J and K.
Yeah, yeah, exactly, yeah, yeah.
Well, I think that's like a, I'm sure Jimmy has stuff to say, been quiet for a while, so...
Let's not let them.
But I think that's sort of like the next step of conversation about this topic in general and is somewhere that this paper.
doesn't really go towards it's like there are these examples of programming languages here which
are very clearly esolangs but i can think of many languages that are definitely on the fence or many
that can be esolang or not depending on your context or how you using them or like what point in
history it is you know like i think you know even javascript when it first came out was just like
hey maybe a baby scripting language maybe it's a bit esoteric to use
it in a certain way, but it's transformed.
Yeah, as Automator or shortcuts, like iOS shortcuts, is that an ESOLing?
It ships on everybody's iPhone.
There's like billions of copies of this programming environment that are out there.
But effectively, nobody uses it.
Is shortcuts an ESOLING?
Is it funny?
Not really.
No. Shortcuts is not an ESOLANG.
Why not?
It's not trying.
I mean, I don't think that there's going to be.
hard and fast criteria on what's an S-O-Ling or not, right?
Like, I think it's going to be some fuzzy boundaries here.
But in general, an S-O-L-Ling needs to be created as a social commentary.
I don't think it's, like, created for something other than practical value.
I can create lots of languages for something other than practical value.
But S-O-Langs are esoteric because they're in contrast to some prevailing cultural norms, right?
that they're a reaction.
There's somebody saying, trying to push the bounds of what programming languages can look like and be.
Even if they maybe for some of us, you know, like, okay, like brain fog, it's like, ah, yeah, it's just a turning machine.
But for a lot of people first encountering this, it is quite challenging to their notions of what programming looks like.
And so I think that that's what these things are really a reaction to.
Yes, they can be making jokes.
Yes, they can be trying to do something difficult, but they're really trying to push the bounds of what programming languages can be in the same way that art, like modern art is trying to do the same thing.
It's about like intention behind the creation.
Yeah, I do think, you know, yes, you could try to take something as an S-O-L like J or K, and J-R-K may be qualified because they're trying to do this, but really their reaction to APL, you know, and they're not trying to, like I think the practical purposes is,
not quite the right way of doing this, but they're not aiming for code to be written by other
people so that they can accomplish a task. Like, I understand that's still like practical purposes,
but nor are they like, oh, I just wanted to implement a language so I can learn something. Like,
I still think practical is the wrong thing, but they're trying to make people encounter these
programs and think something different about programming. That is, to me, the purpose of these
S-O-Langs. And if they're good, they do that. They really, at least for a certain group of people,
they really challenge you, they really make you reconsider what you knew before. And I think
what might be more in the veins of this are code golfing like things can also do that, or the
obfuscated C competition can also do this all within traditional languages. So a challenge I love
to give to people. And if you, listener, want to take up this challenge, I really highly
recommend it because it's fun, is
to do Fibonacci
but with no bullions
or pattern matching or anything that's basically
just a disguised bullion.
Numbers are disguised bullions.
Not Fibonacci. I meant, sorry.
I said Fibonacci. I meant to say FisBuzz,
with no bullion's. Fisbuzz
with no bullion things.
You can decide how strict you
want to be about those words.
Strings are disguised bullions.
Yeah. So when I say disguised bullions, I mean,
pattern matching or for example one thing that's like you can do it you can decide whether this
follows the rules is like well i have an operator in my language that's like get something but if
it's falsie give me the default value you can decide whether that's allowed or not in your
implementation but it's a fun way and you'll see every time i've given people this challenge and
they've actually gone and done it i've never had a single person come back with the same answer
as a previous person came up with.
I have my answer that I think is fun,
but there's lots of ways to do it.
And so, like, yeah, I don't know.
I think this paper says so much that I agree with,
but it says it in such a way that almost, like,
undermines the very thing it's trying to get us at.
Yeah, yeah.
Because it just takes a very dry, boring, summary approach
to such a rich, interesting,
multi-layered topic that it's like somebody trying to give a very boring account of like
what is modern art modern art is done because it's fun and it's done because it might be poking
fun at existing art and it's a reflection on the earlier era of art as if no other era did that
yes exactly that's what this paper feels like to me is it's it's saying things in a way that kind of
when the very subject matter it's talking about. And it doesn't actually decide to take its
subject matter seriously. What I would have loved to see is a deeper analysis of one, like one
S-O-Leng they find to like be the exemplar, the S-O-Leng that really captures the spirit. InterCal
would be a good one simply because it was, you know, the starting point of a lot of these. But you
could pick another one. There's lots of good, interesting ones out there and like analyze what it does
well and why people are attracted to it and then start talking about different dimensions that
we could develop Esolings in, different ways in which we could push out S.O. Lings further.
That's what the practice of S.O.L.ing is about is reflecting on it. I think we'll start seeing a
bunch of S.O.L.ings playing on the idea of AI generated code. You know, that's the cultural
moment we're in now is this AI generated era. The one that I would love to make, that I don't know
how to do, but if someone has ideas
is I hate
and I understand it, you don't have to fight
me on it, I hate when people say
there's no such thing as an interpreted language
that's the most obnoxious
thing you can possibly say in my
personal opinion. Even if you're right,
I don't care, it's obnoxious. And so
I want to make something that is a
language that can only be interpreted. And guess
what? It could be as easy as say, this
language must be interpreted. Because the same
people who say, there's no such thing as interpret
languages also say languages are defined
in terms of their spec and my spec says
this language must be interpreted
but I think it could be so much more than that
I also think like playing with a socially
defined language a language that
only takes its definition from
the uses and practices that people
make of it that there is
no canonical definition just like natural
language would be a fun esoteric language
yeah like spell
what is this
it's a new uh esoteric language
okay but it's not it's not finished yet
but um
That you happen to be making, Lou?
I'm not making it.
Oh, okay.
Is it Googlable?
Yeah, you said it as though we should perhaps have heard of it,
and then are like, well, I'm not going to tell you what it is.
No, no, no, no.
Which is cheeky.
Spill language.
I wonder if what comes up.
This is live Googling, everyone.
And you can tell.
No, it doesn't come up yet.
Well, you're searching for that.
Oh, wait, did I lose?
Did you lose?
Oh, shit.
I unplugged my own headphone cable because I'm fidgeting.
Oh, come on, man.
And then I'm like, wait a second, why can't I hear you or myself anymore?
Apologies.
I see what you mean, Jimmy, that this paper doesn't really push?
you know, like, I don't know, like doesn't really go far enough, you know, in analyzing
what makes an ESO-Lang worth it. And I think, yeah, one really in-depth example would have been
lovely. The different reasons for developing a new programming language are quite surface level.
They cover some of the different reasons. One of them is expressivity, and it's not the kind of
expressivity that I would be interested in, which is like personal expression. This is talking about
exploring how to make a language that's more expressive. That makes me want somebody to make a programming
language, maybe an isa-lang, that is designed for the other kind of expressivity explicitly. This is a
language that is designed to help you express personal, deeply held, meaningful things. Like I roost.
Yeah, okay. That's actually a really good example. Yes, a roost. Or maybe, maybe arguably in Form 7 or puzzle script. Artistic expression, creative expression as an artist is one thing that I think a lot of programming languages exist for. But what about a programming language that is explicitly designed to help you through a difficult relationship? That's designed to help you deal with a breakup.
or a divorce. Wow. Like, for instance, I had a friend who made a programming game or something like,
it was some kind of, it was a game, but it was also a programming language or something like that.
And he gave it to one of his classmates, and the classmate really liked it and went through it and did it.
And at the end, it was a like, hey, do you want to go out? It was like a, like a, hey, I like you,
and want to go out with you in the form of a game
because he knew that this classmate would really dig that
and then they started going out.
So that like programming system as a form of professing one's love
or that's like there's, yeah, like really pulling on that kind of expressivity
I think would lead to a bunch of beautiful, beautiful ESOLANGs.
You know what a good reference for that is?
SFPC School for Poetic Computation Love Languages course.
they cover like how you know computer use can be a love language i think another good example of that
is coming out simulator by niki case and in fact a lot of niki cases games and explorables
are ways of communicating something whether that's like a personal feeling or like a phenomenon
you know it's trying to communicate it in a way that perhaps only a game or an interactive thing could do
My personal favorite, while we're on the subject, is dysphoria by ananthropy, just tremendously affecting and is a wonderful use of the interactive medium as a way of making a, conveying what it feels like to be a person to another person in a really succinct way.
So the paper says that actually most ESOLangs are only for exploration, not.
not economy, education, efficiency, expressivity in the programming sense, not the personal sense.
Which is interesting.
And so I'm trying to piece together, like, how does that fit in with the points it mentioned
earlier?
Like, because it covers that you might do it for comedy, challenge, creativity.
I'm like reading this, trying to piece it all together.
Like, are these the same as exploration?
That seems quite different to exploration, if you ask me.
Just a point of clarification, it's saying here is why the ESOLANGs that we've looked at tend to be created.
It's very much like doing documentary work.
It's saying this is patterns that we've seen among the existing body of languages, which I read that as challenge accepted.
Here's a big empty space where ESOLANGs aren't currently being created.
Like there aren't ESOLANGs that are being created to attack and dethrone capitalism.
So somebody should go and do that.
Except for Dreambird.
Dreambird's doing that.
Yeah, yeah, yeah.
I can just erase this paper and write Dreambird over top of every page.
So, but that is true.
Like it says, the most commonly asserted reason for developing an Esolang involves humor.
I read it wrong.
But yeah, that's about right.
Do you want me to get a clean take?
of this entire episode, please, yes.
There's a thing that you said a little while ago
about this paper
kind of like failing
to make its point that we should take Esolang seriously
so hard that it actually ends up making the opposite point
and I have a passage that I want to read that to me does that
where it's like they did not live up to the task
that they set for themselves and so this section here
It's under Section 4 pedagogic value, and it's talking about one of the reasons that Esau Langs are good is that they're a way for people to kind of explore as part of their own learning process.
And they cite Pappert's notion of hard fun.
We learn when we're having fun, and there's no need to be embarrassed about this.
There are many other beneficial learning outcomes when a novice programming student is exposed to Isa Langs.
One obvious learning outcome is the reinforcement of Dykstra's dictum that GoTo2 is considered.
harmful.
Dykstra.
For instance, some Isolang's only have a go-to style construct, such as Shakespeare's.
Let us proceed to scene N.
Shakespeare code is sadly often spaghetti code.
Ha, ha, ha, ha.
Very funny.
You put a joke in the paper.
But the following paragraphs are awful.
So, they are.
Another positive learning outcome is the realization that syntax is merely the surface form
of a program and can easily be altered.
so far, so good.
The bizarre or unexpected nature of much ESOLANG syntax foregrounds the fact that the surface
look and feel of code is flexible.
Learners begin to understand that what really matters is the underlying structure and semantic
content behind the syntax.
This liberates novice programmers from being overly attached to any one language, instead
promoting a more conceptual language agnostic approach to software development.
this sucks shit. I think this is awful. I think that this is parroting the dogma that yeah
syntax doesn't matter you know you should you should learn a bunch of different languages
because that'll broaden your horizons and beware the man of one book is a quote that often
gets bandied about. This is I think the exact opposite of the direction that this paper should lean
because the fact that people mostly play with the syntax the take there has to be
that it shows how powerful and important syntax really is as part of programming.
That, like, syntax, the part that you smush the crevices of your face and body onto when you are programming,
it's the texture, it's the shoreline, it's the spiral staircase.
There's so much to syntax, there's so much beauty and import to it,
And Isolang's heighten our realization and appreciation of that.
And what they don't do, what they certainly don't do and ought not to do,
and what we ought not to take from them is that syntax actually doesn't matter
and that we should learn to be syntax agnostic and just deeply care about semantics,
because that is a very professional suit and tie get the job done way to relate to programming.
And ESOLANGs, to the extent that this paper appreciates them, stand in stark contrast to that and reflect on that and push back against that.
And we harken to this earlier time in our lives when that's what programming was about.
And this passage is suggesting that the lesson of ESOLANGs is to not do that.
I think this is actively wrong and bad, this passage.
Learners begin to understand that what really matters is the underlying structure and semantic content behind the syntax.
Like that to me is unforgivable.
That to me is the like smoking gun of them not quite deeply enough buying into what it is that makes Isolang's great.
I find the ending to also be a little bit of a strange ending and it kind of...
The AI ending.
Well, there's the AI and I will just say, I hope that they wrote this for the preprint and then know that they're going to remove it.
later. That's my hope here on the AI thing. It says, no research work is complete nowadays without
considerations of implications of AI on the topic. I hope that's sarcastic. I mean, it's almost
esoteric. Yeah, it is. I mean, it is almost esoteric, right? Like, are we just being pranked? Yeah,
I think that is their attempt at a joke. What if this is all a big joke and we're just being
punked right now, you know? No. I would love nothing more. So it says, as we have looked
at S.O. Lang's, we have endeavored to learn something about the essence of programming,
but in fact, we appear to have uncovered something about the essence of programmers.
Dot, dot, dot.
Precisely what? That they are a strange bunch?
It appears that S.O.L.L. Users and developers derive perverse pleasure from the constraints
and complexities of S.O.L.angs engaging in the techno-masochism identified in another paper.
We didn't talk about that.
That's why I'm G.
But perhaps the observation
does not apply to all S-O-Lang programmers,
but certainly it covers a significant fraction.
Citation needed.
I just,
I don't think that,
I don't think that that's what is going on here.
And especially for that to be like the whole conclusion
of the whole thing.
I don't know that that's what we're doing
when we're challenging ourselves
to write a BF program from scratch, right?
or to make BF there's the key difference yeah uh they say S-O-Lang programmers so I don't know in that
sense if they mean the people who are programming in an S-O-Lang or create because you would think it
would be creators because they talk about they do draw all that distinction earlier but I don't
remember which terms they use for what anyways I don't think that that's what's going on I don't
like I do think that there is I find you know I've said before I find difficult programming challenges
It's very fun.
I do find programming fun because it's hard.
And I have found that when something can be done by an AI system, which is not always, I find doing that task less enjoyable now because I'm like, well, it could be automated for me.
Why am I doing it manually?
I do think that there's some relation with all of these things.
But I think what is going on with these difficult programs?
is not some sort of techno-masochism.
I think that there's an aesthetic appreciation going on
when you realize the clever tricks,
the interesting details that come out,
that emerge out of these simple languages.
That's what's so interesting about them
is that they,
even though they seem so inelegant on the surface,
when you actually start looking at them
and you start writing them yourself
and you start understanding them,
you see this like,
oh, that's so simple and clever and beautiful,
even though the surface syntax might feel so cumbersome,
even though it might be hard.
It's about taking the time to aesthetically appreciate them.
I find the same thing for like esoteric music where, you know,
it might be like a, and Ivan's giving me a weird look here,
but the kind of music that Ivan listens to,
where it might be like atonal,
it might be like the average person might listen to it and say,
that's just noise.
But if you actually take the time to listen to it and like figure,
it out. Ivan is physically
in pain right now. There's something
very pleasing about it.
Is there?
Yes. I will point to Ivan's
own work here.
Ivan's own music for this.
No, I believe you said the music I
listened to, which is a distinction
from the music that I make. There's a difference
between programming in brainfuck and making
brainfuck. But now I will point to Ivan's own work
because I really enjoy it, which is
diminished fifth.
Oh, that. That's not music.
But I really enjoy it, and I think it's really good.
And it is something where if I just let somebody else hear it, that is, like, I think
most people would go, that's just obnoxious noise.
I'm going to be honest.
I think the average person would find it.
And, like, if you actually take the time to listen and think through, you know, hear it, like, there's something very aesthetically pleasing about it.
And I think a lot of music that is more challenging to people is that way.
Yeah, it's no Mersbow, but it's, you know.
I don't know who that is.
Some of the listeners will know.
I have two things that I do think would be interesting to talk about still in relation to this paper.
and then just won this in general.
I feel like this paper doesn't give us enough
to distinguish between Esolangs and something like a Zachtronics game.
Mm-hmm.
So, Zactronics games, the one that I've played most,
I always end up forgetting,
because it's always on the tip of my tongue
right before I say...
Exapunks.
Exapunks.
Yeah.
Where there is this very constrained little assembly language,
and part of the joy of programming in it
is the difficulty to, like,
get it to be super efficient.
So, like, it is, there's something really interesting, and it's, you could say, oh, it's not
esoteric at all because it is just assembly, but that is slightly different from any existing
assembly language.
It has its own quirks, its own things.
I don't feel like anything here has really told us, like, how does an ESO-Leng differ
from a language created in a video game to have that same kind of difficulty?
Ooh, wait, what's a video game where we can say there's a con Leng without spoilers?
Chance of Cynar.
There we go.
Tunic is another famous example.
There's an indecipherable made-up language in the instruction manual in that game.
Minecraft, Redstone, is an ESO-Lang.
But also, enchantments are also a con-lang.
Right.
Oh, I didn't know about that.
Yeah, in the book, they have the little script, and you actually can interpret it.
But, yeah, I think that there's, and, you know, you could do, like, Baba is you, right?
Like, I don't think you would really say Baba is you as an S-O-Lang, even though it could fall into the Turing tar pit, blah, blah, blah, blah.
I think this would benefit, this paper would benefit from a discussion of, you know, constructed languages that are not made for practical purposes, but are not S-O-Lang's.
And I think game languages are exactly that.
Well, I mean, this is one of the things that I wanted to talk about.
I like the paper, because it's like a good signpost to various things.
However, I think it does not signpost to all of Esolangopia, you know, the world of Esolang's.
I think it takes a very limited view of what they are and what they can be, leaning into the most pop culture ones.
I think it really misses out on lots of things that would be considered Esolangs that are closer to the fence.
and I think those are some of the most interesting ones.
Got some examples?
Struidle, like Tidal Cycles.
Tidal Cycles is a Haskell-like language for creating music live and in the moment.
And I would say that it is an ESO-Lang.
I think many people, perhaps even the creators, might say no, I don't know.
but I think it pushes the boundaries of what a language can be.
It pushes the boundaries of the relationship we can have with the language
and the relationship we have to written code.
And Strudel is a JavaScript-like language based on title cycles.
Another one is, you know, basically all of the languages I make,
I would say, are esoteric languages.
They're supposed to try to push and challenge
what a programming language can do and be.
It's funny, it's almost like their esotericness is almost like incidental.
I'm usually exploring something specific, like with A Roost.
I was trying to explore how to make a tool that encourages people to be more creatively free,
and it just so happened that I made a visual programming language as part of that.
You know, it didn't start with esoteric programming language.
It started with a specific need
and the need bubbled up
into a very esoteric programming language, right?
So I think this paper misses some of those
different views or entrances into esoterica.
There's two other things that I can't help but think
when I'm talking about this.
One of them is that code that's written
with esoteric languages
is often not meant to be run,
is meant to be read by a human,
you're supposed to read the code.
And the code itself is like this artifact to share
and a shared language between humans.
Even looking back to things like the game of life,
which was not an esoteric language,
but it's like a thought experiment.
What if this existed as a computation?
And I think that's the same sort of mentality
that appears with a lot of ESO langs.
They didn't even run it.
They just imagined running it and wrote down on bits of paper how it could be run.
I think it's better than that even.
Yeah?
Oftentimes people don't even write code in these languages.
They just talk about what it might be like to write code in that language.
Yeah.
Yeah.
And this makes me really think even more of languages like tidal cycles where a big part of that is sharing the code itself.
I'd say it's almost frowned upon to not do that.
I think there's something about that, about the code itself is part of this genre and medium of esoteric languages.
The other thing is, and I think this is really important, which is why I was saving it,
is that Ivan, me and you, we ran a session at Strange Loop like, what, two years ago now, called Institute of Weird coding.
And what we did was we got everyone in the room to try and order every single programming thing from least weird to most weird.
And so on one end, we had all the esolangs.
And on the other end, we had all the non-esolangs.
And in the middle, you know, it sort of got a bit blendy.
And one of the things that came up from all those discussions was a lot of this is like a culturally relative thing, right?
something might seem weird to you, it may seem esoteric to you, but to other people it may be
not. So when I say something like tidal cycle seems very esoteric to me, you know, someone who's much
more familiar with it might disagree. And, you know, I think there's definitely scope for something
to be created and start as just, well, this is just an esoteric idea. I was just trying to push
and explore things and demonstrate that something could be done.
But there's scope for that to change over time.
And I think that's something that esoteric languages do
is that they challenge our expectations
and our limited viewpoint of the world.
We can do something that's different.
We can do something that's, you know, like heady, right?
To some people that seems like a very esoteric idea.
What if we had a programming language
that is designed to be trans, well, to work,
with other languages, right?
That seems like an esoteric idea to some people,
but to some people that just seems like common sense.
And, you know, there's this question of how do we take things
from these esoteric languages and make them normal?
For me, like, to take an esoteric language seriously
is almost to make it stop being an esoteric language.
And maybe that, maybe we should do that.
But that's a very different way of thinking about it.
All right.
I'm done.
That's it, said it all.
Any comments?
Yeah, okay.
Jimmy's laughing, so I'll jump in.
Two thoughts.
One of them, there's a Jonathan Richmond song that I want to plug.
I don't know the name of the song, but the relevant lyric is,
let's all drink the wine and not talk about it.
Wow.
Wow.
It's good to drink the wine and not talk about it.
Let's taste the wine, but not talk about it.
wine to taste and not to talk about gave us the wine to taste and not to criticize
so we taste it we don't criticize it and wasting it gave us the wine to taste it so take it
But don't let's talk about it in.
Cry it rock, cry it raw.
But stop if you want to stop.
And don't criticize and wasted.
Gave us the wine you tasted.
The other thought that I had is sort of like the intentionality of it, right?
Like, are you creating the ESOLANG?
in the case of Hetty, it's like really
if Hetty is making
a statement, if it's fair for me to say
what the statement that Hetty's making is, it's like
come the fuck on,
why aren't all of our
programming languages doing this?
Like, why can't we have programming languages
that actually do take syntax seriously
and realize that syntax is really
fucking important?
And that the English
hegemonic nature of
programming is
bad and dumb and
not even essential
and that this view that like
oh syntax is not important
so by you know
we shouldn't care about syntax let's just make it
all based on English because
you know of course but let's not care
beyond that like that's a really
harmful bad dumb outdated
idea and there's no reason
why that should continue to be
the norm
right we had tools like isomorph where it's like
you can pick your syntax but the underlying
representation is going to be the same
and at any point you can switch to the other syntax
and use the same programming tools
to write the same program,
but the surface syntax is just like a,
you can just flip between a bunch of different choices
and it will like re-render your text in different ones.
It's not like a racket style,
like who I can nest one language inside another.
It's like a literally look at the same source code
in any of these different syntaxes.
Like if we have that,
we should be doing that with all of our languages
and with human language.
Anytime you're saying, you know, if, then, with, while, do, you know, all of that, that should be easily, trivially translatable.
Const.
Yeah, const.
Yeah, const.
Func, fun, fun, function.
Funion.
You know, and I see, I've seen some of the impacts, like the positive impacts of Hedy, right?
So there's like a current initiative going on within the strudal language to add support for,
localizations, which is, you know, involves kind of some brunt work, but also some
problems to solve and Hedy has been used as a reference, partly as inspiration and
encouragement for that, but also some practical ways of doing it well. I think some people
would hear about Hedy, look at Hedy, and think that it's an esoteric language because it seems
like an unusual idea to them, but maybe it shouldn't be considered as an esoteric language.
However, I think what Ivan is saying, and Ivan can confirm or deny this, is that whether
we consider an esoteric language or not, its very existence is trying to communicate the idea
that it's ridiculous that we're not doing this already. And so I could see some shared lifeblood
with esoteric languages. Yes, and.
It's also doing something that, like, closure and Haskell and a bunch of, and Scala.
Sorry.
Why are you laughing at Scala?
Because it's a funny language.
Because Scala is a very funny language.
Scala is a great joke as programming language.
And however many millions of dollars were spent on Scala as a thing that exists, it's really great long-running gag.
Like those functional languages, a lot of people pointed at those.
said, persistent data structures, death to mutability, provable properties, there's a bunch of
qualities that functional languages have that were championed as things that other languages
should learn from an adopt, and that programmers generally would benefit from understanding,
and that even if you're writing JavaScript, if you spend a bit of time playing around in a
functional language, you'll learn things, you know, the Perlis quote, Perliss said, and I quote,
So it's super great, dude, to program something, because then when you go and program something else, you'll be good at it.
It's good to fold those ideas into languages where they weren't created with that vision in place.
It's good to program Python having done some functional programming because that makes you a better Python programmer.
And eventually what you see, and you see this in JavaScript, you see this in C++ a lot recently, and like the existence of Rust and Swift as they exist is,
Let's build new generations of programming languages learning the lessons from those functional languages.
We just went through a big wave of that.
And so those functional languages are seen by people as like charging out ahead and saying, here's where programming should go.
And here's things that are long known in some intellectual sense but aren't deeply appreciated and reflected in the design of languages and tools and the way that programming practiced.
And I think Hedy really ought to be taken seriously is doing that same exact.
thing, that it is charging out ahead and saying, here is a thing that we all kind of intellectually
understand, but we aren't taking seriously, and it's not, like, deeply reflected in the way
that we're designing the next generation of programming tools, and also changing the way
that we do programming as a practice in order to incorporate that understanding, that human beings
come from a plurality and diversity of backgrounds, and that is directly affected and mediated
and influenced and limited and in all ways interacts with the syntax of programming languages
and that programming languages need to catch up to that realization.
So like maybe it's an ESO-Lang, maybe not, but what it's doing is the same as what Closure
and Haskell and Skelov did.
Just to clarify what the paper says, it puts Hetty in this section that specifically is contrasting
what ESO-Langs, ESO-Langs do.
So it's a language specifically designed to help novices, and this paper thinks that
ESO-Langs have to be in contrast to that.
Yeah.
Or can be.
Yeah, can be.
But it says this.
In terms of education, ESO-Langs are explicitly not designed for novice programmers.
So the language that the paper actually uses is definitive.
It doesn't say it can maybe sometimes not be, but Ivan likes to translate all definitive
language and to be more charitable of they didn't mean it literally well they they
wouldn't have except in this case they failed to take iso lang seriously and so they do use
definitive language where they shouldn't have yeah didn't understand the assignment i would
definitely not consider hetty and s o lang at all i think it's aiming to be a very practical
implemented language that people can program in to learn programming like it wasn't meant as making
a statement that kind of way
Or it wasn't meant at being obscure, at making a statement through its intentional...
Yeah, through an esoteric means, right?
Yeah. Yeah. Right. So, yeah. It can be making a statement, but it's not trying to be esoteric at all. Yes, it's trying to be very...
Trying to do the opposite. Non-esoteric. That was my only point of clarification. It's just that kind of thing. I said we should talk about, in general, ideas for ESO-Langs. So maybe that's how we end.
Yeah, I do... I did want to do that. That's good.
shit. We should spend a couple minutes
talking about like what kind of Esolangs would we
want? Can I, can I
actually, I, you have the ceiling.
I just know, they're, they're all made already.
There's no need
to make anymore. We just need to
put them together. Right. Do you know there's even
in Esolang that you
program by playing the tuba?
Mm-hmm.
So Timken, Daniel Timken, just published a paper called the Olympus programming language.
What is that?
That's an S-O-Lang where you ask the gods to write code for you?
You have to make them look like prayers to Greek gods.
You can't write the programs yourself.
You just have to ask the gods.
Great and good Athena, perjure of evils, who hears all words spoken in market and assembly.
Please make a function called print bot for parameters in that prints in, beer string, and on the wall.
And it really seems to be, you know, I just mentioned that we're in the AI generation thing.
This seems to be a comment on, you know, the AI gets to write your code for you,
but instead it's these various gods, and different gods can do different things,
and they can ignore your requests if you don't say them quite correctly,
or you say them to the wrong God.
If you're too obsequious and subservient, the program will crash
because you didn't say, please, the right now.
number of times instead of too many times.
Yes, that kind of thing.
I think it could be very fun to make some ESO loans
actually using LLMs as part of the implementation.
The LLM is not the one that's coming up with the idea,
and it's not the one necessarily that's doing the execution,
but the way that the LLM reacts to the ESO lens,
to the ESO-Lang makes the element the butt of the joke.
It's the mark.
If you look around the table and you can't tell if you're the L-O-M,
I regret to inform you.
Oh, shit.
I think like this, like entropy kind of...
...corrupts the data.
corrupts the data over time, letting that LLM continue to corrupt your code
and the context rot that happens from these things, et cetera, right?
I think this could be an interesting thing to play off of and make an S-O-LAN and see what.
I was just joking. I have non-stop ideas for Isou Langs.
I would love to see a language that really leans into tolerance for your own errors.
could call it like
fuzzy script or something
or like
fuzz fuck
you know like
it basically takes
whatever bullshit pseudocode you write
and it tries its best
to run it as you intend
but it doesn't use LLMs
it's like the fuzziest
parser in the world
you know
like you miss off two brackets
or you do a typo in your variable
and it's like
oh that's come on
you wrote print it
you're definitely meant to write print
print it
like come on
for fuck sake.
It's like, print, print it?
Did you mean print?
I'm like, if you could figure out what I meant.
Yeah.
Why didn't you?
Why the fuck are you telling me about it?
Yeah.
You know?
Why are you still sitting here?
Am I, E, C-L-I?
Yaping on.
Do you know the...
That would be good.
Fuzzy script.
What is it, like, Postal's principle?
P-O-S-D-E-L?
No.
Postal's law?
It's the...
Post-law?
Post tools law
No, not post law
Also known as the robustness principle
It's like be tolerant
and accommodating in what you accept
And strict in what you put back out
And that's this principle that some
Systems, for example HTML
was really designed in terms of this
That you can write malformed HTML
And instead of
You know, X-Html
style saying
You missed a quote around
this attribute. We're going to refuse to render
anything on the page it will instead go to great lengths to be accommodating of of you know
quote unquote erroneous input yeah um which is a wonderful wonderful space to play in so i love this
idea of like how maximalist can you get about that there is a language called fat finger fat finger
and it lets you write uh javascript but if you are wrong on
some identifier, it will just find
the closest one. Oh, that's good. That's
great. That would be fine.
So you can write like conable.
dot log and that will work perfectly
fine. Oh, it's by Roddytooth.
That's cool.
Roddy tooth also made
one that I wanted to cite, which is
Rivulet. It's
an Esolang made out of
these diagrams that look sort of
like strings, not like strings
of characters, but like a thread
or like a cord, something like that.
in different colors that are laid out in these really beautiful patterns.
There's no text, though I think it's made out of like Aski characters,
or sorry, Unicode characters, but it's, it doesn't have to be.
You could draw it in some kind of a vector tool or something,
but it's this beautiful little, almost like not-work diagrams as programs.
But yeah, Roddy Tooth has made so many interesting visual language.
Which is Timken, by the way, in case...
Fuck!
We were in his bedroom the whole time.
Ha ha ha ha ha.
