Transcript

Transcript prepared by Bob Therriault, Adám Brudzewsky, and Igor Kim.
[ ] reference numbers refer to Show Notes

00:00:00 [Conor Hoekstra]

APL, number one was feature functionality, number two was perf, whereas q and k it's number one is performance, number two is feature functionality which I think is…

00:00:08 [Stephen Taylor]

No, number two is still perf. Still perf.

00:00:12 [Leslie Goldsmith]

Maybe number three is still perf. OK, number four is feature functionality.

00:00:16 [MUSIC INTRO]

00:00:26 [CH]

Welcome to another episode of ArrayCast.

00:00:29 [CH]

I'm your host, Conor, and today with us we have a very special guest. A follow up guest to the individual we had last week, who I'm super excited to talk about, but before we get to introducing him, we are going to go around and do brief introductions and then a couple of announcements.

00:00:40 [CH]

So we'll start with Bob, then go to Stephen, then to Adám and then to Marshall.

00:00:44 [Bob Therriault]

I'm Bob Therriault and I J enthusiast.... I am a J enthusiast, I'm not just skipping words.

00:00:49 [ST]

This is me, Stephen. I'm a q and APL programmer.

00:00:53 [Adám Brudzewsky]

Adám here. I do APL.

00:00:56 [Marshall Lochbaum]

Marshall Lochbaum. I did J. Once I worked at Dyalog and now I am developing BQN.

00:01:00 [CH]

And as mentioned before, my name is Conor. I'm a polyglot programmer with a huge passion for array languages, and I think we've got three announcements, so we'll go to Adám first, then Stephen and then Bob.

00:01:13 [AB]

Right. The announcement I have is that APL seeds 2023 is now taking registrations and you can see the short descriptions of the presentations that will be there. [01] APLSeeds is this special meeting for those that are interested in APL or in new to APL, but not established users yet, but anybody who wants to is of course, welcome to join.

00:01:44 [CH]

And to be completely clear when Adám says registration, what he means is just signing up via e-mail. It's completely free, at least, unless if anything's changed for 2023. Last last time I checked, this is a free conference, right?

00:01:57 [AB]

Yes, it is absolutely free. It's not e-mail though, it's a form. It's going to happen with us to zoom webinar.

00:02:03 [CH]

OK, small form then, but yes, free conference. Highly recommend. I mean most of the people listening to this podcast probably are already in the boat that are interested, but if you know students or people that might be interested this is like a great way to get folks that are curious about this sort of space interested even more. All right, we'll go over to Stephen for his announcement.

00:02:22 [ST]

OK, KXcon is in Montauk, NY, 17th to 20th of May [02] and there's a call for papers out. You can find it by going to kx.com/events.

00:02:34 [CH]

And it looks like that's open till February 28th and today. Today's Valentine's Day. Happy Valentine's Day and this will be coming out a few days later. So you've probably got a couple of weeks, (laughs) Adám, just put a little heart in the corner of his his window on the zoom thing. So yeah, if you've got the, you know, a talk that might be worth presenting at the KX con, definitely go check out that link and submit your talk and we'll go to Bob for our last announcement.

00:03:01 [BT]

I was just going to say KXcon, is the rumors are it's going to be... Massive.

00:03:06 [ST]

I heard that rumor.

00:03:08 [AB]

You mean billions of people coming or?

00:03:11 [CH]

Bigger than Pycon?

00:03:12 [ML]

You won't be able to store them in Kdb.

00:03:15 [BT]

OK, a lot of times we get excellent letters from and questions and all sorts of things from our our listening audience. And I usually mention this at the end of the show is ways people get in touch with us, but this last just prior to the last episode, we got an amazing letter from somebody who talked about how much this podcast actually meant to them, and it it honestly it really touched our hearts. And just wanted to say to Daniel, thank you for sending that. That really was very kind of you to do that and and and we're very happy that the podcast helps you in so many ways and that's just excellent and it's not what we set out to do, but you know something like that makes a huge difference to us. Thank you. Thank you for letting us know.

00:04:02 [CH]

Yeah, I'll follow up, I read that the message in full and was like, yeah, made made my day, if not week and also as a small sort of side note. One of the things Daniel mentioned, hopefully this isn't revealing too much self identifying information is that he's a clojure programmer and this is probably a very little known fact about me, but clojure I think is probably my third favorite programming language and all of my, well, all of my there's only one website that I've created plrank.com [03] is written in technically clojure script, but clojure script is just like a subset of Clojure and for folks that like array languages, I think Clojure is like a a beautiful language. It's has very very many similar things in terms of like composing operations together in a single statement to do nice things anyways. So for the very curious, Clojure is a great language. Rich Hickey is a genius and made amazing decisions in creating that.

00:05:00 [CH]

Alright, we will now move to introducing our guest today. Leslie Goldsmith was mentioned on our last episode with Michael Higginson [04] and I think we actually we've gotten some feedback from Leslie in the past, which hopefully is going to come up in the, you know this conversation but a brief introduction. I believe Leslie, you started at IPSA in 1973 and worked there for about 16 years, then went on to work at Affinity Systems, which Michael covered that in a bit of his sort of background and then worked there for, I think a couple decades plus and then have been working at KX since. I think I first heard Leslie speak during the Iverson centenary. You gave a short, I don't know if you wanna call it lightning talk or sort of just speech at the at the beginning, there was a bunch of folks that talked and the stories that you told. I think I recall you were talking about going to give like an oral defence and I'm not sure if it was U of T, but the school you were defending at and anyway, Ken had, like some words of wisdom for you, and it was just a very funny story anyway, so I'm hopefully looking forward to hearing a lot more of those I'll throw it over to you. Take us back as far as you want to you know when you had your first computer or when you first sort of entered your journey to the array languages and, and we'll go from there.

00:06:12 [LG]

Thanks very much for the introduction, Conor. Yeah, that's almost exactly right. We're pretty well done, except for it was more like 17 1/2 years at IP sharp instead of 16. But other than that you summarized it quite well. My introduction goes back to high school. I was really fortunate to go to a private school in Montreal, Lower Canada College [05] where I was first exposed to computers and it it would be no exaggeration to say that LCC changed my life. LCC at the time, and still does, placed a lot of academic emphasis and athletic emphasis on high achievement, and they routinely.. the students, would routinely win high placements in both academics and athletics. The head of LCC's Math Department was a fellow by the name of John Brown, and he had written a couple of books on Euclidean geometry by the late 60s. Around the same time he attended a pedagogical conference where he met Ken Iverson and Ken and John somehow arranged to have IBM Yorktown Heights provide APL time Sharing Services LLC based on IBM's XM6 program product running on a System 360 a little bit after that, maybe 1970 or so IP Sharp opened its Montreal office with David Keith as a branch manager. David convinced the school to switch from IBM's APL to Sharp APL and actually they did do that. And the APL that I ended up learning was really the Sharp APL variant, although it was based on IBM's product. LCC started teaching courses in APL to students in the upper years, which didn't include me, and actually that didn't bother me at all. At first I wasn't particularly interested in computers, but I had always been very interested in mechanical and electrical devices and the new computer terminal that we had was certainly one of those. The terminal was an IBM 2741, so if you're not familiar with this, think of a smallish desk where most of the surface was occupied by a largish machine. The device was basically an elaborate Selectric typewriter that was outfitted with communications capabilities, and one of two type balls either AA987 or A988, for the two different communication protocols, correspondence and EBCDIC that was supported by the 2741 and it operated at a whopping 134.5 Baud, which is a little over 14 characters a second. But when this thing was printing, it was pretty magical to watch and it smelled good too. Something about the ink that they were using on the printer and the typewriter was really, really interesting. Anyhow, novel for the time the terminal was connected to the telephone line through an Anderson Jacobs serial modem and the modem was a really, really elegantly crafted dovetailed cornered wooden case into which you would fit the handset of your telephone and then you'd fasten the box close to hold it in place tightly. I spent a lot of time with this machine, mostly taking it apart and putting it back together because I really had no interest in the software side. I did try to do one programming thing though. With zero knowledge, I might add, my uncle was a professor at the University Of Montreal and on one of my visits to his office on a Saturday, he gave me a really cool print out of a Mona Lisa facsimile, which was generated using ASCII characters on a line printer with very, very narrow line spacing, so the characters were quite close together both horizontally and vertically. The toning in the picture came from the creator's really clever choice of characters that had the appropriate spatial density, and the result was absolutely amazing, even close up. I wondered if I could use APL to generate this thing, and I wasted a bunch of time and paper doing that.

00:09:49 [LG]

