Transcript

Thanks to Rodrigo Girão Serrão for providing the transcript.

00:00:00 [Aaron Hsu]

When I got recommended Scheme, it actually wasn't my first experience with it because when I was perusing the family library, I used to read a 1.5 Lisp manual.

00:00:22 [Conor Hoekstra]

Welcome to another episode of Array Cast. My name is Conor and today we have 3 panelists as per usual and a guest which I am super excited to talk to. First, we'll go around with brief introductions. We'll start with Bob. Then go to Stephen and then go to Rich. Then we're going to have 3 short announcements and then we'll hop into our interview with our guest today.

00:00:43 [Bob Therriault]

I'm Bob Therriault. I'm a J enthusiast and I'm also working on the J Wiki right now and we're making some progress, hopefully by the end of February we'll have a working online way to play around with J. Sort of like Try APL, but it'll be the J version, so that's what we're aiming for by the end of February.

00:01:02 [Stephen Taylor]

I'm Stephen Taylor. I'm in APLer way back and these days I'm Kx librarian.

00:01:08 [Richard Park]

I'm Rich Park, I'm an APL programmer and evangelist, working for Dyalog Ltd.

00:01:13 [CH]

And as mentioned before, my name is Conor. I am not APL or J or k or q or BQN developer. I code in C++ day-to-day professionally, but I love the array paradigm and all the languages associated with it. But yeah, that's all I'll say for now. We've got 3 short announcements. I think we'll go to Rich first. Then Stephen and then Bob, and then we will introduce our guest.

00:01:35 [RP]

First thing then is voting has started for an APL logo that's vendor agnostic; so there's a little bit of history around what I said there. APL, historically, has been developed by lots of separate entities who will have used their own logos to promote it. There hasn't been a cohesive single logo for APL, the language, really before, so some members of the community have decided to lead an effort to rectify that and sort of, just try to decide on a vendor agnostic APL logo and currently there is a vote on if you'd like to have your say in deciding a shortlist for five possible candidate concepts. For a little more context you can watch Conor's video, code_report APL logo video. He describes things a bit, a bit more there, or to actually go and find out how to vote, you can go to APL dot wiki, forward slash APL underscore logo [apl.wiki/apl_logo] but there'll be links in the show notes for all of those things.

00:02:41 [ST]

Dan Baker, the Kx evangelist, is currently canvassing interest for a Vector Dojo. This will be a regular practice area for the q programming language and the model is not a webinar; it's not a classroom, but a martial arts Dojo where students of all levels can practice with each other and participate and share knowledge. If that interests you, if you'd like to learn more about it or just or got some ideas about what you'd like to learn from it, register at community.kx.com and find Dan's announcement and tell him what your interest is.

00:03:24 [BT]

And I've got an admission; when when I work with people I often work with them on a first name basis so the two guys that I've been working with on the wiki are, Will and Jon and of course their last names, I didn't bother to find out how to pronounce. In the last episode I massacred their last names. It's Will Gajate and Jon Hough. I've checked with them. This is accurate and they're also working with Joe Bogner, who I also have checked with. So now I have the pronunciations right, and apologies to these gentlemen.

00:03:53 [CH]

Awesome, all right. We got last name pronunciations and a couple of exciting announcements. Yeah, the logo, definitely go vote if you're interested, that is. I am super excited. Anyone that's watched or follows my YouTube channel knows that I'm a huge programming language logo fan and yeah, it'll be, it'll be nice to no longer have an orange, you know 3D cube box, which I sort of stole from Dyalog's, the company's website that I've been in, sort of, place of not having the logo, using that, and yeah, the vector Dojo also sounds super cool, so I will have to check that out at a later date, but without further ado, today's guest you may have heard his name, probably a plethora of times on this podcast so far. If you've been listening to past episodes, is Aaron Hsu currently works at Dyalog Ltd., so a coworker of Rich one of our three panelists today and also, you know, works with I think we've had on now both Morten and Gitte, which are the CEO and CTO of Dyalog Ltd., so for those that you don't know if this happens to be the first episode of Array Cast that you're listening to, Dyalog Ltd. is the company that puts out Dyalog APL, which is the most popular version of APL these days. And before working there, Aaron was very well known and is still well known for his work on Co-Dfns, which is a GPU-hosted compiler that compiles APL down to run on the GPU, so I believe you spent most of your time at Indiana University getting your PhD working on that. And then I think still continue to work on that at Dyalog APL as well. And I will the only other thing I'll say about Aaron, which hopefully we'll get to hear a little bit about is before becoming a huge APL fan. Aaron spent a lot of time as a fan of another language, Scheme, which I think is super interesting because there's an individual in the C++ community that's super well known Stepanov that had a similar path, spent a decade in love with Scheme, and then sort of found his way to C++ and just, I find it interesting when people that are huge fans of certain languages, before that language there was a language that was entirely different. Scheme is, well, actually, we'll get, we'll get Aaron's thoughts on how different Scheme and APL are. But with all that said, we'll throw it over to you, Aaron. Feel free to you know go back to however far back you want to and give us a brief history of yourself. And we'll go from there.

00:06:22 [AH]

Sure, sure, yeah. And you know, as excited as you may be, I think I'm also pretty excited to be here because I really like this Array Cast and I like what's being done here so it's pretty exciting for me too. The, I guess, I'll try to keep it brief. But, uh, I have I have been programming since I was basically in middle school. So like, I have to go and like chart chart my experiences back there. So I began basically doing, learning programming in a middle or early high school and absolutely fell in love with it. And just like that was my thing then I just kept kept working on that and I used to do it on QBasic with the I don't know if it was like a 46 or one of these old machines and that really formed a lot of my, the the pain that I went through and the fun that I had at that time really formed most, a lot of my early filters about how I judge a language and from there I sort of ,the struggles that I encountered with working with QBasic led me into really appreciating what Scheme was able to offer. So when I, you know, I when I was struggling around with C in C++, uh, you know, as a teen learning trying to figure out how these things work, playing around with Blender doing like 3D stuff. Then I discovered the Scheme stuff on the recommendation of a programming mentor and it like, just blew the doors wide open in a way that I had never seen before. And the the degree of freedom and liberation that I felt in doing that was something that I could still remember to this day. Sitting in the room. Working on this going oh my goodness, this is just, what have I discovered here? You know, this this whole world just fell before me and the walls crumbled and all this other kind of stuff. And then I got pretty good at at Scheme and then basically APL was my, I don't know if you like in the martial arts stories, uh, you know the histories, the mythology of martial arts. Since we're going with the Dojo theme here. And I I also like the martial arts, so I have to bring that in. Uh, there's a point at which, like this experienced martial artist, encounter somebody who's just in who's got something else. And then you they they battle it out and they realize "wait a second like my stuff isn't quite good enough here" like there's I can't just keep going on the path that I'm going and and defeat or or learn or master this this other martial arts master that I was kind of my encounter with APL. 'cause I played with APL and went "Oh my goodness. What's going on here." and like and then I started, you know, that started my trek down APL, and I guess that started in 2010-ish. So it was actually probably separated by a few decades, for each one. A decade in Scheme a decade now, I guess in APL.

00:09:26 [CH]

And so I guess maybe the the obvious question which we actually spent our first episode, I think talking about and we try to do a good job asking all of our first time guests on is is what is it that you know drew you to so you said you sort of there was a war at some point or some battle between Scheme and APL and you were holding the the blade of Scheme and someone else the bow and arrow of APL or I don't know whatever weapon represents APL and..

00:09:51 [AH]

It was probably it was probably more accurate to say I had just uncovered this dusty old tome.

00:09:56 [CH]

OK, so there was no battle. You just you were...

00:09:59 [AH]

Yeah, it it was more than I, the battle was imagined in my head. After uncovering these tomes because it was a little bit like uncovering an archaic... Like like the APL of 2010 is not the APL that we have today.

