Transcript
Transcript prepared by Bob Therriault
00:00:00 [Conor Hoekstra]
Oh, wow. What a-- Stephen, brilliant comment. Wow. What a moment. You've just-- wow. Wow. Top, top, top 10 moments on ArrayCast? I never realized that.
00:00:18 [MUSIC]
00:00:26 [CH]
Welcome to episode 81 of ArrayCast. I'm your host, Conor. And today with us, we have no guests, but all of the panelists. We will go around and do brief introductions. We'll start with Bob, then go to Stephen, then to Adám, and then finish with Marshall.
00:00:38 [Bob Therriault]
I'm Bob Theriault. I'm a J enthusiast. And I'm currently in a five-point harness for this one because it's taken off.
00:00:44 [Stephen Taylor]
I'm Stephen Taylor. I work with APL and with q.
00:00:47 [Adám Brudzewsky]
I'm Adám Brudzewsky. I do APL, a Dyalog, and language design. I feel like I'm increasingly being pulled into language design discussions for various flavors of array languages. But it's all very interesting.
00:01:02 [Marshall Lochbaum]
I'm Marshall Lochbaum. I started out with J. I did make a little language called I at one point. Now you may know me for BQN.
00:01:09 [CH]
And as mentioned before, my name's Conor, host of ArrayCast, massive array language fan, excited to get to our conversation today. But before we do that, we've got, I think, several announcements. So three from Stephen, one from Adám, and then half an announcement from me.
00:01:26 [ST]
The website for Iverson college.com [01] announces that all the places at our meeting in Cambridge are now taken. All of us panelists, except Marshall, who's done it before, will be in Cambridge. But if you have a sudden revelation that you think you ought to be there and you'd like an invitation, there may yet be people pulling up. So you feel free to write to Warden at Iverson College and say that you'd like to be considered for the wait list. And why?
On the 12th of June, I'll be presenting the Q201.org project at the KDB meetup. That's called Everything Everywhere All in KDB+Q. That's in Madrid on the Wednesday, the 12th of June. If you can't make it there, don't worry. It'll be live streamed and also posted up on YouTube afterwards. The day before, there is a workshop on vector programming techniques in q, which is free to anyone who wants to come. If you're thinking of going to, of flying to Madrid for the workshop and you're coming from London, please think again and write instead to dean@irisoncollege.com because we're planning a similar workshop in London, vector programming in q. And I'm pleased to say that I've managed to get myself to and from Madrid without using aeroplanes.
00:03:05 [AB]
Way to go. That's impressive. I suppose you took the train or walked or something.
00:03:10 [ST]
Well, I'd have liked cycling.
00:03:12 [AB]
My announcement is that the APL Forge, which is this incubator/competition for projects using Dyalog, APL projects and tools and applications, has a deadline this year in about... by the time this comes out, it will be a couple of weeks at the end of June. So if you have something you've written using Dyalog APL lying around and you think it could be a nice thing to show off to others, you might be able to win a nice prize if you submit that. So check that out. We'll have a link in the show notes.
00:03:53 [CH]
And last but not least, this is half an announcement because we kind of announced this in the last episode. Marshall and I recorded the second episode of Tacit Talk yesterday, which was probably about two weeks as of when this comes out now because we're recording this episode a bit early due to scheduling conflicts. And the reason I mention it is because we ended up spending about half of the hour and 45-minute podcast talking about I, which I don't think was planned but was perfect because I is a completely tacit language similar to Uiua. And I learned a ton, so folks that are listening to this are probably interested in that topic. So link will be in the description. And that's it for announcements, which brings us to our topic for today, which is going to start with me throwing it over to Stephen to talk about a talk that he's going to be giving in Madrid, the one that was aforementioned. And then we're going to see where it goes from there because we were discussing what we wanted to talk about. We threw around a plethora of ideas, and then I think we just decided at what our starting point was going to be. Where will it take us? We don't know. I have a bunch of questions that may or may not come up. One correction. Will the correction happen? We don't know. But with that said, I'll throw it over to Stephen, and maybe you can start us off by giving us an overview of what the talk is going to be about and what you're hoping to achieve with it, and we'll go from there.
00:05:12 [ST]
Oh, thank you. Well, the title of the workshop anyway is Vector Programming in q. The thought behind it is that there are vector programming techniques that are familiar to people in APL and who moved on to k. That q, which is made as a wrapper around k to help get you started quickly, tends to mask from you. So if you use q quite casually, pretty much as a data pipeline to get data out of KDB datasets, you don't really need to deal with that stuff. And that's an important feature of q. It makes it quick to get started and get something done. But if you need to get mastery in q, if you need to squeeze all of that amazing speed out of KDB, then you've got to come to grips with the vector techniques. For at least 20 years, the main way that people would do that was by doing an introductory workshop, one of the famous, get you started quickly, and then you join a team where people are using it. And that team would be internal to KX First Derivative or maybe one of their customers. You join these crowd of lunatics who are using this strange language and you pick up from them the advanced techniques. As the language spreads out and as KX addresses more and more of a retail market, there's more and more people dispersed around the world who are wanting to get those q skills, but they're not surrounded by experienced q programmers. So the premise of the Q201 project is to have advanced study materials for learning the vector techniques. What I really want to talk about here is not to talk about my talk, but to talk about the title of the vector programming techniques, or as I thought I might call the talk, Notation as a Tool of Thought. My predecessor as the editor of Vector Magazine, Stefano Lanzavecchia, famously was asked years ago, "What does APL still have to teach computer science?" And his answer was, "Well, nothing really. The lessons have all been learned. But if you wanted to make a million dollars writing software all by yourself, APL would be absolutely the place to start." Where does that come from? There's a lot of stuff which got spun off from APL, functional programming, MapReduce, they're all found there in the 1960s in Embryo in APL. But the big question that I'm hoping that the rest of you on the panel will help me chew over, it's an old bone, is why is it that the array techniques, when I find them lifted into other languages like array methods in JavaScript, like list comprehension in Python, why is it that they seem like a pale imitation of what I think of as the real thing? Why is APL, and I'd argue q as well, J succeed as a notation for a tool of thought? That's my first question. I don't know if you agree with me, but if you agree with me, my question is, what's missing?
00:08:35 [CH]
I will start by redirecting it to Marshall, because Marshall just said yesterday when we were chatting on Tacit Talk, look at this, we got the cinematic, the Marvel Cinematic Universe equivalent of this is...
00:08:46 [ML]
Connor cinematic universe. CCU.
00:08:49 [CH]
Yeah, this is the the array language cinematic universe. We've got, you know, DC and anyways, you said that when you first stumbled on J, that you like absolutely just like fell in love with it. And then when you when you started learning other languages, you were just like, wow, this is odd, because like J is clearly superior. And then later on, you had a more nuanced take. So what was it initially that made you have that reaction?
00:09:14 [ML]
Well, I think the implicit mapping is a lot of it. So like in a lot of languages, if you're working with, say, vectors in three-dimensional space, it is actually shorter to write out element-wise addition with three plus signs than to do a loop over the dimensions. And that's really-- that is not good programming practice, because that means your code has deeply embedded in it this idea that you're working in three-dimensional space and not another number. And it just-- it doesn't give you a high-level picture of what you're doing. It's you've taken your high-level picture, and you've written it out, expanded it into this low-level notation, because that's what the language best supports. So even if a language has a map construct, if it's very awkward to use, then you really don't get the same utility out of it. I can complain about JavaScript in particular. [02] It's got this map that also passes the array index in, which sounds nice and useful. Like, yeah, sometimes I need the index, except that then when you have a function of a variable number of arguments, it's often going to get passed in this index and do something useless and completely break your code. So you have to rewrap your function into something that ignores its second and actually third argument as well. And so the map in JavaScript is not even usable as a map, whereas in APL with addition, you just write plus. you don't even need to map because the language figures it out for you while interpreting.
00:10:47 [BT]
One other thing I think, the reason you might have fallen in love with J to begin with, Marshall, is that you were a student of Henry's, and Henry was...
00:10:55 [ML]
Yeah, well, I mean, I will make, I will not attempt to hide that it's really just because it was my first serious programming language, other than programming calculators and TI Basic, but I mean, I didn't even know what a for loop was. I used gotos for everything.
00:11:08 [BT]
But what I was going to say is I think this loops back to what.... I'm full of these ones... Comes back around to I'm catching my own puns now.... But it comes back around to what Stephen was talking about is that for a long time these languages were taught almost with mentors That it was a one-to-one that would bring you in and sort of bring you into the language Well, I think that's actually what might have made any language that you started with more impressive to begin with is you had a one-on-one with a person who was experienced with the language I think that's particularly useful with array languages
00:11:47 [ML]
Yeah, and it's worth noting that I didn't have this for something like Java or something like Python I mean I took classes on Java in college. That's Obviously one on many but yeah, if you can talk with someone about the language Then you're able to be directed to you know What is good about the language? How to use particular parts of the language as opposed to just presented with what everything does and yeah I think if you're learning a second language, you'll often assume well now I know how to program So the question is how I program in this other language But you've already by virtue of learning in one language You've broken down your idea of programming into particular ways to do things And so then you try to translate these particular ways instead of thinking Whether they still apply in the new language
00:12:32 [CH]
I will say though, I'm a counter example to that. My first programming language, my very first programming language, probably Python in University. I mean, also TI Basic, but I mean, all I did was program the quadratic formula. So it's, I mean, technically, officially, it is my first programming language. But the first thing I did anything serious was with Python, and then Java, and then C++. And then I picked up on that because of competitive coding in university. And anyways, I consider myself a polyglot now. But like, I didn't, I didn't love those, like, I loved programming. But I wouldn't say that like, I was in love with those languages. But then when I stumbled across APL, it wasn't with a mentor, it was just on tryAPL.org. And I just happened to be like, at the right point of my learning curve, I discovered Haskell, Haskell was beautiful compared to C++. And then I saw plus slash, and then plus the other slash. And I was like, alright, I'm sold. And like, when you compare this to NumPy, like the verbosity, the how cumbersome it is, and, and just the inelegance and the asymmetry is it's, it's just, it breaks my heart. Like the when you when you convert something from APL, that is just like a plus slash, you know, one plus whatever, just some scalar pervasive operations followed by a reduction, and you convert that into the equivalent in NumPy, first of all, everything is prefixed by a namespace np dot. Second of all, some of the operations that are scalar pervasive in array languages are also in NumPy. But like a lot of them, you have to just it's a NumPy dot reverse or NumPy dot and then you have to so like some of them you can just you've overloaded the plus operation and that works, but then you need to nest that inside the parentheses and pass it as the first argument to certain functions. And it's just like when you're used to the beauty of array languages like APL and friends, having to then convert that into that, it's just like, okay, like, sure, you board all the ideas, but it completely destroys the beauty and the symmetry of the original array code. Adam, you're going to say something.
00:14:35 [AB]
Yeah, like what you're saying about symmetry and straightforwardness of things. I have to write some JavaScript from time to time, and my JavaScript looks weird because of my background from APL. So it's all maps and reducers and things everywhere, and chaining things, long lines.
00:15:01 [ML]
Yeah, my Java professor complained about that, or one of the TAs probably.
00:15:09 [AB]
But one thing that happens to me a lot is I want to... I mean, sometimes in APL, you do need to use an each, because you're not using a so-called scalar function that can auto-map. And that's fine, but sometimes I want to map a function over two arrays of the same dimensions. And that's easy to do in array languages as well, with an explicit map or whatever it's called in the respective languages. And then I try to do that in JavaScript. And the asymmetry there is just jarring. The fact that you can map over one array, but to access the corresponding elements of another array, you have to index using the extra indexing thing you get in the map. That's just... that's just horrible. Why can't I map over two arrays?
00:15:51 [BT]
Do you think, Conor, that another part of it for you, you're talking about your favorite languages, but you didn't mention Excel. [03] And I know that Excel was a big deal for you, that you did a lot of work in Excel, you enjoyed Excel, and you were almost primed for thinking about structures in an array format.
00:16:12 [CH]
Well, I'll say I just looked over at one of my monitors and I have two or three Excel. Although I've been converting my Excel to Google Sheets just because of the ubiquity of it being everywhere.
00:16:26 [ML]
But that's just another dialect.
00:16:27 [CH]
Yeah. Well, no, I mean, Google Sheets, we're not, well, let's not do this. Let's not do this, folks. We're going to go down a rabbit hole. All I'm going to say is that Google Sheets is a watered down shadow of Excel. You know, Excel got Lambda.
00:16:36 [ML]
I need a Venn diagram by Monday.
00:16:40 [CH]
So I mean, why do I love Excel though? I don't think it's the reason I love array languages I don't think has to do with like the tabular nature of Excel and thinking of things and sheets I like Excel because of like the programmability of it, but like writing Writing formulas in Excel is a is a what's the word I want to choose devastating Experience like it's one of the worst program. It's like similar to TI worse than TI basic You know everything is a prefix function You know they have a single line that you write the formulas in and I know they've changed that now where that you can Get like a bunch of lines And I think you can even pop it out into like a kind of VS code or maybe it is VS code But like for a long time when I was younger You know it's just you've got a single line, and you're typing you know some some if like ranges clicking things Don't get me wrong extremely powerful, but it's not a pleasant And then when you get it right like when you get it right It's like well It's amazing dopamine hit But like you're looking at like the parentheses that are being color highlighted being like what's going on here like it's like the worst way to code But it is extremely powerful especially because you've got VBA Visual basic application which you can just go crazy with like you can do everything It's it's such a powerful thing and being able to visualize your data is very nice But it's not really the same reason why I love array languages like I love array languages because how beautiful they are.
00:18:07 [BT]
But your data structure is a grid, right?
00:18:12 [ML]
Yeah. Well, I think maybe you could say that they share a lot in the semantics, but what Excel is missing. So you don't see the similarities in the array-based approach to things, but you see the difference, which is that APL notation is actually designed to be read and written, whereas Excel is just designed to do the job.
00:18:32 [BT]
Yeah. I think the grid of Excel primes you so that you've got this pent-up energy of trying to make Excel do what you would like it to do. Then suddenly you see APL and you go, "My goodness, look at that." In two characters, I can do what would have been all these brackets and all this click and move things around. But you're already thinking in terms of a grid, so that suddenly you had access to the same grid. I think that was part of what might have clicked with you with the array languages.
00:19:05 [ML]
If the way you think about an array operation, if you think about reversing as an array, as a specialized loop over half the array and swap elements in place, which I think is how a lot of very low-level programmers might see it most of the time. Then when you come to APL, you're going to say, "Well, it does this style of programming very badly," and you're not going to see that it does a different style of programming very well.
00:19:31 [CH]
I would say too that really like the path that I took to recognizing the elegance and the power and the beauty of APL initially and then other array languages was the path from like C++ and Friends, then to Haskell where they had sections in like abbreviated lambdas and like not the namespaces and the overhead of everything in C++ and Friends and then landing at APL. Honestly, like Excel, Excel really like the equivalent data structure is not a matrix, it's a data frame in most cases. Like yes, sometimes you do have a table of whatever your floating point or integers, but most of the time, like when I go and look at the spreadsheets that I have, like one of them it's a, you know, like it keeps track of like the titles of the books that I've read and like the date that they finished. So like one column is like the title of the book, the second column is the author, the third column is the date I finished. Like that is not like a matrix per se, like that's gonna be like a nested whatever, I guess you could store it, but like it--
00:20:34 [ML]
But I mean, APL is perfectly good at nested lists at least since the 80s.
00:20:38 [CH]
Yes, it is perfectly good, but it's not really like the, I guess it's whatever.
00:20:45 [ML]
I think the concept that I think Bob is sharing this concept with me is that You're thinking not in terms of individual values, but in terms of the larger structure like the the concept that you need in order to make use of APL is to pull back a little and work with an array and not think about what's inside it.
00:21:08 [CH]
Yeah, that is true. I mean, at one point I went through a half year phase of trying to popularize the term collection-oriented programming when I came across it from a couple papers in the 1990s. Some people call it wholemeal programming, or like when I was talking about it, I had a couple people DM me and they said, "Have you heard of wholemeal programming?" versus I think the opposite was like piecewise, meaning that like you're operating on collections. So like even in a language like Haskell, you're typically, you've got... And I mean, you can point to SQL as something that does the same thing with a very different structure. So you'll find the link that has a, it's a website called K2 something that was popular back in the day. And it has this collection-oriented programming. And the two examples are array programming and I think it's data oriented, but the example they give is like SQL. And I think actually when I discovered that, I think we actually even said, "Oh, we should find someone to come on and talk about the SQL and like the relationship between the joins and those kinds of operations and group eyes and whatnot and APL." But I really do feel like my, I might've been primed, but like my love for the language is like literally I just, a couple hours ago added, 'cause I was upset with the Tacit Talk logo. I knew I needed to add some glyphs and then I was trying to think about it. And I went and found the tweet from back in October when I was at the Minnowbrook conference. And I don't even remember what the problem was, but it's like match monadic before, and then it's got like, and, or, or, but like one of them corresponds to the dyadic meaning and the other one corresponds to the monadic. And then it's the same thing on the right side, but it's like, it is one of the most beautiful, not lines of just BQN code. I'm talking about most beautiful lines of code I've seen in my life. I've seen in my life, folks. And I was thinking about that, like, I know that a Dyalog 20 or whatever is going to get reverse compose. The equivalent in Dyalog APL will not be as beautiful as the code in BQN because of the choice, Marshall's brilliant choice of the symmetric before and after glyphs. And reverse compose is close. It's got the circle, but the line underneath is asymmetric. And when you're starting with, you know, we're here and now we want to add something, it's pretty good. You can't, you can't really do better than something like that. Adding an underbar to the glyph. Like you're definitely going for symmetry, but when you're starting from scratch and you can choose the glyphs, there's just something about the monadic before or and dyadic, just the before and after. It's just so like, chef's kiss, chef's kiss. It's absolutely, absolutely amazing. And, and I was starting to think too, that like I, I like my top three languages are probably in no particular order. We'll figure it out at some point. Although Jello, do we count Jello? Jello, CAP, Uiua and BQN. We don't know the order, but I'm starting to think that like one of the things about Uiua that doesn't excite my brain the same amount is the fact that you're always building something right to left in a way that everything is prefix. And the fact that both binary and unary, monadic and dyadic functions are prefix, leads to less symmetry. And this is completely unimportant from a practical point of view. Like you can write the exact same piece of code with the same number of glyphs using the same kind of combinators, maybe a little less in Uiua because you don't need them. But like this symmetry of this, your final operation in the middle, and then you're building out using befores and afters and the S and sigma combinators that comes out of the three train model in Dyalog APL and BQN. And there's something just so, it's just so, it's so wonderful. Anyways, we're off in the deep end. I'll let everybody respond, but it's maybe I was primed, but Excel does not have the before and after from BQN. It doesn't have the combinators folks. And what are we talking?
00:24:48 [ML]
Somebody write a letter to Bill Gates.
00:24:52 [CH]
Or the Microsoft Excel team.
00:24:54 [AB]
I mean, Just imagine if Excel had a Combinator function so you have to write the word in all caps, of course, "Combinator" open paren, Quote, letter of the Combinator, quote, and then comma and then the functions that it takes, right?
00:25:08 [CH]
I don't think I got to express how heartbroken I was on the last episode when you said "quad no value" and I was like Oh, how do you spell that? And then you spelt it out and I, like, my heart broke. I was like, okay Well, like what are we what are we talking? That's not that's not usable. I'm gonna have like a four character solution It's it doesn't really matter.
00:25:26 [AB]
It's only used in a in a very particular context Where it's already wordy It's like when you're using these colon keywords in APL and it's there's a keyword to return from the function So it's like an old-style APL would write go to zero But you could write colon return and they can take a value after that So you can say colon return 42 with function returns with the value 42 colon return Quad no value the function returns without giving a result probably causing a value error in subsequent expressions so It doesn't matter that it's super ugly
00:26:03 [BT]
But that does touch on something like the whole typography thing does touch on something that I know J is criticized for is The fact that it's not quotes a beautiful looking language But I think when you've got the glyphs and you match the glyphs to the operations you do gain something more J attempts to do that with the diagraphs I don't find them that disturbing but I can see that the actual changing of the typography allows you to sort of see what you're doing as you write the code, which I think is a very powerful thing.
00:26:35 [ST]
I'm really struck here by both the energy of this conversation and its focus on aesthetics. It's like we've got a pack of hounds here baying after beauty.
00:26:48 [ML]
Okay, this is a lot of metaphors. We were taking off, then we were in the water somehow, and now there's hounds after us.
00:26:57 [ST]
And I I guess.
00:26:58 [ST]
I guess I want to draw attention to it because we're not looking at efficiency, we're not looking at speed, we're not looking at code volume, we're not looking at the kind of metrics that people usually talk about around computer science. Gosh, is there something really important about aesthetics here?
00:27:15 [CH]
No, probably not. I mean, I think that's it's come up a couple times where I've I've blasphemously mentioned an array language that used keywords like like q and like what's the problem and then and then and then You know, I think Adám or some people on the podcast have gotten like, oh, yeah What are we talking about? You can't you can't say that and I think Marshall you've said that I actually I think it's an Less explored space like there's more exploration to be done there. I could be misquoting folks Yeah, but at the end of the day, I think Beauty is like well at the original question was what is it that feels? lacking when you go to these APL inspired things and I think like the number one thing that pops to mind is this verbosity the Cumbersomeness of it the asymmetry the inelegance all of those words. That's not to say that That's what people should be caring about But that's just what pops like when I go and write NumPy code my just as my heart is just being trampled on I'm like the spirit is here, but the elegance is not And potentially NumPy or if you're like, you know going to qPy which is just an accelerated version of NumPy You're gonna get more performant code than you would in the equivalent, you know array language of your choice But I don't think that there's any reason why you couldn't have all of the above, you know an elegant Array inspired or array language that is extremely performant and does you know, we do start focusing on the things people care about.
00:28:44 [ML]
So it's not purely about having an aesthetic. It's not about looking like something nice. It's about having the look of the code be correlated to what it's actually doing. So one of the really big problems in NumPy with all this np. stuff is that whether you write something with an np. or not has no correlation to its meaning. It's like what operators existed in Python. And actually, I've worked with this a little in BQN's multi-paradigm thing. You can tell visually when something in BQN is good old-fashioned array code. And you can also tell if it's-- well, you can tell if it's tacit because it's got no variables. And both the variables and the namespace export use these double strokes. So the namespace export is a doubled arrow. And that gives you a visual signature to say, well, now I'm working with something that's got more names in it, moving more values around. So having this distinction between, at the very least, symbols and words might help you see what the code is doing, like be able to approach things more consistently.
00:29:53 [BT]
And a very similar thing happens with J, because J's got the control words that show up as, you know, if dot.
00:30:01 [ML]
Yeah, and those have a pretty distinctive look.
00:30:02 [BT]
Yeah, and you know, as soon as you start to see control words, somebody is programming sort of in a different way, as opposed to tacit code or even explicit code that's just linear and feels more array-driven. And the other thing I'm thinking is, Stephen invokes beauty, but I'm thinking the one distinction we're not making, or at least maybe in my own mind that should be made, is the difference between something being pretty and something being beautiful. And pretty is often what I think of when I think of glyphs, but the beauty is actually, as Marshall was saying, in the power of the glyphs reflecting what you're doing. And beauty has a power that pretty doesn't. And so you could have very pretty glyphs, but that doesn't mean the same as having a beautiful glyph that reflects what you're doing. And I think that is where that power comes from. And that that power is maybe something that isn't always recognized when somebody starts with an array language, and in fact drives them away when they start because they can't see what that glyph is telling them is going to happen, because they're not even thinking in terms of arrays at that point. They're thinking, "Well, okay, so a slash with a bar through it, that does a loop? Huh? That doesn't make any sense to me."
00:31:20 [ST]
Beauty, by the way, is more usually pronounced "cool" in this business.
00:31:24 [BT]
Well, that's how you pronounce it.
00:31:27 [CH]
Yeah, I would say too, I'm one of the things I jotted down before we started recording too, which ties into this whole conversation of beauty is that I've, because here and there, I've been doing the code golfing, [04] making my way to the top of the leaderboard as one does. And all I do is I solve the problem in whatever the top solution is in. I have no interest in solving a problem if it's not going to get me the number one spot. And all of those languages have been J and q. And it has made me think, like, what is, or what are people's opinions on what is the actual epitome of elegance for an array language? Because we've got languages like k, and one of the things that I've learned about k, correct me if I'm wrong, folks that may or may not know, is that k has an equal, but it does not have a not equal. And that hurts my soul. Coming from array languages that always, and so to contrast k and J, J has an abundance of operations due to the fact that it has multi ASCII character glyphs. It's also got single ones, but it's got single and multi. And it's, I'm hoping to give a talk in, later this year, called Dreaming in Combinators, which is going to be a talk about basically like falling in love with J for the purposes of code golfing. Like I find myself sometimes, I literally like dreaming, like, oh, how do I flip this around? Because like so much of it is, you have to think in combinators and realize that like, oh, I should actually prefer the Phi combinator in a monadic fork, where I use the left time as the identity instead of an S combinator. Because if I use the S combinator, the hook, I'm going to need parentheses. And if I eliminate the parentheses by replacing it with a monadic fork and just a single tack, we're good to go. I saved one character there, which is ridiculous. I've never had to think about stuff like this before. But like, if you can save one character, that's the whole point of the game here. So k doesn't have things like not equal. And so you need to, it's more elegant in that everything is a single keystroke, but some operations are actually multiple keystrokes because you need to compose things like a compliment and equal in order to get not equal. But then on the other side, we have J, which may be less elegant because you got to make sense of the dots and the colons, but you have everything. You've got p colon, you got q colon. And then you've got things like we want APL, BQN that have symbols that there's a, you know, higher barrier to entry because everyone's like, how do you type that? And then you got q that has keywords and some beautiful keywords like differ. I miss differ, you know, differ in a language like BQN, differ is hard to spell in BQN. And it might even only be a couple extra character strokes in q. Differ being a not equal two-wise reduction. And so like languages like Uiua or BQN that don't have an N-wise reduction, you have to do a, there's a couple different ways. But the shortest way I think is doing a two windows and then a row-wise reduction, not equal. Which is like, it's like four or five characters or something like that. Anyways, I'll throw it over the panel. So, you know, what is the epitome of elegance when it comes to array languages, when you have your choice between single ASCII, multi ASCII, symbols and keywords.
00:34:38 [BT]
Well, I think there's a context to that question. It depends what you're trying to do because it it seems to me like the the interview we did with Stevan Apter, he talked about how k allows him he said, you know, k is a pretty simple language. It allows me to do things quickly and I think about them And then he mentioned J and said I I'm intimidated by J because there's so many different glyphs There's so many different ways I can go There's so many it doesn't really speak to me about how I do this if you start with a relatively Smaller set of tools and you learn how to use those tools really well Then it feels like it's got more power. Even if you're using more um More characters to do it on the other side of things. You've got jelly, right? Where you're taking all these glyphs and you're just making them giving them assigning them specific duties So that you can minimize on your cold golf at the same time It's building on the same kind of combinators and things that give you the power of the language and jelly came out of J so it's almost like we took the the number of operations and functions Out of J and just said well, you know what we could make all these a single You know a single character and then we'd have a real but it doesn't get away from the fact that still If you know those characters you can spell things in ways that are is very powerful so Do you go with the k version where you reduce your tools? But you learn them learn more about them or do you go with the jelly version where you've got these huge range of tools? It just depends on what you want to do
00:36:11 [AB]
Conor's asking about the most elegant things can be. Surely, arbitrary restrictions of the underlying technology, hardware even, shouldn't define what the language is supposed to be if it's supposed to be elegant. It may be practical like that, it may be practical to use ASCII only, but surely that doesn't come into elegance, right? Just like you can have designers design a house or a car or something that the engineers will refuse to build because material science can't keep that up. But that doesn't change that the designer would like it to look like that. And so having to use multiple glyphs from ASCII, that's just catering to the environment at the time. Unfortunately, Unicode was launched immediately after J. And even Jelly, actually. Jelly does not give one symbol for each thing. It is intended for CodeGolf, and so it tries to assign meaning to individual bytes in a custom code page. And so it's restricted to 256 because of this arbitrary decision to use 8-bit computers in the IBM 360. And in order to get even more functionality in, it does use byte glyphs as well. So it has like prefix glyphs that mean that the next thing means something else, kind of like quad in APL, or like the dots and colons in J. And the specific glyphs chosen are just those that you can type on the US international keyboard. Again, it's catering to something arbitrary, external. Surely that's not as elegant as things can be. There would be better symbols for it. And even today, when we add glyphs, well, to a Dyalog APL or say, Uiua or BQN, we choose things that are already included in Unicode's character set, because it would be very awkward to get Unicode to add more glyphs because we want to use them in a language. But potentially, it could be done, or you could use private use area character. I believe the Wolfram language, Mathematica, does this. And I'm wondering why they have a private use area character for the transpose symbol, like a superscript capital T, when there is a superscript capital T in Unicode. But hey, that's how they chose to do it. And maybe to prevent people from pasting their Mathematica code anywhere else. So I would say that the most elegant is unrestricted, right? Don't think about how you're going to do the keyboarding or what the names of things, these are going to be, how they're going to be represented in the computer. Ultimately, I would like to have my thoughts flow directly into this symbolic notation that I can read back somehow and not care about all those technical details.
00:39:07 [ML]
But I do want to say, unrestricted, so yes, it is best to be not restricted by the sorts of characters you can form. But still, and this is going to depend on what kind of language you're designing, it's not necessarily good to just keep adding primitives. So one principle that I have, which I don't know how successful I was at it, but a principle that I considered when designing BQN is that the language should kind of set you up for success in that people are naturally going to prefer to use glyphs when they're there. And so the choice of glyphs should push you into using algorithms that are first going to have fewer corner cases that are going to be maintainable in the future. And that also, so a particular thing is that you can modify if it becomes necessary. Like for example, talking about prime stuff, if you have a function that gives you the totient function of a number, I mean, yeah, this is a useful function in mathematics, but it's pretty easily calculated using the prime factors. So I think of just providing this function as sort of less elegant than providing a way to factorize the argument. And then you can pretty easily compute the totient function [05] from those factors. And that's the efficient way to do it as well. So it's not that like you can't provide the totient function in addition to the factorization, but I think if you're providing a bunch of big compound functions, then it sort of brings up the issue of what you do if this function is not exactly what you want.
00:40:50 [AB]
What do you mean by compound functions here?
00:40:53 [ML]
Well, so like the totient function is not, it bundles in a lot inside of it. And that's maybe not the best example, because it does have a more natural definition that's just computationally very inconvenient. I mean, I guess I think of stencil as one of these that does a whole bunch of stuff at once. So stencil is moving along the argument and picking out subarrays of it and applying a function to each of these subarrays. There are many natural variations on that sort of operation. So if you write code with stencil, it may happen that eventually you have different requirements and stencil no longer meets those. And then you have to rewrite the code. If you write the code with something different that is actually representing the way you're traveling along the array, often you can tweak it and get the new operation that you want. So it's kind of, and this is also where the idea of orthogonality comes in. You want to be able to split your operation into what it really means. And I mean, it's kind of hard to say, you know, sometimes maybe that really does mean writing it in a more C-like style that operates one element of an array at a time. But I think in practice, it actually doesn't. And an array paradigm works very well for that. But I've found that at least when I write programs, they're a lot more maintainable if I'm representing them in terms of a more limited set of simpler primitives. Because then when I want to change something, it's just a change to one part of that as opposed to having to break apart this big complex operation.
00:42:38 [CH]
I think the quintessential example that comes to mind and I know this has come up on the podcast before is like Splitting functions like in Haskell. There's like a data dot list dot split and in APL there's the partition and close or enclosed partition the two different ones like the the left shoe and shoe underbar and A lot of the times those are what you need But some of the times what you want is like one of the 20 or 30 functions that is in that Haskell library Which is like split after split before split after drop split before drop like there's all these tiny variations of splitting functions and like I have a whole taxonomy in my head. I call them cuts and like there's integer cuts There's unary predicate cuts binary predicate cuts and like you can Using partition and enclosed partition in APL get your way to each of those But a lot of it it ends up you're rotating masks to figure out or you're switching from one partition to the other partition in order to drop elements and At the end of the day like the question is is like should you add 20 primitives for all the different splits or should you try and put the two splits in there? that you think are the best ones and then Let people mess around or should you keep them out of the primitives and then like add a library? That looks very similar to the Haskell library data dot list dot split and then just like hand roll those all yourself So each time you want one you're just reaching for the you know split drop before or something like that I Don't I'm not saying I have the answer. It's just it's definitely a non obvious problem to solve when designing one of these languages
00:44:11 [BT]
Or you could split the difference and kind of do what J has done in terms of fold, right? Where he's created this mechanism that you've got this, I guess, glyph which is followed either by a dot or a colon and the way they're followed ends up how you're doing your reduce and your scans. And it gives you all the power, but it's, at this point, is really kind of a library because it's not even written in C to be able to optimize its speed. It's still written in J because it's still in the process of, I guess, being able to be changed. But I think the thing that you gain by having something like fold is if you try and do that by yourself, it's doable from the existing primitives, but there's an awful lot of opportunities to get it wrong. Whereas if somebody's got it right, you can kind of pick that tool off the shelf. Now the question is, I think Marshall's coming up with the orthogonal argument, difficult to say, is that you want to make sure each of those tools is really sharp. And maybe one of those tools is kind of blunted because it wants to fit in a number of different areas. But if you have really sharp tools, it's easier for you to use them appropriately. And you would create from the beginning more often, but you know what that tool is going to do, and it's a really good screwdriver, and it's a really good hammer, and it's a really good saw. But it's not a combo thing that might do it most of the time, but sometimes it gets you into trouble.
00:45:47 [AB]
So there's a balance to be struck here. Ultimately, we want to optimize for the programmer's time. And if we give the programmer a Swiss Army knife that he can't lift, it's got the tool for whatever he wants to do. It's got the tool, but he can't lift the tool. Or just give him a chisel and a hammer or something like that, and you can go from there yourself. Then you'll have no problem having an overview of the tools available, but it will take him a long time to get the task done. So there's a balance. And it may even be that it's not the same for everyone. Some people can handle a larger vocabulary. Some people can better handle a small vocabulary.
00:46:34 [CH]
Go ahead, Stephen.
00:46:35 [ST]
Let me come back to Conor's original question, what's the epitome of elegance? Because my answer to that, I'd frame quite differently. For me, the epitome of elegance is when I can write the solution as a line of unary operations. To elaborate on that a little bit, I'm remembering something of what Arthur told me that Ken Iverson used to think of as even binary dyadic operations as a sequence of unaries. So 2 plus 3 times 4 times 5 is like 2 plus is the unary, is the monadic, four times and so forth. That feels to me the most I can get of elegance when I've got it written out a solution. You started on the right, you did something, you passed the result along, you did something else, and so on.
00:47:28 [AB]
Well, I definitely miss that sometimes, the ability that you have in k to just put one argument next to a function, on the left of a function, and have it bind together, because that's more elegant than having to reach for an operator conjunction to bind them together.
00:47:48 [ST]
I go back to a very simple example, fizzbuzz, because this illustrates what I was asking at the beginning. What is it about thinking, the vector thinking, that seems so different and so powerful? If you write a solution to fizzbuzz in a scalar language, it goes something like, here's my number, does it divide by 15? Yes, it's fizzbuzz. Does it divide by 5? It's buzz. No, it divides by 3, that's fizz, otherwise print the number. Next number. There's nothing difficult about that, but it's kind of an oodsworth thing. But if I tackle it in a vector language, I start by taking all my numbers and I say, divide all of them by 3 and by 5. Do I get any zero modulus? So do a knot on all that lot. So I turn my massive number, massive integers into ones and zeros. That gives me a Boolean pair for each number. I can map that to them with a 2N code, a 2SV and q to the range 0 through 3. So now I've got, for each of my numbers, it's been mapped to 0 or 3. And I map those into an empty symbol, a fizz, a buzz or a fizzbuzz. And then I fill up the empty symbols with the original numbers and I'm done. I am at a loss to explain why I find that satisfying and I like coding that. I just feel like I'm wasting my time writing the one potato, two potato approach.
00:49:33 [ML]
I don't think I do find it satisfying in that case, but also, I mean, for me, I think the reason for that is that I can guarantee this problem was created by a scalar programmer.
00:49:45 [AB]
So well, I mean, it's an old game, but Stephen, I think you answered the question yourself because you said that something else feels like a waste of time. So that fits nicely with something I'd like to quote. And then you can guess who wrote this. The whole idea of a higher level language is this. Programming time is very dear. Let's use the computer to minimize it. As computers become cheaper, this strategy becomes ever more valuable. Computers are now very cheap. In the room in my house where I'm writing these words on a computer system are no less than three computers. The most expensive piece of equipment on an hourly basis is me.
00:50:32 [ST]
This is the ArrayCast Pub Quiz.
00:50:34 [BT]
Well, I'm going to say Ken Iverson, because to me that would be something that Ken would say.
00:50:38 [AB]
Yeah.
00:50:39 [ML]
It sounds a little like Perlis to me, but I don't think it's him. Alan Perlis.
00:50:44 [ST]
Roger Hui.
00:50:45 [AB]
Any other bids? You'll be surprised. Conor is going to fall off his chair.
00:50:50 [ML]
It's not someone mainly known for array programming, is it?
00:50:55 [AB]
Yes and no. This is Jef Raskin. Anybody know who that is? [06]
00:51:02 [BT]
That was Apple.
00:51:03 [AB]
That's Apple. He was the one who came up with the idea and led what was called the Macintosh at Apple, which is, I guess, predecessor to what loads of people have on their desks and in their pockets today. And so when they were hashing out this Macintosh project at Apple in '79, he wrote up a bunch of stuff about that. And he envisioned that the Macintosh would have a calculator. And that calculator had to have a language, the Apple calculator language. And while he does say about that, you think it's like coincidence, Apple, you know, APL, that kind of thing. He says, "The reader might well comment that the following language seems similar to the work done by Kay Iverson over 18 years ago. Apple is based on a re-spelling of Iverson's work." So that is APL. "Even the name Apple might seem derivative from the name he chose for his language." And so he goes on to describe a language, a simple language for this calculator that he envisioned would be the language for the Macintosh calculator. And it is, I mean, he speaks about APL again and again, and it's clearly derived from APL trying to simplify some things and get rid of some annoyances that he has. It's a, interestingly, it's a left to right language, mostly symbols for central things, but also some keywords. What I want to bring from this is exactly that point. It feels like a waste of my time to do something else. That which Conor brought up at the beginning as well. I try to use these other languages and it feels like a waste of my time. Once I know that it can be done better. I don't know why it didn't pan out this way. And today we've got other programming languages being used on Apple's devices. It should have clearly have been an APL derivative that would be the programming language and the only language on all Apple devices. But hey, it should have been an APL that was the programming language on Microsoft devices as well. But Bill Gates gave up on that because he thought people would pirate it, I think. That was the main reason. And there was some resistance from people around him. But don't waste my time having me write things in awkward programming languages where the computer needs to do less work and I need to do more work.
00:53:33 [BT]
I wonder whether there's actually a predisposition in human beings to take the one potato, two potato approach. And then for that reason, if Apple had decided to go APL-like and IBM had decided to go APL-like, but Commodore hadn't, maybe we would be how universe work. Commodores were the predominant, you know, computer, because they took a paradigm or a way of thinking about things that seemed more attractive to people who might not instinctually think about things in sequence. And that step back to think about the whole may be a slightly different... I mean, to me it doesn't seem like such a big jump, but that may be because I've made the jump. If you haven't jumped over to think of things in the whole, maybe that's too big a jump. You want to always think about one potato, two potato, what's the next one? next one. That's how I'll solve the problem, oh that works. No?
00:54:33 [AB]
I don't think so. I think we can have a very clear indication that this is not the case. People who have tried teaching array programming to other people would quickly find out that somebody who is new to programming, or say young people, pick it up very easily. And those people who have been exposed to the potato approach have a harder time grasping or switching to that mode of thinking. So it would seem that human nature is able to do array programming, maybe just as well or even better than one thing at a time, but language influences how we think.
00:55:18 [BT]
Well, maybe it's it's almost like a crystallization though with what you say is true If a person hasn't been exposed to the one potato two potato approach, they're exposed to the whole that comes quite naturally But that's instructed that doesn't mean they would have picked it up on their own That means somebody has said would have picked up any of those approaches on their own.
00:55:39 [AB]
Is programming natural to people?
00:55:41 [BT]
Um, I always think of it a bit like cooking and I do think of cooking sequentially. It's if I'm looking at trying to prepare a dish I might look at the whole Almost as a meta thing saying what I want to do what I want to accomplish with cooking this, but when I actually get down to the production, I'm doing step by step
00:56:01 [AB]
Yeah step by step, but you still have to do things step by step in array programming But come on when you have a cooking recipe It says add the remainder of the ingredients or add the eggs Surely doesn't said add add an egg if there are more eggs add one more if there are more egg, right? And then until there are no more eggs then continue to the next step Nobody would ever write that
00:56:20 [ML]
Yeah, I mean an old-school APL program consists of steps and that's the same thing you're doing in cooking. It's just that the steps can deal with any number of ingredients and you know, you as the cook, you're the CPU. You're able to evaluate that by cutting up each individual vegetable or whatever.
00:56:41 [AB]
Yeah, I think it's very telling that, and I've been wondering about this actually, for specifically cooking recipes, they very often split up the ingredient amounts with instructions. Why doesn't it say add two eggs? It says add the eggs and then somewhere else in the recipe it says that you need two eggs and when you go in the steps then you have to look back and see what was the value of those eggs. So that seems inherently array-based to me and perfectly normal.
00:57:09 [BT]
And I think it's the difference between actually cooking and following the recipe as opposed to creating the recipe. I think to create the recipe you have to think in more of an array based thing. You think about your ingredients as a group. You have to go collect them, bring them all into one place and then you take your steps. And that's why the ingredients quite often are separated from the steps. But then as well I think somebody who's creating a recipe has to think about the timing and a lot of things on a wider scale that are not so much step based. Because if you did step based suddenly you get to the point where you should put it in the oven, but you haven't preheated the oven. Oh, oh, oh, okay, so now if I'm actually creating the recipe, the first instruction I give is preheat the oven. Because I'm thinking of it as a whole. But I'm not sure that way of thinking is always the one that first occurs to people when they're trying to accomplish a task.
00:58:06 [AB]
But that's more a parallel programming issue than it's a one thing at a time while the oven is heating do these other things But it's not One item at a time unless processing of an item takes a very long time. They need to kind of account for that But recipes will only spell out should we say explicit for loops if they need that add the eggs one at a time if that's necessary, the default is array-based
00:58:37 [ML]
Well, and not only that, if there are multiple ingredients that are to be handled in the same way, it'll tell you dice the tomatoes and the peppers and whatever like that. So even at a higher level.
00:58:50 [AB]
Or even group them with a common name. It might even dice the vegetables.
00:58:55 [BT]
Mix dry ingredients.
00:58:57 [AB]
Yes. Yeah, exactly. No, I think humans are very good at thinking of groups of things. And even the way we memorize and keep things in working memory, if you try to make humans deal with too many individual things, they lose track. We have things like how many digits can people remember? How many items can people remember? If you group things into wholes, they can remember, say, seven, eight, nine of those groups. If you try to do it in individual digits, so they can only remember seven, eight, nine digits. Humans are very good at handling large amounts at once. Even more so, an amazing thing that humans can do is we look out through two eyes at the same time for most people and immediately gain an understanding. This is apparently very difficult to get computers to do right. And even when we think we've got it right, then you just put a sticker on the stop sign and it thinks it's a turtle or something like that. We're clearly processing everything very much as a whole, not as individual things. We don't think about the individual pixels in our eyes in any way.
01:00:04 [BT]
No, there's certainly that going on, but the other thing I think is that when you're trying to accomplish a task, not when you're trying to write out the instructions for a task, but when you're actually trying to accomplish a task, I think we're naturally predisposed towards thinking step by step. Now, you're right, we wouldn't ask for each egg to be put into a recipe. We'll say put the eggs in, that's a group. But the point at which you put the eggs in is still a step, and it has to come at the right process. And the person who's thinking of it more as a whole is the person who's writing the recipe, not the one who's executing the recipe. I think with the array languages, the vector thinking that Stephen's talking about is essentially training people to be more like a chef, somebody who's going to create a recipe, as opposed to somebody who's going to execute one.
01:00:58 [ML]
Yeah, but I think it is worth pointing out that there's a lot in APL that doesn't come naturally to people. It's not like you can just tell somebody the basic concepts and they'll be able to program. So something that a lot of people have trouble with is grade. [07] This idea of taking a list of unordered things in and getting a specification for how they should be ordered out. That's not very natural to people who would be coming to APL. So the broader idea of this programming in terms of whole collections, I think, is for most people, that's the right way to do it. But I don't necessarily think APL's operations are the best manifestation of that if you're trying to be just approachable to people.
01:01:42 [AB]
But I think in general. Meta information to reach the goal. It's harder for people to comprehend, to comprehend like another greatest one. It's the meta information you need in order to sort nub sieve or indicate first or whatever you wanna call. It. Is the meta information you need in order to find the unique elements and that would be equally difficult for people to kind of think of. These are not concepts that we. Think in terms of us humans like to have everything very concrete and that it's very hard to describe our name. These intermediary things that are only really necessary for a for a technical reason, not for practical reasons.
01:02:21 [BT]
You see, in those cases, I think that strikes me as tools that are very sharp. Grade is a very sharp tool, and it can be used to create a sort. But the point is, as a grade, it's so sharp that there's a benefit to leaving that as grade because having that so sharp, I can use it for other things as well. Or I could just create a tool that is sort, but then I lose the power that grade itself has.
01:02:51 [AB]
I like your analogy. We got super sharp kitchen knives at home, so why do I need normal eating knives? Anything I can do with a super sharp chef's knife, I can...
01:03:03 [CH]
I mean, this is a bad time for me to interrupt, but I do have a predisposition to eating things with my sharp knife from the little thing Even if it's supposed to be like a minute steak, not that I've had a minute steak in years But like, you know when I had them growing up, you can cut that with a butter knife but why would you want to struggle even in the slightest when you could just slice through that bad boy with a nice non serrated. I don't want a serrated knife I just want a sharp knife from like the little you know, what is it a knife holder thing? So that's the wrong time for me to interrupt, but I just want to say
01:03:40 [AB]
No, no, it's but it's good. But why do you need the butter knife at all? You can surely cut your butter using that super sharp knife
01:03:48 [CH]
Great point that's I've had the same thought of lowercase letters my whole life. Why do we have them? Folks? Doesn't make sense. What are they adding? Nothing.
01:03:55 [AB]
They're double. OK, so uppercase.
01:03:56 [CH]
I used to write all of my I what I mean used to, I mean I guess I don't write essays anymore, but in school I would just write in capital letters and then make the start of a sentence like a larger font like. I just don't understand why we have lower case letters. Why?
01:04:11 [AB]
Uh, I mean. Different shapes for them.
01:04:13 [CH]
Is like, yeah, we, we, you're doubling the number of letters kids have to learn. For what? What's the point?
01:04:19 [AB]
Well, just be happy and not doing Cyrillic, but they've got four different ones because they italic ones are entirely different than the operate ones.
01:04:25 [CH]
Yeah, that sounds terrible. That sounds terrible.
01:04:27 [AB]
But but I mean, OK.
01:04:29 [CH]
I just like I would like it to be noted on episode 81. No one had an answer No one had an answer folks.
01:04:36 [AB]
No, I do have an answer for you Conor I do. The lowercase letters are useful to well They could to do two different reasons lowercase letters are more distinct in the outline than uppercase letters that usually fit into pretty much a rectangle and to make it much faster For people to immediately spot them a word read a whole word at a time rather than one potato to add one letter At a time
01:04:59 [CH]
What? First of all, that's not even it fits in a box better The only letters that go below the line are lowercase letters. What are we doing G? What are we doing q?
01:05:08 [ST]
That's the point.
01:05:13 [AB]
That's the point, that the letters that stick out make every word have a distinct, immediately recognizable shape, so you don't have to read one letter at a time. Uppercase letters, and especially if you do monospace, there's nothing distinct about the letters anymore. You could also say, why don't we just have bit patterns, little dots instead, which you do have in braille, but it's faster to recognize things that are more distinct. I think Marshall even discusses this about BQN, about symbols being distinct. If you try to make things too uniform, then readability suffers. It's good for humans to have distinct items, whatever it might be.
01:05:52 [CH]
Maybe for reading, but for writing.
01:05:53 [AB]
That's one reason.
01:05:54 [CH]
And we live in a day and age where I can write in all capitals, and then when someone has to read it...
01:05:58 [ST]
You mean type not write?
01:06:00 [ML]
And no one will read it.
01:06:01 [AB]
Yeah, that's another thing. Writing uppercase by hand is hard. Writing lowercase, connected letters can be fast. But another reason why you want uppercase, lowercase letters is because it can be meaning-bearing. It would be insufferable, that's the right word, to write BQN using only one case. It would just not work. You'd not get anything done.
01:06:23 [BT]
In terms of English, you have the uppercase letters start each sentence, so that helps. And your proper nouns should all start with uppercase. So you can...
01:06:33 [AB]
Some of it is just convention, but some of it can be important. In German, still uses a convention where nouns are uppercase. And Danish used to, until after World War II, when they wanted to get rid of any trace of German-ness in Denmark, so they changed it to lowercase all the nouns. And that gave a problem. When people came into the doctor's office, there's often multiple doors, and they will say, you know, the first door goes into the actual doctor's room, but you need to go to the next one, to the waiting room. And so it used to say, the next door, which is "de næste dør" in Danish. And the "d" in "dør" is uppercase because it's a noun, next door. And then they lowercased it, and you might as well read it as "de næste dør", which is spelled the same except lowercase, and it means the next one dies. So sometimes it's very important to have lowercase and uppercase letters.
01:07:26 [CH]
I would just make I want to rebut by saying this argument of the Denotation or the semantics that you're trying to communicate can be achieved With one set of uppercases and just different sizing font like I said I still would put a capital T like just a bigger T at the start of my sentence and like I was thinking sure Okay, you're learning English and you don't know what an Oreo is and you see a lowercase Oreo you are you confused? No, you just make the Oh bigger just make the Oh a big Oh and so like I agree that semantics can be conveyed but that same Semantics could be conveyed with just a single set of 26 letters in in English like there There are other things that I agree, but also you gotta here's some context I was the guy that read George Orwell's 1984 and when my dad asked me what I thought I said some good ideas in there, you know double good triple good You know double great. Let's simplify the language. What are we doing with fantastic and amazing? What do they even mean? Can you define the difference? No, you just like wonderful fantastic amazing. They all mean the same thing Let's let's get rid of some of the the surplus words double good triple good now we're talking I thought that was a decent I understand not the point of the book. My girlfriend's laughing in the background
01:08:38 [BT]
Since your dad is a journalist, I would have loved to be in the room when that...
01:08:39 [CH]
He was quite appalled. He was like, do you think that's what the point of the book wasn't I was like I understand its not the point of the book. I'm just saying I get that They're trying to present it as like oh, what was me? They're destroying, you know art and literature and I was just like Is it actually a terrible idea? You know, we're not sure. What's that language? Um, I can never remember the the universal language that we're gonna send to the aliens.
01:09:03 [ML]
Esperanto. I didn't know about any plans with this language.
01:09:06 [CH]
Yes. Well, that's in in I think three-body problem which is a Netflix show and book series that it was based on they send a bunch of stuff to space and I think with it they send Esperanto because it's was a computer science created language That you know gets rid of all the bloat and it's just minimal need for a communication. I'm not saying we should go that far I'm just...
01:09:31 [AB]
Esperanto is just a, like a harmonization, what do you call it? Like, like a simplified... It's a synthesized language. Yeah, but it's, it's comes from the Latin based languages anyway. It's not completely made up from scratch to be ultimate in any way. Making it easy.
01:09:48 [ST]
And if it's got a small vocabulary, it's probably because there's not many people speak it.
01:09:51 [CH]
Yeah. I just had an amazing realization too. Scrabble, [08] favorite game of all time. Doesn't have, doesn't have case, lowercase, uppercase. So it's just got uppercase. Now we're talking, now we're talking folks.
01:10:03 [AB]
We don't need a lowercase. What's next? You're going to simplify English spelling as well? And get rid of the letter C?
01:10:07 [CH]
Don't get don't get me started on the English language and how complicated it is.
01:10:13 [BT]
I've got an idea, Conor, for Scrabble. Yeah. How about if we just take the numbers off the tiles? How would you feel about that? We can still score. Would that make it easier for the writer and harder for the reader?
01:10:18 [CH]
We can still score.
01:10:20 [BT]
For the writer and harder for the reader.
01:10:22 [CH]
Do we get to still score the points? Like, cause I, I've got the score, the values memorized. We don't need, I technically, I have a Scrabble game that I wrote where I added the numbers to the tiles for the visualization, but then I didn't like the way it kind of looked asymmetrically. So I just got rid of them. And you know, I know I'm in my head and I'm the only one using the game. Right. So it doesn't matter. But wouldn't it be, it would be simpler if you had the same score for every, every piece. No, but the game was designed beautifully to weight the score of each tile based on the frequency and the difficulty to use it. You should get more points for playing the tree sequoia as a bingo than you should for some other tree that doesn't have the q in it.
01:10:59 [BT]
I think it points out that your whole object of communicating is how easy it is for you to write, not how easy it is for somebody to read.
01:11:09 [CH]
Yeah, yeah. I mean, well, when you're writing essays in school, it's not because I want to, it's because it's a provincial exam and they asked me to opine about something that I really don't care about. Well, we cut out a lot of overhead by just removing the essay. That would be fantastic.
01:11:28 [BT]
But I really think in general terms, the idea of writing something down is so somebody else can read it. Although there is a secondary thing of thinking as you write, and that's very important, but mostly is in terms of communication. You're writing for the reader.
01:11:41 [AB]
Hold on, it depends what you're doing. Sometimes I just need to get a job done. I have some dirty data, I need to import it. I'll write some ridiculously long APL expression to just import it once and be over with it. It doesn't matter if it's readable to anybody, even myself afterwards. I just keep adding more stuff until I get the darn thing in. There are different goals with things. If you're writing notes for yourself, you might write some kind of shorthand that only you can read. And if your goal is to describe an algorithm, then you can do something like what Iverson did with Iverson notation, where you even leave things out. You don't have to specify the length of this thing because you can infer that from the length of that thing. The only thing you need to do is some pseudocode that conveys a message. There are different goals with writing things.
01:12:34 [BT]
Absolutely no argument there.
01:12:35 [ST]
Well, I think you should get extra points for Q. That that, that's why that's that's why we devise Q2O1. See a little Scrabble Q Scrabble tile with Q1 and 2O.
01:12:48 [CH]
Oh, wow. What a... Stephen, brilliant comment. Wow. What a moment. You've just... Wow. Wow. Top 10 moments on ArrayCast. I never realized that. q, 10 points in Scrabble. J, 8 points in Scrabble. k, 5 points in Scrabble. These are the highest... These are the highest scoring tiles. We're missing X for 8. Wow. And Z for 10. Get on it, folks. We need an Array language X and an Array language Z. Look at that, though. Of the five highest scoring Scrabble tiles, three of them are popular Array programming languages. This is like Illuminati stuff here, folks. First, having the realization that all the Scrabble tiles are uppercase and now that. All right. We were supposed to land this plane like 15 minutes ago. But the hounds are chasing us. So, here's what we'll do. We'll do a final round, Robin, of final thoughts on any of the of the questions that were asked. I mean, the first one was, you know, what are the APL inspired things or array language inspired things? What are they missing? There was a couple other questions along the way. Feel free, final thoughts, comments. I have three, and these are gonna be totally random. I've just been storing them in the back of my head for like the last half hour. One is that the fold in J, I don't think it's just the dot and colon. There's six of them, right? There's dot, colon, colon, dot, dot, colon, colon, colon, dot, dot. So you brought the example up, and then I was screaming in my head, yeah, like, and I think even Rich said that it's hard when you get to this point to design something elegant 'cause you have all these different flavors, then what do you do? So I was thinking that in my head. Second point was that, I think, Stephen, you made a comment that is extremely topical 'cause I had the exact same thought literally just yesterday was that trying to get to this composition of monadic functions in a row, just a sequence of unary functions, it is like one of the epitomes of elegance in programming. And I was writing some Haskell code where I had to do this like zip width, equal, equal, S combinator, tail, and then I was writing it as the more verbose way of spelling something using a map adjacent, basically a two-wise reduction. And the two-wise reduction basically formed a unary function and it was so much more elegant. And I had this thought like, the best code when you're writing in Jello or J is just like function, function, function, function, function, function. I don't need the combinators. Technically, it's just the B combinator, unary function composition all the way down. So there's something there. And then my last thought is that in the day of, in these days of LLMs, is this whole conversation moot is a thought that I have in the back of my head because I'm able to do like ungodly things with Python now, like matplotlib. I don't even need to know what the library is. I'm just like, I would like a PDF, 50 pages long with this graph, blah, blah, blah, blah, blah. And the LLM just goes and does it for me. I need to know Python to be able to tweak it the exact way I want. But like, can I do that with the array languages? Not right now. And that could mean that like the richer just gonna get richer. And in like 20 years, all there is is us speaking to computers, like with our voices, and then having that computer craft some stuff in the background. Anyways, that was way too many thoughts. It was supposed to be like a 30 second round, Robin. I'll go to Adám 'cause he's to the right of me on the screen and then Marshall, then Stephen, and we'll finish with Bob.
01:16:13 [AB]
Well, I think I'll take another thing from Jef Raskin in this paper. We can leave a link in the show notes to it, of course. It's a living that live. I think we achieved the most agreement here on the people on the podcast with their different purposes to writing. Whatever suits you, right? If you find it tedious to write in one programming language and you find it pleasant to write in another one, all means use that one. There's nothing wrong with using any particular language. You have a limited lifespan, and so use it the best way you can.
01:16:55 [CH]
Marshall?
01:16:56 [ML]
Yeah, so one thing I... The conversation kind of moved on when we were talking about me and J. I never... I mean, you could say I fell in love with J, but I never thought, you know, this is the best possible programming language. I mean, I thought, you know, there must be some other good ideas out here. And then I tried these other languages, and I only saw the differences that were bad. So I thought, well, these languages are just purely worse than J. And much later, I kind of figured out that this is not really true. But I had tried to translate my J knowledge into the other languages, which hadn't really worked. And I'd concluded that these languages had nothing in them. So I think there's a lot of... I mean, when you're programming, yeah, pick what overall is comfortable for you. But if you're questioning the ideas about language design, you really need to understand each language and figure out, you know, what in the language works and what's good. So one idea that is maybe starting to make it into array languages, but that kind of takes some work to fit in is pattern matching. So that would be an interesting thing to see more of in array languages in the future.
01:18:08 [CH]
Stephen.
01:18:08 [ST]
Stephen moving on to the next question in theArrayCast pub quiz Besides being very very smart. What do Sherlock Holmes and Arthur Whitney have in common? Answers on a postcard, please. We'll reveal all next time.
01:18:23 [CH]
Amazing, amazing and Bob.
01:18:26 [BT]
I'm not sure how I followed that I'm gonna be googling like crazy.
01:18:33 [ML]
Um, I was well just name two other random people and ask what they have in common [LAUGHTER]
01:18:38 [BT]
One of the things, and I was going to go a different direction, but when you mentioned the LLMs, I'm wondering whether what we're doing is giving the LLMs [09] the role of a chef who creates the recipe, and we're most happy following the instructions. And that to me is a bit chilling when you really get down to it, because as long as people are able to create recipes, they're able to adapt them and they're able to understand them much better. But if we give that role of creating the recipe over to something else, we lose a skill that I think is really vital and seems to be, to me, passed along in the Array language almost as a mentorship. But that's just sort of my conclusion out of this whole thing. Lots of things to think about. If you have thoughts, and I'm going to wrap this right into what you want, Conor. He just smiles away. If you have thoughts, you can get in touch with us at contact@ArrayCast.com, and we welcome your questions and your observations. And I think that wraps it up for me. This has been fascinating.
01:19:43 [CH]
This has been fun as always, and with that we will say Happy Array Programming.
01:19:47 [ALL]
Happy Array Programming.
[MUSIC]