When my grades curriculum was expanded to include APL courses, there was some expectation by my teachers that I would do decently well given the amount of time I was spending in the computer room. Of course, they had no idea what I was actually doing there. That turned out not to be the case, and I miserably failed the first APL test that our class received. I remember my algebra teacher pulled me aside when he handed out the marks and he said, well, what's going on, and I embarrassingly suggested that perhaps I hadn't studied hard enough for the test, which was certainly quite the understatement and I promised to do better on the next. So basically I was shamed into learning a computer language and I'm just thankful that that language happened to be APL. I started reading Gilman and Rose that night and I loved absolutely everything about the book and the notation. This was the first version of APL and interactive approach from 1970, and it predates both Unix and K and R's the C programming language, which is another excellent language manual. Gilman and Rose is a great book with lots of practical examples. It's when I first learned the leap Year rules for the Gregorian calendar. I had always thought it was just years divisible by 4, but one of the problems in the book explained that ignoring epoch extremum, a year is leap if and only if it's divisible by 4 unless it's divisible by 100 unless it's divisible by 400, unless it's divisible by 4000. I was completely unaware of the centesimal and millennial wrinkles, but note the alternating parity of the rules, which suggests that there's a nice solution using not equals reduction. If people were seriously worried about the specious, I would say Y2K problem. What they should really be worried about is either 2038 or 2100 stuff is definitely going to break in those years anyhow. Started spending spending pretty much all my free time programming, thinking of new problems to solve and exploring the public libraries that were available on the IP Sharp system. I went through them all. There were hundreds of them and two in particular interested me both for the same reason. Actually, they both tried to keep people out. One of these libraries was a database of travel information that was maintained by the Canadian government about trips taken by politicians and civil servants. The other was an electronic mail system. They were both really, really intriguing. I got into the government system without using too much difficulty and developed a few handy techniques along the way. What I didn't know, however, was that each failed attempt to access that system was logged and reported to the government agency. The system's author made the Selectric type all do a really captivating dance while, as I later learned, it was collecting information about the violation or a security report. This caused our school to be flagged by the RCMP, which is the National Police Service responsible for overseeing government security in Canada. One day they came by the school to talk to me and a couple of others who were involved and I guess they came by to find out how much of a national risk we actually represented and not much I expect, but out of it, we got a day off school, a free trip to Ottawa, a job offer and some amazing pizza at a place called Colonnade. We also got a bit of a dressing down by the headmaster, who wasn't too pleased about our antics and the attention that it had attracted. That other public library I mentioned, the mail system, was even more intriguing. IP Sharp Associates, it turned out, ran on e-mail. It was really the lifeblood of the company and of some of its customers well before SMTP was even proposed. By breaking into the mail system, I was able to see things that well, it's safe to say I wasn't supposed to see lots of confidential for your eyes, only type of stuff, but the eyes weren't supposed to be mine. Even some assignations here, here and there, and certainly some embarrassing stuff. I reported what I had done to the operations group at IP Sharp and the author of the Code, Larry Breed [06] from Scientific Timesharing Corporation, STSC, made some quick fixes. We repeated the cycle a few times. He'd provide a new release to me. I'd break into it. He'd go back and make some more changes. And I developed even more techniques along the way that were helpful in helping me to protect my applications from others. At the school we were getting pretty good at the computer stuff by this point, and David Keith, the IP Sharp Montreal branch manager, got to know a couple of us quite well. When LCC approached David and asked if he would write a computerized report card system for the school, David suggested that they give the project to me and my classmate Gary Benjamin. The big selling point there was probably that we wouldn't charge anything to write it, but this was created in complete secrecy from the other students at the school, but using the same computer terminal and the same account as everyone else was using. We wrote and ran the student record subsystem as we called it from that point until when we graduated. Gary actually graduated a year before I did, but from all that I had learned, I was pretty confident that no one would be able to get into it. Even if they knew that it that it was actually there.

00:15:02 [LG]

A stroke of luck for me came when David Bunyan and IP Sharp offered me the job of writing a new mail system for IPSA, one that I couldn't break into when I was 16. The new system was designed was supposed to be functionally comparable to the existing one, but I was given carte blanche in terms of its inner workings and of the details of the features and capabilities that I wanted to put in it. Now this was truly an epitome project and it was lots of fun to write. The thing about an e-mail system though is that the read write pattern isn't really typical for most database applications. It's generally appropriate to optimize the database for reads over writes, but the ratio of reads to writes in our mail system was a shade over 2 to one, and it would have been closer to parity, in fact, if we're not for the capability that we supported address groups, so it was really easy to send a message to lots of people. This means that you have to optimize simultaneously for both reception and sending, and that turns out to be a lot harder than it sounds. The mailbox, as it was called, wasn't my first project for IP Sharp, it was actually my second. The first was writing a new system to inform timesharing users of planned or release changes to the APL library system. Sorry. To the APL system or to the libraries that we that we were supporting. As a side note, remember that in 1974, a bit later, someone decided to expand the new systems purview by releasing an article about Nixon's resignation. As an international company with lots of users in the states, you can imagine that didn't go over very well. The item was retracted pretty quickly actually. I started working for IP Sharp during the summer before my final year of high school and continued throughout that final year. This is, as you know, is the time when you have to start worrying about university placements and I was trying to decide what I wanted to go into. Software is my passion, but I figured that I already knew how to program. I didn't, however, have the foggiest idea about how computers actually worked, so I decided to apply to electrical engineering faculties. I was accepted at some pretty attractive places in Canada and the US, but because IP Sharp's head office was in Toronto, I decided to go there. I made the decision to go to University of Toronto [07]. And from there I got my BSc and MSc degrees in electrical engineering concurrently with working pretty well full time for IP Sharp and I continued at IPSA after graduating. Interestingly, although Arthur and I overlapped in time at U of T, we didn't actually share any courses. This was partly, I expect, because he was in computer science and I was in electrical, but even though I took some courses from the CSC department, we somehow didn't manage to be taking the same thing at the same time. We did have some great discussions about algorithms back at the office, though.

00:17:51 [LG]

IP Sharp was a fantastic experience and those of us who were lucky enough to work there knew just how lucky we were at the time.

It was a place of amazing talent and there were virtually limitless possibilities in an atmosphere of absolute trust and respect. I got to work on lots of great projects at IP sharp both in APL and in 360 assembler [08], enhancing the core APL system. I think one of the best ways to learn a language is to read other people's code, something I still do now. And there were beautiful examples of 360 assembler behind the scenes. This influenced both my writing style and my commenting style in assembler and in other languages, even APL. One of the system enhancements that I made was it was involved with extending the APL event trapping mechanism that had been implemented by Eric Iverson. I proposed and implemented a system variable that offered a kind of dynamic runtime contract between the programmer and the interpreter regarding the interruptibility of a program. This finally made some of the attack vectors that I had exploited years earlier impossible. This proposal actually was part of my master's thesis. One section of it had to do with system enhancement stapl that could improve security. My interest in security and performance led to work on APL tools for programmers at IPSA, including a bunch of stuff on searching, static analysis and text editors. The culmination of this was building a secure programming environment for APL that included a hierarchical file system with version control and features to help write, organize, build, deploy, and run complex applications that were too big to fit in a work. This product, which we called Logos, was created by David Allen, Mark Dempsey, Kevin Harrell and myself. Logos was of course written, deployed and run using Logos, which is I think one of the things you have to do if you're gonna build a programming language or an environment, as a show of confidence in its security. I moved the mailbox into it as soon as I could. Over the years, we made lots of improvements to the mailbox, Dave Markwick, Henry Schuler and I added cross domain support by networking IP Sharp's computers with capabilities from IBM, smads PROFS, and DYSONS systems in the early to mid 80s, we actually tried to get connected to the Internet around 1986, but sadly, the Internet rules for commercial.com entities at the time was that they they had to be involved in either government or educational activities in order to be admitted. It looks like they kind of backed off that requirement at this point, but when one mailbox node was able to talk to another, it offered 100% of the features that it had always offered, including fail safe security, irrefutable authorship, guaranteed message delivery, real time message retraction...that was certainly a favorite among its users...Disseminated, pending, and unread message states, address and group interrogation out of office notifications and lots and lots of other things in.

00:21:04 [LG]

In 1987 Word had acquired IP Sharp and the workplace began to change. It was still fun, but it was becoming more political and the overall mission less clear due to a general decline in the time sharing industry. About a year after the acquisition, Hugh Hindman and I, a close colleague, got together and we started talking about the future. We were both directors of development, but we felt the time was right to leave and to start our own company. With Ian Sharp's blessing in in 1989, we found an Affinity Systems with the goal of offering premium quality software consulting and product development services. Culture was really important to us and we wanted to emulate the respectful atmosphere that Ian had nurtured and in which both Hugh and I had had the privilege of growing up. Affinity had the opportunity to work with some terrific people and terrific customers in all kinds of diverse areas. We built trading systems, financial analytics products, imaging systems, Internet crawlers and sentiment analysis systems at Internet scale really, really hard stuff. We built Indigo Books first website, Mastermind toys first website, 12 Investor Gold, Webkinz Junior for Ganz and several key healthcare applications for Cancer Care Ontario. We also built mission critical control room software for the IESO [09], the independent electricity system operator that runs the electricity grid in Ontario. We have the privilege of working side by side with some some of the best and brightest people in these industries and learning from them. It was really a fantastic time. One project that was to change the course of Affinity Systems was work we did for the smart metering [10] entity, the SME within the IESO. The SME handles the collection and dissemination of smart metering data from electricity meters across the province, so all the meters on the sides of houses or or commercial institutions, commercial establishments feed the IESO's system. As well as collecting the data, they also are responsible for the calculation of billing determinants from that data. About 10 years ago, the IESO was looking at alternate ways to provide query access to the smart rendering metering data to overcome performance problems that they were having with their existing systems, and also to pave the way for public access to that data, which was a a growing interest in the province and in the world in general. We looked at dozens of possible technologies to address the business problem and ended up choosing Kdb Plus [11] despite the fact that that we at Affinity Systems had never used it before. Our experience with KX, with Kdb plus and with First Derivatives [12] led to our being acquired by FD in 2015. Many of our top notch Java, C andC Sharp developers went on to become top notch Q developers. Michael Higginson, for example, who was a recent guest here, is a perfect example of an array convert. Most of my time spent at FD and KX has been building the KX Sensors product, which is a high performance data acquisition and analysis platform for industries such as utilities, semiconductor manufacturing, telco, pharma and so forth. It's challenging work because although it sounds like a really, really easy problem to solve, we have the requirement for absolutely non-stop performance even during functional and database upgrades and requirement to ingest and be able to analyze and query in real time a huge amount of data and this is really what makes the problem challenging and for which we think Kdb was an absolutely perfect choice. That's kind of it. I could talk more about the present, but that's certainly a a lead up to where we are now and how I got here.