00:10:13 [CH]

This is very true, very true.

00:10:15 [AH]

And the ecosystem is not the same. And things like that. So it really was more of a uncovering the ring of power or something like this. You know, going into the libraries. Trying to peek into things, it was a lot more like that.

00:10:29 [CH]

So what was it about, and maybe if you want to contrast sort of QBasic versus Scheme. 'cause obviously you know you fell in love with Scheme, so you know what was it about Scheme that spoke to you and then what was it about APL that really made you fall in love with with that language? And then you know, switch from one love to another love, basically.

00:10:47 [AH]

Yeah, so when I learned a computer science as a kid, I basically started with sorting algorithms and so what we did is we went through each of the sorting algorithms and we had to design flowcharts to implement those sorting algorithms and then implement the flowcharts inside of QBasic. Now as a young kid, I had no concept of a lot of the ideas that would helped me do that in QBasic, right? And so when I got to the radix sort and I tried to use a type of recursion inside a QBasic, well I hit this tiny, tiny stack limit on the system because I didn't understand how QBasic's different a subroutine, calling mechanisms work and all that, and so I just hit a wall. I couldn't make any progress on doing a lot of these algorithms that I wanted to do, or using a lot of these programming techniques. And when I got recommended Scheme, it actually wasn't my first experience with it, because when I was perusing the family library, I used to read a 1.5 Lisp manual. Uhm, I had no idea what it was saying, but I just looked at it and was reading it because I loved what I was reading and I was I i didn't really know what I was reading. I was just reading. And so there I visually had already been sort of attuned, I guess, to what I was seeing but you know I can remember pulling out that little slim white Lisp 1.5 manual or it looked white to me was probably more like an aged cream at that point. Uh, but the uh, when I when I downloaded MIT Scheme and started playing around with it, I eventually switched over to Chez Scheme, but I remember going alright, here's the test, can I get this radix sort thing working in a way that I am like, feel good about the code? And if at first it was again, a public well I had no idea what I was doing, but I I had gotten onto some IRC channels at that point and I remember Taylor Campbell actually was very helpful during this time and I played around with it and then it clicked like the data flow in a functional style through the procedure is flowing through the system and that forming your code and then I wrote it and I looked at it was like "Oh my goodness I don't have to worry about all sorts of stuff.". Like it was the system removed the limitations for me, I had I was no longer... I all I had to do, I felt like all I had to do was think about my problem. And then express it in this particularly elegant, universal way, and that held on for a really long time, because I think it was Abdul Aziz Ghuloum who told me, uh, this first that that Scheme was like the the language of least restriction. And and I still think that kind of holds true today is that you can, there are very few languages that let you do as many cool things from a computer science standpoint as you can get away with in Scheme, right? You can go really low level, but you can also go really high level in Scheme and accomplish just about anything from a semantic standpoint, right? And you can build macros on top of macros to build whatever language you want, and that flexibility was extremely powerful. And so I I used it to build like a hygienic literate programming system, the Chez Scheme modules were really cool. That, and of course at this time i was in one of the great seats of power of Scheme right at Indiana University, with some of the at this time some of the what I consider some of the greatest minds in Scheme there. So of course I had a lot of advantage in terms of what I could do there and what I had access to in terms of experience to play around with the Scheme language but at the time I was also really interested in exploring parallel systems. And the parallel systems uh, we had talked about all sorts of parallelism in the Scheme community and Kent Dybvig who I consider one of my early mentors, he had written a dissertation on trying to automate parallelism inside a Scheme and the difficulties around that. And other people at IU at this time were really working on, work-stealing schedulers for task, threading, and I had read this book, i think I've still got it right over there on concurrent programming. It's one of the classic formal texts on concurrent programming and using an axiomatic semantics to reason about concurrency and that book highlights the difficulty of the formal logic around actually talking about task, parallels, and these other kinds of parallels. And at that time alternatives were getting a little steam that people were exploring, like these dataflow models and all around this point I had started needing to explore things outside of Scheme and I was playing around with them but Scheme was still my base. And then I really, after, x number of years in the language, i started saying well what, what else can I learn? What am I going to add here that's going to be a little value add? And we had always scared our introductory students in some of our, what do you call labs? Some of our early CS labs with a line of APL, the Game of Life saying don't be afraid of Scheme, we could be having you program this. And of course, you know, it actually kind of worked, because I saw this and like "Wait, you could really do that to us?". And so I had known about APL, but only from that, "Oh, it's the crazy symbols language", and then I started saying, "Oh well, I guess it's I really don't know what this language is. I don't have an idea of it. I don't have a sense of it. I have a lot of opinions, I have a lot of you know, basically judgments that are made without enough evidence.". And so I started going in and saying, well, what is APL actually? And I started reading about it and then I started playing with it and I downloaded APLX and i started trying to solve some problems with it and unlike with Scheme, where there was this wall that I had to kind of play with, there was a bit of a wall with APL, but not so much 'cause I was a lot more experienced by this point and when I started playing with it, it was like, again, these walls falling away. There's there was a certain sort of, I guess it's the, i'm trying, there's not really, uh an easy universal analogy to it, but but it was liberating. In some of the same sense, except it was totally different than the sense I got when I was playing with Scheme right? When I was working with Scheme i was building something. And when I was using APL, I was writing a description of a solution. Uhm, it was a very different experience. One was like architecture and another was like fiction writing or something like this, it there was a there was a total paradigm shift in terms of how I approached problems. And I and of course with every other paradigm that I had received, I could just re implement it in Scheme and get all the same values. So I thought, OK, great, I'm going to take all of this and bring it into Scheme and it didn't work like I I I tried and every single time from various angles that I tried to implement APL in Scheme, it lost its magic, it was no longer the APL that was giving me the experience that I wanted, and it wasn't any better than what my Scheme solutions were. Adding the APL for me into Scheme didn't net me the kinds of benefits that I expected, having already experienced APL in the native form, and I was really confused by that because that had never happened to me before. That's sort of the unpacking of the tome right is I went in there like "wait, what's going on here?" and and like in some sense, the martial arts were just a little incompatible. Ah, and I didn't understand why they were I didn't understand why APL was the way it was and then it took me a long time to unpack that, and eventually I discovered that it was, it was because of syntax. It was because Scheme is so driven by semantics and a freedom around semantics and APL in the large way constrains those semantics. But by doing so gives you massive freedom in terms of the expressive power at a syntactic level and and in a different dimension and I couldn't get that by trying to mimic the semantics of APL inside of Scheme. The only way I could get it is if I basically reimplemented the syntactic APL in Scheme, and I would have had just another APL interpreter at that point, and that's when when things really like just started taking off for me.

00:19:36 [CH]

Alright, I have there's so much I could ask and say, uh.

00:19:40 [AH]

Yeah, sorry that was a bit of a rant.

00:19:42 [CH]

Actually what I'll pause 'cause I i'm pretty sure our other panelists have a couple questions. I know, I think I've seen a couple people jotting notes, so I'll throw it to Stephen and then we'll we'll circle back. But yeah, this is this is awesome.

00:19:52 [ST]

I can't, I can't resist this one. I hadn't realized how deeply you were into Scheme in your background, so Whitney has often described k as a blend of Lisp and APL. I'm wondering what was your experience in encountering k and q.

00:20:09 [AH]

