Transcript

00:00:00 [GC]

When I was a guest, a couple of weeks ago, these guys started brainstorming about "why don't we do a live podcast from the Dyalog user meeting" and I didn't have any objections to that. So, here we are, and I’ll give the word to Conor who will explain to you what's going to happen and how. Take it away.

00:00:30 [CH]

Welcome to another episode of Array Cast. My name is Conor and today we have an extremely special episode because we are recording live from the Dyalog APL 2021 conference, which, for those of you listening to this, was a conference that just happened a week ago, if you're listening to it when this gets released; but if you're listening to this in two years, then it took place two years ago. So the way this is going to work is I am going to briefly ask our, four panelists, I believe, to introduce themselves. They'll give a brief introduction. And then, we're going to start off with a tiny recap, just talking about our thoughts on the past two days, because I believe we are sort of the last formal session of this conference, and then we will also have standing by many of the speakers and presenters from this conference. So, we will be monitoring the questions, so you can ask questions of the speakers, you can ask questions of the panelists, and yeah, we are going to sort of moderate – I'll be moderating, choosing some of those questions. I think I'm not... I can't actually tell if the chat is open, but feel free to open up the chat as well and I can monitor that. If funny things are said, we can, we can bring that up as well, but first, we will start with our brief introduction, so I will ask Bob to go first. Then we'll go to Adam. Then we'll go to Richard and then we'll go to Rodrigo and then we'll circle back to me and go from there.

00:01:53 [BT]

Thanks Conor. My name is Bob Theriault. I am an interloper. I'm a J enthusiast, but actually, my first array language was APL, back in university days. And so, as a result, it's kind of neat to be involved in all of this, and watching where the array languages go. I found this conference really neat and just an aside, because he's not here but he's a regular on the on the panel, Stephen Taylor as well participates. He wasn't available today, he has another engagement, but he's the librarian from Kx Systems. So he's another interloper. So I guess I get to represent interlopers.

00:02:31 [AB]

I'm Adám Brudzewsky. I'm a full time APL programmer at Dyalog.

00:02:35 [RP]

Hi, I'm Rich Park. I'm an APL evangelist and I teach APL sometimes, and I'm mostly working to raise awareness of APL and array languages outside of the APL space.

00:02:48 [RGS]

And my name is Rodrigo Girão Serrão, and I make Richard, Richard's words my own. So apart from the name, everything is more or less the same: APL evangelist and trying to build an, an array-oriented community.

00:03:02 [CH]

And as mentioned before, my name is Conor. If you just were listening or watching Richard's presentation on sort of the Dyalog APL media update, you'll know that I am a professional C++ developer, so although I am a huge array language/APL/BQN/J enthusiast, I spend a lot of my free time, you know, coding little problems in array languages; day-to-day I develop in C++. I'm also on the C++ ISO committee, so I help evolve and standardize that language. And I work day-to-day at a company called NVIDIA, so hopefully in the future there might be some, I don't know, GPU enabled APL or array-like language, but that'll, that'll be for a later date. And sort of, yeah, Bob talked to this: I guess we should briefly introduce, all of our regular listeners will know what this podcast is about but, for those of you that might be watching this live, and this is the first episode you're hearing of Array Cast... So, although we're at an APL conference, the Array Cast Podcast, we cover all array languages or array-adjacent languages. So as mentioned before J, k, q, APL, BQN, uhm, and I think in the future there's gonna, we're gonna have people on speaking about even sort of less well-known, like, there's an array language coming out called ShapeRank, or it's already out and being developed... So yeah, if you're interested in APL, or maybe not APL, or other languages, we, we talk about a plethora of array languages. So, at this point, I guess maybe we can do a circuit again, uhm, and then people can say whatever they want to about the last two days. Maybe they had a favorite talk, a favorite moment or something they're just looking forward to, based on what they've seen over the last couple days. And, from there, we will start taking a look at some of the questions and I'll also run through the list of names that I can see on my screen... Oh, actually, I should ask, can everybody see all of the participants? In that case, then I don't actually – so Adám's nodding his head, so I don't. If you have a question for someone that is on screen and visible, feel free to just ask that question in the Q&A and and mention their name, and we will ask that question live to them. So, I guess let's go back to Bob and then we'll go to Adam and Richard and Rodrigo and yeah, feel free to say briefly what you thought about the last two days of the Dyalog APL 2021 conference.

00:05:20 [BT]

Well, one of the things I want to say was that people who haven't tried to organize an online conference probably don't appreciate how difficult this is to do, and how bringing everybody like, even this screen here, and I include Josh David this morning apparently moved to a local library so he could get Internet connection to do his presentation because Internet went out between New Jersey and Chicago! So, this is actually remarkable, that you can do these kinds of things, and that you can do these things online. And if you do go back and listen to Gitte's present- or episode with Array, she talks about how important it is to get people together. And I completely agree with that, but still appreciate what's being done to do this online, and that's my impression of this conference: it's been amazing and thank you for putting it together.

00:06:08 [AB]

Well, uhm. I'll say definitely some exciting things that have been presented here and we've talked about in previous episodes of the Array Cast, how APL traditionally has had problems with communicating with the world outside, uhm, dealing with interfaces to other things and I think several of the talks here are really showing that this is finally coming together. Finally, getting tooling that makes it possible to actually employ APL in real life work as well, not just as a toy.