00:24:49 [AB]

Well, that's something.

00:24:52 [CH]

Alright, this is gonna be... I got... This is one of the episodes where I just have 1000 questions. I mean, so first of all, this is really not that important of all the things you said. So when you said Lower Canada College, for those that you don't know that are listeners, I live in Toronto and Leslie also lives in Toronto, so I just figured that you'd always grown up in. And so when I heard Lower Canada College, I instantly thought - I had no idea there was a Lower Canada College in Toronto. Like, there's an Upper Canada college like makes sense that there be a lower one. And then I went and Googled it and it says that that's in Montreal. So and you had mentioned that you had, was it a a relative that worked at the University Of Montreal? So you grew up in Montreal then for the your childhood until you went to university.Is that accurate?

00:25:34 [LG]

That's right. I left Montreal when I was 16, actually, before my first job at IP Sharp, David Keith, branch manager of the Montreal office, got me a job at an investment house in Toronto. So in the summer of 1973, while I was in between my penultimate and my ultimate year at high school, I worked for a Toronto company and then it was while I was working for that company, CanInvest House, that I got to write the new system for IP Sharp and in the same summer the mail system for IP Sharp. So I was kind of working on two jobs at the same time. And then I went back to LCC to finish high school.

00:26:13 [CH]

And then moved to U of T where you had started working for IP Sharp in the summer and then continued to do that for the entire duration of your I guess undergraduate and postgraduate studies.

00:26:24 [LG]

That's right. After graduating from LCC, I moved to Toronto immediately and had made arrangements in the spring of that year to work not as a programmer, but as an operator, running the APL time sharing system along with a group of other people, of course. And I wanted to do this because I wanted experience on the operations side and that's what I did in the summer of 1974. It was a great job, actually a good opportunity to meet a slightly different group of people with whom I would have had interaction anyhow, but also to learn what it took to to, to operate the system, to run backups and restores, to handle emergencies when they occurred, to cause emergencies in some cases by pressing the wrong button. Yeah, but it was good all around.

00:27:06 [CH]

Wow and I can't help but think that like like we all have heard your name, obviously, and some of some of us know you much better than I do, but like you've told the story basically where you were this like hacker to the extent where the police are showing up at your school. Were you like famous like at at your like Leslie's this individual that was unintentionally or maybe intentionally or you know you didn't really realize what it was doing, but like that's and then you ended up like you said going in cycles and fixing things along the way like that's like I hear that story. And then I think about like someone like George Hotz [13]. I'm not sure if you're familiar who he is, but you know his first person to hack the iPhone and has been become quite the social media figure and you know Twitch live streams and stuff. But like when I hear your story, I think about that like is there is there are are you are you a part of some like you know dark circle of like hackers that want some sort of badge? Getting the police to show up like it's it's just an incredible story.

00:28:08 [LG]

I don't generally tell that story. Yeah, I don't talk about that part of my past. I just thought it might be interesting, but nobody at the school short of the staff, sort of the teachers and the headmaster knew about this. It was interesting the day that the RCMP showed up, what happened was they had master came by and found what class I was in. And he was at the entrance to the class. Everyone feared the headmaster, by the way. He was this kind of dominating guy. He was overbearing. And you knew that when he spoke, you listened. Anyhow, he came by the the door of our class. He looked around the classroom until he saw me, and then he pointed his menacing finger at me and then motioned come here without saying anything, and I pointed to myself, saying me, and had this quizzical look, and he nodded. So I had to leave the class and everyone in the class knew something was wrong, but of course they assume that something's really wrong, that you've done something wrong and that you're gonna get whacked or something like that. Anyway, I went to his office and in the office were several people from the RCMP and I had no idea what was going on and he explained that there had been some reasons for concern because it looked like there had been some illicit activity perpetrated by someone against this particular government database and the source of that activity was tracked to our account number on the IP Sharp system and they were obviously able to track that to the school directly. So I had an opportunity to describe what I had done and why, and I made it clear I wasn't interested in any of the details of the database, and I wasn't going to do anything with the data. I was just fascinated by the problem of breaking into it and especially this psychotic dance that the type ball was doing, not realizing that every time I did that and watched it in amazement it was another violation that was being logged. So this was all unknown to the students, and that whole thing about writing the report card system for LCC, that also was unknown to the students. So I wasn't well known except within IP Sharp and the APL community where I did start to have a name.

00:30:16 [CH]

And how did the headmaster? Did he just assume because you spent the most time of all the students that it was you?

00:30:20 [LG]

Yes, because he didn't had any idea. There was nothing to track my name. We were all using the same account number.

00:30:28 [CH]

It was just how much time.

00:30:31 [BT]

So I've got a question. When you were in the office with the headmaster and the RCMP? I have a guess that you were more frightened of the headmaster than the RCMP.

00:30:42 [LG]

The RCMP were pretty intimidating, OK and there were discussions at the time of reprisals.

00:30:50 [BT]

Oh, OK.

00:30:51 [LG]

So it wasn't comfortable. I was actually relieved to walk out of there and go back to class.

00:30:59 [BT]

And were you allowed to tell the story when you went back to class because I thought there was a lot unknown.

00:31:03 [LG]

No, no, no, I I don't know what was said to me about telling or not telling the story, but to me the whole thing was embarrassing. So I wasn't going to tell anyone except my parents.

00:31:11 [CH]

How did your parents react? Were they proud or were they upset?

00:31:16 [LG]

I think they were kind of proud. It's an interesting story, but there's probably a bit of head shaking. I don't really quite recall, to be honest. I didn't get reprimanded at home for it. I know that if anything, they were probably supportive, but since I was honest in my intent. I think that made it OK. And that was clear, too, from breaking into the e-mail system, for example, as soon as I'd done it, I reported it. So, I felt that if I had known with respect to that government system that I was actually doing something wrong, I would have reported it too, but I wouldn't have known to whom to report it with the e-mail system, since it was an IP Sharp thing, it was easier to figure out what to do. Yeah, and I think it was pretty clear it wasn't really a threat.

00:32:00 [CH]

It is interesting that like probably these days if, not that you would really have the ability like, but if you were pinging some database, you probably get some message saying like, you know, it's not allowed et cetera. But your feedback was the dance of the type ball. So like, you know, how are you supposed to interpret that, right?

00:32:19 [LG]

Something I wanted to do more of or see more of. In fact, in the student record subsystem that we wrote, I incorporated some access to the application, so we knew nobody had tried to get in.

00:32:34 [CH]

Stephen?

00:32:36 [ST]

I was a user of the replacement mailbox system that you wrote for IP Sharp Associates and I have to say it was an inspiration to me as a young junior programmer. One of the great features about the APL systems and in that environment was you could interrupt them pretty much anywhere. And when you did that all the pieces were laid out when you're developing. I mean, this is a world away from, oh, what were the alternative environments at that time compiling FORTRAN. Something like that.

00:33:10 [CH]

Fortran, right?

00:33:12 [ST]

Yeah, that was my first language, Fortran. So with the APL system, you you just interrupted somewhere and see what would and inspect all the variables and done it's stuff we take for granted now, but APL was literally, I think decades ahead of most other environments, and damn it, you could not do that with 666 Mailbox.

00:33:34 [LG]

Right. So one of the things that intrigued me so much about the e-mail system was that, as you said in APL when you interrupted something, you had access to all of this, you had the access to the execution stack, the function names on the execution stack, the local variables, if they weren't shadowed... The sub functions which were always there as globals and you always had access to the global variables and if you think about what it would take to build an application like an e-mail system and have it performed decently, you have to figure that whatever you're doing to authenticate a user, you can't do that every time they ask to do something, you have to do that and set up certain variables that relate to who they are for messages that they've sent and received, possibly groups to which they subscribe, permissions, authorization, things like that, you have to set this up and do it once, and then you have to be able to use that repeatedly and know that nobody has interceded to forge the person's identity or to forge their credentials within that identity and that was impossible to do an APL. Absolutely impossible. I don't mean hard, but what Larry had done was because Larry was one of the implementers of APL 360 when he implemented the mailbox. Realizing this conundrum, he made changes to the interpreter to make it so that names that were in the symbol table of the mailbox workspace at the time he ran a certain function were locked into the symbol table. He did that by mapping the print names so that the first character of the name was a symbol, it was itself a symbol. So if the name were ABC, that might have become times ABC.

And if you were to type times ABC, of course, that's not going to be interpreted as print name. And so he made two changes. One is to map the names of the objects in the symbol table, so they were untypeable. And the second thing was to change the interpreter so that it would not print these untypeable names and the result was that there were zero global variables in the workspace that you could see, except for the thing called Scribe, which was the documentation. The only functions you could see were the public sub functions. If you interrupted the program, there were no local variables over and all of the functions other than the root function had no names.

00:35:43 [ST]

I have waited nearly half a century to fit to learn how you did that.

00:35:48 [LG]

Well, it wasn't me who did it. It was Larry who did it, but I used the same technique and then extended it to do a couple of other things to provide the security that we had, but that means this couldn't be done right.

00:36:02 [AB]

It's something you have to the system from the from outside of API had to allow for. This hacky thing of giving names that are not legal.

00:36:11 [LG]

It could only be done if you run a privileged terminal and you ran a magic function that we had, so the average user couldn't do it, but the only application to which we did it at the time was the mailbox. There was another one too. I wrote another system called 666 Numeric which was responsible for creating accounts in the system and authorizing them, and that system had the same security as the mailbox did but we didn't use it anywhere else.

00:36:36 [AB]

You spoke before about API functions controlling how you were allowed to suspend them. Is that this that you're talking about or did you said you added a mechanism or like a system variable that controlled?

