Transcript
Transcript prepared by Bob Therriault, Igor Kim and Sanjay Cherian
00:00:00 [Christopher Augustus]
We're in a complexity crisis. We've been in a complexity crisis. And everything I do now is about simplifying, reducing complexity, reducing complexity, because every line of code you write increases complexity. There's so much stuff that's additive and almost nothing that's subtractive. And this is this mess we've created for ourselves. If you go back to Brooks, 90% is accident, 10% is essence. I'd say it's more like 98%.
00:00:32 [Conor Hoekstra]
Welcome to Episode 78 of ArrayCast. My name is Conor, your host for today and for always. And before we get into our announcements and an announcement from Bob, we're going to go around and do brief introductions. So we'll start with Bob, then go to Stephen, and then go to Marshall.
00:00:45 [Bob Therriault]
I'm Bob Therriault, and I am a J enthusiast.
00:00:49 [Stephen Taylor]
I'm Stephen Taylor, and I'm fairly enthusiastic about q and APL.
00:00:54 [Marshall Lochbaum]
I'm Marshall Lochbaum. I'm the creator of BQN. I've worked with J in Dyalog and a little bit of k in the past.
00:01:00 [CH]
And as mentioned before, my name is Conor. Massive Array language fan, fan of all the languages. Excited to talk to our two guests today because they are not, I think, originally... I know they have some experience in the Array languages, but they've got experiences with a ton of other languages. But before we get to introducing both of them, we've got a couple announcements. But first, we're going to throw it over to Bob.
00:01:16 [BT]
Yeah, and I often end up doing these sort of sad announcements. And this one is a sad announcement because this is a person I actually did meet and knew and have, well, as many of the people I've talked about and have high regard for. Joey Tuttle passed away in February of this year. [01] And Joey was a really interesting guy. He's got an interesting background and maybe as much away from computers as anything else. But he's got a lot of history with APL and the Iversons and all that sort of thing. And I'll... I'll just reference a really good article that Marshall put upwhen we both found out about this in the APL Wiki.And it gives a good background to Joey's life. And really a true gentleman. That was one of the things that I took away from meeting him. I had the honor of meeting him at the 2014 J Conference in Toronto. And really, in the true sense of the word, a gentleman. Really a gentleman.
00:02:12 [ML]
Yeah, and I met him there as well. And just came across as, you know, very genuine and humble and all. And only later did I find out, you know, how much history. He had with APL.
00:02:22 [CH]
Yeah, and we never got the opportunity to interview him on ArrayCast. But luckily, a sibling initiative, the campfire that Adám put on. I think Joey was in a couple of those, at least. And so I'm not sure if they're mentioned in the article. But we will leave links in the show notes. If you do want to go hear some of the stories from Joey, you can do that by checking out the links in the description. You know, thoughts go out to his family and friends, obviously. With that, we will transition. To our other announcements, which I think Marshall has both of them.
00:02:54 [ML]
That's true. So the first announcement on the previous episode, I said when talking about WeWa that Kai's use of the inverse operator for pattern matching was something that I hadn't seen before. Specifically the way it does, you know, it applies the inverse to functions with many arguments and many outputs. That was true. However, ArrayCast alumnus, Vanessa McHale, pointed out, on the J Forum, that actually another stack language, Factor, has had this for a while. And she linked to a nice paper that explains how it works. And it was renamed. So it's now the switch syntax thing in Factor. And it does really something surprisingly similar to Uiua. It has, you can invert like constants, and you convert list construction and all those sorts of things. So I've used Factor and I hadn't seen it. So maybe the Factor community isn't going to be able to see it. I'm not getting as much use out of it as I should have, but it was interesting to see, you know, almost the same design come up independently. And I have, I do have another announcement. I'm announcing this, I'm sort of taking over from Bob, the J enthusiast, but I'm an indices inverse enthusiast. So I need to announce that the latest J beta implements the inverse of the indices function. So indices tells you, you know, you give it a list of natural numbers. And it repeats each index that number of times. And so the inverse of indices tells you, you give it a list of counts or no, you give it a list of indices and it returns a list of counts of how often each index was repeated. So this is really useful for, I mean, sometimes it's called like histogramming, even though that's not really what it is, but it's basically, you know, counting how many times different things in the data occur. And so this was, I guess, Howard Aiken's quote, he told Ken Iverson, you know, if your ideas are any good, you'll have to beat people over the head with them. I became an advocate of this change somewhere around 2012. And since then I've implemented it in Dyalog and BQN, and it's been implemented in a bunch of other languages. So I've sent, you know, numerous messages to the J forum saying, over time saying you should implement this. But this time I was able to point to a list of like four or five different languages that do it. And some examples of usage. And so Henry Rich went ahead and put it in. So that's very good news.
00:05:29 [BT]
It only took 12 years.
00:05:31 [CH]
And if you recall, I think I can actually remember how it came up, but at some point it organically came up on, we'll say episode 32 plus or minus 20.
00:05:40 [ML]
I think it was a lot earlier. I mean, I was not even a panelist, was I?
00:05:43 [CH]
All right. We'll say episode 22 plus or minus 20. And, and I had just, I don't know. Discovered it one time because I discovered inverses. And then I was messing around with all the ones that you would expect to have inverses. And then, you know, one time I just said, oh, I wonder, I mean, you, you could probably invert this, but I thought there's no way it works. And sure enough, it did. And then I came on here and I was like, did you know this? And then Marshall was like, yeah, I did that. And I was like, what? Anyways, very cool. Happy for the J folks. It is a, you know, very cool inverse. And, you know, it really, it really shows you that you can go past just the mathematical operations.
00:06:18 [ML]
Oh yeah. And, um, I should point out that J also. Extends it in the same way as BQN and we want to do. So that part, I guess I can actually claim as opposed to, I mean, the, the inverse, it was like somebody else suggested it. And I said, yeah, this is a good idea.
00:06:31 [CH]
And should we mention the difference for those?
00:06:34 [ML]
Yeah, I'm going to describe it. So the result of indices is always sorted because it just, it doesn't, you can't tell it what order to list the indices in. So it all always just puts them in order. So naturally the inverse should only accept a sorted array as its input, but, um, it's. It's also very useful to take an unsorted array and just kind of implicitly sort it and equally efficient. So that's a BQN and we want now J all, um, implicitly sort the argument. So it's just the argument is a list of indices in any order. And it returns an array where the number at each index is the number of times that index appeared.
00:07:11 [CH]
I did actually, I did not know that was the difference. Um, so that is, that's interesting. I'll have to go play around with that afterwards.
00:07:19 [ML]
Um, yeah, well, it was kind of funny cause I was, BQN is pretty strict about inverses. So I only decided to make this extension like two years into BQN programming or something, probably a little more because it was just like, it kept coming up and it's like, well, I'm, I'm not allowing myself to use this useful thing just to keep the rules of inverse. So eventually I said, well, I'll, I'll stick it in the spec that there's an extension to inverse. That's not strict, but this works. But the whole time I was thinking, well, this would be great for J because J is really loose about inverse. So it should, uh, it should implement this with the extension. So, but by this time, you know, BQN has implemented it. And so J does have it as well, but it's not the only one.
00:08:00 [CH]
Well, for those of you interested head over to BQN pad or to the BQN site or to that other BQN online editor. There's like three of them to choose from now and, uh, and play around with it. But with all of that out of the way, we will hop into introducing our guests, which we have mentioned not by name, I don't think, but via their podcast. They are a pair of individuals who have started a podcast that is hosted on YouTube called proglangcast. [02] I believe they have released seven episodes, probably five of which maybe six of which we've mentioned. I know we mentioned the F sharp one casually. We definitely mentioned the BQN one, the J one, the APL one. And then I think you had Adám on. So that's four plus five. And I believe there was an F sharp. Yeah. The F sharp one I just mentioned. Anyways, I don't actually know the other two. There's more coming that they may tease anyways. And depending on how many of these you have or haven't listened to or watched to, you may not know their names because for the first couple, they didn't even introduce themselves. They just launched into what they were talking about. So our two guests for today are Christopher Augustus and Steve Thames. And I think we'll just throw it over to Christopher first and you can give us a, you know, a brief introduction and then we'll go over to Steve and then we'll start our discussion about everything, you know, array languages, this podcast, other languages and go from there.
00:09:18 [CA]
I call myself Christopher Augustus. And I think of myself as a human being who likes to program. I've been doing that for a very long time. So I'll try to keep this, uh, all my historical stuff as brief and relevant as possible. If you feel like I'm straying from the path, don't feel bad to reel me in or, or 10 X that part of the playback.
00:09:38 [CH]
We don't do that on this episode. That's the other podcast.
00:09:41 [CA]
Uh, I'm one of the hosts of the recently birthed proglangcast. You can call it prawg or prog, but since it's programming. I, I go with the proglangcast, which is actually part of a project called proglangbase. That's still in progress. That's intended to be, hopefully you will see it soon. Uh, an incredible resource for all programming languages that provides information in a multi-dimensional way that you can query and compare along all kinds of axes and, and ways that you couldn't before. Uh, I know there's a Rosetta code and there's things out like that, but we, we, uh, we plan to take that. Take that up a couple notches, which came about because I've been on a safari exploring all the languages. I didn't know anything about, which was most of them. even though I've been programming for decades, for many years. And then somehow I came across CodeReport and comparisons of 24 languages and 18 languages and nine languages. And I said, wow, I have to look at all this. And following that, Mr. Conor Hoekstra has pied pipered me into combinators, which I'm now a fan of, tacit and very terse coding, which I've always been a fan of. I'm a very visual person. But also the array languages. And I think I caught some of the earliest episodes of ArrayCast all the way back in 2021, right, is when you started. So if this is episode 78. And I've been listening to all of them, many of them repeatedly, particularly in preparation for such as the J video that we released. I re-listened to so many to try to get. And I missed the one on Eric Iverson. I really felt bad about that because I re-listened to that after the fact. And there was so much juicy stuff about it. I think I've got a history of J in there that I did not include in my coverage. So, all right. So cutting it short, that's what we're about here. I did program in APL. Originally, it was the very first language when I was eight years old and didn't quite get the array part, but I was very into art. And I love to memorize the patterns. And I remember memorizing the line of code that would clear the screen. Something about pushing a matrix of spaces across the display. It was a sequence. And I just memorized it as a kid. I thought it was a secret code and great, but I didn't. Unfortunately, I got dragged into the mainstream of programming. But as a result of Conor getting very excited about APL, and I got very excited about it again. And I've discovered recently that programming-based can really use the power of array programming. I'm actually working on building the core data model that drives it in an array language. And I actually have started examples in APL and BQN primarily. I'm focusing on BQN. I'm finding it very useful for that. And I actually even started dabbling a little bit with the J representation of that so that I could understand these languages a lot better and compare them to each other. I kind of like doing that. I like implementing the same thing across a couple different modalities. So that's what I'm about. I think that's enough for me.
00:12:46 [CH]
Well, there is so many questions that could be asked there, but we would run the risk of talking for like 40 minutes and being like, oh, wait, we got to talk to Steve. So we'll pause all the questions that we have and we'll throw it over to you, Steve, to do the same thing.
00:13:00 [Steve Thames]
Well, I'm Steve Thames. I'm the other half of the proglangbased proglangcast team. And Christopher has pretty much covered most of what we're doing. I'm a programming solution enthusiast. I've spent a great deal of my time in imperative languages like C Sharp, C++. Most of the languages that are based in the C lecture, I'm familiar with nearly all of them. I've spent a long time working in Perl, done some PHP. Sorry. No opinions there. But I did do some APL some decades ago in a data mining project. And so now I'm kind of enthusiastic about getting back to it, seeing some of these kinds of listening to you guys and the ArrayCast and talking about these ways to manipulate data using the array programming paradigm. And I'm really excited to find out more about it. So I really appreciate being invited here and having a chat. And I hope to learn a lot from, you know, hopefully things that will remind me what I've missed about array programming all these years. So I'm really excited to be here.
00:14:07 [CH]
And so how do and I guess maybe we can ask like a third introduction is how so you mentioned that you wanted to start this ProG, I guess I should pronounce it the correct way, ProGlangBase. It's that's similar to the how people pronounce mute or mutt in Rust, because some people say it's it's or is it?,Oh, no, it's car because most people actually say mute, which is short for mutable.
But car.,Okay. Car is how most people pronounce what is short for character. So should it be care or char or char? Yeah. Yeah. So it's most some people have the it should be pronounced whatever it is the prefix of pronounce it the way the full word is pronounced. But then other people, you know, it's just whatever people say.
00:14:45 [STh]
I think in England, it's it's chair, you know, in America, it's car.
00:14:52 [CH]
Oh, yeah. That's a that's a whole issue. Depending on your jurisdiction. Right. It's a different pronunciation. But so was have you guys worked together? How do you know each other? And how did was this a sort of a joint initiative or one person wanted to and reached out to the other? What's the sort of the the Genesis story of ProgLaneCast slash base?
00:15:10 [ML]
I was just going to say the prog clears up some confusion because we know we're not talking about bands like Genesis and yes, and so on.
00:15:21 [STh]
We can talk about bands like Genesis and yes, if you like. I mean, I'm a fan.
00:15:25 [ML]
Nope. Purely a prog day today, not Prog Rock.
00:15:28 [CA]
All right. I'll break the secret. I try to hide a lot of personal stuff.
00:15:31 [STh]
Really? Yeah. We've known each other for a few days.
00:15:34 [CA]
For a few days. We're brothers. Yeah. Steve's the elder. I give him that.
00:15:40 [STh]
Thanks for throwing that out there, OK?
00:15:42 [CA]
A couple of years.
00:15:44 [CH]
This is this is fantastic. So the listeners of ArrayCast, this is like, you know, breaking news.
00:15:50 [CA]
Yeah. We we grew up in a computer family. Our father worked on the Saturn five rockets for NASA. That's why I was born in Houston. That's. Our family's from Texas, though. I grew up in California. Steve and Steve and I both mostly grew up in California. And our mother is a college professor who had a computer lab. She ran a computer lab at a community college. And that's where I was introduced to APL at eight years old. And I was in the computer lab and these hearing impaired gentlemen were doing fun things on the green screen. I think it's a Tektronix 4004, something like that. But I was really into art. I was like, can I draw lines on this vector display? And they taught me APL and how to. How to write some code and use some of that stuff. So that was my exposure to it.
00:16:35 [STh]
And I think Christopher, you hit on one point. The difference between the two of us is he was much more artistically defined from the very beginning. He painted, he plays the guitar. He's when he went into programming, he was very much about the graphics, which is, I think, why he found himself moving into the game environment. And with me, I was always process oriented. I liked making things communicate. I love taking things apart, putting them back together, building different cables for communication, working at the microcode level for doing communication, serial communications, parallel communications, just trying to figure out how to make the coffee pot talk to the curtain rod. Just anything that makes... That's why I really like DevOps. I really like networking and general process and problem solving. He's very artistic on the other side. So he does a lot of things that I just don't have a clue about. But that's really what I do. That's really the difference between us. And as he said, we grew up in a family that was very, very well versed in computers. In fact, he was talking about our mother who had that computer lab. They were doing things there when she was writing books and using the technology to aid her in that when they weren't doing any of that kind of... It was very new back then, how he got exposed to it. As far as the array language is concerned, I got exposed to it sometime later when I was working at the Aerospace Corporation. [03] That's where my father was working. He got me a summer job there. So I started working, doing some APL at that time. I had done some APL on the old IBM 5100 like Christopher did, but he did much more of it than I did. And so it's been quite a while. And so like I said before, it's kind of exciting to get back to it.
00:18:14 [CA]
Let me make a point about APL in the very early days that I remember from it. It was mainstream, mainly because I think IBM was mainstream. The mainframes were IBM. And the first small computers. You can't really call them personal computers if we don't count the hobby kits and you don't think about Apple. This is still pre-Apple, even Apple I. They released the 5100, which is this boat anchor. It's very heavy. It's not very large. It's very heavy. And the screen is about that big. I think it was 52. It wasn't even 80 columns. Wasn't it 52 columns or something like that?
00:18:50 [STh]
It was 16 by 64. It was exactly 1K of characters that you could display.
00:18:56 [CA]
Oh, was it? It was 1K. But the point is, APL was built into it. APL was the language. And there really were no file operating systems at that time in those kinds of facilities. So my first exposure to APL was on that 360 through Tektronix, not knowing what I was doing, but once our family had acquired one of these 5100s, which they were doing businesses, applications with IBM, it had to switch and it had to switch APL or BASIC, and the keyboard had the actual APL glyphs right in the keyboard.
00:19:24 [STh]
Symbol set, yeah.
00:19:38 [CA]
And then they came out with the 5110. They still had the switch. And then at some point, they came out with the 5100, sorry, the 5120 or the system 23. I ended up working on these machines. By the time I was a teenager, I was working on application programs. But at some point, the APL button went away and it became BASIC only. Do you remember, Steve, was it the 5120 or 23? I know the 23 only did BASIC.
00:19:51 [STh]
So the 5110 didn't have the APL, it was 5100, yeah.
00:19:54 [CA]
Oh, so it stopped that early.
00:19:57 [STh]
Yeah. They got rid of APL. They stopped that early. Go ahead, Marshall.
00:20:00 [ML]
So there is a pretty nice, I think it's a 5110 emulator online, and that has an APL BASIC switch. That's pretty cool. I mean, you can use it in program and see what APL was like then. Not of course with a real keyboard, but you can put in input anyway.
00:20:18 [STh]
Do you still have, you said there's an emulator online? I've actually looked for one. There used to be one called PC51. Which we had, and I can't find it anywhere. Christopher has asked me to, I mean, I've been trying to find some old code that we wrote back in the 5110 and I can't find that anywhere. So I'd be curious about that.
00:20:22 [ML]
Yeah. So it's, you have to, or no, here it is. I think this works.
00:20:42 [CA]
Oh, you've got the emulator. So it was the 5120 was where they took it away. I knew they took it away on one of those versions. And from that point on, the IBM PC, Apple, it was all doubling down on BASIC. I mean, you guys have mentioned that the story of Bill Gates had written an APL interpreter and was considering that, but the whole world just kind of went, "No, we're not going to go in that direction." And that was the last time I had done it. I didn't even know, Steve, until you told me about your background at Aerospace. We didn't really grow up together much of the time. And I didn't even know you had continued to use APL there at all. I mean, that was my last...
00:21:20 [STh]
We lost touch for a while. Here we are again, back and talking about programming.
00:21:25 [CH]
Yeah, I mean, it's super, super awesome that you guys are starting a podcast. And I was thinking too, this wasn't an interview on ArArrayCast, but on my other podcast, ADSP, we interviewed Dave Abrahams, who's been involved with Swift in a major way. And he told his sort of discovering programming story and had the identical appearance that was a professor. I think it was at Princeton. And then he told that he was so addicted to APL on these terminals that literally he would break into the lab on weekends when his mom was there. And he figured out... I can't remember if he got the key or something. But anyways, he was so enamored with this language that he would sneak into these computer labs. Anyway, so I wonder how many folks have this similar story where they had a parent that worked in higher education and access to a lab that had some kind of APL terminal, and they were able to pick APL up that way? Because it's such a unique story. I mean, like when I was in elementary school, everyone had the colorful Macs. We had one in every classroom, and then we had a room. So it wasn't like the story of, "Oh, they're first coming out, and you have a parent that has access to these machines." There was only a window of time where that was possible, right? So it's very cool to hear that story now twice.
00:22:43 [CA]
I think it also demonstrates the power of the default. Right. APL disappeared from the scene because they decided to take that default away. I mean, we know that with the web browser, right? The dominance, the monopoly of JavaScript is by one virtue alone. It is the only built-in programming language of web browsers as decided by browser makers. Nobody's really making an effort to do something else. Sure, people are trying to veer around it with LiveView and Elm and things like that, but the default establishes a monopoly for the most part. And it's sad, as you point out, that they just took that button away and decided BASIC was the future for a while.
00:23:21 [STh]
Well, in addition, it might be much simpler than that. I think that IBM was interested in selling computers, and there just wasn't... APL is a challenge. You're going through, you're learning symbols. It's much easier to read lines like "for i = 1, 2, 10" or "print this," and that's what you have in BASIC. It's a learning language. I think it would be more... I remember when I was at Aerospace and was programming in APL there, which is funny. Christopher and I were talking about it the other day that the popularity of APL might have been part of the fact that when we were programming in it back then, you had these IBM Selectric terminals that had that ball, that literally had the APL symbol set on the ball. And this was for typesetters that were going to go in and do things in different fonts and different languages. They had different balls. I remember mom had a case of all these different balls that we would use in the Selectric typewriter, and one of them was the APL ball. I think when it comes to the 5100 line, 5110 line, probably the reason they went away from it was just because... Well, and it may very well have been an extra cost to put it in there, and just BASIC was more popular because people could learn it easier. It might be that simple. And from my experience, one of the things that... You were talking about how many people like... Conor, you were saying how many people might have had parents that... And they learned computing and they learned programming because their parents were into it. And from my experience, this comes from a time in which there was no training for computers in high school or college. This was a field that had yet to be developed. In fact, one fellow that I worked for years ago who was a computer enthusiast, he said that there were no... He really wanted to have a degree in programming, but there weren't any available, so he became a mathematician. And so for me, I went from BASIC programming on the IBM 5110, did some APL, did BASIC, and then immediately went to learning how to code in straight hex on that old 5100. So now it was recording in machine language. And the computer itself had a 22 megahertz process, and the operating system was essentially a downloaded 370. So you had this massive operating system in a 22 megahertz processor. And of course, anybody who doesn't remember, the IBM PC's original processing speed was 4.77 megahertz. So this was five times as fast as that original PC processor. And it made the BASIC interpreter so incredibly slow, where you would type in a line and press enter and you'd have about a half second beep before it came back, because they had put so much code in this 22 megahertz processor. So needless to say, the stuff that I wrote in machine language just screamed by comparison. I mean, like, 5,000% faster than anything written in BASIC. I can't speak to what it would have been like in APL. Christopher, you might be able to speak to that.
00:26:27 [CA]
No, the last thing I did was a skateboard game in character mode, because I was into skateboards and it was on the 5100. And yeah, I mean, that was it. But I ended up moving into assembly language too, because I got into the PC and the apples and stuff to do games, and the BASIC on there was the same problem. It was so slow. And it wasn't compiled, it was interpreted. I actually do have the credit of releasing some of the earliest games on the IBM PC when it came out that were graphics. I was a teenager at the time. They're derivative copies of other games, so they weren't that interesting, but they were really slow and I realized I need speed. So I grabbed that technical reference manual that IBM's downfall to some degree, the blue thing, read all about the BIOS, learned how to program an assembler. And you could code in the macro assembler, that was free. Like if you wanted to program in Pascal, [04] you had to buy the Pascal compiler if you wanted to do the other thing. So one thing I could do is program in machine language, which I started doing. And if you did any programming on the Apple, I don't know, Conor, if you remember this, and you wanted to do games, you might've used Applesoft BASIC, but it wasn't BASIC. It was peak and poke and peak and poke and peak and poke and peak and poke. You're actually just sit there, literally just directly manipulating the video buffer to make the images that you wanted. It really wasn't BASIC code. Sometimes the interpreters were so slow. Eventually they came out with a BASIC compiler and ended up in high school working on a game that I did compile in BASIC. But the last thing I want to say about BASIC is you guys always make the point, the Alan Perlis quote about, you know, language that changes the way you think is worth knowing. And I really have discovered that in my exploration of functional languages, array languages, certainly. I'm now looking towards stack oriented languages, very interested about Factor and some of these others, uiua not being stack oriented as I'm kind of leaning in that direction as well. BASIC I feel like does change the way you think about programming for the worse. That's the problem.
00:28:23 [STh]
It's a hell of a place to start.
00:28:24 [CA]
Those changes aren't necessarily good. It really strips away all the things that matter in the kind of software engineering that we need to do now. And there's a long legacy that has fallen out from that in affecting the way people continue to think in some ways about programming.
00:28:41 [STh]
One thing I might ask you about that, Christopher, is because I was just thinking that, you know, as we as our family separated, we both were into programming into different things, but ended up a lot of times in the same places. And I think maybe for some of the same reasons, that lack of ability to do the things that we needed and wanted to do. When I came out of, I mean, when I was, I did a great deal of work in BASIC on the 5110 and then immediately I got exposed to the assembly language and the actually it was actually straight binary coding in hexadecimal on that machine. But I think what happened with me was my direction was I wanted to do anything new. Okay. Anything I hadn't done before, any language I hadn't experienced. So I found myself working in Pascal. I found myself working in another kind of BASIC, which was based on a COBOL compiler. It was really clear when you saw it was on the NEC Astro machine had this basic language that the way it was structured was really similar to COBOL and to RPG as well. Everything was done essentially on cards. They weren't in cards, but everything was 80 columns long, specific positions had a specific meaning. So that was how I came into kind of learning all of these different techniques and concepts. And I'm mentioning all of that because getting back to the impetus behind ProbeLang Cast and ProbeLang Base was having all of that experience and learning all of these things and not being specific to a language. I think that's always kind of been where my strength is. I'm a programming solution enthusiast and I like some languages better than others. It would be more accurate to say I dislike some languages more than I dislike other languages, but I've never been so much language specific. And I think that Christopher's experience, and correct me if I'm wrong, is similar in that regard. It's just some different directions, but always kind of came back to trying different things in different places in different languages and getting exposure to different concepts of programming. And I think we both kind of went into the object-oriented field and we drank the Kool-Aid and became cult members of that for a long time. And I at least, I know he's kind of recovered. I'm trying to recover from it now and making some progress.
00:31:02 [CA]
There was a time back in the early days when there was a magazine called Programming Language, or Computer Language Magazine. Some people I think here, anybody remember? They're familiar with that?
00:31:14 [CH]
I feel like, is it the one with the covers and stuff?
00:31:18 [CA]
It was the 80s. Yeah, it was in the 80s. And I remember the issue with Prolog came out. I was working for a company, I'm still pretty young, I think I'm in college at this point, maybe before I went to college. And I was writing an operating system in Assembler with somebody writing drive, drive. Let me tell you, that's the most tedious work you can ever do. And again, the derivative thing, we were moving the operating system of the Series One over to a PC so you could run its programs on a PC. And fortunately, Turbo Pascal came along and saved me from that. But the original author did not like C. He was like, I don't understand C. So he decided to do it all in assembly language. And of course, no re-entrancy, you know, it's just like assume what registers were holding what on the entry to every routine. It was just miserable code to work in. But I was very interested in computer languages and Prolog. And the whole push was the AI generation is coming and this is it. Like everybody's going to be doing Prolog. And unfortunately, I didn't really dive into it at that time. I was interested, I'm starting to feel the pain of the lack of modularity in particular in programming languages. And so went from Turbo Pascal, which wasn't very modular to Modula 2, [05] Nicholas Wirth, second or third, before Modula 3, he did a Modula, Modula 2. And there were actually compilers you could buy. I remember buying a compiler, we had to buy it back then. And it was a Modula 2 compiler and it had an editor that was like a straitjacket. You could not free edit in this editor. It actually had the intelligence that forced you to have to enter the syntax correctly. Like it would template you. It's like a Mad Lib, right? You type in and you start typing an if, and it would literally block you from being able to, you couldn't reformat or anything like that. It was, the idea was this discipline was good for the programmer, right? So it was literally just building probably an AST behind the scenes, like saving the whole parsing cycle and that. But we felt it was great because suddenly it had this modular protection where we could build large bodies of code without stepping on everything. It didn't go very far, it didn't really fly. And then sometime later, I got exposed to Smalltalk, switched to C++, and that was the beginning of the dark times. And now trying to find my way back into the light.
00:33:40 [CH]
And I did look it up. I was, the magazine I was thinking of was the one that famously, I don't know if Smalltalk got its logo from it or the magazine cover or...
00:33:50 [CA]
The balloon.
00:33:54 [CH]
Yeah, the hot air balloon. But that was the, that was Byte magazine. That was not...
00:33:54 [CA]
That was Byte.
00:33:54 [CH]
Yeah. Yeah. That was the one I was thinking.
00:33:56 [ST]
Yeah. July, August, 1981.
00:34:00 [CH]
Yeah. Yeah. It's probably the most famous, or at least for me, the most famous, like old school magazine, computer magazine cover. Because, or at least whenever I'm looking for logos for a while, I would just use that magazine cover, not knowing that it was a magazine cover. I just thought it was a bad logo. Well, I mean, so this is, definitely don't worry about veering away a little bit from the Array Languages because I know when all of the panelists are silent, just listening, it's because we're entirely engaged, which means our listeners are as well. This sort of history of your path from APL at one point to other languages and back is extremely fascinating. So I guess my thinking, like the next question is, so your goal is to, with Proglang Base and Cast to kind of create this, I guess, similar to Rosetta Code, but a bit different where you can highlight sort of the powers of different languages. I don't know, maybe build on that if you will, or correct if that's wrong. But what are your... So you've covered, we mentioned a bunch of the languages. I know you've said off recording that you've got episodes planned. What in sort of the near future in like the languages, do you plan on sticking to mostly the functional paradigm for now in Array? Because you've covered almost all of the popular Array Languages. What is the sort of near-term, long-term future for Proglang Base and Cast?
00:35:26 [CA]
Well, I still plan on doing k. I haven't done that yet. I don't know if I'll get around to DL, but it seems like the big four in the Array Group is APL, BQN, J and K, and then maybe Uiua was kind of coming in as a new newcomer.
00:35:39 [CH]
Yeah, I think the Uiuaboos... Oh, I said it. The Uiuawins. The Uiuawins.
00:35:44 [STh]
That's a better one.
00:35:48 [CH]
Yeah, they would be putting their hand up.
00:35:51 [ML]
Well, I'm honored enough to be included in the big four.
00:35:55 [STh]
Hey, Marshall, we'd love to see a version of Bye Bye Hello World. I'm happy to do a podcast of that.
00:36:00 [CA]
And an interview with you would be great.
00:36:02 [STh]
Yeah, that'd be outstanding.
00:36:04 [CA]
And Conor and everyone and Stephen and everyone, we'd love to have you all on. The interview with Adám was really a pleasure and Bob as well, way better than I expected. And we feel honored to have done it.
00:36:17 [STh]
Way longer as well.
00:36:18 [ML]
Yeah, that is a concern.
00:36:19 [CA]
We won't torture you for four hours. You can pull out, pull the ripcord and get out of that one.
00:36:25 [STh]
Bob, you were being so polite the last half. Hour going well, Gee. I could have said I had to. Go 15 minutes ago.
00:36:34 [BT]
Yeah, well, you know, I'm Canadian. That's the way we are.
00:36:39 [STh]
As far as what the future looks like for what... It's funny, Christopher and I were just talking about that this morning. I was starting to think there's a lot of... We kind of talk back and forth about expressing opinions. And obviously, being doing this for a while, we have some opinions about what's good and bad about some languages. And so I was making the point that I think it's going to be equally important to do something like bye-bye, hello world, or a discussion about languages that we actually don't like. And to try to talk about what their history is, why they're here now, what their strengths, if any, and what weaknesses, if any, there are. So you could very well in the future see one about JavaScript, see one about Go. That's one we were talking about this morning. And obviously, I mean, I don't think it's really fair to do things... Like so far, until I did the Erlang... Well, no, until I did the F# one, I was... The first couple of them we did were languages we know well. Like anything in the Clexa, we know that really well. So I really loved going off and doing it in F# and Erlang. It was my first experience in functional programming, which I really enjoyed. But I think that... And I think Christopher has talked about doing something in JavaScript. And then we talked specifically about Go. And I think down the road, we've also been talking about, instead of being specific about the bye-bye, hello world, which has a specific impetus toward... Or a specific purpose, at least in terms of why we started going that way, just talking about some concepts of programming in the future. One of the things we talked about was we were talking about object-oriented this morning. And how did you phrase it, Christopher? The locally...
00:38:20 [CA]
Locality of behavior.
00:38:24 [STh]
Locality of behavior. And we got halfway through that discussion. I said, "You know what? We probably want to talk about this on camera. Let's talk about locality of behavior and how do languages support that and how do they not support it?" And we were talking about a couple of different examples. So this is the kind of thing that, at least for me, I would like to see us go in the future. In addition to talking about specific languages, what their strengths and weaknesses are, but also talking about programming concepts and how sometimes they catch on, sometimes they don't. Maybe they're more difficult. Sometimes a concept is out there that's really valuable, really beneficial, but it's hard to grok initially. And so talk about some of the... I think... I don't know if that really answers your question, Conor, in terms of the direction I would like to see us go is, in some cases, language-specific to talk about these specific strengths and weaknesses of languages, but also to talk about the concepts of software development and what are strong and weak about those.
00:39:25 [CA]
I have a more specific agenda. The things you mentioned obviously cover a massive amount of ground that it would take a thousand years to cover. So I have an insatiable curiosity and I'm the great dabbler. So when I have to label myself, people say, "Tell me what you do, what you are." They want to say, "Are you a front-end developer, back-end developer, full stack, half stack, Belgian waffle?" Sometimes I have to adopt the term "software architect" reluctantly when I want to actually get paid for what I do. But I've been all over the map. I've been across a lot of domains. I just call myself broad spectrum, kind of like those antibiotics that aren't as strong as the targeted ones, but hopefully they cover the diseases that you haven't yet diagnosed and you're maybe going to be okay with it. So dabbling, I've been on this crusade to learn about all these languages that I didn't know. I kind of had a wake-up call to functional programming many years ago. I actually worked with some young guys back in 2013 and I was doing... I was porting their 3D engine C++ to Android for them. I have a long history doing a lot of 3D graphics, building an MMO, trying to make a company happen with that, building my own engine, and spent a lot of years doing that all in C++ because you had to have performance and that's what you had to do at the time. And they were talking about Haskell and they were using Erlang and I was deaf to it. I was just deaf. I couldn't hear it. They hired me as a C++ guy to do object oriented. Their engine was C++ and they were saying things like, "Not everything needs to be in a class." And I'm like, "No, no, of course it's object oriented. Everything's in a class. Even your static things that are basically just freestanding functions, they're in a class." And I couldn't hear it. And then I started to wake up a few years later and started to recognize a lot of red flags I saw in my past that I dismissed that were problems that, like the failure of Corba and the failure of object databases and some of the things I won't necessarily get into. I've been down that whole enterprise track too and I'd rather not talk about that. But the point I want to make is I feel that I was wrong in a lot of ways, or I was very biased in a lot of ways, and I wanted to avoid that in the future. And I started seeing a lot of benefits in the functional way of thinking [06] and practicing and feeling those benefits. And I realized I need to learn more of what I don't know. And that takes us back to the 60s and 70s, and where the explosion of innovation in programming and languages really was. And when I look back at the intervening decades, it feels like so much movement has been lateral and not really forward. Sure, new languages showing up every week, but if you look at the set of mainstream languages, Conor, on PL rank, it's like, how are these really different from each other? You know, what are they doing other than incrementally bolting on, okay, we'll do a little functional thing here and a little functional thing there. It's like, there's an intentionally, we forgot all these great things we learned back then because, oh, they weren't performing or whatever reason. And so we've amputated all our limbs, we've cut them off, we've got these very imperative procedural languages, we've embraced the OO thing, but there's a lot of disillusionment with that. And but now this functional thing that's been out there for a long time, it's the new thing on the block. Well, we'll start integrating a few little pieces here and there. It's like you cut off your limbs and then you put back one tissue at a time. In fact, I think Go just made an announcement that they are adding a functional range feature to their for statement. And it's kind of like, well, why did you take it away? It's been around in these other languages. And I totally respect the idea of minimalism. I'm on this rampage right now about minimalism. You know, I have a bucket full of theses about software and Steve's been pushing me to try to put them out there. I don't know if there's any value to anybody, but I would say the top one is, is that we're in a complexity crisis. We've been in a complexity crisis. And everything I do now is about simplifying, reducing complexity, reducing complexity, because every line of code you write increases complexity. It's additive. There's so much stuff that's additive and almost nothing that's subtractive. And this mess we've created for ourselves. If you go back to Brooks, 90% is accident, 10% is essence. I'd say it's more like 98 to two. It's just incredible. And I just feel like it just gets worse every day. And so, for example, the last Uiua episode where Kai was saying he took something out of the language, it's a little sad, you know, functions as first class values is great. I like using that in Scheme and elsewhere, but I respect the idea of him saying less. I don't need it or it's compromising what I want to do. I have a vision for this, less, rather than the problems with JavaScript are being solved right now, but just, okay, we'll add this, we'll add this, we'll add this, we'll add this, we'll add this, and it's like, but you can't get rid of your backward compatibility. So now you're going to be looking at a generation of code that you're going to look at code that spans this generations of sometimes the old way, sometimes the new way, sometimes in the middle. And I understand the advantage we have for people creating new languages, we get that clean slate, right? I mean, Conor with C++, you're very much covering all of that, the generations of C++. And the problem is, sure, we've got these new features, but it's still going to have to be backward compatible to the masses of code out there. And so are we making it better by just adding to the better things we realized we should have had a long time ago, or is this just going to make the mess even muddier? That I don't know the definite answer to.
00:45:00 [BT]
It'd be an interesting thing to find out whether there's an axis of difference between languages that subtract and languages that add, because quite often I'm thinking, if you come up and you design a language, the first thing that happens is, well, how would you do this? Somebody throws a, well, you'll need to do this, right? And you go, okay, well, I'll do this by, now the question is, will you do it by adding something and patching over, or do you do it by taking something away and saying, you know what, I'm not going to address that right now, or I will address that, but when I'm going to do it is I'm going to limit what I can do, and that addresses it. So now I solved the problem. It really changes the different way, I know Adám talks about how APL is such a diamond, that it's intense, it's tight, and you can't do very much in it to change it if you're trying to keep that structure of the integrity of the language. There are other languages you've met like JavaScript, where you can practically see them daily adding patches to cover things, and it's becoming like a big ball of mud, and it has its purpose, but it creates a very different approach to programming, I think.
00:46:14 [CH]
Well, I was going to say about C++, and this has kind of come up, 'cause I think Christopher, yours was one of the several comments on a recent YouTube video that was talking about the verbosity of C++, and I think everyone, well, not everyone, a lot of people misunderstand when I make these videos, and I think a part of the key to have a successful YouTube video is you have to be slightly inflammatory. [07] You gotta say something that people can misinterpret. It's like, "Oh, he's saying that everything else is terrible." It's like, "No, you interpreted it that way. "That's not what I meant," but it's good, it's good for the engine, good for the ratings, but I view C++ as an, it's already been a ball of mud for years, like a decade, and when I'm typing out the namespaces, I've kind of given up hope so that C++ can be beautiful. It is what it is. It's got a bunch of features, and when I hear a proposal that's adding a feature that I like, sure, it might add complexity, it might not work with some other language feature elegantly, but it's not, C++ is not elegant to begin with. It's a language with 40 years of history and like X number of standards, and it's kind of just like, you can try and carve something beautiful with this ball of mud, but at best, it's gonna end up looking like a baseball. You're not gonna get to a diamond. You might get something that's circular or spherical, but yeah, it's, C++ is, in languages like this JavaScript, they're never going to be this beautiful 'cause they can't have a makeover, right? Like it is what it is, but that doesn't mean that they're terrible. Like there are things that you can do with languages like C++ when it comes to metaprogramming and stuff like that that you can't do with array languages, and it doesn't mean that we should give up on C++, but yeah, if you look at the comment sections on the videos that I make, everyone is just disagreeing with each other about, you know, oh, have you heard of Zig? Have you heard of Rust? Have you heard of this? And it's just like, yes, I've heard of them all, and like Rust's template metaprogramming or metaprogramming is not as powerful when it comes to this kind of stuff as C++ is. Like they have the macro metaprogramming that Lisp has, but that's a different kind of metaprogramming when compared to the template metaprogramming and the variadic generics that you get with C++, and it's like, you have to really get into like the super, super details of like everything, and you're just gonna lose people in a YouTube video, so it's better to just, you know, make high-level statements that upset some folks, but to those that care, you know, it is gonna hopefully be educational to a certain extent, and I do have a question, but I'll throw it over to Marshall 'cause he had his hand up.
00:48:46 [ML]
On the role of languages full of mud, I mean, personally, I just don't wanna program in C++ 'cause it's too messy, but I think these sorts of languages have an important role in the development of programming language features because when you work with something that's so freely adding features, and Uiua is doing this as well, you're able to kind of explore new territory, and the Uiua removing functional programming or first-class functions is really interesting too because it, you know, it makes it so much more efficient to explore the stack paradigm when you don't have to worry about, you know, the function value whose stack effect is not, or is dynamic, so that makes Uiua really good for exploration and finding new ways that programming languages can work. And then what you can have is another programming language that comes and cuts back and says, "Well, we've discovered this new territory. "Now let's make a language that actually belongs there." So that's what BQN's trying to do with some features of APL, not array programming itself. I mean, I think APL has a pretty good hold on that, but kind of the interplay, actually, nested array programming is probably the big thing that I would say that BQN tries to, you know, actually inhabit. And Singeli is another, like you said, C++ meta programming is really powerful. Singeli is kind of an attempt to, you know, find what is really a proper basis for this sort of meta programming. And then what you get is this distinction from between the runtime and the compile time, and the meta programming layer being like a scripting language, or at least that's what I got. So, I mean, I have experience with both of this kind of exploration and consolidation, and I think they're both important steps, and I don't think you should try to do them both in one language.
00:50:39 [CH]
Yeah, I think in general, people miss that and I think what both Chris and Steve have said echoes this without having said it explicitly. Languages all have a role to play. Sure, there are some that are worse than others on average, but it's not like: "oh, my favorite language is X and I'm gonna program every single thing that I do in X". It's just that sometimes, Python is the best thing to programming, because it's got a bajillion libraries. Sure, it's dynamic; sure, it's interpreted; sure, it's 10 to 100 times slower than maybe some alternative, but if I need some script that's gonna run in less than like a 10th of a second, do I care? Like, no! The answer is I don't care. I just wanna get something done. I wanna scrape something from the web and I need to toss it. And it's like, I could reach for some language like C++, because I know it really well or maybe even do it for fun in BQN because I like coding in BQN. But if I need to get this done as fast as possible, Python might be the language to get that done.[08] And everyone likes to get in these language wars of my language is better than yours, because it has this feature, which is better than the equivalent feature. And it's like, every language is good at something and there's stuff to learn from all of these languages. Why do we have to have programming languages wars? It's like an ongoing war that it's just like, languages die out, and then the new one ... [sentence left incomplete]. It's like Rust has the strongest battalion of soldiers right now [laughs] and they're throwing, shooting their arrows and "rewrite everything in Rust", so much so that they've meme-ified themselves to the extent that they have the Rust evangelism strike force. And anyways, they know that they promote themselves so much that they've made a joke of themselves. But they're proud of the joke. Anyways, we're here to talk about languages though [chuckles]. We'll throw it over; maybe Chris, Steve, you have thoughts.
00:52:27 [STh]
I was just going to say, Conor, that you hit on exactly what the impetus behind proglangbase and proglangcast really is.
00:52:35 [CA]
I was going to say the same thing. I was going to say exactly the same words.
00:52:38 [STh]
Christopher, you made a point earlier before the cast when we were talking about how there's a lot of podcasts out there that. Because I asked the question to him (I'm not as familiar with the casts out there as he is in this field) and I said, "do we have something to say that somebody else hasn't already said?" And he said: "yes". He thinks we do, because a lot of people out there (particular exception to the ArrayCast), are pushing their thing. They want to bring more people into their thing, which this group is obviously not trying to do. We're trying to talk about programming, conceptually specific [to] array programming. For Christopher and I, a little bit more broad, talking about different programming languages across the spectrum. But we want to talk about what's good and bad about programming across the board and really being language agnostic, even though we might personally have favorite ways to do things and favorite languages to do them. Conor, you mentioned sometimes you just need to get something done and I don't give a damn if I can do it a thousand times in a half a second. I just need to do it once this second so I'm going to write it in a script and I'll figure out how fast it is. I mean, hallelujah, brother, because that's done so many times like that. I don't give a damn about how it performs. I just needed to do it without [it] having to ask me any questions. Just go do this thing and don't bother me with it and I want to get it done fast. So it's always domain specific. What do I need for this domain? And if it's fast [or] slow ... [sentence left incomplete].
00:54:06 [CA]
Until maintenance becomes a factor. Then those impulsive moves to implement stuff is something that you and other people have to live with and then maintain over a lifespan if it's of high value. I want to say that, yes, you hit the nail on the head about proglangbase. Let me tell you what the agenda from my point of view is. I started making a spreadsheet of languages and I started making columns of all the features. And I'm like, I want factual information. I already know all the opinions and the persuasions and the way this is sold and that's sold and I certainly have all of my biases just fully loaded with my biases and what I think is going to be great and what I think is terrible. I need a resource where I can capture, in detail the various features and the aspects of all these languages and be able to compare them to each other and to list them. Not just the mainstream ones and in fact, my goal with proglangbase is to give air and to give atmosphere to not the mainstream ones. Everyone else talks about JavaScript and Rust. I don't need to add to that conversation, but I will add it to the list and to say, this feature works like this in this language compared to, oh, J; you haven't heard of that; or you haven't heard of Futhark; or you haven't heard of this, or you haven't seen this. To your point, what are the paradigms? Is this an array programming language or functional programming language? If you go to Rosetta Code, suddenly they have to throw languages and they have to give them three categories, right? Because they're now multi-paradigm. I'm not even going to do that. I'm going to make it a histogram. I talked to Bob about this. I see array programming, hopefully with input from all of you, to say the ultimate array programming or way of thinking would have these features. And then we could rank any language and say it hits these three out of ten spots. It hits two out of ten on the functional; hits this. And then when you go to browse it, you can see a histogram and you could see the most array programming language and then a gradient of those that fall behind it. And then you could filter and select: "okay, exclude these based on features I'm not interested in". So I started trying to build this on a spreadsheet, which is a matrix, which is a rank two array. And suddenly I can start to see there's three ranks and four ranks, depending on how I want to penetrate and cross-cut this. This would be an amazing site. Who hasn't done this? Where is this? I need this factual thing where I can compare languages and not just the top 20 or the things that people are paying for right now. I'm on sabbatical for a year. I decided I want to build software in exactly the tools I want to use. I don't want to be carving wood with a screwdriver because that's what I've got to do for work. And it's the only tool available. I want the best tool to build the things I want to build. What are my options? What are my choices? And I can then see them and rank them and query them and do all that sort of stuff. So that's kind of the goal with the site, is to [be] a great resource that's a factual breakdown; not editorializing. I'm not even going to include popularity. I've mentioned this to Steve. I've said, I think we should leave popularity out. You've got plrank.com and Red Monk and all those people to talk about popularity. I think languages like the array languages specifically don't get enough attention because they go through that filter. "Oh, it's not in the rank; it's not popular; I'm going to ignore it". No, I'm going to give you a site that shows you the features; the capabilities. And of course, there's a little subjectivity in deciding. There's a judgment call to say, I think it qualifies for this or that, or has that feature, but to try to keep it really, really factual so that somebody can, without any kind of contaminated bias, other than what these languages offer. And then examples! Bye bye Hello World just became an example, a way to express the same spec across these languages. And I definitely am leaning towards exposing the lesser talked about, the unknown but viable implementations that are available to be used where they're available. If you have this flexibility and you can gain the benefits from these, don't settle on mediocrity, which is where the mainstream is. The mainstream is in this zone of mediocrity. It's in this, what I call mid-level programming. And two things about the array languages are also on my thesis of what I want to do going forward. One, I want all my programming to be interactive where possible. There's an amazing video out there (I can't remember the name of the gentleman); he talks about "Don't be do dead programming" (Editors Note: Stop Writing Dead Programs by Jack Rusher). And it changed my life watching this video. And I agree with him.
00:58:22 [CH]
Is it Brett Victor?
00:58:22 [CA]
He's the one who says Don't Write Dead code, right? And he's talking about how NASA can radio to a satellite running Lisp and make [a] change. I'm like, this is how we should be working on all software. This whole batch cycle is ridiculous and interactive programming and array programming ... [sentence left incomplete]. I just want everything to be interactive. And then also I feel that we should be as high level as possible and only drop below the high level when necessary for performance or whatever. And what I see in the industry is this settling in this mid-level. Not truly low level but not truly high level either. As you've talked about a lot on array programming; it's high level. I was thinking, it isn't about some really high level of abstraction. [It] is more like high level of mechanism, of implementation at a high level. Yeah, if I'm going to do a for loop 50 times and it's essentially iterating over and applying an operation or summing or scanning [and] I only have to use a single glyph or a digraph, that solves the problem. I don't have to worry about all the bespoke variations of that. That should be a feature of every language. And as you point out on code_report, you show how these languages are starting to introduce these, right? We've got our maps or folds or filters. And so this is kind of where I'm thinking where I want to go. I'm tired of operating at a level where I'm forced to use inadequate tools for the things that I want to do. And I'm thinking other people are out there as well. I wanted this resource. Nobody had it. Let's build this resource. Let's make it happen. And then let's make a podcast where we can talk about it and talk about languages and give examples of comparisons and stuff like that.
00:59:54 [STh]
You can see which mind the genesis of this comes out of, because I'm the guy that will use a screwdriver to carve wood, okay? If that's what I've got, that's what I'll use, all right? So the genesis behind proglangcast and proglangbase really comes from Christopher. It's been a lot of fun so far, so I hope we continue on doing it. Go ahead, Conor.
01:00:14 [CH]
Yeah, I was going to say, this is super exciting because one, we've already had a subset of this exact conversation or thing you're trying to build in one of the podcast episodes that was "what makes an Iversonian language, Iversonian?" [09] where we were debating [this]. We've got all these array languages (even if you want to include libraries like NumPy, which definitely is APL and J inspired) and we were trying to come up with a list of things, like what is the short list of things that we can agree on that makes it like an APL inspired Iverson language. And we had a super interesting discussion where we didn't all agree and certain things like that. You know, we'll link to it because we've only got a short amount of time left on this conversation. So we'll just link to it. And so to hear that you guys are going to try and do that for all the languages, I think is awesome. And also because I think in other paradigms, the same conversation happens. Like I remember being at a conference, having a dinner with a few folks (it was a C++ conference). And we were talking about what makes a language functional because everyone has a different opinion on the short list of, you know, pure functions, immutability, et cetera. Once again, not going to list it off here, but like everyone has a different ... [sentence left incomplete]. If you listen to Richard Feldman (the individual behind Roc), he thinks that only two of the list of things make a language functional. I've heard folks say that how a community uses a language, that influences whether it's functional or not. Like you can have a multi-paradigm language like Scala but if the community decides to lean more on the functional features versus the Object Oriented features, that influences the the perception of whether it's a functional language or not. Like technically, if you used Haskell (and they've got a bunch of unsafe functions where you do non-pure functionally things) [and] if that's what all Haskell code was, you wouldn't view it as a functional language as much as we do. So anyway, super excited that going forward, I feel like we're definitely going to at least have like an annual recap or touching base with both of you. Because I feel like we had a bunch of other things too, we were going to talk about them. We're probably not going to get to all the topics. So it's multiple reasons, you know, to hear about this stuff. I think Marshall had his hand up first and then we'll go to Stephen. We got a bunch of questions because clearly we're all excited about this [laughs].
01:02:27 [ML]
Yeah. Well, if I can interject on the functional thing, one of the issues with defining "functional" is that at present, nobody agrees what functional is, but everyone agrees that it's good. So [chuckles] what you get is people list all the features they think are good. And then they say: "well, these are good so these must be the definition of functional programming". And maybe that'll change like object oriented programming during the nineties was pretty much universally seen as good. Now it's seen as more of a mix. So I think as a result, we're able to be more clear. I mean, there are still some people trying to hang on to "object oriented programming is about message passing" because, you know, that's what they learned in it. But I think we're a little more able to tease out what makes object-oriented programming. I think it really gets in the way when you attach good and bad to kinds of features. I was actually a little concerned when I heard you saying, "well, you'll be able to sort languages by how much array programming they are and so on". That kind of feature worries me a little because then that starts fights over, "well, is k really the true array programming language or is APL?" You're going to have some trouble. Just warning you, you're going to have some trouble with the one-dimensional versus multi-dimensional arrays, and deciding whether that's array programming.
01:03:53 [CH]
Whoa, whoa, whoa. Marshall!
01:03:56 [ML]
Not to push any opinion on you.
01:03:58 [CH]
Before we let Stephen ask his question, this is the clear difference. Conor has a YouTube channel. He knows what lights the engine on fire. Marshall does not, and he's like: "well, that could start some arguments." That's exactly what you need to light the engine on fire and people start commenting and liking!
01:04:14 [ML]
Well, yeah, that's true.
01:04:15 [BT]
In the Iversonian episode, we established that Marshall is in fact the bouncer [Conor laughs]. He's just doing his role. He's just calming things down. Everybody, please, out of the club now. Don't cause a problem here. Conor is the guy on the stage, the DJ, just hitting it. Just trying to get that crowd going.
01:04:36 [CH]
Yeah. Which one of these comments upsets me the most? Then I'm going to make a response video to? Anyway, Stephen, you had your hand up for a bit.
01:04:44 [ST]
Yeah. Well, it's clear there's a reason [it's] called Marshall Law, isn't it? [others laugh]. I want to come back right to the short stack in the Belgian waffles. But to start with the minimalist aesthetics, because pretty much all the smart people that I know seem to share this really fierce attachment to minimalist aesthetics. My gut feel is in the wave of complexity, minimalist aesthetics is going to be a path that will save us. It's kind of a side note here that in the environmental movement, there are people who are saying if we're going to find a way through the collapse of the environmental systems and our social systems, and our politics, and our agriculture, it's perhaps going to be driven by changing the aesthetics. Of wanting a different, lighter way of living. Bob and I made a little pilgrimage last autumn to someone who lives near him, a guy called Robert Brinkhurst, [10] who's a linguist, an environmentalist, and a poet, and a mythographer. An interesting way of looking at the question of what languages have, Robert teaches that languages encode ways of doing and thinking about things. So when we look at a new programming language, we think: "what can I do with this that I couldn't do it before?" I think what happens when you lose a programming language. Conor was talking about languages coming and going, and they disappear. When you lose a programming language, you also lose a community and a way of thinking about problems. As part of what I see that we're doing in the ArrayCast is trying to preserve and enlarge the array programming paradigm, to keep that way of thinking about things and keeping it going. While Conor, you made it sound like it was stupid to argue about which is the best programming language because they've all got their points and they're good at some things. But we've got a limited amount of cognitive ability. I don't think that we're trying these days to find the one programming language that will do everything. But we might reasonably be trying to find a short stack; the small group of languages which will conserve our cognitive ability and let us do the most. That's my holy grail. It's a short stack. Ooh, Look at that! [laughs]
01:07:37 [STh]
Now you've done it! Now Christopher's bringing out his board [everyone laughs].
01:07:41 [ST]
What have I done?
01:07:43 [BT]
Well, just for those who are on audio, Christopher has just showed up a board of his preferred languages, I suppose in a way, preferred (I don't know whether that's the accurate term).
01:07:53 [CA]
I realize I'm going to be polyglottal going forward and I think it's a good thing. I don't think that's a bad thing. But I just made this chart to slice the domains I work in everywhere from Unreal Engine, to web, to command line, to all that. The bottom in these red colors is like "what's the default language that I might have to work in?" Like for example [for] mobile, I've got to do Kotlin and Swift; there's no way around it. Apple's not going to let me do anything else until I inject scheme or something else in there, which I'm trying to figure out how to do. Then what would I prefer to use? What would be nice? So, I don't think all languages are equal, at least for me in terms of what I want to accomplish. I want the site proglangbase to be factual, not opinionated. To your point, Marshall, I'm trying not to make the decision that this is an array program or this is more of array programming.
01:08:44 [ML]
Well, I mean, yeah. You're not attaching the word "good" to it, but your users will [chuckles].
01:08:50 [CA]
Well, I don't even want to attach the word array programming [Marshall agrees]. I want to basically just itemize the feature, and then when you do a view, it'll show a histogram. It has this, this, this, this, this, this.
01:09:00 [ML]
Maybe even you could select what things you're considering part of your particular paradigm?
01:09:07 [CA]
Exactly. You could make a filter that says: "show me the ones that hit these bullets", and then you'll get some ranking [Marshall agrees]. I'm totally with you on that because all we hear about in other people's languages is persuasion. Persuasion and convincing for not necessarily bad reasons. But in order for us to make clearer decisions, there's no resource that says: "here's the facts about this, and here you can really directly compare this to that and this to that". I made [it] for myself. I'm like: "okay, here's what I have to work with; here's where I don't have a choice. Here's where I have maybe two or three choices, which one will I pick?" For example, web, right? I don't have to use JavaScript, but pushing away from JavaScript is very hard to resist. But there are movements; HTMX is an example. LiveView is an example. I'm now looking at Erlang. I'm saying: "can I build a website in Erlang?" Because I feel like doing anything service-based, I just don't see any architecture that's superior to the BEAM. So whether it's Elixir or whether it's that or this, it's just like anything that needs to be robust and fault tolerant, that is it. They figured that out a long time ago, fell into obscurity, except for those who know and those who use it and big sites like WhatsApp and whatever that really use this sort of thing. But the core of it is this multidimensional array thing. So it's like: "well, I can mix the languages." Erlang allows you to immediately use GNU APL. I've already done that. They even have it built into the Erlang source. They say: "you can use GNU APL just by calling this". I'm trying to figure out how to plug in BQN into it [chuckles] because I'd rather use BQN than GNU APL. But I'm feeling like even this application itself, it will have this Erlang outer shell to manage the service part of it, but where it's got to manage this very complex data model (that I'm literally modeling in BQN; I'm sitting here creating an array list to figure out what the model looks like). I want a high level way to do that and I want to have to worry about implementation, data storage and efficiency just to get this model right. It may serve as a great engine for that. So I'm realizing that I'm going to be polyglottal, but I can choose amongst the set of options because there are so many to choose from [chuckles], right? I don't have to necessarily go with the most popular thing that people are using, unless I'm worried about not being in that community or that cult or finding a job or whatever. And those are all reasonable concerns (well not the cult part) but I want to be in the larger community. I want to make sure I can pay my bills. Yes, these are real important concerns, but where there is room to decide what information do I have so I can pick the best choice for the situation.
01:11:42 [STh]
I wish we had more time because I really like to dive more into what Stephen was talking about, about the minimalist approach. But I think that what Christopher is talking about is kind of an extension of what you were saying, Stephen. Trying to come down to that set of languages that answers the question of how do we solve different problems effectively? He's trying to build a language right now that will do it across the board. It's an interesting challenge. I tend to think that that's probably a difficult one to solve but I think we all agree on the concept, or at least I personally believe that minimalism is absolutely ... [sentence left incomplete]. It's one of the things that's polluted, especially the area that I've been working in business data processing: the massive amount of what we call stacks and the waffle and there's just so many ways to do things because in some cases, because as Christopher mentioned, it's motivated by the market. It's motivated by the monopoly and in some cases for instance, Vue is an example of a framework system that just came out of what, Australia or someplace, because some guy didn't like Bootstrap or he didn't like Angular or he didn't like React, so he went off and created Vue. Some people are doing it for that reason. I think that it's muddying waters like we were talking about before. I think that's, if I understood you correctly, Stephen, I think that's kind of the point you were making.
01:13:11 [CH]
Well, I mean, even though we're out of time (as you said, we wish we had more time) like I said, we're gonna have to make this ... [sentence left incomplete]. Maybe even, we won't wait a year because I said we might make it an annual thing but if proglangbase is gonna be launched at some point, that might be the perfect opportunity to have you guys back on and we can dive into it at that point, sort of, if we've got a little grid that we can link people to, we can chat about what different languages are offering and we haven't really dived into what you learned about each of the different languages that you've done videos on but we'll save that for part two and have you guys back when you're ready to announce something potentially whenever that is. So I'll throw it over to Bob who has our little outro and then we will sign off.
01:13:54 [BT]
And if you wanna get in touch with us, you can get in touch with us at contact@arraycast.com and my apologies to you, Christopher and Steve for saying "prawglangcast". It's "proglangcast" and I will make a point of being pro ... Glang-Cast. So thanks so much for being on. This is fascinating. Really neat, really neat stuff.
01:14:17 [CH]
Yeah, thank you so much for taking the time. Once again, whenever all of us are silently just listening, you know that it's not just us that are gonna be enjoying it, it is the listeners of the podcast. So looking forward to our next conversation and with that, we will say happy array programming!
01:14:33 [everyone]
Happy array programming!
[upbeat music]