00:06:40 [RP]

You probably qualify that with "for people coming to APL for the first time now", because obviously there's a large contingent of existing users who do use APL in real life for their work, but I think they've, I don't know, figured out their way of doing it, but uhm... Definitely the combination, from my perspective, of APL talking to the outside world; that, that kind of story improving, as well as some of the new materials – like Steven Krueger's talk was really entertaining about his book, and I've also read that – and it's, you know, really excellent in terms of onboarding people who aren't familiar, and they're going to want to see that story of APL talking to all their other favorite technologies as well. So yeah, I think that's really exciting as well.

00:07:27 [RGS]

Well, on my end, uhm, I'm just going to ditto everything you say, Richard. So far, my...

00:07:34 [RP]

That's why we hired you, Rodrigo!

00:07:39 [RGS]

Yeah, I hope you hired me for, for other reasons, for reasons other than just mimicking you, but Brian’s presentation, and especially the the analogy with the treehouse was the thing I appreciated the most because, on a personal level, I do love building everything from scratch, but sadly, as it turns out, in the real world it's often more practical to use the tools that others have already built before us, and so I'm very looking forward to something like Tatin being adopted and easily usable by, by the mere mortals like I am.

00:08:14 [RP]

I'm gonna say that it's almost like a dream, right? Because you know, I have been around for three years, but a lot of talk from some of the prospect new and prospective APL user spaces has been like "oh where's the package manager for APL?", or "where do I go get the packages?" and wow, it's coming. That's quite cool.

00:08:34 [CH]

And yeah, before I give my little recap, I will say, encourage people now, so after this we'll start the Q&A period. So currently there is an empty queue. So yeah, if you if you do have questions you want to ask any of the people or the panelists on screen, now is the time to enter them. Otherwise this is just going to become a regular live from Dyalog APL 2021 and we're just going to talk about whatever we want. Uhm, so full disclosure: I have not seen all of the talks because I was both working and participating in this conference. But of the talks that I did see, I definitely am excited to play around with the scripting / Link stuff so, uhm, for those of you that don't know, I wrote my first line of APL in 2019 over like a weekend, but was too busy to really dive into it and didn't really dive into it until December of 2019, and then, since then I've sort of actively been learning it, but for a long time I I didn't know about The APL orchard, or any of the communities. So I just had the IDE editor and my experience with it, or I used tryapl.org for the first bit, It was just writing expressions, like simple expressions, just using the REPL to build up solutions to small things, but at a certain point, you progress past the point of just wanting to write single liners or to go back to, you know, a function that you've written and edited, and I didn't know how to do that, and I think I showed up or discovered the British APL webinar and then Adám quickly was like, oh, let's just do like a Skype and I'll show you and he showed me how you could like hit, shift enter or there was some shortcut that popped up a little window where you could edit things and I was like, "Oh my God, this is this is exactly what I've been needing!". But then, once you know how to do that, at some point you, especially if you're coming from a language like Python, you are used to just writing a small script and then, you know, hitting save and then interpreting it or executing it. And I've actually not really gotten to the point where I've done that with APL. Usually, if I'm using the RIDE editor or the IDE editor, I am just building up functions that call other functions and then the top level function that I call `main` or something, I'm just going to, you know, keep on running. So you might have like the equivalent of a script, but it's in the form of several functions that are stored in a workspace, which just coming from like Python land or whatever language you develop in, sort of feels weird. And if you've ever developed in a language like Clojure, which is a really popular Lisp, for however popular Lisps can be these days, uhm, they've got like a really nice interactive thing where you have sort of a script you can execute the whole file or on a single line you can just hit like shift enter and that'll execute that single line. So it sort of combines like the REPL slash, you know, executing a whole file, and it seems like based on the presentations like, I haven't played around with any of it, that we're going to get that sort of experience, like the REPL, is what we currently have, and now we're getting the ability to do scripting stuff. And on top of that, uhm, I had heard of a Py'n'APL from, from Rodrigo before, but not seen it in action and I have no idea what it is like to actually write APL in the midst of a Python file and VS Code, I assume you have to have the keyboard setup in order to do that, but it's intriguing: the idea of, sort of, there's this quote from different communities of functional programming Where, you know, people say "oh, unless if you have monads in Haskell, how do you do IO" and their response is, well, [in] functional programming, really what you aim for is a functional core and an imperative shell, which is exactly what Rodrigo was showing. So I'm not sure if that's the way, you know, people want to develop in the future, but I think it's a really neat exercise, especially if, you know, schools are teaching Python, a bridge potentially to get them to do that: it's just like "oh here's a little APL dot eval function and you can write some APL code!", so a ton of cool things that I have to look into and a ton of talks I have to catch up. Uhm, and with that I'll, well, first I'll let, if any of the panelists want to respond to what I said? Because that was just an incoherent ramble. Adám, you want to go ahead?

00:12:31 [AB]

Yeah, I I I totally get how people coming from other programming languages have some expectations as to how things work. I don't want to write a script and then execute it and then maybe get some error trace. And then you go and look for your problem to fix it. And I, we are going that direction of allowing those kind of that kind of mode of of work. But I think that somebody sticking to that are losing out. It's kind of like using APL and then writing for loops. You need to be able to get out of the box a bit and try the interactive programming. I think that's a large part of it. APL is really, and all APL-type languages, really languages, much like human languages are, we communicate back and forth with the computer and if it's just this one way communication: you run something; you get a bunch of errors; you try to fix it; you run it again. You're losing out on the ability to to modify things as they're running and experiment in the interactive session and seeing what works and then sticking that into your program and continuing it. So I would encourage people to go and explore the interactive aspect as well.