00:36:50 [LG]

That right, it was a variable called quad ec [14], which stood for environment condition, a Boolean value that had a default if you localized it. That said, you don't allow suspension. And then if you're if in execution the program reached a point where the programmer had said looks like everything is safe here, I'm OK to allow suspension. You could set quad ec to one. Now this transition point of not being safe to suspend to being safe to suspend was usually around you're having set up event traps that would pick up any interruptions that might occur, but before that point, before the traps were in place, you're exposed, quad ec guaranteed that you couldn't be exposed. So typically what you do is you localize quad ec And quad trap you were fail safe until you said quad ec to one and in the meantime you could do whatever you wanted to do. In particular setting up your event traps, which would cover if you wanted, interrupts and any errors. Then you would set quad ec to one saying everything's cool, and now your system was pretty safe, but you couldn't interrupt before it reached the setting of what you see.

00:37:57 [AB]

I don't understand.

00:37:57 [LG]

What would happen is we allowed the interrupt, but we peeled the stack back until the nearest higher lexical level that had quality set to 1. That might have been all the way back, or it might have been just one or two levels, because of course it's not.

00:38:12 [AB]

Ohh yeah, now I forget where all these values are anyway we might be getting really technical but the the the reason I'm asking about this is actually a a personal interest. I've been wanting to to do this and that and that like APL we kind of have this thing, we have something locked functions that are more fine grained than just locked or not locked where we can set particular behavior, that's that you can't suspend in this function, but that's part of the definition time of the function at definition time of the function rather than the function itself saying I cannot be interrupted. Ohhh right now I understand right? As soon as you localize it then and that happens immediately when you step into the function that's right, then you're safe.

00:38:54 [LG]

Right.

00:38:55 [AB]

OK, yeah, that's why. Otherwise, if if you had to wait for it to be set, then it would be too late, you know.

00:38:59 [LG]

That's right, it has a default value. As soon as you localize it so there's.

00:39:02 [AB]

It's just different from the normal default value.

00:39:04 [LG]

That's right. There's no opportunity for the user to intercede.

00:39:09 [AB]

Hey, maybe we should just do that. You have the solution.

00:39:14 [CH]

All right, a high level question. So I think this was, I think it was Michael Higginson was the one that mentioned this to me. I could be misattributing this to him, but I'm sure he would agree if and even if he didn't say this was when we first met in September at that Toronto meet up.I remember in the midst of talking about sort of technology companies and and IP Sharp, I think his remark was that, you know, he thinks or even if maybe it's not true, he thinks it's it's debatable whether like what the greatest Canadian technology company has been and most one of the top answers is typically BlackBerry. At least you know in terms of global sort of awareness et cetera. But I think he said that like IP Sharp is a contender, if not one of the greatest technology companies. And it's just very few people have heard of it from, you know. I guess if you worked with them at the time you heard of it. Maybe back in the 70s and 80s it was a... I don't know if it was equivalent to. Like you know, a company like Google probably not as sort of widely known, but I'm just curious to get your thoughts because you worked there for 17 1/2 years and I'm sure you, I think you had mentioned that the Iverson centenary that you you know worked in the zoo as well, which I've seen a Dyalog video, I think it was by Bob Bernecky that was talking about sort of what it's like to work in the zoo. And just like there's so much history and, like, you know, the stories of the e-mail, basically, it was like the first company by a couple of decades that was operating off of e-mail anyway.So just curious like your thoughts on IP Sharp is like this amazing technological technology company that people haven't heard of. And yeah, if you can say more about that or what your thoughts are when you hear that

00:40:57 [LG]

Well, I think it'd be pretty difficult, hard and maybe unfair to compare it to a company like Google or BlackBerry simply because the products that Google and BlackBerry offered were of general appeal and availability. And that wasn't the case with IP E-mail in order to use an APL time sharing system [15], you were probably a government agency, a bank, or a forward thinking company, Xerox, for example, Kodak Cyberon, Bausch and Lomb, these companies were big users of APL. You might also been an educational institution, but you weren't the average person who had a problem to solve because you wouldn't have been able to afford the time sharing costs and the equipment necessary in order to connect to the system, on the other hand, if you think about what Google or BlackBerry requires, the barrier to entry to becoming a customer of either of those companies is extremely low. In Google's case, it's zero in BlackBerry, you know is growing, growing to be a necessity to have a smartphone, and that was arguably the best one out there, so pretty low barrier to entry. If you had any interest. So but but among the people who knew about IP Sharp and and that would, that would be its customers and its employees, obviously it was highly regarded and within the industry it was groundbreaking for sure there were a lot of articles written about Ian and about the great work that the company had done. And about the things that we had achieved as firsts within the world, including the pervasive use of e-mail that, by the way, was a really, really hard thing to manage, you know, in the early to mid 70s, even in the late 70s, there were governments of various countries. Britain's a great example, the UK. Where there were monopolies within the countries for controlling communication services, and this typically dated back to the 16th or 17th centuries and in the case of Britain, the general post office, the GPO had a monopolistic authority over anything that involved point to point communication. So where somebody was sending something to somebody else whether that was by mail or by wireless or by Telegraph or whatever, and so when e-mail came out, the GPL insisted on regulating and prevent. IP Sharp's use of electronic mail, and so did many countries in Europe. So in order to be able to offer e-mail at the time, we had to convince each country one by one and some other neighboring countries precedent wasn't good. We had to convince each country that we weren't a threat to their monopoly. In many cases, the the argument which was promulgated by Ian and by other locals that the backroom finessing that they managed to pull off was based on the fact that in the end we would be using telecommunications capabilities that they were as a result of their monopoly in charge of anyhow. So we weren't denying anyone anything in the end, the services relied on existing services over which they unequivocally had control, but it was a real uphill battle. In some cases we just used e-mail behind the scenes, even if we said we weren't going to eventually, countries capitulated and we had the generally accepted right to use it everywhere, but it was a it was a hard law, so we were definitely breaking new ground on many fronts at the time and Ian was quite well known in the industry, he was a very, very good speaker and you know, he was funny and he was always on point. And as a result, he got to to talk about the computer business in General, Canada's role in it. IP Sharp, of course, at many conferences. So within a certain niche, I think it's fair to say we were very well known, but as far as the average person on the street was concerned, of course we wouldn't have been because they wouldn't have had any opportunity to use or even to think about using computer services in those.

00:44:46 [CH]

Yeah, it just seems it seems kind of incredible that they're this Canadian technology company in the was founded in the 60s and it was massive in 70s and 80s and like so few people, I guess it makes sense like even I work for NVIDIA and there's a ton of people that, like I would say, 90% of people don't know that company of like the general population. And if you point to like that is, but it's, uh, yeah, it's just kind of sad because, you know, there's how many books have been written about BlackBerry and stuff like that. And like you know, I want to read the seven different books, I'm sure that could be written with even more amazing stories than like the fall of BlackBerry, then sort of the rise of of IP Sharp and and like you know there could be a whole book on the zoo. And there's just so many people that we're meeting from this company that have gone on to do different things and it just, yeah. When you hear that Ian's giving all these talks. I'm just like man, why wasn't YouTube around like 2 decades earlier? So we could have these like, you know, finding a talk even by Ken,[16] who is, you know, obviously a Turing Award winner. There's, like, you know, one or two that are more than 30 minutes online and then you can find a few little two or four minute clips. But it just seems like such a for someone that is curious like me and wants to see this stuff like that, we live in this now golden age of everything's recorded at conferences and we can go watch it. But, you know, the closest you'll get to like a talk in the 90s or something or 80s is like a slide deck, which I have emailed people before. Like I emailed Guy Steele once. He gave a talk, called them why or how APL can change the world and the recording wasn't available, but I emailed him and he without any, you know, text in the e-mail message just sent me back the slide deck in PDF form. But yeah, it's it's very sad that you know, these talks aren't mine, aren't online for, for people that are curious to go and watch because I think it'd be amazing.

00:46:30 [LG]

I don't know what year that was... I certainly know Guy, but I remember giving presentations slide decks, so to speak, that were literally glass slides in a Kodak carousel and we had to lug these around from conference to conference, never in our carry on of course, cause even at the time we didn't trust that. But putting these slides together was a Tour de force. Often there was artwork that had to be created. Typesetting anything wasn't easy, and the artwork was line drawings typically and then we use just wax, cut and paste literally the the origin of the phrase, cut and paste to strip it onto a sheet that we would then take a photographic quality, high resolution picture of and then that would be transferred onto glass. It was a lot of work.

00:47:15 [CH]

It's it's. It's interesting. Like the the shift of a couple of decades, like when you were talking about the IBM 2741, I think it's like I looked up a image of it and it's like like literally you were explaining it a full deck desk with like a computer into it and versus like when I was in elementary school, we had the colorful iMac, and like people weren't taking those apart.

People were just playing the, you know, Bugdom was like the game on it, you know, for whatever 2% of our listeners happen to have the same computer in the same game. And it's like and then shift forward to like making presentations. Now you can put together a very nice, you know PowerPoint or keynote in like 10 minutes and your version of that was like I was expecting you to say. What do you call it? The overhead projectors with the the plastic material, but like no, it's even it's even more difficult than that.

It's sheets of glass overhead projectors came later.

00:48:03 [LG]

We did do that too. The nice thing about transparencies on overhead projectors that you can write on them in real time, so that was had if you're giving a presentation at a conference, you can circle something or you can put an asterisk besides something the equivalent of highlighting digitally. You'd actually do with an erasable marker on the film.

00:48:21 [CH]

