Transcript
Transcript prepared by
Igor Kim and Bob Therriault
00:00:00 [Conor Hoekstra]
And then I looked at the time and saw holy smokes, we've once again.
00:00:03 [Marshall Lochbaum]
There's no hour mark in the rabbit hole.
00:00:07 [CH]
Oh, there we go. There we go. A classic, a classic podcast gold from Marshall Lochbaum. There's no hour mark in the rabbit hole.
00:00:12 [Music]
00:00:26 [CH]
Welcome to episode 83 of ArrayCast. I'm your host, Conor. And today with us, we have three panelists and a guest who we will get to introducing in a couple moments. But first, we're going to go around and do brief introductions. We'll start with Bob, then go to Adám, and then finish with Marshall.
00:00:41 [Bob Therriault]
I'm Bob Therriault, and I am a J enthusiast. And I forgot to introduce myself on the last show, even though I was hosting. So now I'm making up for it. I'm introducing myself again. I'm Bob Therriault, J enthusiast.
00:00:52 [Adám Brudzewsky]
I'm Adám Brudzewsky. I am a full-time APL programmer.
00:00:56 [ML]
I'm Marshall Lockbaum. I've worked with J and APL in the past. I created BQN, and I'm a Singeli enthusiast.
00:01:03 [CH]
And as mentioned before, my name is Conor, array language enthusiast, love all the array languages, and host of today's episode. I will say I listened to the last episode. It was fantastic. It's always a treat getting to listen to an ArrayCast episode that you haven't already been a part of. And we're going to actually depart from what we usually do and briefly introduce our guest for today. His name is Jay Bates, and he is the creator of the Jam programming language, [01] which is a fork of the Jelly programming language, which is what is going to be the primary topic of today. But the reason we are introducing him up front is that we have incredibly sad news to announce. And I think we're going to throw it to Marshall first, and then we're going to have some thoughts to share on the incredibly sad news.
00:01:53 [ML]
Today we're talking about a true Array language enthusiast. This is Raghu Ranganathan, who is probably better known by the handle "razetime" that he used everywhere. And just a few days ago, Raghu's father got in contact with some people in the Array community to tell us that, in fact, he'd gotten caught in a riptide in the ocean and had drowned at the age of 22. So I mean, we're all, of course, very sad to hear this. Raghu touched everyone in the community. I can say for my own part that I got to know him when he was working with BQN. He contributed all sorts of support for the language. He did what's on the website now, the help pages. You can see if you click on a primitive and ask for help. He wrote all those pages. He did VS Code support for BQN. So he's done a lot for me. And what I can also say is that this is not really my story. This is everyone's story in the Array community, because Raghu just did so much for all of us. If there was a new language, he was immediately interested in trying it out and seeing what it was about. He was interested in helping other people to try it out. So he was a huge figure in the community, and we're really going to feel his loss.
00:03:10 [AB]
Yeah, it's definitely a loss for me too. I teach a lot of people APL and I taught razetime or Raghu APL as well back in 2020. He just stopped by in the APL chatroom on StackExchange and I asked him, as I usually do with people who drop in if they're interested in APL and ended up teaching him APL, which probably was his first array language and from there he became an integral part of the array community and made several tools to facilitate using APL and many other array languages and even did a paid project for Dyalog and so he's not just an array programmer enthusiast but actually did real work as well.
00:04:25 [JB]
Like Adám, I first met RazeTime through Stack Exchange. Unfortunately, I only knew him through Stack Exchange, but he helped me write the wiki for one of my languages that I've created. He contributed to a language that's close to my heart, and the docs for that. He was always a lovely person to just hang out with in the 19th byte, if you're familiar with that. And was just a pleasure to spend time with, even if it was remote and through an avatar, rather than in any in-person way
00:04:50 [BT]
And my interaction with Raghu, I had a chance to chat with him a number of times on zoom, but because we were doing the J wiki at the same time, he was coming on. The thing is, when he came on, we realised because I'm on the other side of the planet.
00:05:05 [BT]
And my interaction with Raghu, I had a chance to chat with him a number of times on Zoom. But because we were doing the J-Wiki at the same time, he was coming on. The thing is, when he came on, we realized, because I'm on the other side of the planet from him, he was getting up at four in the morning to attend our meetings, which is, I mean, it just shows you what he was doing. And I think, I mean, beyond the sense of loss that his family must be feeling, and I can only imagine, it's the sense of what maybe could have been. He was only 22. A lot of times we're talking about people who are in their 60s or 70s or 80s that are passing away, have been able to, over their lives, make a huge contribution. But in the case of Raghu, it's kind of, aside from the loss that we all feel for what a wonderful person he was, because I want to emphasize that, is what he was going to be doing. He had so much potential, and unfortunately we're not going to be able to be the beneficiaries of that potential.
00:05:56 [ML]
I do think since we have no representative of the k community here, I should highlight that the k wiki is such a great resource for k programmers. And he's also done an introduction to working with ngn/k, which the creator isn't specialized so much in documentation, which I sympathize with, because the reason he wrote my help pages is that I didn't feel that that was something I could do very well. So k was really a big thing for him lately. And I think he's helped a lot of people-- helped make that more accessible to people who want to try it out.
00:06:33 [AB]
It's not just k.
00:06:34 [ML]
Oh, and yeah, this is by no means an exhaustive list. We've listed all the major programming languages because the minor ones would fill an episode.
00:06:43 [AB]
There will be another fairly prominent one is Niall, which I think he also contributed to the documentation of its website.
00:06:51 [CH]
It's it's just incredibly sad and....Yeah.
00:06:58 [BT]
I think the thing that I often take away from this is we're not here for a long time. So appreciate the people you're around, because it can happen very quickly. And our thoughts are certainly with his family, because they'll be impacted by this for a long, long time.
00:07:16 [AB]
We should express our appreciation for his father reaching out and telling us about this. I couldn't... Immediately after it happens, it requires something to be able to go and say... So he... his father must have opened up his email and looked at what were the latest communications he had and then determined those would be the ones to reach out to, to say... to tell these news. So several of us received emails separately and in threads that have been recently there.
00:07:51 [CH]
Yeah, I hope that if... I'm sure we will try and send this episode to his family and they listen to this. I hope it's clear how profound an impact that Raghu has had on the Array Language community. I mean, just... I'm a bit in shock because I found this out less than like 30 minutes before recording this. And over the last couple months, I think I've mentioned on this podcast that I've been going through some of the code.golf problems and RazeTime, the handle that Raghu went by, is on so many of the problems that I'm solving. And k is one of the languages, specifically ngn/k, that that website uses. And I've been referencing that ngn/k tutorial like, you know, every single time I was working on it. And I think there are a few names and aliases that if you start falling in love with the Array Languages, you almost immediately stumble upon, like since I discovered the Array Languages in late 2019. And whether it's during Advent of Code, when you start trying to learn a new Array Language, or you're just, you know, trying to build some small thing, you always run into these handles. And at such a young age, for someone that clearly has so much passion, yeah, I just hope his family knows that this community is thinking about them. And he had a profound positive impact on the communities that he participated in, even for the folks that, you know, never met him in person. Yeah. I'm not sure if there's anything else we want to say before we try to transition to...
00:09:40 [BT]
Well, I think he would probably be upset that we would spend this much time on an episode talking about him, because I think he would want us talking about the Array languages. But yeah, it certainly changed the way my weekend flowed.
00:09:56 [CH]
Yeah. Yeah, I guess, finally, we'll just say, yeah, friends, family, anyone that's listening to this, know we're thinking about you. And I think this is all a pretty big shock and very sad news. But yeah, with that, I think we will try to transition to fully introducing today's guest after that sad news. And as mentioned before, today's guest is Jay Bates, who I primarily know as the creator of a programming language called Jam, which is a fork of the programming language Jelly, which is a language that I have fallen in love with over the last... I can't remember, actually, the first time I really started diving into it. It came from a comment from Adám saying that like, "Oh, you know, you love tacit programming, [02] you really need to look at Jelly." And Jelly is an incredibly confusing language with minimal docs. And so I ended up building a tool called Jello to kind of decipher it. And we've been trying to look for someone to talk about the Jelly programming language because we haven't really dived into it in detail in this podcast. And Jay's name came up because you've done a lot of work with Jelly and have actually forked that and created this language called Jam, which we'll definitely throw in the show notes. It's a great wiki which enumerates all the differences, which I think we'll talk a little bit about today. But on top of that, you're also one of the moderators for the CodeGolf Stack Exchange. And you go by... So some folks may be like, "Oh, I don't know who this Jay individual is." But you might know him by his alias, and hopefully I'm going to pronounce this correctly. His alias is caird coinheringaahin g, which maybe is a great place to start. Do you want to, you know, I guess briefly introduce yourself? Or if you want, you can go back to, you know, when you started getting into programming and then take us to the alias. Or you can even start off with explaining the alias and we'll go from there.
00:12:13 [JB]
The alias is originated in Jelly, so it might be better for me to start with how I got into Jelly and then go from there. Because I was introduced to CodeGolf at that time, it was only the Stack Exchange site. There weren't really any bigger other sites to do CodeGolf on. By a friend in first year of my secondary school education, when I was still learning beginner Python, and I wasn't very good at CodeGolf at the time, because of course I wasn't very good at programming at the time. And after about a year or so, just sort of puttering about the site, getting better at programming in general and CodeGolf specifically, I noticed that another user was teaching Jelly. To another one of the current moderators on the site called Hyper Neutrino. It looked like a cool language. I was like, "Oh, if you're teaching Hyper, could you teach me as well?" So there is a, I believe it's now, oh, long frozen, potentially deleted chat room on the Stack Exchange site, where you can go back for years seeing my progress learning Jelly, learning how to golf in it, and how to actually use the language. And I think that must have been nigh on eight years now. It became the language that I use on CodeGolf. I believe I'm nearing on a thousand answers on CodeGolf, and at least 80% of them have to be in Jelly. And fortunately, my username doesn't come from any one of my answers. Instead, it comes from an answer by the creator of the language, Dennis, who wrote a brilliant Jelly program that uses its built-in string compression to complete the specific task. The task was write a program that outputs programming puzzles, and then when you remove all white space, it outputs CodeGolf. The specific Jelly answer used the string decompression to create two strings, and then took the maximum lexicographically of those two. With white space, the two strings were programming puzzles and cared co-inheriting our thing, and without it was CodeGolf and another string that I can't remember. And I figured it's an answer written in Jelly, it's referencing the site that I primarily use Jelly on, and I don't have a good distinctive username. That's a pretty distinctive username, so I'll take that. And that must have been six or seven years ago, and I've been cared co-inheriting our thing ever since then.
00:15:21 [AB]
We should mention for the listener that if they can't find a CodeGolf site that's called Programming Puzzles and CodeGolf, that's because the site changed name since then. But at the time that was the site name.
00:15:36 [JB]
Yes. In fact, I've just gone back to that answer and in the comments underneath it, there is a comment from RazeTime saying where it all started, clearly made after I became a name on this site. I honestly forgot that that was RazeTime who, I don't know, brought attention back to that.
00:16:03 [AB]
He's still with us.
00:16:04 [JB]
So that's serendipitous, I suppose. Yeah, I forgot about that. There's also a full write-up of what I said and the explanation behind the answer, behind the username on the CodeGolf Stack Exchange, as well as explanations for a couple of other usernames that I had, which are based on that as well. Because, I don't know, it's stuck like that. And it's, yeah, it's distinctive and I like it.
00:16:40 [CH]
So just to clarify, and we will include show notes in the show notes, links to a couple of these different CodeGolf sites, or not CodeGolf sites, specifically these problems. But one of them is the "From Programming Puzzles to CodeGolf," which reads what you said basically at the beginning. When you output the execution of your program, you get "Programming Puzzles, the string." So like, double quote, "Programming Space Puzzles," and double quote. But then if you remove all spaces, tabs, and new lines, it then outputs the string "CodeGolf." So that's the problem you're trying to solve. And then there's a couple of Python solutions at the top, that make it pretty clear what it's doing. But what does, can you explain the jelly code again, that somehow "caird coinheringaahing" leads to CodeGolf?
00:17:41 [JB]
Yes, I can. Jelly has a very clever string compression built in that I've actually written up a full dissection of how it works on a different post on CodeGolf. But basically, it has a base 255 represented by each character in its code page, turns that into a number within the string delimiter, and then breaks down that number by repeatedly div modding it. And based on the results of the div mods and, yeah, based on the results of the divisions and the mods, it picks and chooses words from dictionaries that it stores within the language, and then just smashes these words together to come out with the specific thing. So, in this specific answer, it has the string opening delimiter once at the start and once in the middle. This creates two strings as an array so that you don't have to write, you know, two strings and juxtapose them instead. And the first one looks like gibberish, but through this decompression, it comes out as programming puzzles. And the second one also looks like gibberish, but importantly, it has a space second from last character. With that space, that gibberish decompresses to my username. Without that space, it decompresses to CodeGolf. And then there's a little trick at the end to make sure it's choosing which one is the correct one of those two strings.
00:19:21 [ML]
Maybe we want to back up and give some context. If the listeners, perhaps some of them out there are not familiar with CodeGolf, [03] the idea of CodeGolf is just that you have a problem and you want to solve it in the fewest characters possible. So, perhaps now it clicks why Jelly would have this crazy scheme for writing ordinary readable words in less readable but very tiny strings. So, the analogy there is that, you know, in golf, you're trying to get to the hole with the fewest strokes. In CodeGolf, you try to solve the problem with the fewest characters.
00:19:55 [BT]
And if you're the listener, you're Alice and the White Rabbit just went by. You're going into the rabbit hole. [laughter]
00:20:04 [JB]
Yes. And one thing about Jelly for CodeGolf is it's specifically designed to be good at CodeGolf. As good as CodeGolf as possible to be. Which, that whole side of designing CodeGolf in languages is a whole other rabbit hole to go down. But Jelly was one of the revolutionary ones back in 2016 when it first came onto the scene. Because it makes use of a custom code page where it can use all 256 bytes instead of just limiting itself to ASCII. Which is why they look even more like gibberish than standard CodeGolf programs do.
00:20:45 [CH]
Before we dive straight into Jelly and to Jam, is there more you want to say about your back? Because that was an explanation of your username, but if you want to give a little bit more of your background, because it is a, one must take a very, you know, the less traveled path, something like that, Robert Frost. I think that's the, is that the right guy? I'm looking at Bob.
00:21:05 [BT]
I think so. Yeah, I think it's the path less traveled.
00:21:09 [CH]
Yeah. The path less traveled. Array language is fantastic. Yeah, quoting some guy that wrote a poem, not as good. But yes, your path that you traveled was probably one taken by few. So I'm interested to hear how you ended up, you know, falling in love with Jelly ultimately and code golfing.
00:21:26 [JB]
I mean, code golf in general, it just scratches the itch in my brain of, I mean, there's the classic trying to solve a puzzle and trying to solve a programming puzzle is so fulfilling to do when you actually do it. And you know, we all know that from debugging code to finally cracking that solution to anything involving programming, really. For me, the clear objective goal of shortest possible program just made it so much more, oh, I have to try this. Because you know, you think you have the shortest and then you dream up a way to save a single byte. And that is genuinely an example. I have dreamt a way to save a byte in one of my Jelly programs before. And it works and it's completely weird and it twisted around, but you've saved the byte and that's what that you've looked at it from a new perspective and you get to improve it. And yeah, it just scratches all of the brain itches so well for me that I just love it. And for Jelly specifically, I started learning it and it felt even more satisfying to solve these problems with Jelly than with Python. The tacit programming based around it, the array structure that it uses just felt so new to me and I'd never seen them before. This was before I'd heard of APL or really any array languages. And it felt new, it felt innovative, and it just felt...
00:23:07 [CH]
So, Jelly was actually your first exposure to an array language.
00:23:13 [JB]
Yeah.
00:23:13 [CH]
Interesting. I wonder how many folks can say that. I guess probably a few in the, you know, code golf community.
00:23:19 [JB]
Yeah. Jelly is what introduced me to APL.
00:23:23 [ML]
So you come into APL and you say, "What a weird language. It's so verbose yet comprehensible."
00:23:31
Yes.
00:23:32 [JB]
Yeah. Well, I mean, there's the famous thing of people who haven't seen APL before go, "Did you know that you can write 'game of life' in a single line in APL?" And it's this meme and everything. And I've written an Enigma machine in 36 bites of jelly. So it's one of those things where, yeah, APL is just, it's long, it's verbose, it's clunky.
00:23:59 [CH]
We're gonna get this guy a contract, a marketing contract. So what, I guess, you said that Jelly came onto the scene in 2016 and there was a bunch of languages coming on, but Jelly was, I think in your words, you used "revolutionary." What was it about Jelly that made it so revolutionary for code golfing?
00:24:17 [JB]
Up until that point, code golf languages used, almost always used, a stack-based structure. Push onto the stack, pop it off, do an operation, that kind of stuff. And manipulating the stack lost a lot of bytes in sorting out these programs. The big language before Jelly was called C-jam. And when you look at an explanation, there's so many, which is like, "Rotate the top three elements of the stack to get them in the right order for the arguments." And Jelly went, "Nope, we're gonna make it tacit. No stack, just make it tacit. Passing it through." And so saved a good chunk of bytes just on manipulating the arguments around and not having to push and pop in the right order and make it clunky and that kind of stuff. And then just using a lot of tricks that, I mean, we're all familiar with array languages. Things like folding a list by some, I would use the term "dyad," but an operator that takes two arguments. A lot of old languages, the way that they would do that is they would write a function, push it onto the stack, pop the function and fold by that. Whereas Jelly uses a system called Quix, which I think... Adám, what's the APL equivalent of a Jelly Quix? - An operator. [04] - Operator, yeah. Where it's just similar to an array language. You just have the command that you're folding by with the fold operator, quick, insert your name for it here. And it just, yeah.
00:26:03 [AB]
It's not a coincidence, right? It says in Dennis's... Adverb modifier. Yeah, or adverb slash conjunction. It says in Dennis's description of Jelly that it's inspired by J. And you literally use plus slash for summation, just like APL. Or you can sum using plus slash, just like in APL and J, there's a shorter way to do it. Because it's CodeGolf, it's all about getting the shorter ways of doing it.
00:26:28 [JB]
Yeah, so it's inspired by J. It's very similar to that. And we all know how compact and short you can get tacit array-based stuff. And when you apply a CodeGolf mentality to designing a language like that, it makes it a lot harder for stack-based languages to keep up.
00:26:54 [CH]
And so, I guess my next question is, because when I started looking into Jelly, as I mentioned, or at least I'm not sure you can clarify if there's a hidden book on how to program in Jelly. But when I kind of went to the repo, there was some documentation, but it was pretty light. And I was very confused by the tacit model. Because it's inspired by J, but it's also vastly different. A lot due to the fact that you don't have overloaded characters or symbols, right? Most of them are either monads or dyads. And then because of that, you get the interesting tacit model. So for most folks that stumble across Jelly one way or another, was it through the stack exchange that most would learn it? Or how do people become Jelly experts like yourself in the past?
00:27:48 [JB]
As far as I'm aware, I've never seen Jelly in a context outside of CodeGolf. [05] So it would be through a CodeGolf site. StackExchange, at the time, happened to be the biggest one when I joined and started learning Jelly. So that's how I learned it. I think Code.golf allows Jelly.
00:28:07 [CH]
I don't think it does at the moment. Right now, I think J and k are the two array languages that...
00:28:09 [JB]
There's one CodeGolf language with a setlist that has Jelly.
00:28:19 [AB]
The WeakGolf, I think, has... It doesn't leave...
00:28:21 [JB]
It hasn't left yet the CodeGolf space. So it's one of those things where you stumble across it on one of these sites and you go, "What on earth is this very short, incomprehensible squiggle of letters and symbols?" And then hopefully, the person who posted it has posted an answer, an explanation. I always try and include explanations in my Jelly answers, just because when I was learning, I wanted to know how it works. So anyone else who's learning, they should... They'll probably want to know how it works as well. Which is one of the things I do like about the StackExchange system, is that you can add in explanations and breakdowns of your code, which I don't know if a lot of other sites allow.
00:29:06 [ML]
Yeah, well, it's not Even so much scored on the number of characters you have as as the visibility of somebody's answer will be based on people upvoting the answer, which is just personal opinions.
00:29:17 [JB]
Yeah. Well, it's not even so much scored on the number of characters you have as the visibility of somebody's answer. It's based on people upvoting the answer, which is just personal opinions.
00:29:31 [ML]
Yeah. I have lots and lots of words to say about that system, but that's not what we're here to discuss. But I guess adding in an explanation can only help that, yeah. But it does mean that people will more readily see the answers that are clearly explained. So So you have more emphasis on how something's done instead of just, here it is, here's the code.
00:29:43 [AB]
It's a popularity contest, essentially. Yes. Always. Because, I mean, yes, there's a winner, the shortest code, if you want to do that, or winner per language. But as for the upvotes, it goes on what people... What's popular to upvote. That also means that things that look unusual or somehow is a funny type of answer, unusual type of answer, answered in some language that you wouldn't normally use for CodeGolf, those kind of things, they also get a lot of attention. Or if somehow the name of the programming language you use ties in with the problem, then you'll get loads of upvotes.
00:30:19 [JB]
Yeah. I mean, my most upvoted answer on the site is a three-byte Jelly answer, which, given a non-negative number, output if it's even, otherwise error if it's odd. Three bytes? And you can do that in three bytes in jelly, yeah. Because one of the built-ins doesn't work on numbers, and then you just run that built-in number of times equal to the parity of the input.
00:30:49 [ML]
Yeah, so the issue is that erroring isn't a normal way to use the language, really. So that's the difficulty. That's why it takes so much code.
00:30:59 [JB]
Yes, exactly.
00:31:00 [BT]
Right now, I love the playfulness of the language. I don't know Jelly, but just hearing you describe it and use it in Code Golf and the way it makes you think about a number of different solutions to a particular question, that's the kind of thing that I think is really attractive to a lot of these languages. That's the joy I get from it. Now, what I hate to do, because I think I'm the oldest on this particular panel, is there anything practical about it? Are there things people are learning out of doing this kind of compression? Is there something...because it's so narrowly defined, often you get things that sort of spring from that. Is there anything that's coming out of that?
00:31:40 [JB]
I am aware of one practical use of Jelly, which is when I used it in one of my jobs. Because I found it easier to write up a quick program to do something in jelly than in Python. But as far as I'm aware, there hasn't really been any practical exploration of Jelly in specific, or golfing compression, for example, as a whole. As I mentioned before, there is sort of the ongoing development of making languages that can be better at Code Golf. And Jelly is unfortunately falling behind, because it hasn't been updated in six or seven years now. So there are newer languages coming on the scene that have 10, 15 years of experience that they can look back at and go, "How can I improve?" And so coming out with shorter Jelly. And sooner or later, there's got to be a limit. And I guess it's only more and more development of this is going to result in that limit. So...
00:32:42 [ML]
Well, hold on. Having a limit and reaching the limit are very different things. But eventually, progress will slow, I suppose. It'll only become perceptible to the people that are really very closely involved in this.
00:32:55 [JB]
True. I mean, there's some new age golfing languages that are using fractional byte counts, which is only possible in theory, and never in practice. But if you want to squeeze one eighth of a byte out of your byte, out of your program, so that in theory, it is shorter than another one. At that point, it's splitting hairs, but that's exactly what the limit tends to, right?
00:33:25 [CH]
Without going down another rabbit hole entirely while we're down a rabbit hole I am curious if you can give a like high level You're saying it's six or seven years sort of falling behind at a high level if you know Our listeners are interested in these kind of newer Not sure if they're also revolutionary, but it seems like you're familiar with them Can you throw out the names and if it's possible to give like, you know A five to ten word summary of the the big thing that is added because I am curious as to you know What languages there are out there that I haven't heard of yet?
00:34:00 [JB]
I think the biggest one right now at least in CoGolf is Vyxal spelled V Y X A L Although the creator of this is going to be very annoyed at me because he insists is pronounced Vyxal if I remember correctly but actually Raze time contributed quite a lot to the development of Vyxal and Making it better than Jelly I think the primary thing it has going for it is that it has all of these previous languages that it can look at and just improve so much on there where they have redundancies and where they're missing areas and it does it very well That's the big big one and then there's all sorts of esoteric languages that you'll see thrown out on these code golf sites with a bunch of assorted confusing built-ins and letters that just happen to be really short for these subset of problems I could go onto the site right now and find ten of them if I wanted to list them all off But yeah...
00:35:01 [CH]
Well, maybe we'll dive in what maybe we'll have you back at a future episode and we can we can further Learn about that stuff. So I realize we haven't actually really given like an overview of Jelly per se we've talked about you know, it's evolved tacit model monads dyads But maybe before we start talking in more detail about the the tacit model and what makes it different Maybe let's take a step back and just in case there's a listener that's like what I haven't even gotten a full description other than it's a code golfing language. That's really good at it. You know, what is jelly as a sort of a programming language and then we'll go from there
00:35:35 [JB]
It is very similar to a lot of the classic array languages because it's inspired by them. A Jelly program takes a left argument and maybe a right argument. It chops off commands at the start it applies those commands based on patterns to the left argument and maybe the right argument passes that value on to the next one. Does it again until the entire programs just complete that's more or less exactly that yeah That's exactly how it works if that answers your question or not.
00:36:09 [CH]
I mean it does for me I've spent a lot of time with jelly and I guess to further Delineate it from existing array languages. So J uses ASCII symbols, you know BQN APL uses Unicode symbols What is it fair to say that jelly is I guess we mentioned the code page.
00:36:29 [JB]
Yeah, so Jelly's code page is actually it makes sense It's not like a bunch of random symbols taken from Unicode and thrown together It's primarily letters just the standard ASCII letters Then those letters with a dot over the top those letters with a dot underneath them and those letters with like a hook on them they're taken from various different languages and scripts and actual languages and scripts and put together into this one thing, but the use of the letters and the over dots the under dots is very intuitive For example, if the uppercase B Character turns it to binary takes an input outputs in binary B with an under dot undoes that so it takes in a list and converts it from binary So it's very intuitive if you know what one character one command does you can kind of guess what a bunch of related ones gonna do
00:37:26 [AB]
I can say about those characters that while it's an attempt to make meaningful pairings between characters and what they do, the overarching rule is that the characters must be directly typable from the US international keyboard layout. So that was like the restriction. It's not Unicode, it's US international keyboard.
00:37:50 [JB]
I always forget that one because I do not have a US international keyboard.
00:37:56 [CH]
And it is very, I mean one of the comments I make on Jelly is that it has just a ton of primitives. That's also one of the big differences is even compared to J it's got more. So I mean one of my favorite ones that comes up all the time that is not spellable succinctly in J, APL or BQN is Half. Basically that's either two divide with a, you know.
00:38:24 [ML]
J has half, though it's minus colon.
00:38:26 [CH]
Really?
00:38:27 [ML]
Gonna need another example.
00:38:29 [CH]
Okay. Well, I did not know that J had half, but I think it's.
00:38:35 [ML]
But J's version is two characters.
00:38:36 [CH]
Yeah, that's true. Whereas in Jelly, I think it's Capital H and then I think H under dot, then it's probably double.
00:38:44 [JB]
Yeah, each for half.
00:38:46 [BT]
And for J, it's plus colon for double.
00:38:49 [CH]
I did not know that J had those. So okay, that's I guess something that Jelly just borrowed from J.
00:38:54 [AB]
I think you have increment and decrement in Jelly, which you don't have in J.
00:39:00 [CH]
I think it has that as well, doesn't it?
00:39:01 [ML]
Increment and decrement are greater than colon and less than colon.
00:39:04 [AB]
Oh yeah, you do. You do. Okay.
00:39:09 [ML]
J has a lot of primitives.
00:39:10 [AB]
We're totally, we're failing at this.
00:39:12 [CH]
It's supposed to be a Jelly episode, but we'll call it in defense of J.
00:39:17 [ML]
Well, the thing is J's primitives are also, I mean, so it's only got like a hundred and something primitive glyphs or digraphs or whatever they're called, but they're ambivalent. So most of them has at least two meanings and some of the modifiers have like four or five or six, which I might actually point that out as an advantage of Jelly in that if you see the character, you know what it does, period.
00:39:34 [JB]
Yeah.
00:39:40 [AB]
It's much easier to read in that way.
00:39:44 [JB]
And Jelly does currently have, of the 256 characters in its code page, let me double check. I believe it's 23 of them are currently not assigned as single character things. So it has 233 single character primitives.
00:40:07 [ML]
Well, and so it doesn't have variables at all, right? So there are no...
00:40:09 [JB]
It has one register, but generally speaking, you don't use that.
00:40:15 [ML]
So there's one variable. Yes. But yeah, it doesn't need identifier characters.
00:40:20 [AB]
And then it uses five characters as prefixes to like shift the character set so that you can put any one of the other 200 and something, whatever characters after those and get additional meanings. So it's not just 255 or whatever it is.
00:40:37 [JB]
I think it comes out at around about 400 individual commands or primitives, all of them one or two bytes long.
00:40:45 [BT]
So when you run a Jelly program, it's interpreted, right? How large is the code that's required to interpret it?
00:40:54 [JB]
I can find out. I think I have the... Yeah. The interpreter, or at least the original one, not my fork of it, is 3,000 lines of code. And that's just the interpreter that's not counting the dictionary and a utility, a very short utility file.
00:41:12 [BT]
Because I'm just thinking in a practical case, if you can reduce the amount of bytes in your program, although if it needs to be interpreted and then you need the dictionary, it's going to be much larger than that. But for a large program, you could actually reduce the size of like for Internet of Things [06] or stuff like that. Within a certain space, you could put a lot more code in. I mean, that would be a practical approach.
00:41:33 [JB]
Jelly is released as a Python module. If you download it, you can do import Jelly into Python and just run a Jelly program in a Python thing by doing Jelly.interpret and then you give it the code. So in theory, you could do it that way. But yeah, you could absolutely compress down the, or like try and shorten the interpreter, maybe even compile it into something. That's not really anything I know much about.
00:42:04 [BT]
I'm just wondering whether anybody's thought about using that because that would be again, I hate to be practical with something that I think is so playful, but if you can reduce the size of your program by that much, there are places that that would make a big difference.
00:42:17 [JB]
Yeah. And, uh, what, because it's done with a code page, you know, you look at it and it's these incomprehensible strings of characters, but they are at the end of the day, they're just bytes. So you can do it with any, you know, series of characters to represent each byte that you want. So you can throw it into some machine code style thing. If you can translate those bytes down really low level,I guess that that would be a very, very interesting thing to see.
00:42:45 [CH]
All right. So I think now it is time for Tacit Episode 5.5, which comes right on the heels, I believe, of Tacit Episode 6. For a little spoiler for the listener that's made it this long in our podcast. So I think one of the most interesting aspects of Jelly is the Tacit model that it introduces, which I have not seen a Tacit model in any other language that is similar to the one that Jelly has. And it's incredibly powerful. You know, it's arguable whether it's practical, because it, I think, requires both the writer and the reader of the code to understand the Tacit model. But I think it definitely would be interesting to chat about it. So I guess in your own words, how would you describe it? And what was it like learning it? And I'm not sure if we want to get into that much detail, but of like describing links, chains, and multi-chains, because like that stuff I still fully haven't like wrapped my head around. And most of the time when I'm typing in Jello to program in Jelly, I will like test it out. And then I'm like, I know it's one of these ways, because I'm creating technically, I don't know if it's a chain or a multi-chain. And it's like at the end of the day, I get it to work. And then actually 5% of the time, there'll be some problem where I kind of, I need the Uiua stack model of like, I need to save this thing here because I need it in like three, you know, operations. But I like, I don't know how to carry that state along in order to the time where I need, you know, that state plus the current result that I'm at. So anyways, I'll, after that little monologue, I'll throw it over to you to describe, you know, Jelly's Tacit model. And we'll go from there.
00:44:26 [JB]
You mentioned how difficult was it to learn? That's the hardest thing to learn in Jelly. What all the commands do? There's a massive table of them. You know, you just scroll through them and you find it. How on earth am I arranging my program to make the patterns work? A question I was asking myself every single time I was writing a Jelly program for the good three years when I first started. And even now I'll turn around to someone else who knows Jelly just as well as I do and go, why is, why is it working this way? Shouldn't the pattern be this? And then go, Oh no, wait, hang on. No, the pattern's actually this. And it's complicated and confusing because the way that it works is that it, as I said before, it chops off the first few commands and then runs those and then does that again. It chops off the ones that start and then runs them and keeps going. The way it decides which ones to chop off are based on how many arguments each of the commands takes, whether it's zero, one or two, which is why Jelly, unlike J, has fixed arity on every single command because it directly affects how the program is parsed. So you can't really have like variadic programs or commands because it means a completely different thing. I won't go into what those patterns are, but it's basically, you know, do I have a, you might have say plus an H next to each other. So adding half, that's a two, one pattern. It means you throw the one argument on one argument and then add them together. You half something and then add. So let's say that you were given the one argument of five for that. You'd half the five and then add it to it to get 7.5. Makes sense.
00:46:18 [CH]
Which, for the combinatory logic enthusiasts, is the S-combinator. It's the hook.
00:46:23 [JB]
Yeah. But if you gave it two arguments instead of one, it doesn't do that anymore. It adds the two arguments together, and then halves the sum. Because the pattern is different, because it has a different number of arguments provided to the entire program. But the arities are always the same. If that makes sense?
00:46:41 [CH]
It does. It does.
00:46:42 [JB]
This is genuinely the most complicated bit about Jelly. It's also the elegance in the language is these patterns. So Jelly is broken down to atoms, which are the individual commands. Each one is an atom. It makes sense, it's the most fundamental building block of the program. You combine atoms into links, like you mentioned, and then you combine links into chains. And the elegance of Jelly is that the patterns that you use in atoms in links is the same patterns that you use with links in chains. In that, I'm trying to call on an APL or a k comparison. APL, you can..
00:47:28 [AB]
I think you can say that you can combine functions or modify functions with operators deriving new functions. And these derived functions can then be in trains, for example, to create whole programs. It's not exactly the same, but it's kind of that direction.
00:47:48 [JB]
Yeah, you build up the program using the same building blocks, whether you're looking at it at the extremely low level or you're doing this super convoluted one that requires chaining chains together into a multi-chain. And there, it's still the same patterns. So once you learn the patterns, you've learned the language, which is why I think it's incredibly, incredibly complex and yet simply elegant in how a Jelly program is broken up and run.
00:48:18 [CH]
Yeah, I completely agree with the elegance part. I mean, like I mentioned, is it practical is another question that I'm not really interested in answering. But it does-- I mean, I've kind of come to referring to the Tacit model as arity pattern matching.
00:48:37 [JB]
Yep, that's exactly it.
00:48:38 [CH]
It kind of looks at the arity of the fixed arity functions. And I think actually-- so once or twice on this episode, I tried to correct something I said in Tacit Talk when I think I was talking with Kai. And then I got into correcting myself, like I am right now, and then never actually corrected myself. And the thing that I said was that APL and BQN, it was possible to do this overloading on the arity of the functions, which is what in Uiua, it does with a couple different operations like partition. If you give it a unary function versus a binary function, it does different things. And I said, "Oh, I think that's possible in BQN or APL." And that was incredible-- like it was a throwaway comment, but it was incredibly incorrect. And it's like, I think very important to correct that I was wrong because it is the fixed arity that makes this kind of thing possible. You can absolutely not do this kind of thing in APL and BQN because of the ambivalence of the functions. If you aren't able to say, "Is this a unary function or is this a binary function?" How could you possibly dispatch on the arity of that thing? Because it's got multiple arities, and it's depending on how you call it, which is, I think, like an important thing noting when you kind of contrast these languages because you're able to do things in Uiua that you can't. And then also in Jelly, you're able-- like the ability to do this arity pattern matching elegant thing, it hinges on the fixed arity of this stuff. Adám's got something to add to this or to rebut.
00:50:15 [AB]
Well, it's actually two things, both adding something and rewriting something. The addition is that even k can do this kind of thing. Those flavors of k that can have a monadic marker, a colon after a primitive, they can choose based on whether an operand takes a monadic or a dyadic... Sorry, whether an operator takes a monadic or dyadic operand. That's the addition. The rebuttal is you could... I'm not saying you should. I'll actually say you shouldn't. But you could pass in your monadic function bound in such a way that the derived function cannot be applied dyadically. So at least in dyadic API, if you bind the left argument to a function or a right argument to a function, then it cannot be applied dyadically. You'll get a syntax error saying this function cannot take a left argument. And you could have an operator analyze what it has gotten to derive the intention of the user. Say, if you're giving me a function that surely cannot be called dyadically, you must mean the monadic meaning of this. And otherwise, dyadic.
00:51:32 [ML]
Yeah, but then you rely on the user to pass in something that has a form that's known to the analyzer. And most functions that you...
00:51:40 [AB]
Just like using the colon in k to indicate whether you want monadic or dyadic form. But I, again...
00:51:49 [ML]
Yeah, well, but k is a totally different mechanism. So k...
00:51:51 [AB]
Marshall, I said you shouldn't. Don't do this. Okay, just don't. I'm just saying you could.
00:51:59 [ML]
I don't think it's really the same thing. Like k semantics, I think there's a little wiggliness. I haven't sorted this out really. But in general, the semantics are that a function has a specific arity. However, and this depends on the k version, the arity of every function is decided syntactically, statically, before the program is run. So that's what the colon does for you. It's kind of choosing between in cases where the syntax doesn't tell you. You choose either, you know, I want the dyadic plus or I want the monadic plus. But once you actually get to run the program, every function has been given an arity. In APL and BQN, [07] what you have instead is any function at all, you can choose to either call it with one argument or two arguments. And that's just something that the language gives you. Now, it may error in one of those cases, but there's not really such a concept as an inherently monadic or dyadic function. It's just, I mean, this is something that we might choose to call a function that errors in one of those cases.
00:53:01 [JB]
And Jelly does actually have three quicks that you can apply to monads and dyads to turn them into dyads and monads, which can completely change the parsing. But the way that they work is that the quick is just attached to its atom to make one other atom or make a link. And that link has the arity decided at the start of the program before anything happens. If you use a dyad with a backtick, which turns it into a monad, it's always going to be a monad. And if you use the left and right braces on a monad, it's always going to be a dyad, no matter what. So the arities can get changed with these specific commands, but the arities are still fixed, if that makes sense. There's no way of changing them mid-program, after writing, or anything like that. And so the pattern matching is still sound and makes sense.
00:54:00 [CH]
That was one of the comments I was trying to make was that it's an incredibly elegant if not entirely practical, but I it makes me wonder like this it hasn't been explored I don't think like this kind of arity pattern matching tacit programming in any other programming language that I know and I and I Wonder if there is a simplified version of this like this the goal of this tacit model was code golfing It's you know cram as many patterns as possible So I don't need to do extra things to get the you know order of operations of my atoms Evaluated I don't have to add extra stuff But you know there's a lot of really nice things that fall out of the arity pattern matching one of them It's just unary function composition. You know it's one of the things that I It saddens my my heart in BQN and APL is that when you're trying to do tacit code? And you just have a bunch of unary functions you end up having to do You know parentheses or the the breaks or in J the cap in order to get you know? unary function composition, but in the Jelly model, and I assume all of this applies to jam as well I'm not sure if you've made any changes in the tacit model there But it's just when you see a one one that's just unary function composition and that kind of yields you another unary function so this series of Fixed-arity functions that are all one one one one one is just you know you're just applying unary functions, and it's it's really really nice and You know sometimes you end up doing a bunch of stuff that you get this hierarchy of you know if you do the equivalent Of the what do you call them the train trees in APL to kind of visualize what it's doing It's crazy, but I wonder if there's like a simple You know a simplified arity pattern matching model that could be used in kind of like a general programming language And it would be quite nice.
00:55:51 [JB]
There is. I've actually written as a Exercise for a code golf question I came up with gelatin a programming language Which is an incredibly simplified version of jelly with very? Simplified pattern matching because the intent is write an interpreter for gelatin and do it this way, but it simplifies down this pattern matching Into a way, which is a lot more digestible than going into the jelly interpreter and seeing how it breaks down all of the patterns Which by the way I did do when learning these patterns I went into the code and taught myself what each one meant because that was the easiest way that I could figure it out But yeah, I have also as a bit of an exercise, and I never finished it by I messed around with a language like old hatred because it does Because the intent is again this arity pattern matching in the least intuitive ways possible Just as a as an exercise because jellies patterns are also incredibly intuitive if you are interested in common logic they make sense in the same way that a lot of the Combinators there just go well yeah, of course it would do it in this order What how else would it do it for example if you have three dyads in a row in jelly? And it's given two arguments it applies the two outer ones and then gives their outputs into the inner one So if you have plus times plus Then it will add them both and then multiply the result which makes sense because you go well. Yeah, I'm plussing on the left I'm plussing on the right, so I'm gonna multiply them together So it's not only simple in the concept of the patterns, but also Intuitive in how the patterns are applied.
00:57:44 [CH]
I have I have found your hatred GitHub repo in the description. A programming language where no command does what you want it to.
00:57:53 [JB]
Yes. I believe the GitHub repo is quite out of date, and my local copy actually has more development on it. But I just ended up with the pattern matching on GitHub if I remember correctly.
00:58:06 [CH]
Interesting. A side question, you've mentioned now hatred, gelatin, and we've mentioned jam. We should spend some time talking about that as well. How many programming languages have you created in total, and how many are available online for people to look at?
00:58:24 [JB]
That is a very good question. I have lost count.
00:58:27 [CH]
Oh, wow. We're talking double digits then at least.
00:58:31 [JB]
Oh, we're talking 20 plus. Yeah.
00:58:34 [CH]
OK.
00:58:35 [JB]
Honestly, if you look at my GitHub, basically, it's all just different languages. I could talk for a while about my different languages, but that's not the point. Because I like to do them as a proof of concept thing of, that would be a neat idea of passing instructions between each other or data representation or something like that, and then just build it until it seems like a coherent model. None of them are groundbreaking or anything, but they're fun proof of concepts most of the time. The one I was really happy with is called Add++, which is one of my first ones that I made. Yeah. RaiseTime actually helped me develop that and wrote the wiki for that. Far-reaching impact. Sorry. But Add++, I then managed to write an interpreter for another language in that and prove that the language Add++ was interpreting was Turing-complete. Managed to write an interpreter for a Turing-complete language in one of my own languages, which was a neat proof of concept to exercise. Their languages in the sense that they are interpreters for proof of concepts.
00:59:55 [CH]
We did mention a jam as well, and that we should spend some time. Tell us how similar it is to Jelly. Obviously, it's a fork, so it has a lot of the same stuff. So, you know, what have you done to extend or make the language different?
01:00:05 [JB]
So I do actually need to correct you on Jam. Jam, I haven't really been working on Jam for about a couple of years now. Real life stuff happened, so it never came out as a finished product. I'm planning on finishing at some point. It originated from a fork of Jelly, and is my attempt to update Jelly with, you know, we've been using it for eight years now. We know what a lot of the mistakes that were made in the original design were, where two byte commands have been used that should be one byte because they're used all the time and it's just wasting. I mean, famously on CodeGolf, there was a challenge where an APL answer beat a Jelly answer because APL has lowest common multiple as a single byte built in, whereas Jelly has it as two bytes. And so I believe it was one of Dan's answers, actually, beating Jelly with APL. And it's one of these things where there are lots of flaws in this language. I would love to update them, correct them. The pattern matching is actually one of the only things I haven't touched because it was done perfectly first time. I couldn't improve on it if I tried. But the big ones are behavior of atoms, new quicks, new features, that kind of stuff. I wrote up a solid amount of it, and then real life stuff happened. I went to university, and that took up a substantial portion of my free time. Whereas Jam was first developed during the pandemic, just after I left high school and had all of the free time in the world to work on this thing that I wanted to work on. And then real life happened and it kind of got relegated. The biggest thing that stopped it was just adding in all of the commands. I think I wrote up a list of about 500 different primitives that I wanted to add in. And understandably, that takes a long time to actually implement. But the usable thing for Jam now is the Jelly fork, because that was effectively the alpha version of Jam. My aim for that fork was to update Jelly to be more competitive years after it stopped being updated, but still keeping backwards compatibility with the actual Jelly. The fork is a fork of the language; it's not a new language itself. But most of the commands that I added into that fork, I have either brought in or I intend to bring into Jam. At some point, I will finally finish off Jam and publish it, and I can see just how well it compares against Jelly. Yeah, I feel a little bad that I was invited on to talk about an unfinished project of mine.
01:03:24 [ML]
So all these forks, have you considered using a spoon?
01:03:27 [JB]
I don't know. I like stabbing things.
01:03:31 [ML]
Even if they're jelly?
01:03:33 [JB]
Yeah. Have you never tried eating jelly with a fork?
01:03:36 [ML]
Suppose not.
01:03:37 [AB]
Come on, Marshall. You're one of those Array language people that likes forks.
01:03:41 [ML]
Yeah, well, they have their uses.
01:03:43 [JB]
The big thing is the improvements on jelly that I decided to go. It's been long enough. The creator is no longer updating the language. I would like to add in my own updates. And it's had some use, especially in CodeGolf. I've beaten quite a lot of my own jelly answers by three or four bytes. The first time it was used, I improved a seven byte jelly answer down into five bytes using my fork, just with one command that I added because the thing it replaces, effectively, it's a operator that takes a command and uses keep those for which the following equals the right hand value. So, you know, if you have a list of lists and you want to keep those with a specific sum, then you just do this with the sum and then the sum on the right hand side. So you want to keep those that sum to five. You just do sum, keep command five. And in normal jelly, it's like five bytes to do that because and it's a very common thing. And in golfing, save every byte that you can. CodeGolfing specifically.
01:04:58 [AB]
A bit of context as well for the non-CodeGolf listener. You mentioned like three, four bytes. And most people writing computer programs, they don't think of three, four bytes as a whole lot. They usually measure the code in, I don't know, millions of lines of source code or something like that. Yes. But for CodeGolf, it's a big thing and it's perfectly acceptable to be able to save one byte on, say, like a 20 byte program, even if that means that there will be the heat death of the universe before it finishes. I mean, theoretically, it will finish.
01:05:33 [JB]
Yeah, I believe a couple of years ago on one of the categories in our best of this year stuff was biggest answers, by which I mean takes the longest to finish. Because some of my jelly programs in the effort of saving one or two bytes had complexities of O two to the n factorial or O n to the nine to the n. [08] Because it's two bytes. I've got to save those two bytes.
01:06:11 [CH]
For anyone that hasn't tried CodeGolfing, it may sound like it's an odd hobby, but it is. Or maybe I just have a similar brain to yours, Jay, in that the same itch is scratched. But it is, it forces you to bend your mind in a way that no other problem does. Because how often are you trying to do like your your sole goal is just shaving off characters or bytes.
01:06:38 [AB]
It's a very old sport, I can tell you. I have from my, from good authority, from my father who works at IBM, I think it was from '68 to '72, and they were doing code golf. Sometimes out of necessity, because the computers couldn't contain large code. They could spend more time, but not have more memory. And they would do things like come and present some programs, say if anybody can shave off one whatever code unit they were using at the time, maybe not a byte, and then they would give them a cup of coffee. And he even told me about a problem he was given. He was informally known as the Department for Seemingly Unsolvable Problems from IBM International, so people around the world couldn't solve a problem, they would send it to him. And he was always worried that he would get fired because it was so hard for him to do his job. But one of the problems that he got this way was implementing some translation table between two things as part of a larger system that was already filling the computer's capabilities. So there wasn't enough space to have the two tables, so the lookup table and the corresponding result table. And he solved it by looking at the commonalities between these two tables, and then only translating those parts that were actually different, or couldn't with some formula compute what the other one would be. Maybe the, I don't know what it was, maybe it was like the alphabet, and the alphabet is in the same order, but in a different place, or partially in the same order, those kind of things. So he had to use code golf methods, this kind of ridiculous code, in order to shave a little bit off and made it run. And he got in trouble because one of the code pages, or whatever it was, one of these tables was proprietary, and they weren't allowed to change it. So I have to say, do you want to keep the rules, or do you want the program to run?
01:08:29 [JB]
Yeah, I have actually written up a fairly long and detailed history of code golf post, because it originates, as Adám says, back when it was a necessity. And then died out until the early 2000s, when Perl golf exploded onto the scene when Stack Overflow was created. There was a bunch of people who just went, "Hey, let's do code golf on this, and do it in Perl, because apparently it looks incomprehensible." And APL used to be considered cheating, because it wasn't real code, and you're making up symbols for it, and all this. And then there was the very first golfing-specific language created called GolfScript back in 2008, and it's slow, and clunky, and horribly verbose now, compared to the five or six-by answers that you get in modern code golf. But I've done a complete breakdown of it. It's a topic that I very, very much enjoy talking about, in case you couldn't tell.
01:09:40 [AB]
Hey, I did code, you said in the early 2000s, I did code golf in, I think it was '97, at the age 12. And I was in the home of Anthony Camacho, who's an APLer and I think developer or leader of the IAPL project that never really went anywhere. I was there with my father and there was this traditional, simple, O-N squared way of getting prime numbers in APL and everybody was using the same exact formulation. And I came up with a shorter way to formulate it. And my father and Anthony Camacho, they were all like, open arms about this, like, "Whoa, he beat the record. This is, we have to revise the books now. This is a shorter way of writing, getting prime numbers in APL." So it was definitely a known thing to them in the APL community.
01:10:39 [JB]
Well, I mean, especially in languages like APL, J K, where you can write incredibly short code and it still does the same thing at not an unreasonably complex process. You're not shaving off every byte you can, but you know, occasional quick APL train, why write out the full variables and assign it when you can do it in eight or nine characters? Because that's all you need for a quick offhand script. It's completely valid. And CodeGolf just went, "Hey, watch me try and make this into a sport for fun rather than just a necessity and we can do this."
01:11:23 [ML]
Yeah, so I have Dijkstra [09] complaining about in 1972, he says, "You know, the first thing a group of programmers end up doing when they get an APL terminal is they start, you know, asking, they start trying to solve problems in one line and then they ask each other, you know, can you solve it in fewer symbols?"
01:11:45 [CH]
So that's all that Dijkstra said. I thought they were surely it was going to slam, if not APL, some programming language.
01:11:54 [ML]
"As if it had any conceptual relevance," is his complaint.
01:11:58 [CH]
There we go. Okay. I was like, that sounded almost neutral. Well, I was looking at, because I had put my audio Audacity recorder behind a screen and then I looked at the time and saw, holy smokes, we've once again...
01:12:16 [ML]
There's no hour mark in the rabbit hole.
01:12:20 [CH]
Oh, there we go. There we go. A classic, a classic podcast gold from Marshall Lockbaum. There's no hour mark in the rabbit hole. But yeah, we will be sure to add all the links in the show notes to all of the languages mentioned and also to the the history. And if you haven't tried it, you know, whether it's Code.Golf or one of the Stack Exchange sites, I think there's you mentioned another one. Adám was weak golf or something like that.
01:12:45 [AB]
It's not active anymore. Unfortunately, I think it's closed down.
01:12:49 [CH]
Yeah. And it would be it would be neat to see. I think Code.Golf, I mean, Code.Golf, it has a super nice UI and ranking system that like I love leaderboards and stuff like that. So like they should they should get on top of adding, you know, a language like Jelly or even some of these newer languages like Vyxel or Vyxel. And= yeah, Jay, you're going to say something.
01:13:12 [JB]
Yeah, I found I found the site I was thinking of. I think the oldest Code.Golf website, it's called Anarchy Golf. Anarchy Golf. Yeah. And it doesn't do explanations. It's just here's a problem. Try and solve it. It has jelly on it. It has 115 different languages. Yeah. And that's been going on since I believe 2008.
01:13:36 [CH]
Wow. We will leave a link in the show notes as well to this. Initially, when I clicked on the link, it said not available. But then after showing that like two seconds later, it the site did load, but it's got a triangle with an exclamation mark in it that says not secure. But yeah, this looks great. So, yeah, links for everything will be in the show notes. Thank you so much, Jay, for coming on. This has been fantastic. And I guess, you know, for folks that are looking to get into Jelly and Jam, what's your recommendation? Basically just doing what you did, go read the source code, you know, suffer for three years and then you're an expert.
01:14:09 [JB]
Honestly, I would recommend you go on to Code.Golf and you ping me. At Caird and say, I'm interested in learning Jelly and I will happily teach people who want to learn Jelly.
01:14:19 [CH]
Wow. Look at that. Look at that. What an offer.
01:14:21 [JB]
We have the room, the chat room that was originally used. I would love to unfreeze it and go through them because there's a bunch of learning resources on there, which I'll link for you so you can put in the show notes. Awesome. Yeah. On just beginner exercises and stuff like that on how to learn Jelly.
01:14:35 [CH]
Fantastic. Yeah. We will be sure, as mentioned before, to add those to the links in the show notes. And yeah, what an offer. If you're listening to this and you're thinking, oh, this sounds tricky. Well, you've got a personal teacher waiting to teach you if you're interested. And yeah, I will throw it over to Bob, who...
01:14:57 [JB]
Don't overwhelm me.
01:15:01 [CH]
Don't worry. I mean, actually, we do. We do have the listeners in the hundreds.
01:15:05 [ML]
Worry, but only a little bit.
01:15:07 [BT]
Well, if you do want to get in touch with us, you can contact us at contact@araycast.com, and we welcome your comments and questions and feedback and shout out to our transcribers, Sanjay and Igor, who do a great job every episode putting this on to... And Adám as well, who does the initial transcription that gives us timestamps, which is wonderful. Thank you again to Adám. And during this episode, a number of times references to razetime have come up. And undoubtedly, if you're in this community, you will see that name pop up from time to time. And when you see it, just pause and reflect and be grateful for what he provided to us all. I think that's an important message going forward.
01:15:51 [CH]
I think with that, we will say happy Array programming.
01:15:54 [AB]
Happy Array programming.