00:13:34 [CH]

Yeah, I guess I what I would say to that is that I I 100% agree like my preferred way to develop is like in a REPL, it's it's like oh I need to solve some problem and I'm going to start with OK, I I need to do 5 things and I'm going to slowly build up an expression that is a composition of those five things. That is my preferred way to do that, but at a certain point, when you start writing an application, you have to, you know, write more than just a small expression and then the question is, is like what is the interactive version of that and it is becoming blurred even between like, interpreted and compiled languages. So like in C++ Topia where where I live, there are websites, the most popular one is called Compiler Explorer, that actively recompiles while you are coding, and so like as soon as you stop typing for like even a second, it'll start compiling and it'll interactively like show you the output as you are sort of coding so, technically, you don't, like, people don't think of compiled languages as languages with fast feedback. But with like, you know, incremental compilation and these new kinds of websites it's blurring the line between interactive and what people wouldn't consider interactive. So I guess, and that's why I sort of mentioned the Clojure thing, is like, they have built in the REPL experience into like file development so you can build up all your functions and just build them up one at a time and execute them one at a time and then at the end of the day just hook them all up. But yeah, to say the least, all of this stuff sounds very exciting and I'm looking forward to checking it out.

00:15:06 [BT]

And and on top of the interactivity, which is sort of endemic to the array languages, they all seem to work very well that way, one of the things I was really impressed with was early on an earlier episode, there have been issues raised about how hard it is to move between workspaces or import workspaces in APL, and then a lot of that seems to be being addressed and with different things like the GitHub and the Git repositories and moving things back and forth and then taking it to the next level, Py'n'APL where you're actually interacting with another language and you uh, packages from another language. I think that represents one of the places that some people who are using array languages found quite challenging. Especially, I think more in APL where you're looking more with with the binary the workspaces than the the script based languages like J. But that is, I think that's a real step in the right direction. It opens up to a much wider group in the community who would be using languages, would be interesting, I think, as you mentioned, with an engine that might be array-based and then using a wrapper around that, that might provide you user interface. Things like that that, you know. I think those things will come with the array languages, but they may not be as developed because just of the size of the communities of some of these procedural languages.

00:16:31 [CH]

Richard, go ahead.

00:16:32 [RP]

I think it's a, it could be a double-edged sword actually, because I remember one of the winners of a previous APL problem solving competition I think was Alve Björk, I remember him saying during his presentation that year he was like, he said, I found it really refreshing that in contrast to the more popular languages, when you go to solve a problem in APL, the first thing you do is not Google, "how do I solve this in APL?", and you actually, you know, partially, you're forced to think about it yourself, although maybe some people might prefer to say you're encouraged to think through the solution and code it yourself. And as you know, as much as we want this community to grow and the ability to find your answers quickly to improve in a lot of ways, Part of me does wonder whether we'll we'll lose that little part of it. For people coming to the language for the first time, when one day, you can Google, just search up how, how do I solve XYZ and someone just copying and blindly copying and pasting code snippets but.

00:17:40 [BT]

Well, I guess I can reply on behalf of J. We're almost Google proof. So that's the secret message. Make it almost impossible to Google.

00:17:51 [CH]

Yeah, Googling for J is first you Google J, then you Google J language, then you Google J software after you learn that J language isn't enough and then you just go to the J software website and search there, and even then search isn't great, but Rodrigo, you were gonna say something.

00:18:06 [RGS]

Yeah I want to reply to actually to Richard's comments, and I think it goes back to something that Conor mentions a lot in his videos. It's that APL is much more inviting to experiment with, so if I have an idea in Python, I have to type much more code to check if it makes any sense, when in APL, just with three primitives I can check if my idea makes any sense and then I can build from there. So even if even if APL isn't Google proof like J, or actually, this probably also holds for J – I don’t have much experience in J –, but it's it's much more inviting to experiment with, so even when you can Google for things, hopefully people will still have, or still feel the need or the desire to experiment and try by themselves.

00:18:53 [CH]

I completely agree with that. Although you did just say that that's something I say all the time, so that's not surprising. All right, so we have two questions lined up in the Q&A and like I said, feel free to ask any kind of question whether it's a sort of generic question for the panelists, slash speakers, or if it's targeted at one of the speakers, or others feel free to tell them in the queue. Our first question is from Aaron Hsu, who I believe is a past presenter at at least certain APL conferences, and his question is what is the killer app for APL?

00:19:23 [RP]

Well, Aaron, Aaron so is a is a snake in the grass who knows exactly what, where he is and what question he's asking to the audience. He he should be on this panel right now. Answering that, answering his own question. But I do see I'm pretty pleased to see Morten Kromberg got their hand up, so I think you should answer this Morten.

00:19:45 [MK]

So when when the young lions push me aside at Dyalog because I'm standing in the way of progress, I I have an idea to build a data transformation tool, 'cause I think that's actually the the killer app for APL. Pretty much all the successful APL applications I've seen have the most amazing data import transformation cleaning front ends that they use to import data in in a variety of formats. And I think it should be possible to to build something really fantastic. Now I've given my idea away, of course now it's going to be a crowded space, but there you are.