Yeah, all of this talk of the conferences from decades ago makes me think we gotta do this ArrayCon. And there's got to be like a certain percentage of talks of, like bringing back the greats that like people from my generation, never got to hear or see speak. And then we can record it, put it on YouTube and... Yeah, I mean I would have... What I would have given like even when you mentioned that... I always forget that Arthur Whitney went to U of T, because I just, I associate... All my brain space and connected to him as the K1 K2 K3 K4 K5 K6 K7 K9 Shakti A+. Like he's done so much stuff that I forget. At some point he was studying. And so yeah, like if, yeah, if he would ever speak at a conference like that. But hey, speaking of Arthur, like, so you said you attended U of T at the same time as him. Was he also working at IPSharp, though at the same like doing the same thing that you were doing: working full time basically while studying and that's. Because you said you got to have some interesting conversations about algorithms with him. I assume that was at IPSharp.

00:49:23 [LG]

That's right. It was back at back at our offices. I am not sure whether he was working full time or not. He was definitely working at the company. And but he was in a different group. He was working for the databases group. That was actually David Keith's group. And I didn't have anything to do with them at the time I was on the systems side, so our interactions were strictly academic and we had some good discussions about algorithms and how they worked, whiteboarding things, and it was a lot of fun.

00:49:51 [CH]

What was the general like, I don't know if you want to go to, org structure, but like you know I've worked for several different companies in my limited career compared to some of the folks on the call. And different companies have different things like they'll have weekly sort of, you know, one company called them interest group meetings where it be an hour and one person would present on something they were working on, but it would always devolve into or not devolve evolve into a sort of discussion of the technical merits. Like was there lots of stuff like that or was it mostly people were contained to their groups or are they or they like how often were there, sort of, you know, cross company or is everything so distributed globally with working on e-mail that having meetings like that doesn't happen very often?

00:50:32 [LG]

That's a good question. Well, first of all, the company was international. We had over 50 cities in which we had offices. So although Toronto was the largest single office, we had a lot of people in some other places. Rochester, NY is a good example. The opportunities for people to get together between offices were not that common. They happened obviously at user meetings. Management would get together, they would have branch managers comps, but that wasn't technical. And the main form of communication was definitely e-mail where there were really no boundaries as a result of the fact that the companies approach to hierarchy was very, very flat to begin with. There really no boundaries in that sense and whatever perceived geographic dispersion there was was mitigated by by e-mail. So people talked all the time and exchanged ideas, and you know, test versions of software were made available to people through e-mail, etc. But in Toronto, there was, and probably this is true of other cities as well. It was definitely true of Rochester. There were groups of people who routinely got together both socially and to discuss technical problems. In Toronto there was a room that was referred to as the bean bag room. So some listeners will have some physical some mental recollection of what that looked like and people would go there every evening around 6:00 o'clock and spend maybe half an hour or an hour and we would always be talking about interesting stuff, technical problems, or what's going on in the world or whatever. But it was good opportunity to exchange problems that people were having with whatever they were working on. It's kind of like the water cooler.

00:52:12 [ST]

Alright, cool bean bag room on a visit to the Toronto office. One of our colleagues took me in there for a discussion and while we were talking, the door cracked open and a a very hairy face leaned in and said the Mounties are in reception. Is this room clean?

00:52:34 [LG]

There were things that went on in the bean bag that were not atypical for a software company at the time. So there was concern that there might be some. Materials in the room, let's say that would have been frowned upon by any official agency.

00:52:52 [BT]

Substances. Ohh.

00:52:54 [AB]

Wasn't that deal with the between STSC and IPSA that they would supply each other with such substances. So they didn't because one was headquartered in in America, one in Canada by supplying each other this for that. Then they didn't need to try to take anything across the border.

00:53:16 [LG]

I am not aware of that. We certainly had some arrangements between the two companies, the two sister companies worked together very closely for a while. For example: The technologies related to the file system and quad FMT which originally was called Delta FMT, the report FORMATTER we're jointly developed and shared, and so was the e-mail system, but not in source code form. The e-mail system that that I had broken into that Larry wrote was the property of STSC. That's partly why IPSharp wanted to have somebody write a version that IPSharp owned. But as far as sharing things other than software artifacts or the ability to use each other's site as disaster recovery locations in the event something serious happen. I'm not aware of any relationship.

00:54:01 [AB]

In other words, you can neither confirm nor deny. OK got it.

00:54:04 [CH]

I've still have a bunch of topics, but I feel like I should just say a bunch of stuff and then you can just talk about whatever you want because you probably know the the most interesting of the answer. So a couple of the things you know you've mentioned Larry Breed. Obviously Ken Iverson was a part of the company. We haven't really talked about your thoughts on like APL versus q. And then there's also the... I can't even really recall what the feedback was, but I recall back in... I wanna say November something we were doing one of those Iversonian, Is it an inversion language and your feedback had been something that some criteria that we talked about that if it didn't have or something, there was some strong feelings. Anyway so like any of or all of it. You can go one by one or you can choose which are the best. Because yeah, I we're already coming up on the hour mark here. Umm and and I feel like, I mean, we've still got some more time, but I won't have time to ask all my questions. So there's all the stuff that is that like at the top of the list of my list of things and you can just choose which ones you want to respond to.

00:55:04 [LG]

Well, the comment that I had made late last year had to do with material that was discussed on on Nick's interview with you [17] and it had to do with specifically what might be a defining characteristic of an array language. And I think the discussion actually went back to an earlier podcast that I hadn't listened to at the time and because you actually had a whole session on that essentially. But out of context, just listening to Nick's talk I felt that people were talking about the internal representation of an array as being either a collection of lists, a list of lists, or as being a single allocation of contiguous memory. Suggesting that could be one of the characteristics that define whether a language was an array language. And I had pointed out that I think this would have been anathema to Ken, whose attitude with respect to anything that related to the implementation of a language, was not the purview of the definition of the language. So he drew a stark line between the language definition over which he had control and anything to do with necessitating what it would take to make that be a commercial enterprise. So for example, this is something I didn't appreciate in the early years of my being involved with IPSharp until I started having discussions with people in the zoo and with Ken. Things like the way the primitives worked was squarely Ken's domain, but anything that began with right paren, [18] a system command quad a system variable or a system function or before that delta being a keyword, delta FMT, delta F or F under score I should say Delta FI, Delta VI, Delta FD Delta was those are the keywords. Those were outside of Ken's area of interest and he basically said do whatever you want with them. But when it came to the language primitives the operators the functions the way they interacted, what was an error and what wasn't. He felt very strongly that should be something that was tightly controlled, that was extended only with careful thought. And as much as possible, where there was agreement in the industry about the direction things should go in, something that we lost with APL 2 [19] by the way. That's split between the axiom system that Trenchard More and Jim Brown proposed very much bifurcated the APL community along the lines of either Trenchard More's view or Kens view. Which IPSharp stuck with and Dyalog actually supports both. Basically by having a compatibility mode.

00:57:33 [AB]

No, no.

00:57:34 [ML]

That's that. That's that's another split. That was the ours APL 2 split.

00:57:39 [LG]

There's quad MC. I think it is.

00:57:41 [AB]

Quad ML only changes the behavior of certain primitive. Just and it's mostly, I mean it's very little, but this doesn't change the array model in itself.

00:57:51 [LG]

It's true, it doesn't change what happens if you do an enclose of a scalar, for example, but there was still some attempt to support.

00:57:58 [ML]

Yeah, I mean, Dyalog is still firmly a nested nested, floating whatever you want to call it.

00:58:04 [LG]

As opposed to boxed.

00:58:05 [ML]

Sharp, which is grounded or flat or.

00:58:09 [LG]

Except the thing about Ken's notation was the enclose of scalar was a distinct object.

00:58:13 [ML]

Yeah, yeah and and in Dyalog.

00:58:15 [LG]

enclose, wasn't degenerate

00:58:17 [ST]

Was another formal proof that the the two systems were incompatible.

00:58:21 [AB]

Yes, there were. There were attempts at at unifying them in the early 80s, I think and then, but it was you could be clearly shown that that's not possible and not compatible with each other.

00:58:34 [ML]

Well, I mean yeah, 2 equals enclose or two match enclose, two holds in one language and not the other so.

00:58:40 [AB]

But you could have and I haven't even heard this seriously proposed. They appeal to like a family uses the subset symbol or left shoe for enclose and the the boxing family uses less than, monadic less than. You could have both boxes and enclosures where enclosing a simple scaler doesn't change it, but boxing it does change it, but even so, the rest of the language breaks down.

00:59:09 [ML]

Yeah, it's not immediately obvious to me that that's impossible.

00:59:11 [LG]

But you could choose you could. You could have an implementation that simultaneously allow the user to choose. That is, it supports both, but you make a choice.

00:59:21 [AB]

Wasn't Sharp APL [20] originally a hacked STSC APL+ where they changed this so they actually did change it from being a floating type system to be a flat box type system.

00:59:38 [LG]

I think you're thinking of the Unix implementation. Yeah, not the mainframe implementation. The mainframe implementation never had any of the axiom system concepts that Trenchard More's system had. However, the Unix system we had two versions. There was IPSharp's original implementation, which I shouldn't say Unix system in this case there was an original implementation of a 360 emulator that Roger built and this this would be Roger Moore. That's right Roger Moore. He if fed with not Roger Hui.

01:00:16 [ML]

Supposedly Roger needs no last name, but that's a different Roger.

01:00:20 [LG]