I immediately saw how Whitney leveraged his background in Lisp. UM, I think anybody who's done a lot of Lisps will see huge amounts of underlying similarities in how Whitney adjusted these semantics of APL to have more of a Lisp flavor, well, like sort of keeping the, so it was almost like Whitney took the opposite direction. I was trying to take APL and bring it to Scheme, and I think Whitney had a lot more success precisely because he, in its essence, took the semantics of Scheme in some level, or took some of the aspects of the semantics of Scheme and merged them over to the APL side, instead of going the other direction. And I think his net worth would demonstrate that he was significantly more successful at that than I was at doing, going the other direction, and I think the way in which he chose to simplify it, I think it was, it was really clever. Now, whether I, like, personally agree with that direction moving forward, that's a different question, but in terms of the connection, the Lisp/k connection, I think there's it's it's pretty straight, ot's pretty straightforward if you know both languages or or are familiar with both domains, there's a lot of overlap there.

00:21:33 [CH]

And just for the listener that once again this could be the first episode. Whitney refers to Arthur Whitney, who's the creator of all the k dialects, which k4 eventually became q and is now working on shakti. And you could say that he was a protégé of of Ken Iverson, the creator of APL.

00:21:51 [BT]

And he was also a midwife for for J, 'cause he was the one who wrote the original, I think the original macro that that Roger then worked from and and extended into J so.

00:22:03 [CH]

Yeah, what is that? What he called it's called the J inca-

00:22:07 [RP]

incunabulum.

00:22:07 [CH]

Incunabulum. Yeah I have no idea what that word is, but we will link it and it's it's actually 'cause I had spent some time on the J source when I first looked at it I was like "Oh my goodness, that's that's crazy". But then after having spent some time on the J source, it's actually not as impenetrable as you would think like it looks just as like at a glance, it's just like a single page of text and everything formatted oddly. But I think you can even you can see like you know J iota or something. And if you're familiar with what iota does like it's, it's just a loop that's it's not as impenetrable, it's just a bunch of macros. And yeah, it's worth it more than just a glance, if you're curious for sure, yeah, and I would, I will try and find somewhere too. There's a document online I can't remember if it lived on kparc, which was a website sort of dedicated to k at one point, but it actually had, it was like notes from Arthur Whitney of like APL or k versus Lisp, and sort of it was just like a short list of notes that you know. He was saying, you know, in APL we have this and in Lisp we have this or back and forth or k and it was a short document but definitely interesting read.

00:23:14 [AH]

And I, I guess it makes sense to qualify this as well as when I was doing my PhD. My minor was in HCI with a focus on education. So a lot of my study class work that was not heavy CS theory was all in UX design theory and user interactions and how you teach people things, and you know a lot of this psychology around that tech interaction, and so a lot of my perspective is deeply colored by the concept of programming language as a human computer interface, if you will.

00:23:49 [CH]

Yeah, maybe we should talk a little bit more 'cause I think you have some super interesting thoughts on that, but like. How you said it's? It took you a while to grok what it is about APL and a part of that is, is the it's the syntax. It's the notation, and I've also spent like a ton of time trying to figure out... So does the does the q model where they were defined things, even if they're short words, is that just as expressive as having you know single Unicode symbols, or even the the the two character ASCII digraphs in J and? Yeah, there's always something about the single Unicode symbols that like it's the closest thing or analogy that I've come up with is like imagine trying to turn an algebraic expression of, you know, ( 1 + 2 times parentheses or whatever a bunch of stuff, and then you replaced the plus and the minus and the division with, in the best case you know ADD for addition, SUB for subtraction, but like or in the worst case you know, the actual full word. And I was even just looking at some Python code the other day that was basically you can import from an operator module three character, three letter symbols for the operations, add and sub, and it took me like a good minute to realize that "sub" stood for subtraction and and and. So just like there's something so expressive about that little mathematical algebraic expression that, like replacing the the binary uhm, you know operators plus minus with words, it, there's there's just some level of obfuscation that I think is introduced there and that's it's very hard to communicate what it's like. If you can read APL, at least for me, it's hard to communicate like the power of reading something so terse, which is not like not terse, in a bad way. Terse is a concise way of expressing, you know, a lot of information. Anyways, interested to get your thoughts on on sort of that aspect. Yeah, the notation as a as a tool of thought, if you will.

00:25:48 [AH]

Yeah, and for me I always go back to if we're programming for computers, then it doesn't really matter on some what if all we're, our job is is to is to tell a computer what to do, then the like, that's a really different ball game, but we're not really doing that. We're really trying to communicate to people, whether that's to our future selves, or whether like the point of a programming language, is to enhance our ability to communicate to ourselves and to other people an idea. Uhm and it's otherwise we'll just be using assembly at some level, right? It's it's our ability to... The programming languages are a tool for us, not a tool for us to like drive the computer necessarily. It's really, all programming languages I think have as an ideal, some way of empowering us to be able to think about more complex issues around computation and when you get to that, then you have to think well when it comes to human form language, when we think about what are the innovations and what are the general trends that you see over the history of humanity? In where they're able to leverage their minds the best, using external linguistic tools, and I think the trend you see is always towards this natural evolution of very verbose language, which represents a lack of understanding around a concept towards more and more refined, terse language. Until you get eventually some form of expressive notation which encodes that knowledge in a very direct, immediate way that is more easy for the human mind to manipulate. And like this, the best example is mathematics, but you can find this in a lot of different domains and these even if you wanted to look at things like bullet journaling right as a human journaling practice that a lot of people take up. Part of the benefits of the bullet journaling system is its notational conveniences around the metadata associated with a given task inside of a, a journal, and the same thing with mathematics is the brilliance of algebra is the the plate openness of it. It's the manipulative ability that uhm, that capacity to rapidly explore an idea and make it easier to think about how you would explore it. So when you look at an algebraic expression, it takes training to see how you manipulate it, but once you can see that you start to be able to do things in your mind and on pen and paper or even on a computer that you wouldn't be able to easily do or easily perceive without that notation, and I think that if we ignore the current very small window of history we have around computer science, you'll see, I think most people will agree that most human linguistic practices tend towards something around that nature. Even in scientific communities, right? When we have lots of scientific papers, there's usually a diffusion of terminology. A spread of idea. 'cause they all build up these infrastructures and architectures. And then there's this grand like unification that occurs where the terms get simplified. Everything gets, people start recognizing that these are actually the same thing and over time that gets refined into a tight meatball of concepts and vocabulary and syntax and ways of thinking about it and frameworks, and then it has another diffusion. And uhm, that that I think grant some of the strongest evidence in my mind towards a terse direct notation as the the thing we should be aiming for eventually in a programming language, and I think APL is moving towards that in a or, you know, it's for me the the APL symbols represent that mode of thinking better than the other programming languages, yes.

00:29:42 [BT]

When you mentioned that the notation I guess one of the advantages that APL has, 'cause you're when you look at mathematical notation there's a certain amount of it that's evolved and as a result you have all these arcane symbols and used in a variety of different ways. And sometimes when you have disciplines hitting each other, you have a real confusion as to what they actually mean, because the same configuration in one area will make mean something in a different area and I'm guessing one of the advantages APL has is it started from a point at which a lot can be expressed consistently across the language.

00:30:16 [AH]

Absolutely, yeah, I think consistency is really important, but I mean, as a Schemer, I would say that, right?

00:30:25 [CH]

Yeah, there's something about the regularness, too, of APL that, like it was it was sort of similar to when when I traveled abroad and I learned Chinese, I started to realize some of the ridiculous things about the English language that like I'd never realized until I learned, there's a bunch of them and I'm I'm not going to turn this into a you know, why English sucks and Chinese is awesome, but like probably the one of the best examples is like in Chinese when you when you say 1 cat or 2 cats, like in English we have we prepend or whatever postpend whatever the word is an "S" to the end of the word when you have a plural. But like as soon as you've said "2", you know that there's multiple cats. Why are we modifying the noun? And in Chinese it's they don't do it, you just you've got you know your your object and then you just say "1 cat", "2 cat" you don't you don't need to have this extra stuff that's unnecessary to communicate. And like I didn't realize that in a lot of languages you know they have plurals of, you know there's the singular and then the plural. Chinese doesn't mess around with that, and like it was the first language I learned, like I learned French in high school as a as a kid, 'cause I'm in Canada, so it's one of the languages you have to learn. And and I was like "Oh yeah, that that makes sense". What are we doing over here like that? And so the same sort of thing with with APL. So is that you know when when I discovered the min and the max glyphs, you know. I was like well, why? Why did we stop in mathematics at like you know, plus minus multiplication and division? Do we? Why do we give binary infix operators to a set of common binary operations but why do we stop it at min and max? And then those there's still prefix spelled out like and then you see it in APL and you're like. Of course, like why don't we just, why don't we just tell the math people so we can stop? You know it just. It seems arbitrary that a certain set of you know binary operations are infix, some of them are prefix. Then you go to exponents and we're doing superscript. Like it just. It's just like what are we doing here? And and in APL, it's it's way, way, way more regular.