00:20:27 [CH]

So anyone want to take a next stab? I have a quasi answer. But I'll let anyone else go 1st, If they, uh...

00:20:34 [RP]

I'll say go for it.

00:20:36 [CH]

My answer is sort of a non-answer in in that it's not actually an app. At least for where I'm at in my career and it on my sort of array language journey. Because you know, if if I think back over the last almost two years now you know my view of APL and array languages has evolved, but it's it's the title of Ken Iverson Turing Award winning paper: it's a notation as a tool of thought. Uhm which, like when I say, that it it's it, brings to mind like anytime someone had explained how a magnificent like the Grand Canyon was and and I was always just sort of like, I mean, I'm sure it's beautiful, but like it is just a hole in the ground. Like how, how magnificent can it really be? And it's one of those things where like until you have really seen it, or in the case of APL like you know, played around with it it, it's hard to understand what it is to have the way you think be affected by the notation. And like, this is, this

00:21:43

is probably we'll

00:21:44 [CH]

cover this in a future episode 'cause I don't want to go on a tangent. But yesterday, in one of the sort of post-conference discussions, it was being discussed, you know, tacit versus explicit and which one is more clear and and and yeah, like I I I really, my developing belief is that Ken Iverson did APL from 1960 to you know, 1990, and then he went to J and did basically, what is APL 2.0 in ASCII form and that was first when sort of really powerful tacit programming and trains showed up, which then got folded back into APL, Dyalog APL in 2014 and it's my developing belief that like there is so much beauty and like purity in tacit programming, where I'll solve a problem two or three different ways, look at it, and be like there's got to be something simpler, and then I'll realize: holy smokes like the three train using like 4 symbols. And it's so so beautiful like I have one problem specifically in mind, but like my ability to come to that elegant, beautiful solution, then isn't would never have been possible if I didn't learn APL and then didn't continue to learn like the tacit forms and the tacit expressions, so is that a killer app? I'm not really sure, but it's it's what I think is the most like valuable thing in picking up APL. Yeah, that that's my my non-answer answer. Bob?

00:23:05 [BT]

Well, I guess if you're looking at killer apps I'm I'm not sure I have an answer to it, but I think you're right on the on the notation being a way of thinking and then that's the power of, but to me that's not so much, like, a killer app is something that people would use before they realize it's the language. Like, I'm thinking things like Excel, people were jumping on Excel before they knew how it was written or what was behind it and that became a killer app for a platform, people needed to get Excel or I guess the, I'm trying to think of the other name of the spreadsheet that first came out and it sort of launched Apple because.

00:23:41 [CH]

VisiCalc.

00:23:41 [BT]

Yeah, VisiCalc, 'cause it was that the accountants jumped on it, because suddenly they could do things they couldn't do.

00:23:48 [RM]

And and that sort of launched a platform and rack that actually launched Apple Computer because people would go out and buy an Apple computer because it ran Visicalc.

00:23:59 [BT]

They didn't care about anything else about it, and I'll just mention in case you're listening to this that was Ron Murray and and you might have heard his voice before because Ron, and I get a chance to mention this, Ron has actually kind of been on the podcast, kind of because the first podcast I think we did, somebody posted the link to APL and Ron came in and said well, what's going on? And and he was really nice and everything, but we ended up taking it out of the podcast 'cause we thought we could embarrass him. But he's this is his second appearance on. Well, I guess if you're talking about published, this is his first appearance, but but that's right, Ron, that that Apple was really launched and they made a huge difference. Visicalc, I, well I, I don't have an answer for a killer app, but I think the way of thinking of it is notation is a way of thinking about a killer app. Perhaps if it comes through education, if the notation starts to be incorporated because it's more consistent and it's executable. That may be the ultimate killer app if the people in schools start to see the ability of having a notation that's consistent and you can actually also run through a computer. That would be huge, but education is a very hard a castle to get entry into.

00:25:24 [RM]

That's true because the problem is people nowadays treatseducation and programming languages as preparation for a career. So the first thing they ask is how hireable will I be if I learn this language, how many companies want to hire this? The thing that we sometimes miss is, APL an experience as well as a language in some ways, given our quick access to files and other interfaces, it almost feels you have very low bureaucracy, there's little between, very little between you and the data. You don't have to write 4 expressions or things like that. You just start writing APL expressions with the variables.

00:26:06 [CH]

Yeah, there's some, some something very sad about the state of affairs of, I understand university students they want to be employed. That's part of the reason they're going to university. But but in one of the local universities in Ontario, Canada where I'm situated, Waterloo, they teach a textbook called HTDP, which is how to design programs, which is sort of the university university-ified SICP: "Structure and Interpretation of Computer Programs", which was taught for decades at MIT and that version of that course at MIT used to be taught in Scheme and Racket, and now it's taught in Python, but the Waterloo version is still taught in Racket, but I just I I know a ton of Waterloo students and like the number one complaint I hear is like why do we have to learn Racket? But they missed the entire point that, like developing in a Scheme or Lisp is an incredible language to learn the fundamentals of computer sciences in. Because it's there's there's so little there you can, you can learn the the syntax in the language in basically like a day and then focus on the important stuff. And so I think sometimes it's missed that just because a language is niche or it's not as popular as Python doesn't mean that it doesn't provide a ton of value in some in some other way.

