Transcript
Transcript prepared by Bob Therriault and Igor Kim
00:00:00 [Stine Kromberg]
And I knew from the start that I wanted to do project management. I wanted to work with people. I wanted to look at processes and go out into the world and be a sort of middle to top level management. I was five at this point. That was where I wanted to go. I wanted to be a leader and manage people.
00:00:30 [Conor Hoekstra]
Welcome to episode 75 of ArrayCast. I'm your host, Conor. And today with us we have our four panelists plus a special guest who we will get to introducing in a few moments. But first we're going to go around and do brief introductions. We'll start with Bob, then go to Stephen, then to Adám, and then to Marshall.
00:00:44 [Bob Therriault]
I'm Bob Therriault and I'm a J enthusiast and very enthusiastic about J.
00:00:50 [Stephen Taylor]
I'm Stephen Taylor and I like APL and I like q.
00:00:54 [Adám Brudzewsky]
I'm Adám Brudzewsky and I kind of like all array languages, but I can't use them all at the same time. So I just do APL.
00:01:01 [Marshall Lochbaum]
I'm Marshall Lochbaum. I've worked with J. I did work at Dyalog for a few years and now BQN is my array language.
00:01:11 [CH]
And as mentioned before, my name is Conor. I am a polyglot programmer, the host of the show, and fan of all the array languages. And yeah, with that, I think we are going to have a few announcements, three from Adám, and then I think two from Bob. So I'll throw it over to Adám first for the announcements.
00:01:24 [AB]
Okay, so about two years ago, I started a project where we took one problem from the phase one of an APL problem-solving competition and discussed it in the APL Orchard chatroom. [01] And then usually the week after that, I would record a video going through maybe some of the solutions and presenting them nicely. And we've not run out of problems. We've done all 110 of them and I've done 110 videos. And well, you can read my blog post. We'll leave a link to that about it and go watch those videos. If you watch them in one go, then it's a 22-hour marathon. So enjoy. And then there is the APL Seeds 24 coming up. And it's about last time, a chance it's going to be the 27th of March online. And you can find the link in our show notes. You can find the schedule there and summary of all the things that are going to be discussed. It's a little bit different this year in that there will be discussion panels more than just presentations. And finally, Dyalog version 19 has come out. We've been waiting long for this. There aren't big changes to the core language, but underneath the covers, input/output has been revamped. And that has some consequences. It makes it nicer for things like scripting and there are various tools and a new version of RIDE. So go download it. Try it out. Let us know what you think.
00:02:58 [BT]
And on to my announcements, if you haven't seen enough Adám with 22 hours of problem solving, then there's an additional 90 minutes that was recently recorded with the ProgLancast. We've mentioned that group before. And they're doing, well, they started out doing, I think it was Goodbye, Hello, World. And they've now sort of morphed into, at least for the time being, they've gone into being much more interested in the array languages, which we always support. But they talked to Adám for about 90 minutes. And it's actually a really good interview. It makes me think, why didn't we have Adám as a guest on this show already, but he was on the panel? So I guess it all makes sense, you know, but it was a really interesting hour and a half. If you want to know more about Adám and his background and all the things he's done and how interested he is and why he does the things he does, it's really good. And I think it was, I was really enjoying it. And the other thing is we had Henry Rich on a while ago, a couple episodes ago, talking about the new release of J. And now J 9.6 is out in beta. We talked about how J does its releases. It's out in beta now. So if you want to see what is in the pipeline for the next year, it'll be out. You can try things out. You can see it as it develops. And usually sometime around December, it'll become the new version of J. So that has already started. J is already revving up its engines to have another version on its way.
00:04:31 [CH]
Awesome. So links, as always, will be in the show notes, either at our website or in your podcast app. So be sure to check those out if you're interested in any of the things that just got announced. And without further ado, we are going to introduce our guest for the day, the new CEO of Dyalog Limited. I always say Dyalog APL, but that's the name of the interpreter, not the company. So back in, and I haven't even said the name, Stine Kronberg, but back in episode 12, and I looked this up and it's hard to believe that this was back in 2021, I think, like heat of the pandemic. The 12th guest was the previous CEO that just stepped down a couple months ago, Gitte Christensen. We'll put a link in the show notes if you started listening recently and you haven't heard that one already. But Gitte has stepped down, I think it was in January, and Stine has stepped up to the role of CEO. She's hold a couple other roles over the past few years. And this is obviously a big change for not just Stine, but also the company of Dyalog Limited. And we're here to talk to her today about, you know, what's going to be happening in the future with the company and potential changes she might be making and anything else she wants to share with us. So maybe at this point, we'll throw it over to you, Stine, and you can give us a little bit of an introduction of yourself and your history with Dyalog, the company, and APL, the language, and we'll go from there.
00:05:48 [SK]
Well, thank you, first of all, for having me. And I will try to give you a bit of a background about myself. First of all, you might recognize the name Kronberg, not from Gitte, but from Morten Kronberg, the CTO of Dyalog. And yes, there is a family connection. I'm about 30-something years younger than Morten and his offspring. So as you might have guessed, I grew up with the APL in the household. Back when I was a little girl growing up and sitting at the dinner tables, all the chatter was about APL and how great it was. And I thought that all programming languages were like APL. And I kept believing that until all the way into university when I actually started coding with Java, and I was very confused. So a bit more about my background is that I've always been a nerd. I've always been the kind of girl who played with all the boys, and we played computer games and role-playing both tabletop games and running around out in the forest, hitting each other with swords and stuff. I've never been a really hardcore computer nerd, but I've always been a nerdy type, really getting into things and reading up and really committing to hobbies. Part of why being a nerd is really, really important as a CEO of Dyalog is that it makes you able to relate to the people in Dyalog. The thing about Dyalog is that it's full of people who are very, very interested in the thing that they're doing with the interpreter. And everybody has their own specialty at Dyalog. And if you don't understand the need to be a specialist or a nerd within a certain field, you won't understand the way Dyalog works. Everybody at Dyalog is a nerd within a specific little part of the interpreter. And I myself, as I said, am a nerd, but I'm not a computer nerd, right? For me, it's the way people work. It's the relationships. It's the way you optimize people so that they function as well as they can. So for computer scientists, they focus on getting the computer to doing exactly what they want and running as fast as it can and doing everything in an optimal way. And for me, I do the same with people. So I'm a people nerd. I'm that woman in the IT crowd who keeps thinking about the people side of things. My educational background is in business administration, economics, and courses on how to do proper change management and culture changes and all of these things that are very, very interesting when you like working with people. Not very interesting when you like working with computers. Back when I was doing my... I grew up with Gitte and Morten, right? They had this little company and it was nice and it was cute and Morten kept saying that it was fine, it was flat and everything was good. And I was like, there's no chance that Dyalog will ever get to a place where they will need someone who likes to work with people because it's just a small company of 10 people who likes to sit in a barn somewhere over in UK. And I knew from the start that I wanted to do project management. I wanted to work with people. I wanted to look at processes and go out into the world and be a sort of middle to top level management. I was five at this point. That was where I wanted to go. I wanted to be a leader and I chose my education, which is sort of a combinatorial study of business administration, economics, leadership, lots of different things. A bit of programming actually, because it was a study that was geared towards being middle to top management in software companies. And then I thought, maybe that's a bit sort of... You have to know something about something other than people if you want to go out and be a project manager. So I actually studied some maritime logistics, like supply chain management and how boats go from one place to another. So I know an interesting amount of stuff about container ships and the difference between a 20 footer and a 40 footer and a refrigerated one and RORO’s versus other kinds of ships that can take rolling cargo. And I know an incredible amount of that compared to what I'm doing today.
00:10:35 [CH]
If you ever, if you ever get bored of being CEO of Dyalog APL, I happen to know that there's another APL company. I think it's called American Presidents lines or something, and I used to use their logo in like two or three YouTube videos because there was no APL logo anyway, so you got options, you got it sounds like you're...
00:10:52 [SK]
I got I got options. Yeah. So my dream was I was going to work for Maersk or DFDS or some big liner company [02] in Denmark and sit there and do sort of middle management for the rest of my life. And that would be fine. And I actually got my first job right out of uni working as a business intelligence programming consultant for some of the bigger shipping companies in Denmark. And it was actually quite fun for a couple of years. But as I said, I'm not a computer nerd. I don't like... I actually don't like programming. It's not my cup of tea. I like working with people. So I thought I want to go into project management. And then Corona hit or COVID-19 hit and I wanted to go into project management. And everybody was like, we're not hiring any consultants at the moment because we're all working from home and we don't want any foreign diseases inside our company. So I was like, okay, this is not fun. And very luckily for me, the then accountant at Dyalog decided to retire. And Gitte came to me and said, if you're looking for a job where you might actually get something to do for the next six months, that we have this position open and maybe that's something for you. And I was like, I can do accounts. And can I do a tiny bit of project management on the side. Yeah, sure. If you're done with your accounts, you can pick up projects and help do a bit of process. And I was like, okay, I'm in. So in 2020, May 2020, I just left my previous job, came to work for Dyalog. And I started out as a lowly accounting assistant doing all the accounts and not much else for the first six months. And ever since then, I've just been doing more and more project management and process optimization and general things like strategic planning, budgeting, all of the fun stuff at Dyalog, if you ask me. I'm sure everyone else at Dyalog will disagree. But that's the good thing about Dyalog. We are all specialists or nerds within our own areas, right? So hiring someone like me in who wants to do the stuff that nobody else wants to do is actually perfect.
00:13:13 [BT]
I've got a question for you, Stine. I had a sort of almost a parallel background. I worked in a television studio and I managed people who were creative and were very much nerds in their environment. How much of the training that you took in the business administration and stuff, how much of that carried over? How much of that did you have to forget to be able to manage people that are honestly very different than what I think the standard business administration course would teach you about?
00:13:42 [SK]
I think the thing with business administration and the courses you get is that you are provided with a lot of frameworks and tools. And what a lot of people forget is that those tools aren't just one size fits all. You always have to cut a corner off here and tailor a bit here and always provide a bit of context for the tools to work. So I think there's a lot of the tools and theories that I've learned that are really, really useful. But if you don't apply them to what you see, it doesn't matter. Best practice is not best practice, right? You have to always make sure that it fits. You can't just take the playbook of the person next door and it won't work for you, right? So I think a lot of it has actually been useful. But I also think that a lot of my experiences from being a role player and getting all of my role playing friends out and creating teams and making sure we all had a tent and food and costumes and all of that also helped me a lot. Because I knew that not all people are normal. We are all individuals, as they say. Even the people who are very close to normal are individuals in some sense. And you have to make sure that you take everybody's individuality into account when you try to manage people.
00:15:12 [BT]
Neither Gitte and Morten had any sort of leadership management education. So what they did was they always did what they felt was right. And I still believe that in its essence, that is what you have to do. You always have to do what feels right. So of course that always colors... It's sort of my top set of glasses. It's always... It has to feel right afterwards. No matter what the theory says, if it doesn't feel right, if I can't look myself in the eyes afterwards, then it's not right. Even if it's good for the bottom line or all the theory says that you should do something, then if you can't look yourself in the eyes at the end of the day, then it doesn't make sense to make that choice. Then you make a different choice. So yes, it did color my glasses that I grew up with Gitte and Morten, who had a very different way of looking at management. So yeah, definitely.
00:16:31 [BT]
Seems very wise to me.
00:16:32 [CH]
When you mentioned the nerd comments, I mean, this is a random anecdote that maybe our listeners don't care about, but it's relevant because it just happened in the last few weeks. I was at my girlfriend's birthday party, which we were hosting, and I've met her friends and stuff before. But then the next day after the party, I was asking her how it went. She's like, "Oh yeah, my friends are just... Three of them said that you're just such a nerd." And I was like... I'm not sure if anybody has watched Parks and Rec, [03] but there's a character in the show called Ben Wyatt, who's this accountant, that his kind of bit is that he goes and interviews at these other accounting firms. And then amongst the accountants, he's like the coolest, funniest. He tells a joke and then the accountant Jim is like, "Jim!" Or he calls up to Bob, "Bob, get over! Can you tell the joke again?" And he's this coolest person in the world. But then amongst everyone else in the Parks and Rec office, he's the nerdiest. And he thinks he's really cool. He's like, "Oh, I mean, my accountant friends, you should see them. We get along great." But then he's always just the most awkward, nerdy person. Anyways, and I kind of have this view of myself as well. That I spend so much time on these podcasts with other people that are passionate about APL and array languages and programming languages and technical things. And then I think I carry that view of myself into the "normal world." And then when I hear people being like, "Oh, he's such a nerd." I'm like, "What are they talking about? I'm super cool." But then when you take a step back, it's like the stuff that I'm joking about. No one actually is really laughing. But yeah, anyways, I very much relate to this. I'm sure everyone in this podcast right now, whether they identify as a nerd, we all are nerds. And probably not even just nerds, like passionate nerds. Like nerds that are nerdy enough that they want to go on a podcast and talk about their favorite paradigm and language. Which definitely, I'm sure most of the folks at Dyalog Like, they would be happy to come on a podcast and talk about this stuff because they're so passionate about it.
00:18:31 [ML]
But that's not because of the language. It's because of the talking.
00:18:36 [SK]
I actually think a couple of them would not be happy to go on a podcast. It would be a scary.
00:18:43 [CH]
I actually think a couple of them would not be happy to go on a podcast. It would be scary. Yeah, I'm sure behind closed doors, if it's not like a mic that's being recorded, all folks are happy to talk about, you know. When you mentioned 19.0, my first thought was like, "Did Reverse Compose ship with that? Or is that coming in 20.0?" That was like my first thought that popped in my head. It's like, "Are we getting the Reverse Compose? Because I know it's on the horizon." Whether it's shipped in 19.0 or not is probably going to be answered right now, to be honest, now that I've asked the question. But the point being is...
00:19:12 [SK]
Ask Adám.
00:19:14 [AB]
No, it's not. As I said, I would have said it has exciting language features. But it doesn't. Sorry. It's like, yeah, 19.0 is... It's all right. I'm waiting for 20, to be honest.
00:19:29 [SK]
I'm not even sure it's going to be in 20, unfortunately.
00:19:32 [AB]
We'll see. I find it interesting, though, at Dyalog that... So we have all these nerds or geeks. I don't know what the difference is. Somebody explain maybe.
00:19:41 [CH]
Nerds are cooler. Nerds are in the 21st century. I think geek is...
00:19:48 [ML]
I think the rule is that the people who care about the difference are both, right?
00:19:55 [SK]
Good thing.
00:19:58 [AB]
I don't care.
00:20:00 [CH]
Sure you don't. Sure you don't.
00:20:02 [AB]
But but so we have all these people that are whatever experts in their in their field, that they're like each one doing their own, their own little thing. But so we have all these people that are, whatever, experts in their field of Dyalog, each one doing their own little thing.And then we also kind of implicitly expect them to speak in public, because we make all these conferences and meetings and we go to and videos. And nobody says this out loud, but it's a given that, yeah, you also need to be able to present your work. And I think most people in the company, either they regularly do or at least have at some point spoken about what they're doing, which is interesting. Like you say, because some of them are not really the speaking type.
00:20:42 [CH]
Yeah, I guess the interesting challenge for Dyalog is like most larger tech companies, they've got a certain number of employees where you don't need every single one of them to speak. Like a fraction of them, 5% is fine, because if you had everyone, you got thousands of people trying to present at a number of limited slots. So the smaller the company, the higher the percentage of folks that you need to get on stage. So I think most tech companies, if they're only looking for a single digit percentage of folks, they have that 1 out of 10 or 1 out of 20 folks that are not just willing but want to go and present at conferences. Whereas if you're at a smaller company where it's 100 people or 200 people, that percentage, especially if you're putting on your own internal, or not internal, but like a conference like the annual Dyalog conference, you definitely need a way higher percentage. So you then get into the, well there was a certain percentage of folks want to go on stage, and then another one is kind of like, well if I have to. But yeah, I mean, I think you actually presented at the most recent Dyalog conference, is that correct Stine? I think I remember seeing at least one of the introductory talks from you.
00:21:50 [SK]
I think I got to do the final talk about the, well I got to introduce our new admin staff who came on to talk about the pricing increases we were introducing. And I got to talk a bit about my strategy path and where we're going, what's going to happen when there's a new CEO. I did get to do about 30 minutes. And I think I also managed to get a standing ovation for Gitte as a retirement present. That was nice.
00:22:21 [CH]
Yeah, we will throw a link in the show notes if folks haven't already gone through the backlog of Dyalog 23 talks. Bob?
00:22:28 [BT]
Well that talk was given in last fall for Dyalog 23. And some stuff has happened since then. You've actually grabbed the reins. What have you found out?
00:22:40 [SK]
What have I found out? I've actually found out that when I did that talk, I didn't think a lot about our marketing strategy. Because I hadn't gotten to it yet. It was still on my to-do list to get through everything and the marketing. I hadn't gotten to that. The only thing I discovered was that we needed to redo our competition. [04] Because it is fairly popular within the APL circles, our student competition. But it was closed to only students. And our sense was that it was a lot of the same people participating every year. And we didn't see a lot of new faces, at least not in the sort of close to winning category. And we also saw that there was a lot of the people who were competing, who were sort of what we would call "serialist language eaters". The kind of people who do all the languages they can get to and they move on to the next language as soon as they're done with the competition. And we like those people. They're wonderful. And if they know APL as one of their tools in their toolbox, it's incredibly valuable for us. But we wanted to do something different for marketing in the next couple of years. Because, I'm not sure if you know, but we are not the only APL vendor out there. There's a couple of others. And there is a trend in the market now where a lot of these sort of very serious professional APLers start slowly moving towards Dyalog. It's not everyone at once. It's not everybody necessarily coming. But we are seeing an uptake in people asking for help in migrating towards Dyalog APL. And of course that's great for us because it's more revenue and we can hire more people and do great things for APL. But it's also sad because it means that we are basically cannibalizing the APL market. And as an APL vendor, we're not interested in eating all of our competitors in the APL market. What we actually want is to eat the people who Python and other languages. We want more people to do APL, not more people doing Dyalog APL necessarily. So languages like GNU APL and similar languages to APL that gets people interested in array languages and maybe even APL along the line are very good for us. Because it actually increases the market pool in general. And so what we want to do with our competitions is actually grow the market and not just make more people aware as was the case with the old competition. So we've done two things. First, we've launched the APL challenge, which was launched on the 1st of February. And that segment is actually focused on very, very young people who've just learned a bit of math, maybe some chemistry, physics, that kind of stuff. And our hope is that they will pick up APL at an early age and start applying it to their sciences instead of something like MATLAB or Python or whatever else young people pick up at an early age. So it will come in as a competitor already at maybe 14, 15 years of age. So the problems in the challenge are very, very easy. Even I can solve them in half an hour. And I'm, as I said, not a programmer. So if all the people who used to do the student competition think that these are hilariously easy and what's going on, well, you are not the market anymore. We are focusing over here. Find your little brother or your sister's friend or something and give it to them. The plan is to do sort of very serious marketing on all the social media platforms for young ones. So TikTok and Facebook and even Reddit. I've been suggested that we do it on Reddit. So and maybe Adám and I was ping ponging the other day about translating it into some of the bigger languages like German and Italian and French and maybe even Chinese, if we can get around to it. And actually getting it out into the schools, like contacting different professors and headmistresses and ministers and to sort of get it out into the schools again, making APL one of the good languages in schools. So that's the plan with the APL challenge. That's why it's so hilariously simple. It's not for the grownups. It's for the kids. And then, of course, there has to be something for the grownups. And that is where the APL forge comes in. That is what replaces the base two. We just decided a name last week.
00:27:33 [AB]
You heard it first here on the ArrayCast.
00:27:36 [BT]
So that's the APL forge. Is that right?
00:27:39 [SK]
Yeah, the APL forge. And the thinking behind the APL forge is that this is like an incubator. It's a forge. It's where you come in and you create these new things. And it's basically going to be sort of a case competition. So you bring your own thing. So it can be anything from a little snippet of code that can just do a simple calculation that are very valuable within some field. It could be like a physics calculation that you do every day. You do it in APL just to show how it's done. But it can also be an application that is more or less ready for being put into production. So it can be anything from a nail to a full suit of armor. So everything goes into the forge and everything can be accepted. And there will be a lot of prizes, maybe even some licensing help if you are aiming for producing a production-ready application. There will be a year free licensing, both developer and runtime, so that you can get your business running. There will also be a cash prize, so you get a bit of seed money to get your company going. The whole idea behind this is to get more people to produce new things in APL, so that we increase the market of people actually doing APL for business purposes. So it's not limited to students at all. It's free for all, even companies who are already doing APL. If they have a new application that they haven't marketed yet that they aren't paying licenses for, that's also fine to submit. It's very, very wide. The main thing is that you have to create something new in APL. And you retain all the rights to your code afterwards, so we won't ask people to publicize their code. They can keep it closed if they want to. So that's sort of the thoughts behind the APL forge. And the whole thing behind this is to create new people using APL, both for fun when they're young, but also in anger and for commercial purposes when they're a bit older.
00:29:54 [BT]
So for you right now, do you feel like the APL community is growing? Are you picking up something that feels like it's growing, or are you trying to rejuvenate something that seems to be dropping off?
00:30:07 [SK]
I think five years ago, it was dropping off. We did see a lot of our current customers who had lots of problems recruiting new talent. But we've actually seen in the past five years, there's been a real surge into the community. There's a lot of the older hands who have been working on the applications for the past 20, 30, 40 years, who have been having trouble getting apprentices. They are actually bringing new blood to our conferences. [05] The average age at our conferences has actually gone down quite a lot in the past couple of years. So we are seeing at least a generation shift. The other side of that coin is, of course, that the older hands, they stick around for a couple of years to make sure that the new people are doing well, but then they head off for retirement. So right now it's growing, but if we don't do something, we might actually see it go down again and normalize at the same stage it was before. So now we're trying to keep that up-going curve by trying to get more young people to actually produce new things, new applications in APL.
00:31:18 [CH]
Stephen, were you going to ask something?
00:31:19 [ST]
Yeah, the answer to this question might well be, Stephen, one step at a time. If I were a potential customer of Dyalog, wanting to build a new application or convert an old one, I would need not just people who could do the language and write the code, people who knew how to put the systems together. And the ecology of system building is different in pretty much every language, Java, Python, whatever. Do you have a plan?
00:31:50 [SK]
Do we have a plan? What we've agreed in regards to the Forge is that we will allow applications that aren't entirely built in APL. As long as the core logic is built in APL, it's actually fine if you showcase that you wrapped it in HTML or Python packages or whatever piping you want to do it in. We also do try to develop tools that support the integration between APL and other languages, because APL is really, really great at building business logic that needs specialist knowledge. The kind of code where just doing the same thing as everyone else does or using AI is not great in APL. APL is really great when the code benefits from having someone who actually knows the subject matter really, really well as the main developer. But also, when you have a bigger team of APLers, at some point, having someone who actually knows a bit about security and has a proper computer science education where you're taught to think about other things than just how does the economics work, but also how do I contain everything securely and make sure that no one can breach into the application in a not so constructive manner. I don't know if I'm answering your question.
00:33:27 [ST]
Yeah, it's definitely getting there. I'm thinking too, not just the system building components and how to get them to use APL with stuff that's readily available in other systems, but even the very workflow. It's years now since I worked on a Dyalog APL production system, and that time, the workflow methods, even an old fogey like me has been trained in, have changed dramatically. So I think last time I was using Dyalog, developing applications on scripts was rather than workspaces was still a relative novelty to the community. And these days in other areas, even before I start thinking about how to tackle a problem, it's I've opened a GitHub repo and initialized something on my local drive. And yeah, what was it I was going to do? Have you kept up with that stuff?
00:34:28 [SK]
I think Adám is probably better suited to answer that than I have, because he's written the code to do it.
00:34:35 [AB]
Yeah, so for some of the more technical things, we do recognize that there's a problem. APL has basically settled in a workflow and a way of dealing with their code half a century ago, and they were very happy with it. And they're still happy with it, and newcomers are startled. And I think we, at least us old timers, including myself, despite my age, are still happy about that. And when we look out there and what other people do, we shake our heads and go like, how can you even program like that? But people like to do that. They like to, for example, just have some script and then a file that contains code, and then you run it and then it falls over and you look at the error message and you go in and edit it and you run it again. Whereas APL is traditionally like something a bit more interactive, an actual conversation, a dialogue with the APL interpreter. But we're not just going to dismiss that. There is the how we store the code. I think we're getting there on that, that we now have what we call link. [06] And that allows basically storing all your code in text files, and we're adding functionality to bootstrap code in various ways straight from text files. But there's also the workflow part of it and the tools part of it. And we are going to work on that. We are working on some of that. There are plans for a proper VS code plugin or like a language server thing that could also be used for other editors. And not just like exists today that just does some syntax coloring and some information about the language, but where you can actually go in and trace through your code and get all the interactivity inside VS code or inside other editors. We are working on things like project management and packages and package distribution and dependency management. Things that APLs have traditionally just shied away from, ignored completely. Actually, Dyalog 19.0, it comes with Tatin, we can leave a link to that Built in as, it's an experimental feature, so it's not quite integrated, but at least it comes with installation. And Tatin is this, basically a package manager, like NPM style thing. And so there's a server online and people can publish packages there and you can download them from inside APL with some user commands. You can declare them in some files and your dependencies and it takes care of tracking and all of that. And it might not be the final way that this will be done, but we are working on things like this to get it, should we say, up to date on how things are working.
00:37:14 [ST]
As the official old guy here, I want to register a thick vein of resentment at the need to use tools like VS code to query variables and step through. It's like, we had that 50 years ago in APL on the tele-terminal. We were there first. Thank you. That was it.
00:37:36 [AB]
You don't have to use these tools. I'm just saying you can. But just an example, sometimes it's actually very nice the way things come out. We can link to this in the show note as well. And I'm maintaining something also called the Jot.times, a name taken from an ancient APL newsletter, but you can find it online as APL.news. And it's very, very simple. And the way the site is set up, there's not really very much APL in it. It's just an HTML file that contains HTML elements, articles, one for each article blog post that's been published. But then it also has an RSS feed. And I don't want to repeat myself. So I have some APL code that generates the RSS feed based on the HTML file. So it goes in, parses the HTML a little bit, and generates the RSS. And traditionally, if I wrote this as an APL program, I might fire up my APL interpreter, load up my workspace, do some stuff, shut everything down. These days, from Windows, I open up the folder. I probably have that open anyway if I'm adding more articles to the HTML file. I right-click, and I choose Run with Dyalog. And that's it. Now I'm ready to push to GitHub. It just does everything right there from outside APL, running the scripts, and I'm done. So I think to the old-timers that might be listening to this, there could be some value in some of the new stuff. And to the young, cool kids, rest assured, we're getting there.
00:39:10 [CH]
Yeah, I think it's been a lot of time, like in J, there's been a lot of approaches to doing standalone programs because the actual J engine is quite small. So you can actually create these kind of things and run J within whatever you're running. And it's just like running a small app because the J engine is a small app. And I guess the advantage J has had is that it is script-based, text-based in its scripts. And I found that quite useful to work with in a variety of different areas that you're not trying to work as much in workspaces. It uses locales to kind of replicate workspaces in a way, but the point is the scripts are all text. And that makes them a bit more flexible with using some of the current tools like GitHub and things like that.
00:39:54 [CH]
And this is entirely random because I had this thought, I think it was probably seven minutes ago now, but when you were talking about going to other languages, or maybe this was Adám's comment about how, I can't remember if it was Stine or Adám, that it's painful looking at what other folks do. I was just in Haskell, was it yesterday or two days ago? And I always forget that Haskell, I don't forget that it has strong typing, but it just like, it escapes my mind that you can't sum like booleans. Like even a lot of languages that are strongly typed, you can implicitly convert booleans to integers. And it drives me nuts. It drives me nuts. Like it's something, like there's so much stuff that when you're in the array languages, you take for granted. And one of those things, or I don't know, maybe, maybe Marshall and folks, like they're always, you know, aware of this. But I forget that in many languages, you can't just, you know, apply a predicate function to some list and end up with booleans and then sum them. And it's just so natural to me that like I go to Haskell, I try it and I get some type error and then I'm, oh, right, I have to convert. And the conversion function is like eight characters. And I have to map that over because I don't have rank polymorphism. So it's like, it's like 11 characters plus a couple of spaces and parentheses in order to apply it. And it's like, that's all for free. And it's not just for free. Like, oh, we made some special unique decision. Like it makes sense. It makes sense for boolean types just be a subset of integers because it's so nice.
00:41:16 [ML]
Yeah. Well, so the comparison just returns, you know, how many of the values on the left are equal to the values on the right. Yeah. So that's zero or one. Yeah. It happens to be that there's only two values that you can possibly compare.
00:41:29 [CH]
So, yeah. And it just, a lot of languages like Python C++, you can do that. You can, you can sum a list of booleans, but a lot of times in code reviews and if you post something to the internet, people will go, ah, that's an implicit conversion to integers. And that's not good code style. Yeah. You know, you know, potato, potato. We can argue whether that's a correct take or not, but it's just so nice that this is like a very small thing of like 10 or 20 things about array languages and APL that, you know, I tend to forget. Are just like so easy. And then you go to what you think is a super simple thing and you go and try and do it in another language. And then there's just so much extra ceremony, even for a language like Haskell, that's actually quite, quite terse and has got a lot of, you know, language facilities and operators for composition and whatnot. That you can usually get something nice, tight, and it just ends up blowing up. And anyways, this is just a little plug for everyone listening. You know, we're talking about tooling and we got away from, you know, the painfulness of other languages. And I don't want to say I'm not hating on other languages. I'm just saying sometimes, sometimes, you know, dip your toe, dip your toe in the array language world. And oh boy, oh boy. It's like, you know, the hot springs up in Iceland. I've never been to Iceland, but I'm sure they're great. I've seen photos. They're like electric blue. It's anyways, Bob, you were going to say something.
00:42:42 [BT]
Yeah. I was just going to say actually along the lines of that is it's the simplicity of the language that I think does appeal and actually makes it an ideal language for at least people starting out with computers. And I think that's actually a very, very smart way to go about expanding the market is what you're suggesting with going for younger people because it's got a relatively low barrier for entry for somebody who hasn't done computers before. But it's funny. It seems historically if you've had a computer science degree, it's almost like it's a barrier to learning the array languages. It isn't actually, but there's enough you have to unlearn to be able to apply them to feel like you're getting anywhere. That the younger that a person starts, the easier it is for them to accommodate those things. Are there other markets you're looking at? I think you're bang on with going for a younger market, but are there other markets that you're looking for? You say you don't want to cannibalize other APLs. So out in the wider world, have you some kind of a campaign plan for Python or something?
00:43:50 [SK]
I don't think we're going to hit like going everybody who's using Python today should be using APL in 10 years because people are using Python for a lot of different reasons. And for some things, Python is the way to go. What we can see historically on our market, like if we look at our customers, the people who use APL successfully in areas where expertise, knowledge, very, very close to the people writing the code, if not inside the people writing the code is definitely where we do great and best. So it's areas where like economics, where there's a lot of law that keeps changing and best practice keep changing. And so you have to be able to change the code quite often to make sure that you are actually complying with the rules that keeps changing because the politicians keep making up their minds. There's changes to the market. Sometimes there's a conservative party, sometimes there's another party and the rules and EU or some other country comes in from outside and says, "Now we should all do something else." So in areas where there's a lot of rule changes all the time, where you have to be even more agile than just changing your scope every couple of years. And when the law changes, you have to be compliant when that happens. You can't just, "Oh, we'll get it in the next cycle." That's probably fine. Yeah, all your calculations have been against the law for a year. That's probably not what you want. So areas where sort of expert knowledge is very, very critical are the places where APL really excels. So we actually want to try and target those markets. So it's people, it's like economics, it's engineers, it's people in sciences like chemistry, physics, all of the physical sciences actually. And that's also why I don't know if anyone saw, but we actually looked for a couple of APL programmers in the beginning of January. And we weren't actually looking for computer science people. We were looking for engineers who had decided that maybe they wanted to do a bit of coding on the side. We actually ended up hiring a computer science person. But he had done math before he went into computer science, so he was sort of the kind of person we were looking for. And we also ended up hiring a psychology student as an APLer. Because we do believe that if we want to find the proper nerds, it has to be someone who's decided to do some sort of degree within one of the, I would say, physical sciences. I don't know if psychology is a physical science. It's probably not.
00:46:43 [BT]
I think they usually think of it as a social science.
00:46:46 [SK]
Yeah, it probably is. We're looking to get into those markets where people are expertise, like subject matter experts is where we're going. Which is also why we're trying to do this APL forge, where we try to see if we can get people within different science fields to write code. Because there's probably already a lot of Python packages that can do sort of specific things within physics and chemistry. And we actually want people to write similar packages, like writing the same packages as exists in Python and Matlab and other programming languages, but writing them in APL. So that in the future it will be easier for people to build on top of those packages. Because some of the feedback we get is of course that we don't have as many packages as Python. So we should have more packages. I think what a lot of people don't realize is that for every glyph in the APL languages, it actually corresponds to a couple of packages in most other languages. So we already do have a lot of packages available that are just hidden within tiny little symbols. And if you don't bother learning about APL, you just look at it and say, "Well, it's all my packages!" Then you won't see that there actually is already packages. But we want to make more packages. And now that we have Tatin, which is the package manager, available, we actually want people to start contributing to that site as well. Which is why you can do everything, not just commercial apps for the competition.
00:48:19 [BT]
Well, I think it's also very smart with the Forge to allow APL within a package. So that you're actually subversively introducing APL within the package and promoting that as well. Which I think is actually very, very smart. Because if you can change that little key part very quickly because you understand the code well, you're accomplishing the same thing that the rest of the package on its own may be very difficult to change.
00:48:47 [AB]
It reminds me a little bit of April,[08] where there's an APL implementation that doesn't try to implement all that extra stuff beyond the core language. It says just leave that to Common Lisp and running inside that. That's probably a good strategy.
00:49:04 [CH]
I was going to ask, have you seen any individuals or even corporations, or I guess it's going to always be an individual, an individual in isolation or an individual inside a corporation that have been starting to, I guess you would consider it in other languages, like open source utility libraries and stuff like that? Or is it early days and you just launched it in the last while and hopefully looking forward to that?
00:49:28 [AB]
I remember one, at least. There was somebody from SimCorp presenting at the last user meeting. They had been needing some tools and they were at SimCorp as I understood it, but published them as a free open source thing to try to give back to the community.
00:49:51 [CH]
There is at least one example. I think that's the thing, once that ball starts rolling, you're going to see like a... When it's early days and people aren't using it, then it's less valuable. But then when the snowball starts rolling and it becomes a package manager that exists in other languages, that is... I mean, there's the whole philosophical argument that always is in the back of my head that Aaron Hsu makes about idioms versus libraries. But a lot of the times, even if the incantation of APL glyphs is shorter than the name of the function, there is still some value to having a library where you can type the name because then I don't have to go and figure out. And then I know Aaron would immediately argue and he's like, "Well, there's value in knowing how to type those, the incantations, because sure, you can know the name of one thing, but if you know how to spell the incantation, then you unlock like 50 things." Which is true. Which is true. But sometimes you're just trying to get something done. And being able to just call some code that some other person wrote and not having to think about it is nice. Is it the better thing long term? Maybe not. But it is one of the nice things about Python is it's like, I need something, I don't want to think about it, and I'm pretty sure I can go find some library that someone else did it for me. And it's like a different kind of programming. You're really just gluing stuff together more than actually programming the logic.
00:51:11 [SK]
I think when I was preparing for this interview, I had a chat with Bob about this thing exactly. And I think I compared, I said that most programming languages like Python is a bit like Lego. [09] Everything is in bricks.
00:51:29 [CH]
Mm-hmm.
00:51:30 [SK]
And APL and other array-based languages are more like Play-Doh. If you know what that is, it's like... Yeah, yeah. So, and if you have a sort of a proper computer science degree, you've spent three to five years building with Lego blocks, right?
00:51:35 [CH]
Yeah.
00:51:43 [SK]
Everything is usually in a package and you are so used to going to your shelves and looking for the package you need and you just take it out and it fits right in and they all put nicely together and you can build the house very quickly because that's what you've done for the past five years, right? And then suddenly someone gives you one of those little cans of Play-Doh and say, "Now go build a house." Yeah. And you're like, "But how do I make the bricks? Why do I want to make bricks?" You can just build the wall and everything. You just make a little ball and hollow it out if that's what you want. You can think out of the box, right? You get to play without the bricks. But if you're so used to thinking in bricks, like playing Minecraft and playing with Lego all your life, suddenly getting a block of Lego will make you very insecure and it's uncomfortable and you don't know how to think in this new way. And I think that's part of that is why we want to catch people before they start playing with Lego. We want to give them the Play-Doh before they get settled into a brick pattern. Don't know if it makes sense.
00:52:59 [CH]
No, I think it makes complete sense. In my head though, I'm thinking that it's kind of... I would take that analogy and say that like every language has, or at least most languages have both the bricks and the Play-Doh. It's just that in a language like Python, you spend most of your time putting bricks together and then you reach for the Play-Doh now and again. But the thing about APL is it doesn't really come with bricks, but the Play-Doh is so much better. It's so much better than the Play-Doh you get in Python. So if I want to build something and I need bricks, I won't go to APL. I'll go to Python. But then when I have to touch the Play-Doh, I'm just like, "Oh my God." In order to reverse this thing or to sort this thing or to do something, list comprehension is just getting the last... All these little kind of Play-Doh-ish things that I need to do, it's painful. It's painful. I want the APL Play-Doh with the bricks. It sounds like this is the start of getting the bricks because that's the best case scenario. Every language has these kind of... Not even I wouldn't say primitives, but they have the fors and the ifs and the language keywords and whatnot. It's just so much more pleasant when you have the APL Play-Doh versus the Play-Doh that comes. Or maybe it's not that every language has Play-Doh. It's APL has Play-Doh and other languages have some, I don't know, more... Yeah, yeah. Some more like super glue or something. And if you touch it, your finger gets burnt. And if you put it in the wrong place, then you got to rip something apart. I don't know what the exact analogy is, but the other languages have something. And it's definitely not as good as the APL Play-Doh.
00:54:36 [BT]
The direction I took the analogy when Stine mentioned it was a sculptor. And Michelangelo or Rodin or any of those sculptors could sculpt in Lego. I mean, you see things like at Legoland that are quite amazing, that they've taken these little bricks and they've made them into something. But they probably wouldn't choose to use that as a medium if they had the choice of using something that's more flexible and can reflect what they really want to do, which is like marble or clay or all the different media that a sculptor would work in. And to me, that was what made more sense is that when you're dealing with the array languages, you're closer to working with materials that are so flexible, the challenge becomes what do I want to do as opposed to what do I have to work with? And that's actually a significant challenge, because what do I want to do bridges on creativity. And in spite of everybody that I've ever worked with saying, "Oh, I want a creative job." If you work in a creative field, you realize your biggest challenge is it's a creative job. You're working very hard all the time because you're not given those things as it's like exploring new territory. It's a wonderful concept if you don't have to do it. But when you actually walk out of the bush and there's no roads, you actually go, "Huh, this is kind of tough." And it doesn't seem to get a lot easier. You just sort of learn to adapt to the new environment. But that's my trail building analogy for that, I guess.
00:56:15 [AB]
I think I can mention another couple that just reminded me of things that have been published. The Carlyle Group, they have a real product, application written in Dyalog APL, closed source. You pay for it, but lots of the libraries that they've created for themselves for using this product, they have published on GitHub. You can just use them for free. But still, I think there's a... It's funny, with the Play-Doh versus Lego analogy, I often have thought about and heard people discuss APL as being Lego because all the pieces fit so well together, as opposed to various packages you have in Python, because Python without extra packages on it, it can't really do much out of the box. And those packages don't fit well together. So being a Python programmer basically means finding all the packages that do the things that you need and then writing the glue code to transform data structures from one library into another so that they can all speak with each other. APL things generally just fit together more like Lego bricks. But then when I was preparing with a presenter from the upcoming APL Seeds the other day, then he was saying, he was describing APL also as like this Play-Doh thing. It's a malleable language. You just make the code do what you want. And if it's not doing exactly what you want, you can just go and tweak it a little bit because you see the whole thing. Everything is transparent. And those libraries that you can get from, say, the Carlyle Group or this thing from SimCorp or even some of the things Dyalog Publishers and the APL team, Kai Yeager's libraries, they tend to be very large. They're not Lego pieces. They are blocks. Or those like, there was a while, especially when Lego was making a lot of these pieces that are very large and can only really use them for one thing, like the whole tip of an airplane or the whole bottom of a car. And maybe there's also room for smaller libraries. And to an extent, like an Apple Cart is like among many other things, with the collection of such libraries that are just one line in APL because they're written compactly and they're not intended to be nice or informative, really. They're just, you want something done and here you go. Here's the ugly little lines that will do it. But maybe things like that could also be packaged. And the tooling out there maybe isn't really geared for it. I know the people in the APL tools group at Dyalog, they always feel awkward about publishing something to GitHub. That's like, okay, you've got to have a license and you have a readme and then maybe it has some wiki and then it has some contributing thing and there's a source code folder and then in there, there's one file with 20 lines of code or something like that, or five lines of code.
00:59:15 [SK]
Just two lines of code.
00:59:16 [AB]
Two lines of code. This is like a lot of baggage you have to lump together with it. And you can just imagine, so you publish it under a permissive license and somebody wants to use it, they're going to include the license for this, for these two lines of code and the license itself is just enormous compared to the code. And to me, it feels kind of wrong. The more compact the code is, the more wrong it feels to have a library for it. But maybe it's fine.
00:59:46 [BT]
Yeah, I guess maybe the analogy might more be not so much the media, like whether you're working with clay or whether you're working with Lego, but maybe it's the tools that you're working with. That if you only had a tool that would allow you to put things together in chunks, you're going to end up with something different than a tool that you can actually sculpt with and shape.
01:00:05 [AB]
It's more fine-grained.
01:00:06 [BT]
And I think the array languages are closer to shaping tools.
01:00:09 [AB]
Well, maybe we do need small APL libraries, left-pad and is-odd, and things like that that are three characters in APL. It also bothers me when a sensible name for something in APL is significantly longer than its implementation. Maybe that's okay if you just want something done.
01:00:32 [CH]
Yeah, I don't know. I still kind of mentioned that earlier, that I think sometimes it's still nice to be able to reach for the thing. If you just don't want to think about it, you know exactly what you want. And in some cases, it is actually quite complicated. I think, was it a live stream? I don't think I made a YouTube video about this, but I was trying to solve some problem, and it involved getting the number of one bits in a binary number and starting with an integer. And so you had to. You know, you can do that in APL with your whatever, 10 inverse decode or encode, or I can never tell. But it's one of those upside-down or right-side-up tacks, and it's not too bad. But in BQN,[10] when I tried to do it, BQN doesn't have the decode and encode. And then I went to BQNCrate and took me a couple shots at searching for it, but I eventually found it, and it was definitely longer than 10 characters. And it's like in cases like that, like this is just an example picking on BQN, but there's definitely examples for APL as well, where you're trying to get the power set of something or whatever, and you do end up with some long incantation. And it is definitely shorter if you had something called power set or something called one bits. And we can argue about the cases where it's less characters than the name of the function, but there are definitely cases where it's more characters. And even then, Aaron would argue you should still have the ability to build up those long expressions, and then it's not a magic incantation. You're just reading APL or reading BQN.
01:02:04 [ML]
Yeah, well, like one strange detail when you're converting to a base is if you have the number 0, what should that convert to? Well, if your intention is to write out the number in base 10 or something, you should have a single 0 there. But actually, the representation-- that has a leading 0, doesn't it? So that's pretty strange. So there's this choice between having the 0 in and getting a readable number out versus not including the 0 and following the rule that it's represented with no leading 0s. So, I mean, this isn't something that's always unambiguously defined.
01:02:42 [CH]
And this gets back to the classic example that comes up is the splitting functions that J has cuts, BQN has groups. I think at one point q had group or Shakti had group, and they removed it. And APL has their partition functions. And the reason for the proliferation of these different glyphs is because there's so many different things that you could do. J tried to cover them all, but really I think Marshall has said this previously on a podcast, is it would just be better to have a library. Like, this shouldn't be in the language if there's this many design choices. Throw it all in a library, and then you can give like 20 different versions of the split, include after, split before, split drop, all these different things. Anyways, we're getting way too down into the technical details. The point being, though, is that I think libraries definitely have utility. And even if it hurts you as an APL developer to not write in the symbols, I think it still provides a bridge for people coming from languages like Python. And maybe they can start off by reaching for the libraries. And over time, they'll realize, "Holy smokes, I'm typing out eight characters here, and this is only four APL glyphs next to each other." And then it becomes like a sort of an art form is when do we reach for something in a library, and when do we just spell it out ourselves.
01:04:04 [ML]
But there are also a lot of libraries that are very much not primitive. Like in science, you might be doing some geography, and you might have a library that gives you topographical information about the shape of the earth. Obviously, that's a terrible primitive because you'd have to have it change as new measurements are made or as Mount Everest gets so much shorter or whatever. So that sort of thing, that's where you really want a library system.
01:04:36 [CH]
Yeah, yeah, yeah. Especially when you get into domain, very domain narrow specific stuff. A lot of Python code and data science, it'll reach for this super, what do they call it, signaling and physics. And they have all these libraries and functions that are very specific to that one thing. And they all have names. Like if you want a signal processing engineer to be able to make sense of code, probably the name stuff is just immediately, even if they were APL experts, just reading the name of the signal processing function, it's like that's the thing they want to read. Anyways, all right, Tatin, go check it out in the show notes. Upload all your code, open source it. I think, yeah, as always, we've blown by the hour mark. So we should probably start to wrap up. Is there any final questions from any of the panelists or any last things that quiz Stine about? Or Stine, if there's any last sort of statements or calls to action? We've mentioned the APL Forge and the APL Challenge. The APL Forge, if I am correct, isn't open at the moment, but it will be at some point later this year, the first edition of it.
01:05:51 [SK]
We are working to make it live as soon as possible, but people can start working on code from now. I think the first deadline will be the 21st of June, right, Adám? So it will be a short run, but after that it will be open all year. So you can basically just, once you've created something, you can submit. And then every year on the 21st of June, we will collect everything that's come in during the year, and we will compare and pick a couple of winners and give out some prizes and invite people to the user meeting. But this year's run will be fairly short, but the website is in the works.
01:06:32 [AB]
I think the idea we had was that, yes, you can submit whenever you create something, but since this hasn't existed before, people might be sitting on some code, and this would be an incentive. You can win a prize. You can go like, "Yeah, maybe this is something I could publish and submit for a very low overhead of cleaning it up a little bit, add a readme and a license or something like that, or not." And that's why we can get away with making it very short, the first one, an invitation to just submit your stuff. You can't lose. Oh, you can. I mean, you don't lose anything. No, it won't cost you anything is what I mean by you can't lose, but you can only win.
01:07:16 [CH]
I was like, "What? You can't lose? It sounded like this was a contest."
01:07:20 [SK]
You already have it lying around. It won't cost you anything. You might get an all-expenses-paid trip.
01:07:26 [BT]
Maybe you might win instead of you can't lose.
01:07:28 [CH]
All right, so you all heard it here first. Take your existing APL projects, if they exist, and submit them to. Well, they can't submit them yet, but once the website's live, we'll announce it here on the podcast, and you can submit that code. And if you don't have an existing project, you've got until... It sounds like roughly the end of June to be confirmed when the website's out. And yeah, as Stine said, if you are looking to go to the Dyalog Conference, which this year is in Denmark, is that correct? Glasgow. Glasgow, that's right. So if you're looking for a trip to Glasgow, all-expenses-paid. All you've got to do is have an awesome Dyalog APL project, submit it
01:08:07 [SK]
And you do have to present it.
01:08:09 [CH]
At the conference, I'm assuming. Yes. Yeah, yeah. I mean, I assume. Well, I guess we did talk about some people not enjoying that kind of thing. But if I had a project that won, I would be happy to show off my. I mean, hopefully it would be a cool project. If I won with a mediocre project, that wouldn't be great. But anyways..
01:08:26 [AB]
Well, Conor, you better get started. Start coding now. You heard about it here. Get the first chance before everybody else.
01:08:33 [ML]
Yeah, you've got a head start.
01:08:34 [CH]
Yeah. I think I have a wedding to go to in September when the conference is. So it would be very hard for me to make it. So maybe what I'll just start doing is I'll start working now, but I'll have a whole year and a year plus to work on the 2025 edition of the APL Forge. And then I'll have a huge running head start because, you know, folks, they're not going to start until the summer, maybe not 2025 New Year. So I'll be working on it for like a year and a half. And then it will be pretty sad when I lose because there's going to be some.. I'm sure some 17-year-old wizard that similar to Camilla that I just--it's impossible to compete with. So it will be...
01:09:15 [SK]
Did an all-nighter over the weekend. Yeah.
01:09:17 [CH]
Yeah, I was studying for my university finals, and I had a few hours in between the physics and the Calc 1. So I just threw a little something-something together. And when I watch that video in the Dyalog 2025 conference, I'll be sad, but happy for the brilliance of whoever takes home the award.
01:09:39 [ST]
Oh, it gets worse than that. It will be university entrance exams.
01:09:45 [CH]
All right. Well, we... this has been a blast, Dina. Thank you for coming on. Before we do the final outro, I'll throw it over to Bob, who will tell us where you can reach us at if you've got comments or questions.
01:09:56 [BT]
You can reach us at contact@araycast.com. We're open for questions. We've had a couple of questions, actually, this week that were actually pretty good, and we've fired them off to the Slack group where people can respond to them. Know that if you send in a question, we're absolutely reading it and thinking about it. We don't always have answers for you, but we thank people who are providing that incentive, actually, because quite often people are very positive of what they're listening to. And even if you're critical, we like those too because it sharpens us up a bit. And one other thing I'd like to add is thanks, again, to our transcribers, Sanjay and Igor, who do a great job of cleaning up transcriptions because, of course, like everybody else, we use the LLMs to do the initial transcription, but, you know, hallucinations and all that stuff, you don't really want that transcript going out to people, and we always collect some really neat little things that it thinks it's heard. But Igor and Sanjay do a great job of making sure that we can be as accurate as possible. And it's a way that a lot of people do access this podcast. So ArrayCast, thanks, Igor and Sanjay. Boy, my mouth is not working today.
01:11:11 [CH]
Yeah, no, I will echo that thanks. And, yeah, I personally can't wait for the day because my other podcasts don't have transcripts, and when it'll be good enough. And also, too, I'm hoping at some point there'll just be a button I can click that'll auto-edit everything, you know, you ship it, and I'm looking forward to all the new TV shows that, what was that, OpenAI Sora that came out? Anyways, different topic for a different day. Thank you once again, Stinea, for coming on. This has been a blast hearing about sort of these new initiatives that are coming for Dyalog APLers. And I will say as a last plug, I've done the challenge, you know, that's been targeted at the youth, at the younger kids. But I will say, you know, compared to the contest of years past where some of the initial problems, they can get tricky to, like, number 7, 8, and 9, and 10. It is very nice to just coast, you know, breeze through. You read the problem, and you're like, "That's a single glyph." And I'm looking around like, "Yeah, I don't think they know that's a single glyph." It felt fantastic walking through those problems. I think sure enough, I was done within, you know, 10 or 20 minutes. And the hardest part is just reading the problem. And so even if you are an experienced APLer, BQNer, Array Languager, it's still fun. It's still fun to go through them. And it's like, you know, playing tee baseball. You know, you get to crack it out of the park versus, you know, the hard jobs--the hard problems that we have to solve at our day job. So, yeah, we'll say once again, thanks for coming on. Good luck over the next, you know, years with Dyalog. Hopefully, we'll be able to get you on at some point in the future for the update from the CEO. And you can, maybe when Dyalog, you know, 20 or 21 or something comes out, we'll have you on again. And, yeah, thanks for taking the time. This has been awesome. Great fun. All right. And with that, we will say, Happy Array Programming.
01:12:54 [All]
Happy Array Programming.