00:32:30 [AH]

Yeah, it's a it's more regular the but like there's there's another aspect of that which I think is what part of the institutional momentum that happens with mathematics is that part of the value of something like this is not just in the regularity 'cause you've got Scheme that has regular syntax as well. It's in the predictability of the vocab? Uh, so I think it's the value of the shared core. So when you're communicating with other people, it helps if you all don't have to define all of your terms in advance. Everybody has a shared context that like, so that's what makes like some of it to use the Chinese analogy, some of some of the early Chinese classics are so elegantly phrased, partly because they omit so much data because they assume that they're working towards a literati that a scholarly class at the time who would have already been expected to have memorized and understood a whole set of literature from which you can then pull. And because everybody knows that literature, the way in which you can write is very different, you can play games. You can play these linguistic games that you can't in other languages that have to be much more verbose in setting the stage.

00:33:45 [CH]

Go ahead, Bob.

00:33:46 [BT]

So, you know when you when you use the line of APL to threaten students, is that what's going on there? Is it that when they see, is that opaque line? They don't have that background, it's just like oh this is, or when Conor was talking about looking at the source and going? Well, do you think it's impenetrable? Then you stare at it for a while and you gradually can see the patterns. Yeah, is that what's happened with APL? When we're talking about trying to teach people APL? They're going "this is impenetrable", but it's because we were packing so much on the front end. Is that what's happening?

00:34:22 [AH]

We're showing them so much at the front end. I think so, so it's the, well, we're ranging over a lot of topics, but it's human psychology, right? You've got like the the uhm, when you're looking at, uh, reaching an outcome, right? Your brain has to make a planning assessment to say, how can I get there. And it makes a heuristic judgment of is this accessible or not? Are there roadblocks in the way? Are these roadblocks too insurmountable? And the more danger and risk it sees in that, the higher your stress response is at the beginning, right? The more fear and resistance and avoidance you encounter if you don't know what or how you would approach to give them space so the more foreign the thing is, the more fear you're going to have around it. And so when you present something like Scheme it looks scary too, because it's full of all these parentheses. It doesn't quite look at what you think of programming language to look like, but then when you compare it against APL and suddenly you see this one line of crazy alien symbols or whatever it is, you really trigger an early student sense of like "Oh no". But ironically, by doing that then you step back and now Scheme is less scary and so that relative experience changes things. Now whether that was a really good thing for us to be doing in our labs for the computer science department, that's perhaps up for debate like that might not have been the best approach. But it was certainly a fun approach, and it I think it it wasn't necessarily so detrimental so to us to ruin the students. But I do think that that happens a lot, right? And this is part of the I guess the third leg of this triangle is you've got your, you've got your regular syntax that's consistent. You've got your common vocabulary. But you also have experience in using it, and that's like if people, this is something people often don't quote from, Iverson's Turing Award lecture is that he says, you know, we believe this tool is extremely useful, despite the fact that you need to become a little bit of an expert at working with it. You need to get experience. You have to actually become confident in using it to make make it valuable and that's the truth for a lot of powerful tools is you do need to learn what you're doing with that system in order to really feel comfortable with it and in exchange for that sort of upfront learning curve, you get a lot on the tail end, but you have to accept that you might have to embrace slightly different approaches right now, like touch typing for instance. That's also a similar skill.

00:36:57 [CH]

So, I have a couple questions but we wanted them sort of stacks well on top of what Bob just asked and and I thought about this earlier that you know it's it's very funny or ironic, you know. Choose your word that you know at one point you were scaring students as a kind of joke and then and basically due to your curiosity like you're a curious person that's just trying to put tools in their tool belt or different blades and their you know you know Dojo or whatever.

00:37:24 [AH]

Seeking the hidden knowledge.

00:37:26 [CH]

Yeah, so like it's basically your curiosity that took you to a point where you know, especially pre tryapl.org and you had to go download APLX. You're a very curious person, so you overcame sort of the scariness of this language or the alienness, or you know what we've been describing what. Is, like, the success of this kind of language dependent on people being curious? Or is there a better story? Because, you know, we all here know of the the sort of the pushback that you know people see these glyphs and they say, oh, you two orders of magnitude change the way you think. Notation is a tool of thought. But really like it was also my curiosity that like I had heard about this really cool language on a couple podcasts and finally did a deep dive and was like holy smokes but is it is it just that we're going to collect curious people over time? Or is there a better story for, you know, encouraging folks that like this, it's worth your time to look into.

00:38:26 [AH]

Uhm, so I can i can say yes and no. Uhm, but I, uh, so, given that I think part of my mission is sort of to change the perspectives and the costs around what it is to experience APL, I think when I started doing APL you could I, I guess, in modern terms, it was for the memes. If you would write like I was basically a meme at some point, right? And and when I went from oh, I'm playing around with this, this crazy archaic language to "hey, this has some stuff in it" in my academic circles, it was you're absolutely like crazy, you're you are you have lost your rocker. I we're going to hear that you're in the next asylum somewhere kind of situation at that time. Like the IT was just not even on people radars. And then I I've still got the very embarrassing, very poorly presented video on YouTube about me expressing Intel concurrent collection semantics model in APL on a whiteboard at an IEPL longs talk uh, in the early 20 tens I think and it was a dumpster fire. Uh, it was an absolute dumpster fire because I went in there and you know, I didn't lack for enthusiasm, but you could tell everybody face was just like

00:39:58 [CH]

"Is this?

00:39:59 [AH]

What are we seeing here? Is this is this good? For real? What what is he doing? Does he expect us to like? I mean has he just started having a seizure?" Like there was this collect of incredulity that was so authentically incredulous, right? It wasn't just like, oh, you use Haskell you're you're so edgy kind of thing. No, it was it was like this can't be real kind of thing and but over time we've progressed from that right? So it starts with oh, there's a crazy mountain man out there. And then the crazy mountain man comes and actually builds a monastery and then suddenly, like people go to the monastery and say, hey, this is pretty cool. And then like people start doing things right and you, and at that point and like so one of my one of the things that I've tried to do, and I think a lot of the the people who have pushed APL for like this ArrayCast and things like that is that uh, we we try to make unpack what it is? Explicate it a little better. Make it a little bit more accessible, and make that like bring it more into the range of this is something that's not way off on the mountains. Bring it sort of into the towns and villages if you will, and make it accessible to people who can start to see the value and at that point it suddenly now, if you're curious, now the curious people start to get into something like this and they start playing around with it and they start looking at it and in a lot of ways I think we're on the boundary between curious and and inherent attraction so or inherent value proposition. So I think we still are at a point where, unfortunately, a lot of the most value for a lot of people is coming from curiosity, and the satisfaction of that desire to learn. And being curious, and that's part of what draws a lot of people in and so a lot of people still can't necessarily see or believe like this is something I need to use because I can see that there's value here and I don't care if it's weird or strange or something like that. I want it right, we're not we're I don't think we're quite at that point where we can just sort of say we've pretty well established that message, but we are at a point where it's they it has respect I think it has a very strong degree of respect now that it didn't have 10 years ago and it has the ability to provide something to the curious people and the people who are really early adopters in a sense. And then I think as more and more people get into this from the curiosity standpoint, eventually I think what you'll hit is a place where people go oh, this is something I want to know if I want to get a little extra advantage or something like this. I want to know this and then that shifts from curiosity to I'm picking this to extract value for myself or for my company or to get a competitive edge and then you know ideally the stage from there, you become the de facto standard and then everybody has to try to find some new competitive advantage 'cause everybody is using it. But I you know that's if ever that's down the road, uhm, I think we have to start with the curious people. And then move into other places as we refine our ability to express ourselves.