00:27:21 [RM]

Using Python from APL and vice versa, Kimmo Linna has constructed mechanisms so that you can do the same thing with R, they she can move data in and out of our just as easily as you could do with Python. So in general we should be able to do that. Any two programming languages should be able to interact.

00:27:39 [CH]

I mean, I think that's partly why Python is so popular. It's the interop, you know. They say it's the best language for nothing, but it's the second best language for everything. Rodrigo, you've had your hand up.

00:27:51 [RGS]

Yeah, thankfully it's a virtual hand so I don't get tired, but it's yeah, my comments also change, but the people keep saying things I'd like to address and it's, wasn't it Alan Perlis, Perlis, that said that a language that doesn't change the way you think isn't a language worth knowing. Yeah, and so I think that that's that's the case with APL, and probably with Racket you were mentioning. It's maybe you don't get to be employed because you know APL, but for example, for me I I use Python for a a lot of things, and my Python code changed, and more importantly, evolved because I learned APL and there was this, I was implementing a couple of a couple of toy functions that solved a toy problem in combinatorics, and all of a sudden when I looked at my code, I realized that that's not the way I would have written it two years ago, and the only thing that changed in between was I had like, well, I mean, I obviously learned more Python, but I wasn't using any advanced features. I was just thinking with APL on the back of my mind, and so the code was different and was better. And so that's one of the key benefits to learning APL. But people can only experience it after they learn APL.

00:29:09 [CH]

Yeah, bit of a chicken and egg problem. We'll go with Stephen and then we'll go Victor.

00:29:15 [SM]

Yes, I'd just like to mention that I'm I'm teaching a course in advanced sampling statistics, and I'm using my program TamStat, which, like I like to think of as a killer app. But one of the problems I've found is that, particularly in teaching an advanced course, is that I've I've written a lot of functions that that that do calculations in statistics and they do a lot of things. But when you get to some of the advanced stuff, we where we actually, I actually have to do some, just some external APL, which I can do in TamStat and the problem, I think the problem with that is, uh, I have to, I try to in the beginning of the class I try to teach them some basic APL about arrays and functions and operators. But I don't want to introduce the, I don't have time to introduce the whole language, so I try to introduce, I try to introduce some concepts little by little. I I had to use outer product and that uhm and uhm that got to be a little challenging, but my my question is it's I like to use APL as much as I can in the class, but you can't really teach the whole thing. You have to teach little bits of it and and introduce them. The other option is to write cover functions for some of the APL, the more complex APL expressions. But this is the first advanced statistics course that I've taught, and it'll be interesting to see how the students, I'm I'm, try to observe how the students react to it.

00:31:01 [CH]

Victor, do you want to go ahead?

00:31:03 [VO]

The programming languages we I was taught in my university. I can. I think it's just one. I was taught Python, but in the electrical department engineering they do, I'm aware they do Fortran. And there's matlab. UM, there's R. And then there are other assembly languages that they teach. In chemical engineering they only use MATLAB because that's you know we are advised to learn. We're not particularly total advice to learn, and the risks we get books and tutorials and try to learn in any way we can. But in the CS department, I think they actually really dive into a lot of different programming languages because I always hear the students grumble and complain about what these languages are now. These other languages, other differences.

00:31:58 [CH]

So yeah, just to to fill the listener in. So there was a question from Ray Pulvis, Polka Boca, Polivka. I apologize Ray, and which was asking Victor what programming languages are taught at university and the context behind that is that Victor gave a presentation earlier today as the runner-up winner, I believe I have that correct, of the Dyalog APL student competition, which I believe comes with a cash prize. And so yeah, Victor took second place, gave a presentation on that, and I think it's I think one of the awesome parts of that competition that happens every year, sure, you get to win a little bit of money, but because it takes place virtually, the number of people that are able to compete globally is basically unlimited. As long as you have access to a computer that can download from the Internet. It's a pretty meritocratic thing, and so I think if I recall Victor, you said that you're studying in Nigeria. Is that accurate?

00:32:56 [VO]

Yes, Obafemi Awolowo University in Nigeria.

00:33:00 [CH]

Yeah, that's awesome. And so how did you not, well, I guess now I'm asking a question, but so how did you come across the APL? Did you just randomly stumble across it online, or did you know someone that had known about it?

00:33:11 [VO]

OK, uhm there was this friend of mine. He's in electronics, so we worked together. When it comes to programming language because we are like enthusiastic about projects and stuff that involve programming. So he found it on the codegolf website. Then he came to tell me that he stumbled on this that I sure I would be interested, so that's how I got involved in APL.

00:33:35 [CH]

Yeah, that's pretty awesome. We will. We'll definitely find a a link to the code golf website and throw that in the show notes. We have heard that many many folks have found their way to APL from that site, Rodrigo?

00:33:47 [RGS]

Yeah yeah, so you mentioned that I, I think it was you, that part of why, part of the reason why people go to universities because they want to be employed. Or you can you can do like me: You can go to the codegolf website. You can find APL, then you find The APL Orchard. Then you meet Adám. Then you learn some APL and then you get asked if you want to intern at Dyalog, then you do a decent job and then you get hired. So that...