It was literally fed with the source code of the system and it execute absolutely faithfully to the letter, the principle of operations of the system 360 system, 370s architecture. It was a bit slow though, so that was the actually original version on the PC. STC had a version of their own language on the PC, and then they built a version for Unix when we were getting into the Unix market. We were trying to decide whether we should go the route of emulation or whether we should do some other approach that would be more native. And the drawback with emulation is that it is slow. So we opted instead to adopt STSC system, but we had to make it be Sharp APL like, and so there was a change of axiom system, an implementation of the event trapping that I alluded to earlier, that Eric and I had worked on. This was all done after the fact to change the facade of that implementation. The difficulty is that some the key elements of the way SC system worked went as far down and were as deeply ingrained as the way syntax analysis and parsing worked, and the way the internal representation of the code was stored. So the changes were definitely not superficial or cosmetic. They were deeply rooted in the implementation, and it took a long time to to make it be more sharp APL like. So Adam, that's probably what you're referring to.

01:01:39 [ST]

That's really interesting you did. You didn't get tempted to follow off those route with sharp APL HP.

01:01:49 [LG]

As in implemented natively for some HP architecture?

01:01:52 [ST]

I'm struggling a little bit here. I thought he'd written that in C.

01:01:57 [LG]

The version of APL that STSC built. Not sure if I'm answering your question here, but the version of APL that STSC built was written in C.

01:02:08 [ST]

The reason I'm asking this to if I can put this in a nutshell is that... When Arthur came down to IP sharp in Sydney in, which is 82, something like something like this. He was on his reef was to implement the sharp APL interpreter on a Hewlett Packard 1000 mini computer. And if from memory bit of a stretch at that time I heard that the sharp APL interpreter was 1/2 MB program and the speed that was wanted from the HP mini computer was available to a program as long as it stayed within its 80K core. Which was sort of like a factor of 6 compression and should have been a game changer. And what Arthur did was to rebuild the sharp APL interpreter from scratch, starting with some of the newer features like nested arrays.

01:03:18 [LG]

I'm not aware of that of that activity at all. I am aware that he built very, very compact as in one page implementations of APL subset. It was two columns on the page though to be fair.

01:03:33 [ST]

I love the story. We'll go there some other time.

01:03:36 [CH]

So just to. Because I'm a got a little bit lost whenever it comes to this IBM 2 versus Sharp APL stuff, I think it's come up maybe three or four times on this podcast, and maybe one of the times I think I got some insights from the discussion and the other three times I still was unclear. And then even there was some acknowledgment from people on this panel that are much more experts in the array languages. They're like, well, you know, even some people in the community, like, there's disagreement about what the disagreement is. But so there's a an APL wiki page that talks about array models, [21] and like the top three are the flat, nested and based this Trenchard More theory that you've referred to a couple of times. Does that correspond to one of those three things nested 1 the nested one? OK all right.

01:04:22 [ML]

Yeah, that that's nested. So it's nested. It's also called floating because of this property that that scalars float over like above encloses. Through encloses or however you want to describe it. And Jim Brown is the other big name associated with that.

01:04:36 [LG]

Right. And then when Bob Smith implemented NARS for STSC, he followed that model. Strand notation [22] strand assignment.

01:04:43 [AB]

But that's not actually connected. It's funny. People conflate the two.

01:04:48 [LG]

No, no, I realized that. But he did follow that aspect of the thinking, which can vehemently objected to, which is why I asked why IPSharp never had strand notation.

01:04:58 [AB]

Yeah, but they are orthogonal to each other, right? You could have strands and not have floating arrays. All the other way around. It just happens to be that, Ken was against the.

01:05:10 [ML]

I think it. Is correct to say that the that this grounded model does make it less natural to have strands on general arrays as opposed to because you have three kinds of arrays? You have arrays of numbers, arrays of characters, and arrays of boxes. So if you don't write anything to make a box, it's not natural to make an array of boxes anyway. So what you have is the two kinds. Well, you don't have character stranding cause you can just write a string, but then you have numeric stranding, so you can write an array of numbers and then an array of boxes. It really doesn't make sense, I mean. Maybe you could say like? If you put one box next to another box next to another box, then it'll merge into into an array. But that's just really weird, because then you have to write the boxes out explicitly. So why don't you just write the array out explicitly?

01:05:56 [AB]

Well, you have this in today and while we don't have Sharp APL available, but J [23] behaves the same way and it's interesting when you write 1 space, 2 space 3. If you were to say that this would do a stranding type thing, then you would expect to get an array of boxes as you say.

01:06:14 [ML]

No, no, because array of arrays of numbers are are one of the native types that the language has.

01:06:21 [AB]

Right. And yes, so it's not a strand, it's.

01:06:23 [ML]

So you write out numbers in sequence and you get an array of numbers, so that's that's how you write an array of numbers. But that doesn't carry over automatically to arrays of boxes.

01:06:32 [LG]

But it's degenerate that if you write 123, you can think of that as being: 3 arrays, each of which is enclosed of scalars. Which degenerate to the scalars, so you're using this syntax. This strand syntax to create a vector, so the axiom system supports. It's a way to describe what always happened in APL. If you want to go down that road, but Ken found it very objectionable.

01:06:58 [AB]

Only they only APL2 and right exactly only APL2. Trenchard More's system can describe what always happens, and I prefer to call what always happens stranding even though that term wasn't used and people generally don't look at it like that. But for me, one space 2 space three is stranding just as much as quote ABC quote space quote DF quote so.

01:07:20 [LG]

And neither is a strand to me. I remember years ago Bob Bernecky wrote a paper that was originally titled Stranded in Bethesda, but he dropped the in Bethesda part and it was a treatise on strand notation or not.

01:07:33 [CH]

I gotta go find that. I assume that's online somewhere, right?

01:07:35 [LG]

I'm sure it is. It's an APL conference, so ACM should have it.

01:07:39 [ML]

Well, and so to me, my interpretation of that is that really these do both extend stranding, but they. So logically they or mathematically, you might say they extend stranding it that that they're both systems where you can restrict them and get the stranding behavior got you got in the original APL. But what happens is that different people thought about that original stranding system differently, so they see one system and they say that accords with the way that I thought about stranding this is an extension and the other is not. So it's more a factor of how you envisioned APL360, the original model as opposed to you know which one is correct or not.

01:08:20 [LG]

Is it? Is it how you envision the original model or how you can choose to explain the workings of the original model? Because when the original model was proposed, I don't think anyone was thinking about any of this. You were just entering a vector where it was a vector of numbers or a vector of characters. Or whether those numbers happen to be boolean or floating point irrelevant.

01:08:41 [ML]

I don't know. I think it probably some people didn't think. Alright, well let's me type in in a vector of numbers and well, I can't write a write a list of numbers and characters, but I'm sure that's just the system restriction and it's not. Like really the ideal API would let me put anything in there. That's definitely what Jim Brown thought and wrote about, and it's just technical restrictions, you know, amount of memory and making everything homogeneous that prevent me from doing that. And other people say the natural view of an array is that it is homogeneous. So this is. It would be nonsense to write numbers and characters stranded together.

01:09:17 [AB]

Marshall, you you're speaking from a purely theoretical perspective here. You never actually used an API that did not allow putting together numbers and characters like this right? Well, no, that's because you can have boxes, so you can put them together in an array, whereas in the original APL there's just no way a single variable name could not contain a value that had both characters and numbers in it. Completely impossible. Couldn't happen. No go.

01:09:42 [ML]

So j extends the mindset of saying it is it does not make sense to have an array containing both numbers and characters. It extends that by adding these boxes, which are a mechanism that allow you to put the numbers and characters in the same array, but the array consists of boxes. So I mean, I think I think that is the same mindset that I'm describing. I don't think I would be able to describe it if I hadn't learned it from J.

01:10:04 [AB]

OK, but I what I wanted to to to get at when you're saying it, it's just a restriction in the system. Once it became possible. Especially with the floating system and arrays with mixed type data and then it started happening with people were generating reports and then they would have a single number up there in the corner of a of an otherwise character array. Or you would have an numeric array that happened to have one character number in there. I'm sure this has happened to Stephen and then things just start breaking right and left because they the types are bad and you can't spot it. So I'm you could also see there's a feature. It's for sanity you should not be allowed to to mix the types because it will just get you into strange situations.

01:10:55 [LG]

I would say that heterogeneous arrays are so and close arrays are very handy, although in fact some systems implement enclosed array as a homogeneous type of heterogeneous objects. But the idea that you probably still want to favor homogeneous arrays. I think it's still valid because performance wise, nothing will beat them. So for certainly for most of the applications I work on, I'm very, very careful about when I allow something to become heterogeneous. If I'm going to mix the types, there's going to be a good reason for it and probably we're not talking about something that has billions and billions of entries in it where we have to search on part of it.

01:11:31 [ML]

And I think that is one of the really strong points even today of the of the flat array languages. J is the one that you'd encounter. Is that they do represent better what's happening on the CPU.

01:11:45 [CH]

Or GPU. GPU definitely wants the same types.

01:11:51 [ML]

If J is the GPU, that would be nice, but.

01:11:53 [LG]

Without loss of generality either. I mean, there's still a personal preference here, but obviously both systems work.

01:12:00 [ML]

I mean the one complaint I would have actually is that. What Dyalog does is to is to also it says all numbers are floating point. Well, unless you ohh well, all numbers are complex floating point unless you allow decimal floating point. But then it's able to it. It stores things in a smaller type. Whereas with J actually you choose and with K as well you choose floats or integers. And I think that for performance, the Dyalog model is actually a lot better because it can choose the right integer width for you, whereas width J if you've got 8 byte integers then it's not really like. So an array of eight byte integers stored as, say, 2 byte integers, would would have to have different behavior from an array of floats stored as two byte integers. So I mean, they could still do the same, compressing the storage thing, but then. It's actually harder to optimize because you have to remember. You know, are these integers really integers or are they really floats where Dyalog kind of unifies everything and makes that optimization easier.

01:13:07 [LG]