00:43:09 [CH]

Bob?

00:43:09 [BT]

Do you think that's part of the problem? It traditionally has had in academia is that you're talking about the fact that you sort of you almost have to become an expert to to start to appreciate the language. Somebody who's not an expert who is a professor or has a stature in the community, they may not want to go back to that beginners mindset to learn what they need to learn to be able to become expert at it is that one of the things that holds it back in academia.

00:43:40 [AH]

I'm going to say no. In industry, absolutely. Absolutely, in industry I think that's that's the case, but I don't think that's why, at least at IU this is the case. We had a lot of curious people at IU and we have a really strong PLI department and that uses a lot of languages and so having this new cool crazy like i mean we have a language... What's his name? He was, shoot, all right. I'll think of his name, but his his whole dissertation was on a programming language designed to be entirely reversible so that all computation could go in both directions so that it could be hopefully modeling the chips for various types of reversible computing architectures that were being designed. Things like quantum stuff, right so? There was no end of people willing to go with really off the wall, computational models to play around with... Roshan, Roshan James. That's his name, so you should look up his dissertation on his reversible computing language. Uhm and so the curiosity was there. The problem is, where is your focus on value in terms of where do you extract your scholarly publications? Where do you extract how do you publish? How do you do something new? Where's the novelty and it's novelty that I think was the hard thing to see in APL. Because everybody had seen APL as the language that had already been unpacked and explored in the 80s. And the reality is that a lot of computer scientists right now are just rediscovering what was in the 70s and the 80s. It's this cycle because so much knowledge was lost in a sense, and so they're rediscovering all of these ideas and techniques and tools and having to figure out what works and what doesn't work and why, and the APL language to these academics is it's like oh yeah, we did that back then and it was sort of like a close case, a close book. They, but they didn't get the message at the beginning of what was truly novel about the language. I think that was the the failure is that the research that had been done at the time didn't really address why the language was worth continuing doing research on, especially after the additional innovations in the computer science theory. Because APL, from a semantic standpoint, is true as close to trivial as you can get inside of a computer science program for a real practical programming language. It's probably one of the simplest that you can find what comes what is really unique about it is what happens when you work with that and you actually apply it in what you see out of it. And if your focus has been on all sorts of semantics you've been trained that syntax doesn't matter, which is a lot of how people grow up thinking in the computer science research communities. Is that syntax really? It matters, but it's so much a matter of taste that when you're publishing and you care about novelty, you just ignore it, you know you use the standard syntax and you go do your novel semantics work, and I think that, you know, there are small tweaks here and there that people recognize the syntax syntactic innovations, but you don't publish on syntactic innovations. You slip a little syntactic innovation in your paper that people will start using, and then you work on your semantics and there's not a lot of fruit to be gained by trying to alter APL semantics too much in my opinion. There, there's certainly some there's definitely some some fruit there, but not in the way that the computer scientists would need to care about it in academia. So they were basically just missing where's that novelty coming from? And and it took a lot of work actually with my my committee to convince them that that what was happening here was something that was worthwhile.

00:47:36 [CH]

Yeah, there's. There's a talk that I'll we'll get in the show notes that I watched recently. Because I think it really captures what you're saying nicely and it was a Devoxx talk talking about Java and they were referencing a quote from Rich Hickey, or maybe it was Stu Holloway. But someone from Clojure land about essence versus ceremony and how a lot of like in the example that they were showing was how to get started with you know Java and like it's like OK, well just like let's do a little Hello World world program and it's you know classically there's you know public static you know argv and all this noise before you even get to like the system dot out dot print line and all that stuff. And compared to some other language that's you know newer where you can just go print parentheses you know hello World and it just this the barrier to entry is so much lower and you know that that is what when when I was watching that talk I was just like Oh my God yes like that's that's so much of what it is in APL and just array languages is it's just there's no ceremony like it's, it's just you want to add up a list of numbers you know, plus reduce. You're done. Like it's it's the the the closest to just like pure essence with zero ceremony whatsoever that I've come across with different programming languages that is...

00:48:59 [AH]

I would say it's the it's the closest you can get to a true, the closest I've seen to a true general purpose removal of ceremony. So there are lots of languages that do a really good job of removing ceremony in one very narrow niche and one very specific domain with a specific set of vocabularies around a specific problem. Uhm, but if but in terms of having a single language that removes the need for ceremony across so many domains with the same set of tools, the same vocabulary, the same syntax, the same architectures, I don't think APL is has been beat in that department.

00:49:36 [CH]

Do you have an example off the top of your head what's like a a narrow one with yeah, that's not general purpose.

00:49:42 [AH]

SQL is pretty good.

00:49:44 [CH]

OK, yeah, yeah, that's.

00:49:45 [AH]

Yeah, SQL is one of the classics in terms of the classic success stories of a language that removes massive amounts of ceremony around a particular programming paradigm that people want to interact with. And it's been very successful in it and it achieves what it's trying to do very well, especially if you can stick your problem into pure SQL. But of course, what happens is what happens when your problem doesn't really quite match your RDBMS relational model that you need, and suddenly now you're having to inject direct functions into your postgres SQL database or you need to start thinking about the ordering and indexing operations that are going on and you start adding extra things that you have to now expand it on the language and and do things so it's a very narrow, limited focus, which is why the DSL works so well. It just so happens that APL found this like DSL that that is way more universal than people I think originally gave it credit for.

00:50:42 [CH]

Yeah, no, there's well, this is great. I was just about to mention that so at the end of one of your I think it's a FP talks you or maybe even it was like basically the whole CVP talk, you did sort of just like a live like throw me a problem and we'll solve it because that's that's one of the criticisms is that you know people.

00:50:57 [AH]

Oh yeah, yeah, yeah.

00:51:01 [CH]

Think of APL, they think of math, and they say, oh, it's just matrix operations. Yeah, and the point being is that like no, you can do it's it yes it does very well add matrix kinds of things that is what it was designed for, but it's also very general purpose, and so, uh, you know a bunch of people, sort of from the crowd you, you weren't like you, you didn't you weren't given a list of these problems beforehand, and then you cherry picked a few, literally just people from the crowd would throw at some problem, and then you'd live code it like right there, so that's we'll we'll put a link to that as well.

00:51:31 [AH]

That was in Functional Conf i think a couple of years ago.

00:51:34 [CH]

You you referred to a talk earlier, so we should we should mention you're a prolific speaker in that you've got i don't know how many, at least on your APL wiki page i think there's roughly 20 plus talks across different conferences. I'm not sure if you've got even more, but are there 'cause you were talking even earlier about sort of something that's sounded similar to sort of the idioms versus libraries, and you've got a talk that talks about, sort of there's a list of, I think, 8 things that you're classically sort of taught in sort of, you know, the C++ Java land, and you have to change the way you think about sort of reaching for libraries or modules when you have APL, so I'm not sure if you want to talk a little bit about that, but even before you do that, like of all the talks you know, we don't want to overwhelm our listener and say, yeah, I just go listen to all 30 of them. Do you have like a you know couple favorite that you would you would plug if if you and I guess it's the a lot of them talk about different things so I'm not sure if if it's like you know if you're looking for just an intro, this is the best talk or if you're looking for what I think personally is my favorite talk.