00:34:15 [CH]

Is that, is that a large group of people that have taken that path?

00:34:18 [RGS]

It's it's my path and so it's a non-zero number of people that have done that and it works I. I think it's quite interesting how, yeah, how you can meet APL and stumble upon APL, on, on code golf, and...

00:34:31 [CH]

Richard, and then we'll go to another question in the queue.

00:34:35 [RP]

Really, I just have a question for, uh, Victor, that's actually from Fiona in the Q&A, but I know that in decades gone by a lot of people were introduced to APL at their universities like in APL courses specifically. But Victor, do you think it would have been useful to have been taught APL or shown APL during your studies?

00:35:03 [VO]

OK, yeah yeah. Personally I think it would have been useful to have been taught APL because majorly because of the way like naturally when you learn APL, you you don't learn the shortcuts like the, no, not the longcuts to programming. The trying to make it work when you let it be or you you learn it by like, putting 2 arrays together and making sure it works like. Yeah, it's parallel. It's, you don't have to start trying to make it work by putting addition and subtraction's just trying to [inaudible]. So I I think it would have really been helpful and I will do that actually, reoriented the way we think or the way we used to think, because a lot of things could have been solved with these, I mean, in in my school, for example, we had this notion that I've been not had we have this notion that's most of the things that they teach the students in mathematics, like they did, it's not practical, it's not applicable that they can't relate to it, they just have to read and sit in exames, and there would probably be the end, because after the next year’s exam with for the next year's exam, it's just like it means to get from there. But with APL you get to pick up your paper, your pen and your and your paper. You you calculate you, you get the the optimal way to a solution and you just put it in and it WORKS. It's more like the math comes alive, so I I think it would have been really helpful.

00:36:41 [RP]

A really good day. I think we do hear that kind of perspective from newcomers to APL. Uh, I shouldn't say a surprising amount. I should be used to it by now, but it is always like kind of surprising to hear it said out loud by people outside of our own communities and organisations. That idea of, like you think through the problem you find the way to solve it, and then when you just put it in the computer. It works.

00:37:08 [AB]

I, I think this is something where APL can make a big difference if it's taught, not because you necessarily end up using APL, but it changes your way of thinking. It gives you new pathways of thinking and people who write in, should we say traditional programming languages which are almost all Algol type or C type languages? They are able to write better code if they have opened their mind with APL and so, APL can have an an invisible impact on the entire world of computing. If those people that go out and write those programs in those traditionally used languages in this day and age have been exposed to APL, they can simply do a better job.

00:37:51 [RP]

I want to be a bit cheeky and direct one last Q and a question that we have at Victor only because you're the person on this panel with I suspect the least APL experience out of all of us, right? You're relatively new to this, but Aaron Hsu has put a fairly interesting question in the Q&A which is:

00:38:13 [BT]

there is some, there are some

00:38:14 [RP]

people with a perspective or argument that uhm, APL, the programming language is actually these days more suited to some, a small set of genius wizard programmers who can understand how it works and utilize it. But as a relative newcomer, Victor, do you think APL is just for super duper clever people, or do you think it's accessible and can be leveraged by, quote unquote from this question, normal folk?

00:38:46 [VO]

From my own point of view, I I think anybody who can who could who can take a who can grasp any programming language should be able to code APL. Uhm, it's it's not the hard part, the, in fact there is literally no hard part. You take your time to to read the the book and you you devote yourself to the questions or whatever you want to use APL, for this update, here the rules are, the rules are clear, the there's there's no, there's no gray, there's no gray area. Everything has been outlined clearly and like I, I was working on I I was reading a book on on transformers and I I was wishing I I had this in APL because it's just it would have been so so easy for me. I I wouldn't have to be doing a lot of extra thinking that that seemed normal, so I I I I I don't think I I think that the genius in in the people that let people is the fact that they choose to let it build.

00:39:55 [CH]

Amazing, I feel like we should open that question up to to other folks as well too. So I'm just I can I can re articulate it and and I'd say we I can read the whole thing so this is a second question from Aaron Hsu. Some people make the argument that even after APL education has improved, that the APL language is just inherently too hard to use for quote unquote, normal programmer slash domain experts and that it's really only a tool for extremely competent, quote unquote geniuses rather than quote unquote normal folk, there may be some parallels with some people arguing that traditional math notation is just inherently too hard to be a professional at it except for very few, the debate rages there as well. Thoughts? So yeah, we just heard from Victor. Do other folks have thoughts on this? We've got two hands up so we'll go first with Brian Becker. And then we'll go to Rodrigo.

00:40:39 [BB]

Well, we've conducted the APL problem solving competition now for 13 years, and what I'm consistently amazed by is that it reiterates how really low the entry barrier is to APL. Being able to do productive and non trivial things in APL with relatively small learning curve you can go to any number of presentations over the past few years and granted these the people that have won the competition are generally pretty pretty smart. But they were able to either through the tooltips or reading Mastering Dyalog. Or, you know, with relatively little resource, learning enough APL to not only solve the problems for the competition, but to do a good enough job to win, and so when you say that, you know, you need to be a genius to learn how to use well, there are certainly a number of geniuses in the APL community. I I don't consider myself to number among them, but it's really a a tool for the masses. Yeah, most languages not only do you have to tell the computer what to do, you also have to tell it how to do it, and APL eliminates that second part entirely.