But all of that's an implementation detail, so it ought to be outside of the scope of anything that is not necessarily visible to the user, but.

01:13:15 [ML]

So in in J, if you add integers enough, they will wrap around. They go to two to the 63 -, 1. Up to -, 2 to the 63. And if you add floats you know they follow floating point semantics. In Dyalog, you don't have that all the numbers follow floating point semantics always so. That's the detail you can see from the language, and I think this view where arrays are always homogeneous kind of leads to that idea of, well, we'll expose to the user. They can have arrays of integers or floats. It doesn't require it, but it makes that a more natural choice to make, whereas pretty much all the nested API's just said, well, numbers are floats, period, and we're done.

01:14:00 [LG]

Well, but they're. Not sure quite. Look at it that way. I mean, in Sharp APL for example, the internal representation of of value was limited. I mean, we had one bit booleans. We had four byte integers and we had eight byte floating point values. But if you typed 123 you would get an integer and if you type 123 point you'd get a floating point value. But if you took that three and you added an appropriately high number such that it would become floating point, or you'd lose precision, it would get promoted to floating point. So my point is that even though the language didn't provide you an explicit way to say I want this to be integer, there was a rule obviously. And there was implicit type promotions so that you didn't overflow it inadvertantly. What you might end up doing, however, is taking possibly a large integer table and having it be promoted to floating point when you didn't intend it to be, and that could be disastrous for the operation of the system. But anyhow, that's the way it goes. I mean, it's one or the other. You either are gonna lose precision or you're gonna get behaviour that you may or may not have expected.

01:15:04 [ML]

Yeah. So in, in that way, Sharp APL is a lot more like other APL's and not like J. I didn't.

01:15:10 [LG]

In the case of J K, they have similar characteristics in the sense that once the data type is chosen, at least in K4, let's say you choose something that's a 4 byte integer. If you add enough values to it, then you'll wrap, but you'll stay 4 bytes. On the other hand, a 2 byte integer gets promoted to four bytes, yeah, and there are times when a four byte integer will get promoted to 8 depending on the operation.

01:15:37 [CH]

All right, So what I've learned from this is 1 implementation details should not affect categorization of array languages in Iversonian languages and through all of this I've been thinking you. If we had just evolved to not have alphabets and we just imagine like a Chinese language system where you've got like 40,000 words and really you don't need that many, it's just we're creative people, but we could, we could do it in probably. Like 6000 and. Every word was just a number. We could just have, you know, you'd talk 42637, et cetera, et cetera. And then that's the way we communicate and we could get rid of character arrays. Just have numbers only. Uh, I'm sure there's some science fiction book out there. Where the language system is just numerics and we could simplify our simplified all this because it seems like. A lot of this just comes from, you know characters and strings.

01:16:25 [LG]

It's a good thing the set of. Integers isn't infinite.

01:16:30 [CH]

All right. Is there other anything else? I mean, I'm sure you, I'm sure we could continue chatting for, I'm sure if we move this conversation to a pub and, you know, kept asking for IP Sharp stories. I mean we haven't even really talked about, you know KX and Q and. I'm not sure what you been working on now. I'm not sure. I'm not sure if you want to sort of end with a final story or snippet, or we should just have you back for Part 2 and then you can continue telling. Us everything and up to you.

01:17:00 [LG]

I don't know. I'm not sure which way to go. I'm happy to come back, by the way, if you'd like me to. What kind of a story might you be thinking of with respect to to Q&A?

01:17:12 [CH]

I don't know. I feel like you know q APL versus q. I'm sure you've got a bunch of Ken Iverson. I'm sure you've got, you know, some Arthur Whitney, Larry Breed, even there's. And that's The thing is, like Ken Iverson, Arthur Whitney, the names that come up most commonly but, like, weren't like a collection of the folks that are in that famous photo. Larry breed. Phil Abrams.

01:17:35 [LG]

Dick Lathwell

01:17:36 [CH]

Dick Lathwell like, and a bunch of them won different awards for their work on. I can't remember if it was the Grace Hopper award that a bunch of them won.

01:17:44 [LG]

That's right.

01:17:46 [CH]

I'm sure there's just stories for days. And like you know the the. Zoo stories or? There's too many topics. That's that's the problem is.

01:17:53 [LG]

The APL versus Q thing is interesting because those languages are actually pretty different. Not only are the primitives different and not only is the representation of higher dimensional arrays different, but also the admission of data type. For example is very, very prevalent in q, but absent from APL, so there is no way in Sharp APL, in particular, there's no primitive that will give you the data type of something. There are ways to figure it out. You can work it out. But there is no primitive that says what's the type of this object. And in fact, when packages were created, it was necessary because those were outside the scope of the language they were implemented using names that began with quad. So part of the environment, not the language when packages were implemented, it was necessary to modify algorithms that attempted to impute the data type of a value to include a special case for a package. Which would have caused the APL expression that you could use to deduce type to fail. So type is really important in k in q [24] and. Not so evident, even if it is important to the implementer of a system in APL. But in addition to that, APL's attitude toward the rigor of primitives, I think is a little different from from k's. There was an attempt to handle a lot more special and degenerative cases in APL, and I think to a large extent Arthur's attitude with some of these things was, well, first of all, it costs to do this if we add the check that's going to slow things down and the number one objective with k is performance. Feature functionality is definitely high up there, but performance is absolutely critical. With APL, performance was second to feature functionality and theoretical consistency, so there are places where Arthur declined to put a check in for something and to handle the degenerative case. As a result, you might get an error or you might get the answer you don't expect. Whereas APL generally didn't do that as objects got smaller or bigger, the boundary conditions that came up were very predictable. And you rarely had a surprise at the edge between something going from length one to length 0, for example, regardless of the data type.

01:20:11 [CH]

That's a really like succinct description of those two. Like it crystallizes something that I've always thought about is that, I mean, even even on Marshall's uh BQN docs at one point, I think it's in one of the motivation pages that says that, you know, performance is not something that, you know, most developers are going to be using this language for. Which ends sort of what you just said is. That APL there was number one was function feature functionality #2 was perf whereas Q & K it's number one is performance. #2 is feature functionality which I think is.

01:20:47 [ST]

No, #2 is still perf.

01:20:49 [CH]

No, #2 is still perf.

01:20:52 [LG]

Maybe #3 OK #4 is feature functionality.

01:20:54 [CH]

Yeah, I think that's great though that like it's a, it's a great description and it's also two like that's one of the things I really like about q is that it shows you the B after a Boolean vector. And it's like I prefer personally typed languages and like a language like Haskell, [25] it's very irritating anytime. Like I've become so used to creating a list of like a Boolean list in k of ones and zeros and then just summing that list to get the count of something. But to do that in Haskell, that's not the idiomatic way you'd do that at all, or any typed functional language for that matter, because you have to convert from the Boolean into an integer with some you know ugly function, and Haskell it's called from enum, so you. And a map, you know, map your predicate function, get a list of booleans, then map your enum, or compose those two things and then do a summation. Which is just like. That's just not the way you would do it. You're going to use some function that takes a predicate and then internally does that counting. So like there's a plethora of functions, but like it's so natural to do that in array languages, So what I. What I really want is like a a typed language. You know, obviously you could just use APL, but like in the sort of typed. Typed world that are languages are using elsewhere is like a language that you can use integers for booleans, but they have some way to like delineate between the two. So you can have a function that you know always returns a Boolean or a list of booleans, which is still just going to be integers at the end of the day. But anyways it's just I feel like I'm not sure how much like you said type checking can Q to do around that, but it's just nice to get back like that visual confirmation when you're in the REPL and you do something and you get, you know, 1010111. Whereas that from what I know doesn't exist in any of the other array languages.

01:22:36 [LG]

But just to point out the representation on output of an array is independent of anything else. We've really been talking about, so it would have been possible in K4 not to have an identification of type with a suffix of IJBF and so forth. But just to have had you allowed you to use the type primitive, the type keyword in q in order to define the type, so they're really independent of each other in a way as long as there is an internal representation of the type, it's possible for the thing that's in control of output representation to include that as a hint, but it's not necessary.

01:23:14 [CH]

Right, that's that's a good point. And I think if I'm not mistaken, J also has like data type, which is the the similar. Thing Stephen, you can say something.

01:23:21 [ST]

But you got a difference in philosophy there. I think as a user of APL, I think I'm encouraged not to have to think very much about type promotion. It's like you don't want to think about that. We're going to have that for you as a user of q with the emphasis on performance and extreme control over it. It's really encouraging you: Yeah, you want to think about type here.

01:23:48 [AB]

Well, actually interesting that there used to be a type primitive in APL, but again it doesn't care about internal type and, but rather is it numeric. Is it: character or whatever other weird stuff.

01:24:03 [LG]

Are you talking about something like Copland? Kogate equals one takes zero row, no.

01:24:07 [AB]

The no. The the NARS specification has a has a actual primitive that replaces all characters with spaces and all numbers with zeros and and that's literally called type or type of, but again, doesn't care about internal representation. At all. It still it exists still in in Dyalog APL, but only available by. Changing that quad ML [26] the migration level, although you can get the same effect because of the of the nested array system preserving the internal types well in preserving the types that build up an array, so you cannot have an actual empty array. You can only have an array one element that has length 0. So there's always an element that keeps the type, and so if you enclose the array, reshape it to length zero, and then take the first element, then that chorus is out and it for the typical array of the same structure.

01:25:08 [AB]

And you can use that then to find out what the types are.

01:25:12 [CH]

With that. Wow, this has been. Yeah, this is one of the episodes where I've got too many questions to ask. And I mean, I think we'll probably at some point in the future. I mean, if there's ever an arraycon, we're going to have to somehow try and twist your arm and get you to come and speak. Speak at the conference.