00:52:37 [AH]

Ooh, ah I don't i think it's not helpful to point out my favorites because I'm weird and the things that I like don't necessarily correlate like I've had to accept that I'm a weirdo and a contrarian, and things like that. That's how I make my my living I guess. So I guess the ones that appear to be the things that people say are the most interesting or helpful or most thought provoking anything the ones I've got the feedback on would be you can go ahead and read the dissertation. That's one of the if you want, uh, the sort of single document that lays out a cohesive step-by-step argument in a non traditional APL domain. For APL you can read the dissertation. Uhm, a that's a a GPU hosted compiler for the data parallel language or a data parallel compiler for the GPU language or something like this. I can't even remember my own, there we go, oK, hang on. Uh, "data parallel compiler hosted on the GPU", there you go.

00:53:40 [CH]

Oh, that's a whole book there.

00:53:42 [AH]

And the the the other talk was, does APL need a type system and the design anti patterns and patterns design patterns for APL? I think there are two versions of that talk. One is the Dyalog talk and in that talk I added some discussion of APL style, so I spent some more time thinking talking about the different styles and ways in which people write APL code at the end that's available both as a sway presentation and as a Dyalog video, and then at functional conf gave a different version of that talk where I emphasized more of the usability questions. So I included more research citations from early research into programming language usability papers that I think mostly and well know, mostly it's the Turing Tarpit paper, but some of these other guys that do, did some early research and a lot of that came out of the 80s because people I think reached a point where they didn't have the technology to do the research much further in it and and it wasn't getting the results they wanted. But yeah, so so those two talks, I think one or the other, depending on which one you're more interested in i think they overlap mostly in what they say, so one or the other would be fine, and those three tend to be the ones that I hear people discussing the most, more or less.

00:55:11 [CH]

OK yeah, it's good. We'll put we'll put links to all of them, but yeah, and I can highly recommend, I can't remember at what point I discovered your talks and Co-Dfns, when I was falling down the APL rabbit hole, but it was very cool 'cause a lot of the resources are there at specifically at some Dyalog webinar conference but then at some point I stumbled across I was like oh look, there is actually someone at a non APL specific conference talking about APL. This is this is awesome. And yeah, a lot of the times your talk challenge it's trying to get people interested, sort of from different angles. It's like I thought that the idea of you know, just throw me a problem and like I have the confidence that I can solve whatever problem like it, text parsing, blah blah, blah like you know, let's just like you don't, you think APL is for this, but like that's such a, I'd never seen anyone like I've seen live coded talks before, which are always very impressive. I've never seen a live coded, but like I don't know what I'm gonna live code. You just tell me like that is that is very very ambitious and I just thought it was such a great like regardless of the language, I think that that's such a such a cool idea.

00:56:19 [AH]

Well, I mean so so to be fair here, maybe a magician should never reveal his secrets. But but

00:56:28 [CH]

oh here we go. It was all staged.

00:56:30 [AH]

Well no, no no so I like one of the metaphors I use when I talk about my my work is that maybe I'm supposed to be like a wandering apostle of APL, right? And if you think about what an apostle does, they provide a bunch of principles and a bunch of things that get people to think about what they're doing and how they're doing it. But you also have to sort of perform miracles, right? That's part of being the apostle is you're supposed to kind of perform miracles? Or you know, the other analogy is a magician, right? If when you've got something that people don't understand, you have to find ways of unpacking it, and one of the ways you can do that is very academic, but it doesn't explain why you care to learn this thing. But if you start with the beauty of whatever you're doing and you start with this beautiful thing that people can admire, I think you're better off. And so so you know, that's always been my perspective is I want people to appreciate the experience that they can have and and what you can gain from working with this, and so that that idea of the live coding and things like that has always been a part of allowing people to see underneath the curtains a little bit because they get to see how i'm approaching a problem and and I and my thought process that goes on behind it. So I think it's educational. But also it's fun, right? It's just fun to play around with this stuff and they get to see things that they might not have already seen. It's a good way to target stuff but i have been doing programming enough and I've done enough different problems that I have a lot of confidence in my ability to think about programming problems and so part of it is that I'm I kind of know my audience and so I know that my audience is going to give me a certain class or type of problem. Right, it's just like it's going to happen and so so within that space I'm relatively confident within those domains that I know people are going to give me. So it's not absolutely any problem anywhere that I have to deal

00:58:32 [RP]

it's more like a cold reading.

00:58:32 [AH]

With it's it's much more yeah like a cold reading or you know your in essence, the the range of problems that I'm solving uh, it could go really wild, but there's a there's a curve around where I'm likely to get those problems, so the risk there is relatively low, and even if I did get a wild wild problem that would be really fun because you know the end result is really about showing how you can play around with these things, not necessarily proving that you know, not necessarily me coming up with an optimal solution right away and and so showing how APL allows me to think and work i've actually found has been more illuminating to people than just showing these perfectly crafted APL solutions. And so when people sit down with me and see me working with on my compiler, for instance. They go if they have worked on a compiler in some other domain they go. How can you do all of this stuff just here? Because I have so much facility to just play with any aspect of my compiler at any moment and I can just explore and I can walk around data in ways that I can't in other languages. And I can try so many different things when we talk about the like agile and the value of incremental iteration, the a Scheme in the REPL, like one of the grand things that people discovered is the value of the REPL in these languages, because it lets you keep trying things and then one of the things you know that they discover they think they got this huge advantage in the REPL. And that's really true. But then when they go into like an APL session, this is a like a REPL on steroids where, because the language allows me to just play so quickly and type so quickly, it's the difference between somebody who's hunt and pecking on their keyboard and somebody who knows how to touch type. The difference is night and day, because now I can just start experimenting and iterating on that REPL so much faster and see things in ways that are like so, my the when I'm looking at trees in Co-Dfns I can break those trees down into so many diff directions, dimensions, things I can see links I can ask like SQL type queries over in my tree, i can visualize the tree you know, upwards, downwards, sideways. I can go into the tree, I can subdivide it and I can do it all in like one line of code each time. Then I can just play with that stuff and to do that you just, you just have to say no. I can't do that. I have to solve or debug my code or figure something else out to write my code in another language. I can't play that way as easily in another language, and being able to live code, i think at a presentation is a part of showing that and demonstrating that because you you can't manufacture that experience very easily. You have to do it live. I think you have to do it when you're specifically unprepared.

01:01:31 [CH]

Yeah, the word the word play, will throw it to you Stephen in a second, is I feel like it comes up again and again like I've described being in the REPL is feeling like you're in like the APL you know RIDE or IDE that comes with Dyalog APL, it's like being in a playground. It's like the ability like in my head initially when I'm solving some problem, I'll think, Oh yeah, that I could go four different directions. I could go for like a filtering compress approach. I could go for this this and I know that like in the next 10 or 15 minutes I can explore those all super quickly, whereas like if I'm going to, that just doesn't happen in C++ like my day-to-day language like the the the includes and the main and the function and oh and now I gotta go figure out why this compilation thing... Yeah, it's just completely different. But yeah, Stephen will throw it to you.

01:02:18 [ST]

I think it was Paul Graham who said that a programming language is should be like a pencil. It's writing and thinking in. You published a blog post a few years ago on in which you were using a calligraphy pen if I remember correctly, and uh and wrote your code in what I think you told me, you spent Spencerian roundhand. So I wonder if you could relate that to what you're saying about the process of thinking and creativity.

01:02:49 [AH]