00:41:51 [CH]

Rodrigo?

00:41:51 [RGS]

Yeah I want To, I want to speak to the the math comparison part of Aaron's question because I did study maths at university and one thing I noticed is that math notation is not too hard for, you don't have to be a genius in order to be able to use math notation, you just need to be a genius to do genius things with the notation. But it can be, you can be competent and it's and still do pretty good things, and I think it's the same thing with with APL. If if you are a genius then you will probably have an easier time understanding APL and an easier time doing genius-like things with APL. But if you're just a regular person or an average person, you can still learn APL. And of course, that's not to say that some people have their brains wired differently, and some have more ease with it and some find it more difficult, but it's I think it's still fairly accessible to to to to the average person.

00:42:49 [CH]

Ron?

00:42:49 [RM]

Uhm, well my experience started in 1970 when I was using APL to teach computer science in the high schools of Hampton, VA and the one problem that the schools had was that they couldn't get the kids to leave the school at the end of the day, they wanted to be at the APL terminal doing things. It almost became addictive, so and this wasn't a course that was specially narrowly tailored. It was open to anybody who wanted to take it. The only thing was it wasn't a required course. So it wasn't a case that you had to do this. The kids there were there because they wanted to be, and they were actually turned on by the fact that you had this new tool that you've never had before to get a computer to do things for you with the middle of bureaucracy between you and the machine that you didn't have to learn and esoteric language you just learned a little bit at a time and tried it to see what happens.

00:43:47 [CH]

I will, I'll read a couple of the comments to that have been posted as form in the form of questions, but I think they're really answers, so Bob Bernecky, who's a has a very long and prolific APL career, uhm, writes, "I can teach APL to children and artists in two minutes, including a test with reduction. The trick is to choose your vocabulary e.g verb and adverb versus function and higher order function" and then goes on to say that no geniuses know genius is required. And then Tony Corso also says APL isn't for brainy Wizards, APL transforms you into a brainy wizard, which I definitely, yeah, I I wouldn't say that it's the language of the gods as as Rodrigo said earlier, but I I get this feeling like if you've seen the movie Inception, I have all these different like sort of metaphors from movies, but if you've seen the movie Inception where they have the scene where I'm not remember her name but, she's the the dream architect, and Leonardo DiCaprio takes her into the dream for the first time and says, oh, you can do whatever you want and then she very quickly realizes, like, oh, that means I could I can literally bend the rules of, you know physics and flip this city and turn it into a box, and at times that's what APL feels like like it's and it's like I said, it's the Grand Canyon thing, like until you had solved a certain problem that you've only known how to solve, sort of serially or with a for loop. And then you do it in literally like 3 characters you you can't, you know, you can't know what that feels like until you actually do it yourself. And I just I want to sort of linger on the last question. Is there anyone else that wants to sort of give their thoughts? I think it's clear that we're all in agreement. You don't need to be a genius, but if anyone has some sort of anecdotal. I think they want to enter that before we ask the next question. If not, we can just move on. Morten?

00:45:37 [MK]

Well, I would say I mean, APL doesn't become truly valuable until you have an interesting problem to solve. And that does sort of place a bar somewhere.

00:45:47 [CH]

I guess that is true, uhm? I will I I just realized that I did not, I even had an answer prepared that I didn't even say and that is that I've realized recently from listening to, uh, I think, uh, Dyalog, talk, that APL is is an extremely high-level language, and in fact I think I actually realized this when I was talking on my other podcast with my co-host Bryce, and he made some comment that he said, oh, you're a very high-level programmer, which is why you love APL. And I'm a very low-level programmer. I like to think in bits, and that's why, you know, I I lean more to C++ and I had never like my whole professional career has been in C++, so I've always thought as myself as a low-level programmer, but I didn't. I didn't choose C++, I just fell into C++ and I've been doing it ever since and since then the languages that you know top my list, are, you know, APL, Haskell. They're very, they're languages where I don't need to think about the detail. As you know, some people say that APL suppresses the detail, like you can just code, uh, rotate. Or, uh, reverse, you don't have to set up a for loop with an index and incrementing and yadda yadda yadda so, when when people say oh it's when they make this remark is you need to be a genius, I think it's the exact opposite. It's just that it looks different, and that's what scares people. But actually, in my opinion, it's one of the simplest languages like the the expertise that my colleagues that they have to develop in order to be really good C++ programmers. I think you need a fraction of that to become a really good APL programmer, because it's such a it's it's a way way simpler model. We will go to a very we're gonna do something interesting here. So we got a question a while ago that sort of got answered in the chat, but we will do a sort of raise of hands 'cause and and we'll just, I'll get a count of the number of people to see what the answer to this is, so I can't even oh, there it is. Yeah, the questions from Ezekiel Berman. I apologize if I'm pronouncing that incorrectly. Ezekial asks do you do TDD when programming with APL? Now TDD is an overloaded, overloaded acronym. I'm going to assume that stands for test-driven development, although in some circles it's known as type-driven development, but raise of hands if you, while programming in APL, do TDD in some form or another. So that was 1 2 3 4 5 6, of 1 2 3 times 5 is 15 plus 1 is 16, although minus 4 because 4 folks don't have their cameras on, which is 12. So that was what 6 out of 12 is 50% so. So Ron, you've got your hand up so I'll I'll let you go ahead. Oh, and then Richard might have put his hand up to vote so it might have been 7 out of 13, but go ahead, Ron.