01:25:32 [LG]

Or better still, we can do that pub thing that you talked about earlier. Ohh yeah, yeah, I mean.

01:25:35 [CH]

That's probably. I mean it's less, it's less. Great for the listeners. I mean I. This is the last final anecdote, but this podcast that I've just I've been just absolutely loving, called oxide and friends [27]. And it's uh, I've mentioned it before, so I wanna explain it, but it's a group of guys used to work at Sun Microsystems anyways, but they basically just record meetings that they have now. I think they happen on Mondays and like they used to host them on Twitter spaces and now they did it on discard. And I just, I wonder how many of these like conversations of like veterans of the industry that just have so much. You know, wisdom and experience to share and uh, like I wish more companies would start doing this where they have their like and that's the thing is it's not even. Like, they're not talking about proprietary like, they're talking about the inner workings of their work, and they're building these servers and stuff. And I just, it would be so great, I think if more companies where these kinds of conversations, people record them and just put them out in the wild. That being said, yes, I'm. I'm sure the conversation that can happen at the pub would be even better, although there there are podcasts that happened at pubs, there's one called Java Pub House where they, I mean, I think it's mostly remote and they just have their beers at their desk now, but back when they started, they would all get together at a Chicago pub and you'd literally hear, like the pub noise in the background and the audio quality wasn't great. But some of the stuff that they would say after a pint or two it it's fantastic. You know, you're getting like you're like, wow, how would I have ever learned that and maybe we should. Yeah, maybe we'll think about arraycast pub edition at some point if we're ever all in the same in the same city, probably having a beer at like 11:00 AM on a Tuesday. It's probably not the decision we're gonna be making for this going forward, but.

01:27:08 [BT]

It it's 11:00 AM for you. It's 8:00 AM for me.

01:27:11 [CH]

That's true, but it's it's 6:00 PM for some people, so isn't that the code? It's 5:00 PM somewhere.

01:27:20 [AB]

Conor, you know that that before the pandemic for years. British APL associations meetings where at the pub in London [28].

01:27:27 [CH]

I mean, so that's the thing. Is it's. It's like there's pros and cons, right? Like probably my like this. Maybe this podcast would exist, but like a huge part of like the path to this podcast even existing was the pandemic and like I started going down for APL rabbit hole in December of 2019, which has just happened to fortuitously be two months or three months before the world shut down, and then everything including the British APL seminar and all these things. Like all these events that I no longer, I didn't have access to previously. Were being held online and didn't matter if they were in Europe or in Texas or wherever I could TuneIn. And so on one hand I really do miss like the in person meeting up with folks, but on the other hand, it's like would would this conversation be happening right now with Stephen and Bob like we are all, none of us are located in the same location. And like to this day, I've only met. Bob, right?

01:28:23 [BT]

Yeah, I think so. No, I know I met you. I'm just. I think I don't. Think you had anybody else?

01:28:30 [CH]

Yeah, like and that's and the and the only reason I met Bob was cause like last year I just happened to be on Vancouver Island and I was like, wait, that's not Bob cause like. That's The thing is. Like I don't even off the top of my head, know where every single person lives. Just like have a general idea of the parts of the world. That like I know Adam, you know, over in Europe, not in America, I'd say Denmark if I want to say. Stephen, I want to say is. The UK, if I gotta be more specific, London and I know he's got hands in the backyard because I can see the hens, but that doesn't give away his geographic location and Marshall, honestly. I know I'm gonna guess, like North Carolina, north. It's got a north or South in it maybe. I know it's the US United States.

01:29:07 [ML]

You you're right. You're a little hesitant, but. Yeah, North Carolina.

01:29:11 [CH]

So, but that's The thing is like I. I like. I meet with these people once every two. Weeks and like. Roughly aware of where they live in the world and have only yet met one of them. Cause we I just happened to be in his neck of the woods and was like, wait a second. Doesn't Bob, Bob. Bob lives near here, doesn't he? Which is just anyways. My point being is that the yes pub stuff. Is or meeting up in person is great, but also I think. This like collection of people may or may not have happened had it not been for things becoming more remote and accessible. So yeah, pros and cons. But we're in the same we're in same city, Leslie, so.

01:29:47 [LG]

Yeah, we can get together and we should actually. You mentioned earlier that it's a shame that we don't have more recordings of people like. Roger Moore, Ken Iverson. Larry Breed, giving talks at conferences. Not so much, Roger, because he didn't speak that often, but certainly people like Dick Lathwell, Phil Abrams, Eric. Ken and and Larry did speak a lot and it's a real shame that we just don't have any of that on film. If the technology had been there, of course we would have we take it for granted that the whole session. Would be recorded now, yeah, but.

01:30:24 [CH]

Yeah, that's what I. Was talking to Stephen the other day is about conference planning and stuff and I was like the number one, I think the number one important thing for conferences and I realize it costs money to hire people to do the the recording and the audio and stuff. Unless if you're going to do it on zoom and and just record it that way. But it's like putting stuff online like the in person meeting of 200,000 people is great. But like if you have some talks that people really want to see, it'll, you know, the conference that I helped organize last year, there was a talk by someone from Google and it, you know, there was, I think 200 people at the conference roughly and then 100,000 people watched it online. So it's like, yeah, it's the number of people you can reach when you're able to record that stuff. It's just, I think, immeasurable. Except it is measurable by the number of views on the YouTube video, but.

01:31:15 [BT]

Immeasurable, because it's immense. Not because it's not measurable.

01:31:20 [LG]

Uncountable, right? That's accountable. I said that. And I.

01:31:23 [CH]

Was like wait a. Second, I just literally said the number and then proceeded to say that. We wouldn't know what the number was.

01:31:29 [LG]

Oh wait, can I tell you? Can I tell you a story then? Speaking of what you what you just said. It reminds me of this stupidest thing that I've ever implemented was, you know, this is party trick where. You say to somebody, I'm gonna tell you what your birthday is, and you do this by saying to the person. Don't tell me anything, but take your month of birth and then perform some relatively straightforward mathematical transformation on it, and then do something with the day of birth and then do something with the year of birth and then have the individual tell you that final number, and then you tell them your birthday was. January 12th, 1895 or whatever. So I decided this is this is a cool thing to implement in APL, so. I wrote this function and it wasn't until I got to the very last line that I realized how absurd this whole thing is because the function begins by saying pretending it's talking to somebody and enter your year of birth. Enter your month of birth, enter your day of birth. Then it goes through a whole bunch of calculations, and then when I started writing the line that. Says your birthday is, I realized there was an easier way. Not a good use of computers.

01:32:39 [CH]

There's no way to write a unit test if you don't actually also. Ask for their birthday though, so yeah. It's a it's a catch 22.

01:32:45 [LG]

Yeah, at least it got the answer right all the time.

01:32:49 [CH]

All right. Well, thank you so much for coming on, Leslie and answering all our questions and and sharing your stories. Yeah, this is going to be up there with our top episodes, I think especially. Yeah, I don't. You're the first person that we've had on where the police or law enforcement, law enforcement of some kind, showed up at the the doorstep.

01:33:07 [ML]

And never really tell us about it.

01:33:10 [CH]

That's. Yeah, that's true. That's. True. Well, this is where. We need to keep on having great guests on because now that the precedent has been set, future guests will know that if they've, they do have some, you know, encounter with the law that we love to hear those kinds of stories.

01:33:23 [LG]

I think you should make an arrest record a prerequisite going forward.

01:33:30 [CH]

And if it comes back clean and say, yes, that's not the kind of person we're looking for.

01:33:34 [ML]

And if it's too recent, we know you only committed those crimes to get on the array cast.

01:33:42 [BT]

Which actually came back to one of the descriptions of what an array language is, is that if it's mentioned on this podcast, it's an array language. So that kind of opened things.

01:33:50 [LG]

Wait, we mentioned Fortran.

01:33:52 [CH]

I mean, Fortran is in my diagram I.

01:33:55 [ML]

Fortran is quite array like these days.

01:33:56 [CH]

Yeah, it's got a array operator. I mean it's there not as ergonomic as APL, that's for sure, but they do.

01:34:02 [LG]

Like two-dimensional arrays, but primitives don't operate on them except in scalar fashion. But I think you have to include the fact that functions and operators work on these numbered lists or character lists in order to have that be a defining characteristic of an array language.

01:34:04 [CH]

Yeah, yeah. If I recall from my brief dabblings in Fortran was that they had two different functions for they had like a Max reduction for rank 1 arrays and then another Max function for just like 2 scalars. I can't remember something like that like so they had similar to other languages where they have basically just named their functions differently like in Haskell. Maximum is for a list and Max is for two numbers which coming from array languages obviously is somewhat upsetting because it's very nice to just have one function for that. And anyways, that's a whole other whole other thing. We'll cut it there. Thank you so much. Leslie, this has been. My pleasure. Throw it to Bob to. Say contact us at.

01:35:03 [BT]

Contact@araycast.com and once again, just to mention from our opening, it was very gratifying to get that that letter from Daniel. Thank you again for that. Really appreciated it. As Conor said, it made his week, it made my week as well. So thank you for that. And the contact@arraycast.com and we are always looking for input. And ideas for guests and topics, and we may or may not act on them because we are independent, as you probably gathered from listening to this podcast. But but we do take them seriously and do look into them and we do have a number on the on the right now that we're hoping will come up and and we'll be able to deliver on what people have suggested.

01:35:47 [CH]

Our our big sponsorships are right around the corner and then we'll we'll be completely just a mouthpiece for whatever millions of dollars that were paid to to do this podcast then. With that we'll say happy array programming.

[ALL] Happy Array Programming!