Well, I mean. So when it comes to connecting penmanship to, to coding right is I've always felt like pen and paper is powerful, right? And I think a lot of people in my generation have rediscovered the power of pen and paper. I would I would say, as a sort of pseudo luddite, in some sense I never lost it, but but the there's there's an aspect of joy like it goes this happiness but there's also this there's a deep seated joy of working with your tools and uhm, there's a there's i think cultivating an environment in which you're you like what you're doing you like what you're working with, and you can sense the beauty in it. I think that's a bit of an inspiring thing, and sometimes when you're working on things you just, you just need a little bit of that inspiration. You need it that space and and when I, calligraphy, a lot of people will describe calligraphy as like sort of meditative. And so oftentimes I'll use a good like you know I've got my i've got my little Spencerian Flex nib pen that I'll use, or you know I've got lately i've been working on a uh, type of italic, so I've got this italic nib you know I've got these different tools that let me experience a different type of handwriting, and when I work on that and I pick just the right kind of paper that has just the kind of feedback you create a sensory experience for yourself. That sort of helps get you in the in the zone right? And so I'm when I'm sitting there writing and doing these things it and just sketching out this it lets me put it, gets me into this free headspace. It's almost like you can do a type of Zen meditation, if you will, while you're coding and so it's a way of bringing, it's a focus aid to bring your mind into this settled space while you're thinking about the code, and that, I think, frees up a lot of options lets you just sort of feel comfortable with the code you if I think you you, you memorize more of the code that you're doing. And I actually, this is something I haven't talked about a lot, but in any formal talk, yet I haven't been able to formalize it fully. But in my opinion. We pay way too much attention on externalized knowledge and not enough attention on the value of really, really deep knowledge. And the where and you can see this for example in some articles that people talk about the ineffectiveness of group brainstorming like people think, group group collaboration and brainstorming is the key to lots of innovation. But if you actually do the research and look at what these big companies did like Google, I think did a research on this in some other places. They found that in a lot of cases this wasn't the case that it helped occasionally for certain things, but a lot of times the big innovations the the things that delivered the most value came from one individual sitting down and playing with an idea and then getting feedback from other people and then playing with that idea. And I think the part or reason for that was that the power of the individual comes in this really hyper efficient problem solving space, which is your internal mind and the moment you have to externalize that thinking you increase the communication overheads for processing and solving problems exponentially. And if instead you can internalize all of that deep knowledge into your brain in a way that it can work on solving the problems and making connections as you work with it, you've got this space that is really rich and I think people have underestimated the value of the individual within the programming sphere, partly because of some of the the Engelbart effect from from Douglas Engelbart and his his theories about this group cognition type stuff in computing, and and I think that one of the aspects of writing on a pen and paper is the way it helps you internalize knowledge and that internalized knowledge is the thing that allows you to then solve problems in ways that you wouldn't if you were just Googling and trying to find the right library and just working off of external feedback instead of your internal mind working over it.

01:06:55 [ST]

Is aesthetics a big components in all this?

01:06:58 [AH]

Aesthetic, Oh yeah, that's that's the light that goes back to the beauty thing, right? Is you know when you're creating something that's beautiful it's a totally different thing than when you feel like you're creating something ugly.

01:07:09 [ST]

I feel like this is a this is a conversation which we're still like not supposed to have both on is talking about beauty and so on, except we've we've found a way around it by pronouncing it “cool”. So in programmer in in conversations with devs, you so often hear, oh, that's cool. That's really you should look at this. It's cool that we're paying tribute so well we can't call it beauty or aesthetics. And it's, and I feel that while we use the term cool all over the place, we don't acknowledge the importance of it in finding out really good algorithms and beautiful ways of doing things.

01:07:47 [AH]

Well, so OK, OK you've you've hit you've hit a point at which, if any listeners are highly sensitive, please tune out now because I'm going to get into something that extends beyond the world of computing, which is that I think our society in general in a lot of ways has worked very, very hard to undermine the concept of view in a lot of ways, and so they've instead exchanged beauty for a variety of experience or something else. And and I think that that has a detriment on our ability to have ways of gaining deep and rich intuitive understandings of our world and our spaces. And so, for instance art, one of the things that art can do is leverage beauty to bring out contrast and reveal some deep seated human truth that people have a hard time seeing. And I think beauty can do that in ways that other approaches just can't, they fail because there are some things that we don't understand yet, and even in our like very logical, very crisp computing world, there's so much we don't understand about ideas, and there's so much about the spaces in which we work that we don't understand how ideas are connected or anything. But when we apply beauty to that, we can set ourselves up for more serendipitous discovery than if we strip the beauty from a lot of what we do so I I actually think that beauty has a fundamental value proposition in delivering usefulness from a purely pragmatic standpoint as well as from a psychological, emotional standpoint of making your programmers better and and more ready to solve more difficult problems. But, you know, so I i think it's absolutely essential, but I think we are so used to disregarding Beauty as a value, and when we do talk about things being beautiful, we've we've taken to calling so many things beautiful. We've used the wrong word for it, right? Because we've associated that nothing is worth anything if it's not utterly beautiful, well, that's not really quite true, right? Beauty is an ideal that we look to as a guy that helps provide an anchor and a star, but but that doesn't mean we now have to call everything beautiful so that we all feel worth something or something like this. And I think we've we've we've diluted the definition of beauty a lot in in in general use, as well as dismissing it in specialist use or very specific uses, and that the combination of those two things, I think, uhm, undermines our ability to leverage beauty intuitively, because I think we're trained against it. And from in a lot of our social environments and societies, and especially within the computing world, if you're in a professional environment, I think there's still a little bit of that in the hobbyist environments and things like that where you know you can still say oh this is beautiful and if you go in a very math like the mathematician, still I think are willing to leverage beauty in some sense because their their success depends on it in a sense, right? The elegance is almost the definition of the mathematicians space and when you've got the computer scientists in academia, they're fairly adjacent to mathematics in terms of what they're doing, I think a lot of that crosses over and they start to be able to have this deep seated aesthetic appreciation for elegance in its in the sense of beauty and and that sort of thing.

01:11:19 [ST]

There is a piece of dialogue from Stephen Donaldson's 1981 fantasy The Chronicles of Thomas Covenant that always nails that for me. And central character Covenants got projected into some other other world where he's wandering around and encounter in conversation with a with a character there called Moran, and he remarks that in this other world he has a direct apprehension of the health, the vitality of the beauty of the environment. You can see it directly. You can see when the landscape of an ecology is healthy and he wonders at that and and more in terms to him it says so you don't have that in your world? What do you have? And Covenant says, well, we have something called we call picturesque.

01:12:02 [AH]

Yeah, yeah.

01:12:04 [ST]

Moran turns directly to him, his face ashen, his expression horrified, and he says "How do you live?".

01:12:14 [AH]

I do think there's an aspect of that right, i think a lot of people cut into their creativity, partly because they they undermine that aspect of their life or or they're living in an environment that pushes against that for them. And you know, I don't know that I have a solution for that. But I think in terms of how I choose to approach programming, aesthetics has a huge, huge place to play.

01:12:39 [CH]

Yeah, I maybe I should make a compilation of a couple of clips. My podcast with Bryce we can link them there and honestly not the best podcast, we did a live coding in BQN which is like the the next gen APL by Marshall Lochbaum and it's terrible 'cause like I'm not even doing a good job explaining what we're doing like I'm just coding and then Bryce is like what's that? What's that? And like I'm we're not describing anything. But like at a couple different points I just i'm like holy smokes does this? Does that work? And then I'm just like Oh my goodness, this is so beautiful and even Bryce is like that is quite beautiful like so there's these clips of like playing around and it's it's so true like I was coding a Python script the other day and I needed to just print out the lengths of two different lists, and so you're applying a unary operation length to each list and then printing it out. And like in array language with combinators that's just this y combinator you're you're catenating after applying tally to each one and going from like this, sort of beautiful what I think is beautiful and then going to a language that doesn't support that where now I have to I have to spell with six different parentheses and you know, Len paren insert lists, you know, print and then another print like it's it's very hard like So what Stephen you're explaining. You know in this direct connection to the vitality of the land is in, it's like, oh, it's so wonderful. And then you come back to another language and it's like, Oh well I can't express myself the way I want to express myself in in that beautiful world. Uh, it is yeah it just rings very true to me that it's not the end of the world, but just like constantly while I'm programming in other languages i'm like, well, this is in my head, i'm expressing it the beautiful way. But then I type out the less the less beautiful thing and just go oh well, I guess there's no other way to do this here.