00:48:26 [RM]

Well, I've been pushing for test driven development within Dyalog because I did a lot of that when I was working for Amazon. Because the basic problem you have is when you write code, how do you know it actually works? And then once you've written it, how do you know it continues to work when somebody has been changing your code? So there a model that we fell into is once you get past the quick and dirty prototyping phase, when you're serious about your code, you write your, first, write all your test cases that determine whether your code is right, and of course you're writing them now and you don't have any code which means every last one of your tests will start failing immediately. Then you start writing the code until you get all your test cases to pass and you just continue to use those test cases as you change the code. 'Cause one of the problems is even if you think you know what you're doing, you don't necessarily know all the interactions to the code, so you make a change in the code you don't realize until some user has called you up and said this released piece of code does the wrong thing in this particular condition. You say, "Oh.". And so you really need a way to make sure that that kind of code doesn't get out of the wild. You need to have a way to have assurance that your code still works. And if you think about it, if you write your test code in literate fashion, it's not only a good test code, it's documentation for how the code should behave. So someone who comes into your project from new and doesn't know anything about it can read the test cases and start understanding what the code is supposed to do without worrying about some of the details, so that was my experience with test-driven development. It's just a really good thing and that goes along with the notion of continuously refactoring your code, because as you write code over time, you'll discover a couple of things that the way you wrote it originally is not really the right way to do it. Either because you understand the problem better now, or because the management has changed your requirements. So what you did before is no longer really the right thing to do. And you have a choice at that point, you can quack hack your code to make it sort of work the way it should. Or you can rewrite it so that it actually looks like you knew what you were doing when you wrote the code in the first place. And for somebody coming along later on who has to understand your code without having been there in the process, it's much nicer to have code that's more straightforward and actually conveys the ideas more clearly. So those are the things that I think are really good about test-driven development and continuous refactoring.

00:51:10 [BT]

And I I should spend some time listening to Ron about test-driven development. I use it slightly differently and it's because of the array languages that I do that I tend not to write my tests first. My first test tends to be what I write. It's just it seems to get in the way of what I'm trying to do. I guess if I took it up a level it would make more sense, but initially quite often I'm just, when I'm actually playing with a language that's like I'm testing. Now, as soon as I get something locked in, that's where it kicks in for sure because as he was talking about refactoring and making sure that your changes you make are still on course, that absolutely is what I do with that because it's so easy to go in and say I should have done this differently. And then you go in and you immediately see that what you might have thought you were going to do differently is exactly what you want, in which case all your tests pass, or if they fail, how they fail becomes really great information on refactoring, and so the the step I take with the test driven it's not so much driven, it's test-continuation development, I'm not sure what it is, but I find I just want to jump on right away first and try stuff 'cause that seems to be the easiest way, but as soon as I have something working, I'm writing tests to make sure that it continues to work.

00:52:29 [RM]

Just mentioning that when you're doing test-driven development and you've got your test on your code. If you have something extreme starts failing in your code, you have a choice. Is the problem in the code or is the problem in the test? So this is a forcing function which makes sure that your tests are in sync with your actual code that you accurately document what you intended the behavior to be. So that's a way to treat your test-driven development as your documentation, and you can force it to be always correct. The problem with textual documentation is it's not tightly connected to your code. So there's no way to force it to always be accurate, and in fact, there's a general property that people have is, over time, documentation tends to turn into lies just because there's not enough forcing function to make sure you update it.

00:53:28 [CH]

Work alright and I think with that we are two minutes away from the hour mark. So I think I will wrap this up with two different things. Maybe although one of the third last thing I'll note is that Aaron Hsu in the chat who we've heard twice now from has said I like TDD, but not unit tests, which sounds like some kind of oxymoron. But Aaron, if you have a link on TDD in APL feel free to share it with us and we'll put it in the show notes for folks that are interested. Oh yeah, there's a, uh, a link that he just shared us too. I I I knew that there was some sort of content attached to that that oxymoron there.

00:54:05 [BT]

And I sense Aaron will be the guest on a future podcast for sure, yeah.

00:54:11 [CH]

I I don't think yeah, we can have a podcast about array languages without having it or not at some point. But yeah, the the the second last thing here that I'll I'll say or read is a a comment that actually was, it's, uh, typed out in the chat way earlier on, and I think it's a great note to end on, which reads from Ilve, I apologize once again if I'm pronouncing that incorrectly, "My love of Dyalog APL can be said like this: when I am trying to solve a problem, the ability to. stop the interpretation anywhere and test the solution alive. Thanks for this meeting. I hope we will see each other next year in Portugal.". So yeah, I hope as well that this this conference will happen in person. I was really hoping to do this in person this year, but it obviously because of the pandemic didn't work. But yeah, hopefully we'll be able to do an actual in live in person sort of podcast recording a year from now, and that will be awesome.

But with that I think we will queue a "Happy array programming". So what I'll do is count to three and then at the end of three, folks, if everyone wants to unmute, we can have the most synchronous and most people at one time ever in the history of Array Cast saying "Happy array programming". So on 3: one... two... three...

00:55:22 [all]

Happy array programming!

00:55:26 [RP]

Nailed it.

00:55:28 [Music Theme]