01:14:27 [AH]

Yeah, I think I think joy has a big component of it right? As I, like, for me programming has always been intimately connected with a sense of joy in what I'm doing, regardless of what I'm programming, and I've met a lot of people for which that's not the case, and it goes back to that whole picture. I sometimes have asked "How do you live?". Right? Is how, how how can you embrace the pain that comes with programming? Because it is a difficult art do how do you take that? And then without the joy that comes with it? How do you endure? And obviously they have their own reasons for doing it, but there have been times when I have advised certain students in our CS program to really, really have a bit of a think in a reflection over their reasons for being at the program because they were miserable trying to do this coding stuff and they were there because they thought that's what they needed to do to get them that that's just a recipe for a life of misery. And so you know, I think that that that's no way to get into computer science.

01:15:38 [CH]

Yeah, my father always used to say, although it's you know it's a famous quote but you know, find something you love and you never have to work a day in your life and yeah, I'm just lucky that what I loved happens to be in a very booming industry right now. Although APL, not i wouldn't call that booming, but some would say that my

01:15:57 [AH]

on the on a a gentle upward trend

01:16:00 [CH]

yeah, my bang for my buck on my YouTube videos it's like every once in a while I'll make something that's more clickbaity and what people want. And it's like 100,000 views and then all my APL videos are, like you know, 500/1000. But it's no. That's where my that's what makes me happy. It's not about what my subscribers want. But yeah, we are so we've gone past a little bit the hour mark. There's a couple things I'll I'll say to round up the episode but before we do that, are there any last sort of short questions or things we want to mention before we before we wrap things up. I'm seeing sort of head shakes alright, so the things that I'll mention come that we haven't gotten to so you will if you have the time and we'll definitely have you back at some point in the future. I feel you know, like what I said to Henry Rich is. We had 1000 questions and we got to like four of them so we got 996 to go. At one point you mentioned trees and I actually had totally forgotten this, but a friend of mine João had asked us at Array Cast to do an episode on sort of graphs in the array paradigm and I said oh, we're actually having Aaron on. Probably won't have a ton of time to talk about it, but maybe on a future episode we could dedicate, if not the whole episode, or at least a part of it because I know that you've done a ton of work with sort of trees and graphs and that like it seems like something that doesn't fit well with sort of an array or matrix model. But when you take a second look, it's actually it works fantastically. And I think even you told me that or I had heard in one of your talks that an originally a programming language, or maybe it was the second one automated data processing ken Iverson actually dedicates like a huge portion of that book to talking about graph algorithms or tree algorithms. And at one point even some of the Unicode symbols or glyphs, I guess they weren't Unicode symbols at the time, the glyphs were specifically had, like, you know, behavior that dealt with graph or tree algorithms or something. I'm not sure if you want to briefly want to...

01:17:55 [AH]

Yeah, that's the original APL book. Yeah, the original APL book has a section on trees and has some discussion on ways of thinking about them. But yeah, the tree work I we should definitely talk about that at some point, but it's it is the one thing that that the academic community who was willing to recognize in a publication as worth as worth novelty consideration so you know it's it's sort of, it's sort of, i guess you could say my my contribution to the academic space at the moment is is my work with trees.

01:18:30 [CH]

Yeah, so we'll definitely have to have you back on and and we could also do a whole episode too, we didn't really talk about Co-Dfns much in detail, but maybe we'll do a deep dive on folks that want to hear about that and last but not least, we currently I'm not sure if we ever will have a merch shop for Array Cast, but instead of Array Cast, well instead or what, while we don't have a merge shop, Aaron actually and I was i was reminded this when I went to your website recently. You do have a mercy shop that is APL relevant, so I'm not sure if you want to plug or talk about we've got i think two or three different sort of t-shirts and I'm not sure if that you can order other things other than t-shirts, but I'm sure some of our listeners...

01:19:14 [AH]

Mostly just t-shirts at the moment. Yeah yeah, I like come if you go to sacrideo.us there's a link to the shop, but the the people kept joking about my research saying, oh it'll fit on a t-shirt. And I was like yes it will. And so I made one. And so I made sure to, you know go around and there the t-shirts have actually made some public appearances and some things. I think one guy wore it to what looked like something like a EDM rave kind of thing or something that he was DJ-ing for some kind of electronic music thing that he had up there, and so there's this. The symbols on there I thought it the aesthetic was quite good. And then I'm just like I there's some little I like riffing on the idea of people like to put phrases on their shirts and and make things so I just translate the phrases into APL and make them little idioms and and it turns out that they the translations work pretty well, so I've got one or two there and then I have my when you want to make a true religious statement, and where your I guess your your cross or your pentagram right on your chest, then there's the quad ⎕IO ← 0. Sure, it's bad, you know makes make sure make sure everybody knows where you stand on that I I maybe should also include like a ⎕ML ← 1 or ⎕ML ← 2 kind of thing.

01:20:40 [CH]

Well, what's ⎕ML?

01:20:42 [AH]

Migration level, it's the way that you can convert Dyalog to run in either the traditional Dyalog APL Sharp symbol set or the APL2 symbol interpretation which switches a couple of symbols around.

01:20:57 [CH]

So it's like it's a flavor on either side of the APL2 versus a Sharp APL, sort of.

01:21:04 [AH]

Yeah, yeah.

01:21:05 [CH]

OK well so listener if you're if you've been thinking to yourself "What am I even doing with my life?" not wearing APL symbols on my t-shirt we now have we now have you hooked up, not with a merch shop that we've put together but with one of our guests. So bob, any, any last things you want to say?

01:21:26 [BT]

Oh, just the usual get in touch with us contact at arraycast dot com and we love to hear from people. In fact, well, we wanted to have Aaron on for an awful long time, but there have certainly been a few suggestions that we bring Aaron on through that and and now those people and be satisfied that we did listen and we were able to do it and and so everybody benefited from that and then also show notes have been mentioned a lot. We really do work to put the show notes because a lot of what we're talking about can be so deep and I guess require a little bit of background. The show notes really help you if you go in and you're not understanding something, go into the show notes because a lot of the background information is there, but as we were talking about, a number of times, times up front, this can be quite daunting, and if you do a little bit of background, actually none of this is that difficult, but it initially appears quite impenetrable at times. But look at the show notes, see if they help you. If they don't, if you already know this, hey, just have fun. That's that's my message. Have fun.

01:22:35 [AH]

Yeah, definitely have fun.

01:22:36 [CH]

Everyone that was asking for Aaron can now instead of stop emailing they can start emailing. Have Aaron back. But yeah, thanks so much for taking your time to come on to Array Cast with us Aaron, it's been a blast and I always love chatting with you, whether it's at, you know, some conference and gather town or on some zoom call for a, I think it was, you know, the New York J user group one time. It's always always a blast chatting and and...

01:23:05 [AH]

It's tons of fun.

[bell rings in background]

01:23:03 [CH]

Well, that's that's the telltale sign that we got to wrap things up. Right, it's the pizza. It's the pizza you ordered Rich.

01:23:15 [AH]

Well, it's it's been a ton of fun being on here and I think I think this is it's I i'd be happy to come back. It's it's always it's always a blast, so.

01:23:22 [CH]

Awesome, all right with that, then, we will say happy array programming.

01:23:25 [All]

Happy array programming.