Transcript for September 18, 2021 Eric Iverson 

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

00:00:00 [Eric Iverson]

First, first of all, a shout out to you guys.

I've really enjoyed the podcasts. I've listened to them all and enjoyed them enormously. Hi Conor.

00:00:08 [Music Theme]

00:00:21 [CH]

Welcome to another episode of Array Cast. My name is Conor. We're going to go around and do quick introductions. We'll start with Bob, then go to Adám, then go to Stephen, and then we've got 1 short announcement, and then we're going to hop into our interview with a very special guest today.

00:00:35 [Bob Therriault]

Hello I'm Bob Therriault. I am a J enthusiast and I've been a J enthusiast now for 20 years, two decades and I'm really looking forward to this episode because of the guest that we have, so stay tuned.

00:00:49 [Adám Brudzewsky]

I am Adám Brudzewsky and I have been very involved in APL since I sat on the lap of Ken Iverson himself as a little baby. And still doing APL today.

00:01:04 [Stephen Taylor]

I'm Stephen Taylor. I'm an APL and q programmer and currently the Kx librarian.

00:01:11 [CH]

And as mentioned before, my name is Conor. I'm a C++ developer day-to-day. But as listeners know, I'm a huge array language fan, especially if you've been following me on Twitter. I've been just non-stop tweeting APL and other array language stuff. But with that we will kick it to Bob, who's got a short announcement and then we'll get to our interview.

00:01:29 [BT]

Yeah my my short announcement actually is mentioned in the last episode. That tangentstorm was starting off a ridiculously early morning J show where he was live programming J and I've watched a number of them and it's... I'll be honest it if you're it it's not so much about J programming. Although he is definitely programming in J. What I'm finding fascinating is watching somebody develop a structure. Uh, you know. And and I, I just I. I think of it as pushing the envelope and a lot of the things I see him doing. I've played around with in the past and you can see somebody else hit sort of an obstacle and then see them brainstorm around it. Each episode lasts about an hour, or that's what he's limited to, but it's on live on Twitch and then repeated on YouTube because I believe Twitch only holds things for two weeks. So if you're interested in seeing someone WHO programs in J problem solve and that's one of the things I find really good about J. You know problem solve in real time. It's it's really kind of fun to drop in and and watch it, and it's it's been really neat.

00:02:36 [CH]

Awesome yeah. So I'm sure, as always, we'll have all the links in the show notes for people that want to check that out. And without further ado, so our guest, who probably it's no surprise at this point, 'cause it's probably in the title of the podcast episode, but our guest needs no introduction. Our guest today is Eric Iverson. For those the few of you that aren't going to put it together, the name Iverson is probably familiar because it is the last name of Ken Iverson, the father of you could call him the father of the array language paradigm, 'cause he was the one that kicked it off back in the late 50s, early 60s. And probably Eric can correct us if we're wrong, but you probably have more years of J experience than all four of the host/panelists combined. And you know, we'll let you tell your long history, but most recently you're the individual behind the Jsoftware company and the J language, and have been pioneering that work for the last, I think three decades now, so I'll pause there and let you do the talking from here. Usually I say, you know, take us back to when you started array languages. But that's basically the beginning of your life, I think, so I'll stop talking and let you take it away.

00:03:51 [EI]

OK, thank you Conor and thanks to the rest of you. Uhm, I wasn't really sure what to expect from this. I'm I am definitely of the old guard and this podcast, social media, you know, has largely left me by the wayside. However, I was extremely privileged to be, you know part of of a large gang of very wonderful people in the development of APL and then J and and definitely witnessed close up the development of k and lots of other array oriented languages, so I'm going to just, you know, give a very quick overview of sort of, you know my background, I'm I'm not sure why anybody be interested, but it's. That's the only thing I could think about to talk about 'cause I'm not going to talk about. You know, the intricacies of tacit programming and J. If you want to tacit program in J, download a system and go for it. You don't need me to talk to you about that, so I'm going to sort of go back. I mean basically Adám set the stage by saying he sat on Ken when he was a a little guy. Well so did I. So I'm going to go back not quite as far in my life as Adám, but I'm going to go back to 1962. That's when "A Programming Language" was published. And I was 14 then and in high school and one of my main memories of that of the years leading up to being 14 were dad would come home from having worked at the Harvard Comp Lab as an assistant professor, and then he and mom would basically ignore the rest of us kids, the four of us, and they would work on the galleys of "A Programming Language" and you, for modern people, you're going to throw your minds back. In those days, you know nothing was nothing was automated. The galleys were paper, you know, paper pieces of paper they were typed on, and all of the APL expressions were transcribed by my mother manually with using sort of a a planner graph type device to write all those cursed special APL glyphs into the text. Because the technology at that time had no way of coping with them. So my recollection as a kid was quite wonderful, especially being ignored left to my own devices. While mum and dad were busy working on this weird book, called "A Programming Language". I next, surfaced with APL as of course my dad was always trying to get other people involved in it, but he never pushed and that's one of the things I appreciate about Ken. So he gave, uh, he gave a taught, an APL programming course in the high school I was attending. And a couple of us students got got exposed to APL to programming, and again at that point it was purely a notation on the blackboard. We would write our exercise down with pencil and paper and you know the APL expressions. APL symbols, but you know, branching was indicated by, you know, a little arrow going out, out to the side and not back to the line it was going for or whatever. Of course you avoided branching as much as possible. The the next thing that I really remember was in 1966 Ken published a book called "Elementary Functions". And I had the the opportunity then like all of Ken's works, they were all filled with exercises, so Ken was really a firm believer in, you know, here are exercises for the reader to really be sure you understand things and to expand your understanding of it. So the "Elementary Functions" text was filled with exercises and I was very fortunate to be able to essentially write that the exercise solutions to that book and one of my first and very few publications and and then in 1966 I worked at IBM in a summer. Eugene McDonald was my boss and a couple of the high school students from the high school I went to. We were again writing APL notation. But and just write, pencil paper 'cause there was no interpretation of it at the time on on paper. And we were documenting a new timesharing system by IBM, and we are documenting basically just to try to get provide a clear description to the developers of what the hell it was they were building. Because it was like so many of those software projects, that sort of it grew bells and whistles far faster than the core kernel was developed. So I'm I'm gonna try to speed this along. I could talk about this forever, but.

00:08:55 [CH]

You take take as long as you want Eric. This is like. This is podcast gold.

00:09:00 [EI]

OK, but but basically that 1966 that was there for APL. That was the watershed year that was basically the year in which the serious APL implementation basically on on the the IBM 360 started. There had been previous implementations on less adequate hardware with more limited capabilities by small groups of people. So there were some APL prototype APL implementations. But the serious work on a real APL implementation basically started in 1966. So that was another watershed year and then 1968, a watershed year for me. I dropped out of university. I I sort of bummed around the country, United States for a year. I ended up in Toronto and got a job with Ian Sharp because he had a sympathy. Well basically my dad had an in with him so he gave me a job when absolutely nobody else would. But at that time they were starting to get in with IBM IP, Sharp Associates and the first project I got assigned to literally the the day after I joined the company was on an 1130, which was an early model of sort of a. I would wish you at the time would have called like a mini computer. It wasn't a big IBM mainframe, it was an IBM mini computer. 1130 and I got to work with David Oldacre on improvements to the existing APL implementation and that was. That was one of the most critical years of my life, because essentially, David and I had the midnight shift at the huge IBM data centre and we would go in and the building would be absolutely empty and we, David and I had total control of this 1130 which at the time was considered to be like you know, it was quite a giant brain machine. And you know, we would. We would use the punch card device to punch up our programs and feed them into the reader. And then you know, with a lot of luck, we'd get to see an APL expression exist on the 1130, and again, that at that time it was a very limited keyboard, which is a theme I'm gonna maybe come back to; a very limited keyboard so it took three keystrokes to make each APL glyph and the APL glyph was basically unreadable on the little raster screen, but it was a lot of fun and certainly a formative experience for me. And then in 1969, Ian Sharp and some of his colleagues had the brilliant idea of starting a timesharing service based on APL. So IP Sharp associates got at least a model 50 a 360/50 from IBM and we started running the the the DOS version of the IBM APL 360, and then we immediately started work on implementing improvements to it, and that was the 2nd really exciting period in my career because Larry Breed who was an employee of scientific time sharing, came up to Toronto because we we were running the machine that was shared between scientific time sharing and IP Sharp Associates and Larry Breed was the lead developer. But I was a fairly serious junior developer on implementing the APL file system, which is really what enabled the APL timesharing service to become a commercial, a commercial product that was of interest to to business. So we worked on that and then. Not sure well I'm I'm going to skip forward fairly fast here. The one other and so I basically continue that career at Sharp working on improving the IP Sharp Associates Sharp APL, but I did take a year out to work in Germany on implementing an APL system on a Siemens 4004 system, which was essentially was an RCA. A competitive clone of the IBM 360, but it was with a virtual memory operating system, so the main thing that I felt pleased about on that project was that we implemented, so I was the lead developer of that implementation team and we implemented as far as I know, the 1st virtual memory APL system. So we had large virtual workspaces. And the workspace would get larger or smaller depending on the requirements of the program that was running. Uhm so. Basically, I then continued in Sharp for in various roles, but uhm, I left Sharp as soon as it was acquired by Reuters in in 87. So that's that's my APL career 1968 to 87 nearly 20 years, so I should probably OK, and when I left Sharp basically I I left Sharp feeling that I if I never saw a computer again that would be too soon and I essentially I essentially took three years where in the winters I was a ski bum in Western Canada and in the summer six months I worked on construction building houses in cottage country north of Toronto. So that's I consider that sort of the first phase of my career and and my my necessary mental health break of three years being a ski bum and a construction worker. So maybe we should have. I need to catch my breath and maybe you guys have a question or two and then then I'll launch into the second phase which was the J phase.

00:15:00 [CH]

So yeah, my I have one question and then we can. I'll open it to Bob and Adám and Stephen and if they have one. So what was the year? Was it 1968 you were at IBM and then you went to you? You bummed around the country and then ended up in Toronto. What was the year you started at IP Sharp?

00:15:14 [EI]

In 1968, and yeah, what I said was that IBM that was just as a IBM at that point had a very aggressive high school student program.

Not for APL, but for across the board. So I just worked at IBM for two summers the summer of 12th grade after 12th grade in high school and the summer after first year of university. So I was I worked for IBM but just just as a high school summer student.

00:15:39 [CH]

So what I'm going to try and do here is sync up like when you did and didn't work with with Ken, so I assume Ken was. I think Ken, if I'm correct, was at IBM while you were doing those summer internships.

00:15:49 [EI]

Yes, but he was in a different, he was in the research lab and I was at the Mohansic lab so we never saw each other, but there was basically Eugene McDonald at the time was working on a system called IVSYS [?], which was sort of the first attempt to make a timesharing service and their target programming language for that timesharing service was APL, so it was a two part thing. They were trying to make a the ability to do timesharing so they basically a huge gronking central computer through telephone lines or hardwired lines could serve as a number of terminals, as if each terminal user had their own virtual machine. And then and then in 1968 I joined IP Sharp Associates. So Ken was working for IBM in research Research Center in in New York for IBM and I was working for IP Sharp Associates in Toronto.

00:16:50 [CH]

Yeah, and so what I think is really cool about that is that the first time we ever spoke I had no idea that you showed up at IP Sharp more than a decade before, before Ken did. And and then. So I think Ken joined. Was it around 1980?

00:17:06 [EI]

Yeah, Ken joined Sharp in 1980 actually. I mean, that's sort of one or the other. I mean I've got. A passel of scribbled notes here, but one of the ones was that you know, in in the last years at IBM, Ken Ken was getting, he was getting frustrated that he felt that IBM wasn't really behind APL. You know, in the early days IBM was quite strongly behind APL, the APL group at the research at the Watson Research Center was well supported. But as time went on, I'm I, I don't know what it was. The changing of the guard IBM lost interest and Ken felt in those last years that IBM was really not behind APL. In fact, I would go so far as you know, he may felt so frustrated that he felt that IBM was, perhaps, you know, sabotaging APL. I mean. So we we had a number of, he had a number of occurrences like, you know basically PL 1 was the flavour of choice for a while there and Ken felt that you know the Salesforce in IBM was not doing APL. There was another internal, the internal argument within the APL group itself between the the essentially the newer, the newer members of the crew who wanted who felt strongly that strand notation was the right way to go, and that box of a scalar should be nilpotent. So and that was the group that essentially came to dominate the APL group at IBM, and so I think Ken felt that IBM was no longer really 100% behind APL. Or wasn't even 50% behind APL, and that he was he was losing what he thought was a very important battle. The battle about strand notation. And the battle about box of a scalar. The result of box of a scalar and so Ken at that time essentially, IP Sharp Associates was a descendant. You know, our timesharing business was going bangbust gangbusters, we were making more money than we knew what to do with. We'd already hired half you know. Dick Lathwell, Joey Tuttle, Eugene McDonald a number of the core key IBM APL people. So it was a natural move for Ken to move to IP Sharp Associates 'cause he saw, IP Sharp Associates I mean, we weren't just behind APL, we were totally dependent on APL. It was our bread and butter and he also saw there was a very, sort of in terms of the arguments about strand notation and the box of a scalar, the people at IPSA were very much not decided, but we're very much going more in line with Ken's thinking on that and and the result was that you know Ken came to IPSA in 1980. Basically Sharp rejected strand notation and insisted that box of a scalar was an encoding of the scalar was not equivalent to the scalar and IBM with APL SV, with APL2 was a better name for it. APL2 went firmly with strand notation, that box of a scalar was nilpotent and they followed through with lots of other changes in the language, which were sort of to some extent driven or subsequent to those, those two key decisions. So I that was a long answer to your short question, Conor.

00:20:44 [CH]

No no long answers are awesome, and yeah, that's that's awesome to hear. So yeah, I'll I'll pause and give Bob or Adám or Stephen an opportunity to ask a question.

00:20:53 [BT]

Well, I I guess I'll just jump in and say a lot of this this it almost seems like free agent signings in sports with these guys jumping back and forth, you know that somebody takes off and they look like a good team and a good jump across them to jump to their team. But it just it must have been quite a a feeling to be in the middle of all this. With all this stuff developing, I mean it's it's real pioneering work. After the initial pioneering was done by your dad, it comes all the way through to you being in the middle of it. That's that's quite an experience to live through.

00:21:28 [EI]

Yeah, they were, they were definitely exciting times. I mean there was. I was in a very funny position. I was in the in those years. I was head of the APL development group which was informally known as the zoo and so technically people like Eugene McDonald, Joey Tuttle, Dick Lathwell and Ken all worked for me. But uhm. These were all very strong minded individuals who knew exactly what they wanted to do. So basically you know my job was my job was great. I had my own projects I was interested in and I worked on those and I pretty much kept out of the other people's way. And also at IP Sharp we had our we had a very talented development group ourselves. I mean, we had we had about 20 coders and who were you know, intimately involved in APL? And were you know, making improvements to the interpreter, but one of the things I have to point out there is that in those days, the IP Sharp interpreter it was. It was written in IBM 360 assembler so it was done at a very low level. You know we did not have the productivity of C compiled language. It was. It was a. It was a lot of work to conceive of and to implement a change or an improvement to the language. Because that, you know, 360 assembly. It was at that at the time it was a wonderful thing, but compared to the tools that people have available to them now, it was like it was like working with, you know, flints and stones and little sticks of wood.

00:23:13 [CH]

Adám, were you going to ask something earlier?

00:23:18 [AB]

Well, actually, uhm, I took the liberty to ask in the APL Orchard if anybody had questions I should forward to to Eric and I got one question so you mentioned. And this split and thing.

00:23:31 [EI]

Wait wait wait, wait a minute. You mean I'm not just dealing with you guys I'm dealing with. I'm dealing with. I'm dealing with the whole social media thing.

00:23:38 [AB]

Oh yeah, we're not letting you off the hook.

This is this is.

00:23:40 [CH]

That easy, this is the first time ever and I had no idea Adám was doing this either, so.

00:23:41 [EI]

OK, fire away fire away. Hey, I can always say no comment.

00:23:50 [AB]

Yeah, so you touching on the on the the split between the, uh, the flat array model and the the nested array model. And another another interesting split was that APL originally had a. 1-based indexing and it wasn't changeable and they quickly there was added a command to to APL 360 to change the origin.

00:24:15 [EI]

Yeah quadIO, yes.

00:24:16 [AB]

And then quadIO and and so on and and so the one listener wants to ask you about index origin, what do you have to say about index origin?

00:24:30 [EI]

OK, I mean again, I'm I'm perhaps you're reflecting my I, I'm not reflecting my J experience, I'm reflecting my APL experience and that is that quadIO was a disaster. Yeah, I mean I'm for I and most of the people I like firmly believe that index origin should be 0. But more strongly, we felt that it should be either zero or one, but it should not be changeable. I remember once being at a demonstration at the IBM labs and some IBM lab in California and Larry Breed has brought us in and one of the developers had been working on an APL compiler. Very very, this was early days. He'd been working on an APL compiler, and he was going to demonstrate the ability of this APL compiler to compile a fairly simple APL program. So Larry Breed wrote the program, fed it in. It was like a one or two line, but it was a real program. They did a real thing and the compiler guy fed in the compiler got back they got back the compiled results and ran it and it crashed. And after I mean literally an half hour to an hour of head scratching, it was understood. It was realized that the reason it crashed. Was because of quadIO. Larry had been thinking one way and the compiler was making a different assumption. So like implicit arguments like that are almost always a disaster. quadIO was a horrible invention and again it was like one of the things I think going back into those days. I mean we we got caught up in the same thing we were adding at at at IPSA we were adding quad things left, right and centre because it was like it's like your discovery of a new toy. You know here you can now have very easy ways to modify, tune, adjust the behaviour of the interpreter and... But certainly with quad IO it was a mistake and so one of the one of the earliest decisions about which there was absolutely no argument in J was is that there was no quad IO and it was going to be 0.

00:26:45 [CH]

That just made me realize that it's effectively impossible to have a pure function in APL. Especially if one of the verbs depends on index origin, because if you basically use, if you use iota, it's global.

00:26:58 [EI]

Absolutely, absolutely right. Absolutely right.

00:27:00 [CH]

It's global state that you're relying on. I never made that realization. 'cause a lot of a lot of APL can feel pure. When you're just building up functions, you know juxtaposing them and you have your expression. But there's so many verbs that you know that rely on index origin.

00:27:18 [EI]

In at Sharp, I mean I was I was in the, you know, development of the interpreter, but I I know, you know, there were many stories where, like in the application. Basically we made our money not from the interpreter, but from applications from like you know, financial consolidation systems, financial forecasting system, database inquiry systems and on more than one occasion we had situations where like an APL development group who a small programming group and their mandate. You know they basically work with quad IO 0 and they develop all their stuff in quad IO 0. And then at another development group with a completely unrelated product there meant they would develop in quad IO 1 'cause they preferred it and then somebody would come along with the bright idea of like WOW, we could have a fantastic new product if we just merge those thing two things together. I mean, it's like you cannot believe the nightmare you can get into and there it's by definition, it's the kind of nightmare which is very, very difficult to debug. 'cause you know, it basically comes down to like if if you ran things in this order. Everything worked fine, but then if you changed the order in which things ran. It would have. It would have side effects. Anyway, I'm not I'm not. I'm not enough about quad IO, it was a bad idea and maybe the best thing that they did was to get rid of it.

00:28:40 [AB]

Maybe I should defend the current state of of APL a bit and also to answer with Conor saying, professional APLs today will make sure that quad IO doesn't generally bite them by localizing it or using namespaces, and then that means if you have two different modules and they need to work together, each one with their own index origin setting. They don't interfere with each other anymore, so it's less of a problem, but I can imagine back in the day when the workspace was flat, all the names lived together. If you merged 2 and and the quad IO was set for the entire workspace and you just merge them together.

00:29:21 [EI]

Yeah no no. Even even in there, even in the earliest days you could. You could add quad IO to the locals list, but you know that's that's kind of like the, that's the suppression of detail that APL is supposed to save us from.

00:29:36 [CH]

Yeah, that's that's that does work, but it is basically just making sure that you set global state locally everywhere, and if you.

00:29:44 [EI]

Yeah, it's it's a. It's it's a work around for a design problem.

00:29:47 [CH]

All right, well we we probably have a couple. More questions, but maybe we'll let's skip back 'cause I'm super eager to hear Part 2 of the J chapter and then and then we can circle back and answer or ask. We won't be answering. We can ask all the questions that we have after that. So if you want. Yeah, feel free to resume. Part 2 of the Eric Iverson history.

00:30:08 [EI]

Yeah, OK, so I mean that that was sort of like the the the APL era. And then I took my three years off and then you know, having sworn I would, you'll never touch a computer again. And then I don't know exactly how it happened, but so I'll make up slightly make up a story, but it's the essence is true I. I was walking down the street half a block from my house and there was a computer shop advertising an IBM PC. You know that was that? You could just basically buy and bring home and play with, and it wasn't cheap. Was probably like 5 or $6000 but I thought Oh no, what harm could that do? So I I I bought the computer, took it home and I mean again I think I think computing is it's. Another one of these. It's a. It's an addictive characteristic, and it certainly has been for my entire life, so I started playing with it, started programming, having a lot of fun, and then fortuitously I found out that IP Sharp associates who had developed an APL for the PC that... This is a complicated story, but IP Sharp had the APL interpreter written in 360 assembler and then Roger Moore wrote an emulator that would basically interpret the 360 instruction set on an 8086 PC so. IP Sharp was rather desperate to have a PC product 'cause we we we saw that we were being left left far far behind. We were desperate to have a PC product so Roger Moore. So we, combining Roger Moore's emulator with the interpreter we could basically plug onto any PC. The the 360 assembler language interpreter with the emulator and we had a full IP Sharp Associates system running on the PC. Complete, every aspect of it. It was, it was quite amazing. The main drawback to it was that it was fairly slow because everything was emulated. I mean floating point operations. I mean it's they they were all emulated. It was very very slow. But IP Sharp Associates wanted out of that business 'cause they were now owned by Reuters. They had zero interest in that. So I acquired the rights to the IP Sharp Associates APL. So I started I. I incorporated a company called Iverson Software Inc. It was just me and I acquired the rights to that APL PC product from Sharp and I started, marketing is probably too aggressive a word. I started shipping diskettes to vaguely interested people around the world and they were floppy diskettes with a complete APL system on it that would run on you know. Basically any 86 PC, but it was very very slow and so I got I got very interested in essentially taking certain parts of the emulator, so like I then took the the eight the the 360 emulator was running the 8086. I'm sorry the eight the 360 emulator is running the eight on the 360 assembler code to do the syntax analyzer. That's the major blob bottleneck at any APL performance. So I rewrote the syntax analyzer in 8086 machine code and with a significant performance boost, and then I rewrote the floating point parts to again use native 8087 co-processor floating point and and it was a lot of fun and it made that APL system much more viable. But it was also becoming very clear to me that, UM. You know I was in a losing race because scientific timesharing had their natively built, you know, basically, C language developed APL system, and you know my my working with this. You know the severe handicap of the 360 emulator. Now I was never going to catch up. I was never going to be competitive so it was a. It was a fascinating artifact. But not really something that was ever going to get much use, uhm? But coincidentally, that's exactly when Ken and Roger had now been working together for a couple of years. For the while I was out West being a ski bum, and so I went to visit Ken and Roger. One afternoon at Ken's place, and they gave me a demonstration of like. You know, sort of version 1 of the J interpreter, which was very had very little resemblance to what became J? But it was a it was a. It was an array language interpreter. It was very impressive, and so I took a copy home with me. You did sometimes, and I said my God this thing you know, even in this stage it's seriously outperforms the the the 360 emulator version and I realized that that's where the future lay so then I so. So let me just give you some dates there. So in 1990 February 16th I incorporated Iverson Software Inc. as sole proprietor and just working away on this uhm, vanity project of the 360 emulator and then in by by May 15th Iverson Software Inc. issued a small number of shares, a token number of shares to Ken and to Roger, essentially to give J a corporate home 'cause up to then. I mean they didn't have a business, they were just they were just doing like what they like to do. So on February 16th J had an official corporate home and shortly thereafter I dropped the APL part of the business entirely and started working with them on various aspects of the J interpreter. So like I worked on essentially, the frontend like the what eventually became the console front end the line recall things like that and also started working on the earliest versions of a GUI interface, so a graphical user interface. So the first version of that were in a sort of a somewhat of an abomination called gem. Which sort of preceded was an early competitor to window to the Windows API, but then that quickly got converted to essentially a a Windows API based graphical user interface to the JPAC engine that that Ken and Roger developing, and in those in that those first few months, it's also when we tackle the problem of the character set and because up to that point, Roger and Ken were still trying to retain the APL character set, not exactly, but not with the same definitions. 'cause some places they just plain couldn't. 'cause they wanted to make changes but they were still trying to change preserve the idea of special glyphs and then there were some, you know, violent arguments. Not just from me, but from a lot of people saying listen Ken and Roger, you know this Unicode is great, but it's not cutting it and we've got to move on. And we're sick and tired of fighting this character set problem. Let's see what you can do with an ASCII spelling. And again, I I can come back and talk more about this, but I think you know what Ken and Roger came up with that in the ASCII spelling was just as miraculous and just as inventive and just as amazing as what had been done 30 years earlier, with the APL character set, I think you know you can quibble about I prefer this, I prefer that, but I don't. I find it hard to believe that anybody could argue that the work done on the APL glyphs is any any different than the significance of the work that was done on the the J ASCII spelling. I think the J ASCII spelling is inspired. You may still prefer the APL character set, but that's not saying they asked, the J spelling isn't inspired. So we can come back to the character set if people want to, but I like to just plow ahead and finish off this thing. So May 15th, 1990 Iverson Software, Inc. issued shares to Ken and Roger and dropped APL, and basically we were all working on J all the time. Different aspects of it, but basically the three of us full time, and shortly thereafter Eugene McDonald got shares in the company as well and he could he he may. They'd he was basically sort of the earliest critical user, and then in the next milestone was the 1990, uhm Berlin APL conference. So it's held, I'm not sure exactly when August September, but by that point, Ken and Roger Roger Ken with the ideas Roger with the ideas and the implementation, had a. A very to my mind, a very impressive viable J product and Ken and Roger submitted a paper to the APL 1990 Conference for Berlin. And as Gitte Christensen reports, there were serious discussion among the the committee there as to whether this paper from Ken would be accepted. J was viewed as it's a little bit like, you know. Martin Luther. You know, nailing his documents to the church door uhm, but in the end they accepted the the the the paper was presented at the conference. It generated a a lot of some excitement. A lot of confusion and a little bit of resentment, probably mostly confusion. We continue to part along at J. Basically we got a huge boost when Chris Burke and his APL consulting company decided to throw in the weight behind J. Chris basically came to us and said, you know, he's made his, he'd made his career for years as an APL consultant, but he felt that J was a better way to go, and he wanted to place his bets there. He wanted to work more closely with us and be involved with us. So we had a number of meetings. So then in it was basically sort of a two step process. In 2000 April 17th Iverson Software Inc changed its name to J Software Inc. And in May of 28th we issued shares. In J Software Inc to Chris Burke and to his to his business partner, so that's that's it. Basically my career. My working career was 20 years of APL and 30 years of J and basically no regrets.

00:41:55 [CH]

Yeah, so I'll. I'll you know, as always, I always have 1000 questions, but maybe you can just to. Wrap it up. Although you just did wrap it up, but I'm I'm curious so in the last, you know, what is the state of affairs, we've had Henry Rich on, obviously. I think you've probably listened to that episode. Uhm, you know J right now I I think I'm on the email list and I just saw like a version 9.03 beta has gone out so you know what's the state of affairs for J. Like you know, if people are interested, you know. Tell them you know what. What is the latest and greatest and you know what? What can they expect?

00:42:28 [EI]

We're we're a funny company. I mean like. Basically we started out where you know I'd gotten a windfall from IP Sharp Associates from. The, uh, the share the sale of Sharp to Reuters. So I've had some you know, some degree of financial independence. You know Ken was essentially in a similar situation and retired, and Roger was because he's so financially conservative was in a similar situation, so we've always focused on the language, and we've always focused on, you know, making it available freely, making it available as platform independent as possible. Uhm, making it available essentially to I mean to sort of the people who wanted to use it as opposed to trying to think of you know, a commercial advantage or anything. And you know our experiences, but it's it's very hard for us to make a living from J, because essentially, you know a large team is one person and and the J people they tend to be as much as the APL people, but perhaps even more so they tend to be sort of individualistic, eccentric and making their own way. So we yeah we have we have we we have thousands of users, but they're not exactly an organized group which is really good at pushing a donation button or making J mission critical within a company. I mean more than one occasion I had discussions with J programmers who love J. They love what we're doing, and I talked to them about, well, you know, could we, could we get some funding from your company etc and they and they unfortunately the typical response is Oh no, no, you know if the company do what I was doing they would stop me. I mean, that's a. That's a sad, but too often true story. But anyway, I missed I think the main point of your question. J Software we're doing better than ever. I mean, we sort of Roger was the main and primary developer implementer for for the for the form for the key formative years he launched us on a trajectory which is really unchanged and and will persist forever and then we had a few years. There were very little was happening in the core language and we were putting emphasis on front ends. We went through a, you know, a GTK version, a TCL version and now we're using a QT version and a web browser interface to the front end and then Henry came along who'd been using J since the earliest days and Henry was very interested in getting involved deeply involved into the implementation. He so he's dived in so he's now had many years of working on J. And it's really interesting him with Ken and Roger in the first phase of J development. The emphasis was primarily on functionality, stability, robustness, cross platform and and with Henry that emphasis has changed dramatically, but in a very good way to performance. So I think you know we've always been proud of J performance. But I think the work that that Henry has done the last many years means that J. We we, you know you can prove anything you want with benchmarks. But basically J today can compete with any you know, array language system any any any language doesn't mean we're better in all cases, but we're you know nearly as good or good enough and better in some cases. So the development of J is, it's just as ambitious and focus just now, as it has ever been, so we're, you know we're now 30 years into it and it's it's carrying forward. What we're trying to do now and again, this is a bit of a 'cause I'm on a social media here. It's like kind of the first time ever that J has been on social media. Other than other than the amazing work that Michal Wallace and you Bob do. Is that we're starting to open ourselves? We will be opening ourselves more aggressively to managing pull requests. So for example, J has been available on GPL for a long time now, but essentially it's been sort of a, we update it daily, but it's sort of orphaned. We haven't really paid much attention to pull requests and stuff we haven't. We certainly haven't encouraged people to make contributions to the core engine, and we haven't really even comp pushed very much people making contributions to the library, etc. But we're going to be making we're making changes in that area now. It takes a little, you know. We're like a steamliner. It takes us a little while to change direction, but we are changing in that direction and I think in the latter part of this year and in next year you'll see a lot more aggressive action on soliciting contributions across the board to the J ecosystem and aggressively adopting those things into into the product, and I guess the other thing there is that the product will continue to improve, it will continue to be free and will continue to be as cross platform as possible.

00:48:10 [CH]

So this is this is really exciting and I think yeah we should just highlight this a bit more. So currently development on the J source code, I know that it lives on GitHub, but is that primarily how Henry and folks contributing? Or is that just a mirror of sort of a different platform that the changes are pushed through.

00:48:31 [EI]

Yeah, no, no. It's it's a different platform. Basically we we have our own, own J Software has its own private GitHub repo or git git repo, which we which we manage entirely on our own and it has. It has maybe a half dozen people who can can access it, read it, write it, etc. And then on a daily, automated basis, the J software repo is mirrored to the public GitHub repo. So and Henry so Henry, all of Henry changes are done to the J software proprietary repo as our some, as our contributions from Bill Lamina and and a few other people. So what we're going to be doing is we are slowly, as I say, towards the end of this year and and next year we will be adding more people who are sort of in that terms are sort of like inside the tent. Who can access the J repo directly and their contributions don't have to go through a pull request where basically there are people who we vetted we trust etc. But the mirrored GPL repo. We're going to be, and again, this is a harder problem to solve. We want we want people to make contributions in their own forks to that. But we also want them to be able to do that with some confidence that if they do good work, they will be able to send us a pull request and we'll have the resources to vet this pull request, bring it in, make sure that we have the proper rights to it, copyrights, et cetera to it, and and make it part of the product. So then it's a. It's an evolving thing and quite frankly I mean J software, I mean we're years or if not a decade behind, you know other software development people in this kind of development, but we're, we're starting to take it seriously.

00:50:35 [CH]

I think even if you are a, you know a little bit behind the one huge advantage that J has is that at least as far as I know, actually that's not true, because BQN also is open source. But of the sort of established languages 'cause BQN is it's in its infancy. It's the only open source array language that lives on GitHub, so you may be behind, you know comparing to tensorflow or Pytorch or something that's you know was born and actively lives in in the open source world. But yeah, that's that's really exciting. 'cause I'm sure that there's a few listeners that are excited about, you know, hearing about the J language and the history. And the fact that you know pull requests are going to be accepted and encouraged in the future, I I definitely know that there's at least a you know one or. Two listeners out. There, that will probably be interested in. That in the future. So yeah, that's awesome to hear that. That's sort of the. Direction that J is trying to go.

00:51:29 [EI]

Yeah, the main I mean to date there we're very happy with how the GitHub GPL mirror has worked very happy with it. We just know that it could be done more, but I would say the main use of that GPL source is people who have their own pet operating system. You know, some stripped down Linux kernel or Freebsd or. Uhm, we even you know planet. What was it? Plan 9 etc. People have their own pet operating systems that they've been working on and playing with. In some cases for decades and they'll take our GPL source and they'll port it to that. And again, this gets back to the stealth mode. They're doing it because they want to program in J on their private platform. They don't. They don't want us to do a pull request to do a Plan 9 port. And for J software to support it. That would be that would be a silly use of our limited resources, but so the main use of the GPL so far is for people doing essentially their own private proprietary ports, and for that purposes it's worked very well. But we're also realizing that we're missing a major opportunity here because there are a lot of you know. A lot of unbelievably bright young people out there who were, they were born coding and it's stupid of us not to tap into bringing that talent on board within a J within a J framework. I mean I I want to emphasize I mean for 30 years we've been in concerned with the stability, the robustness. The dependability of J as a platform, so we're not going to sacrifice that by pulling in code changes willy nilly. We're going to we're going to pull in pull requests to the extent that we feel we can manage them without sacrificing what we feel is our cornerstone which is the dependability, the stability, the predictability of of J as a as a programming environment.

00:53:44 [BT]

One of the things that Eric you were talking about was that you feel at times. J is now getting left behind, but in a lot of ways, especially when I started on it, J was doing things like the labs where you were actually able to program a sequence of, you know, learning points that you were going through, which goes back to what you were talking about with Ken. All of his information about APL was often, the dictionary is often couched with examples afterwards, things to work through and learn that way, it's a very interactive way of learning. It's a very progressive way of learning. J had this whole lab system already set up in the, well, I'm guessing when it came on, but certainly when I came on the early 2000s it was there. It feels like it was going back, you know, to the first five or ten years of the language that you had. Yeah, you had this way of interacting with the language and learning in the language, and that I don't know of any place else that that actually existed. Where you weren't just getting a lecture and then going back and doing things you were interacting as you were learning. And so you ended up with this lab system that since then my cousin was told I was telling him about the lab system. At one point he goes, well, that sounds like the notebooks in Python, right? And that's exactly what they ended up doing, and I think to some extent has become more popular. But you can do the same sort of things. And I have played around with video and all sorts of things that you can do within labs. They're tremendously powerful. But they're this kind, kind of parallel to what might be popular with other people, and I guess what I kind of hear you saying is that's kind of the area where you might consolidate in the future going forward, so there's an easier crossover.

00:55:29 [EI]

No, I I agree. I think we definitely, you know, pioneered significantly with labs. But we have fallen behind there. We've fallen behind in two respects, we've stopped the core J group. We've stopped publishing labs, so there are no, there are basically very few new high quality labs, and more importantly, we've failed to encourage and facilitate people providing their own labs, we can do a lot more there but, we've gone from being like I think the early in fact, is still the way the labs work is being groundbreaking and and very great, but things like, you know, Mathematica notebook, Jupyter notebooks, what's available in Python? We've now fallen behind. And we've fallen behind in an area where we've always been weak, and that is sort of the combination of essentially the blackboard and a notation and then a computer executable sentence combined with the modern things that people want and insist on and are very valuable like video, voice, etc. So you know our labs are, they're brilliant. As a way of delivering a blackboard lecture, they're not so great with the video and the audio.

00:56:53 [BT]

Well, and then that's an area I've been playing around with, and so you know, I guess to scratch my own back I'll we'll end up including a link into something like I put together a extended Catalan lab that's essentially a voyage through creating the Catalan numbers and you explore the language at the same time. It is a lot of work to do that, and that's one of the things that and I think we mentioned earlier in the show Michal Wallace, he's another one that's done a lot of video, I think. Actually, what scares people off putting video into labs isn't so much labs, it's the video. It's a lot of work to put together video and to organize things. And I think when you've put together an idea of a Lesson plan through a lab, and then somebody says, well, you should do this with video and then they look at all the work with video. It's just like, oh I did the lesson plan, somebody else can do this video?

00:57:42 [EI]

Yeah, it's it is hard. It is a lot of work and and it's a it's a catch 22 if you have, you know, a million potential viewers say in Python you're a little more encouraged to do it if you're talking about, you know, you know some thousands of potential J viewers. There's a lot less incentive to do it, and also, we're just not tied into that, to that mass ecosystem. So like you know, you can do a lab, but. How how do you? Right now we have, you know, a lot of our J users don't even use the J Forum, which I do not understand, but they're looking they're looking for their J information on Twitter, Twitch, remote chat channels, I mean stuff I don't even know about, and because they're young and they want to do things the new way, they won't use the forum so we don't even have a formal way of letting people know what's available because everybody is, it's like, you know, we have this tiny tribe of J programmers. And then it fragments further into the guys who read the forum, the ones who will read Twitter and the ones will only do Twitch.

00:59:00 [CH]

And the ones on I guess yeah, we we can.

00:59:03 [EI]

And the ones on the podcast.

00:59:05 [CH]

Yeah, I was going to say and we can. We can add this. There's a discord that is an amalgamation of all the array languages. It's currently called APL Farm, but they've they've talked about rebranding. But yeah, it's it is definitely a problem. It's exacerbated by the fact that you know, when you Google "J", I mean I, I appreciate the array languages love of terseness, but I think in that regard at least you know at the time. I guess, search engines weren't a huge thing in the early 90s. But so you see, you could not have envisioned the and to say you know there are other more popular languages with single letters such as C and R, so there's definitely precedent, but yeah, because J is a bit more niche and it is a bit harder to search online if you don't know to go to the forums first or something like that.

00:59:56 [EI]

Yeah, you're quite right. When we chose the name J, uh and Roger chose the name J, and Ken went along with it. It was it made perfect sense, but when when, you know, search engines started to come out and become popular, we started using a lot ourselves. We had we had company meetings. We had violent arguments about changing the name and what should it be changed. So I think we all agreed that name should have been changed. But we could not get an agreement on what it should be changed to. So essentially we decided to go back on back to work on things that were more fun and we didn't change the name. I personally regret it. I think we should have, you know almost anything. It's like the quad IO thing. Anything would have been better than just sticking with the single letter, but I I don't. I mean, there's no prospect of changing it now now, what we what we've sort of depended on. You know people searching for J programming language or for J software, but then you get into, you know some of the a lot of the younger people know they don't want to search for a company name, you know, they would search for J programming language, but they don't want to search for a company name. So yeah, so I wish we had changed the name. Maybe maybe we will, maybe that'll be next year project, who knows?

01:01:14 [CH]

I think now it's now. It's well, actually I shouldn't say. But the question I was going to ask is, was there? Was there ever a leading candidate like a you know a trivia fact that you can give the listeners as like you know, we almost changed it to this, but we have never. Was there ever a leading candidate or it was just arguments?

01:01:29 [EI]

But well, I could. I could only tell you one and that was my leading candidate.

01:01:35 [CH]

What was that?

01:01:35 [EI]

Yeah yeah, which is "JEH", J - E - H. It would be. It would show up and hits a same pronunciation and it's an inside joke on Canadian saying eh. But, uh, but uh, I think pretty much everybody else hated it.

01:01:57 [BT]

It's funny you talk about the the violent arguments and everybody I've met in in everybody. I think it earlier also you were talking about the fact that people are sort of idiosyncratic. They're they have their vision and everything, and I I have noticed that about people who are in array programming. But I haven't noticed the interactions I've had with people. I can't conceive of a violent argument. I can conceive of a very opinionated argument and and there's very strong positions held, but everybody seems to like I really haven't had anything where there's any type of when they say anger or emotion, I mean there's there's strong feelings, but that's different again. There's a lot of there's a lot of listening. There's a lot of thinking but but it's funny because everybody, often I've heard other people characterize disagreements as violent arguments, and I think, no, I've been in violent arguments. I don't think violent arguments is what's going on.

01:02:57 [EI]

Yeah, yeah, you're you're. You're quite right, my use of the word violent there is not is not correct.

01:03:02 [AB]

Well, it reminds me of this xkcd cartoon of mathematical symbol fight. I guess we'll link to that which which APL or J symbols would be the most effective in a fight? So that kind of violence and Eric I can, I can, uh, tell you that it's good that the language wasn't named the Jeh Language, J - E - H. Because there's already a language called the Jeh language split like that.

01:03:28 [EI]

JEH.

01:03:29 [AB]

Yeah, it's the human language spoken by 26,000 people in Vietnam. So if people were searching for Jeh language, wouldn't have worked.

01:03:38 [EI]

You're actually right, because no, we we that was part of our nonviolent discussions. It was that any name that anybody proposed. We then realized 'cause we were then, you know we weren't incorporated company were getting a bit more serious about things you would have to hire a lawyer on a firm to do a word search around the world to find out, you know, somebody else already had a copyrighted patented. As a natural language, whatever, and you get down to you know you get, you get basically the leftovers. So we we stuck with J. It'll probably what we'll continue to do.

01:04:13 [CH]

Yeah, I think that's the that's the issue that you know, Arthur Whitney most recent sort of rebranding of K9 into Shakti is they had a bunch of ideas, but they ended up going with shaktidb, because it's so hard these days with all the as you mentioned, Twitter twitches etc. To get a good handle... One of the questions I wanted to ask is, it spins off of a comment that actually I got a while ago on LinkedIn, I think I had posted either a YouTube video or a podcast and one of my former colleagues had had pointed out or made the comment that J is just APL on steroids, and I've heard before also too is that you can think of as J is just it's another APL like it's it has a differently named uhm, it's you know it's not APL2 or APL3 or something, but it's it is an evolved APL. And and seeing as we have you here I, I wonder if you want to just comment in general on that sentiment and then also to, obviously there's a, there's a a different set of ideas that are in J, and if I'm not sure if it's possible to or it's just a long list, or when you think about the difference between sort of J as an Iversonian language and APL is an Iversonian language... What are the biggest things that sort of stand out, as you know, deltas between the two? So I know that there was a lot of questions there, but.

01:05:37 [EI]

J as the name of the language was literally as Roger said, it was, you know, he needed, uh, a filename to save it and, you know, J programmers are only capable of typing one letter at a time, so it was J. And and. But there was also there was at the time. I mean, it's hard to remember it now, but at the time there was serious pushback from the APL community you know Ken and Rogers work was not welcomed right off the bat and and and in some ways it's still not welcomed. It was seen, as you know, we had the APL2 and the Sharp APL schism over strand and and and the box scalar. And yet you know, here were people coming in again, trying to create another schism. And and the real feeling. So like at the as I say, you know, there was serious discussion at the APL 90 conference proceedings that they were not going to accept a paper from Ken and Roger, because it was about, you know something that wasn't APL. And then there was another conference in Stanford APL conference. A year or two later where there was a was a panel discussion with sort of the you know, the leading APL talking heads about whether J was APL or not, and whether J should be included in the APL family or not. So there's a it's, I think it's well past now, but there was in those early days was it was some some some animosity some ill feeling. And rightly so, schisms are not good. We have a, you know, the array array programming outlook, I mean Ken's key ideas are the same across all of them, and but it's, but they're adopted by relatively small community and so to take a relatively small community and split it to, you know, APL2 and Sharp APL, and then it split it again with APL and J, and then it split it again with k and split it again with NIAL, et cetera, et cetera. It's a, it's a. It's not, it doesn't make good commercial sets. It may make you know may make for a lot of you know personal technical satisfaction, but commercially it's a disaster. So I forget the question my my apologies. OK so the overlap between J let let's let's be very fairly specific. The overlap between J and Dyalog APL is is great, it's considerable. The the and the fact that Roger Hui worked the last many years at Dyalog brought into Dyalog a lot of the J ideas which were not radical ideas. They were ideas which you know really made perfect sense in the APL concept. Uhm so so. In some sense, this Dyalog APL has caught up with some of the interesting ideas of J. Dyalog is also pushed ahead in other areas where it's still different and ahead of J in areas, but I think the the key, the three key areas where they differ are the spelling so the APL glyphs versus the J ASCII spelling scheme. So that's one difference. The second difference is strand notation, which I think Ken, and the people at Sharp and certainly, and most of the people at J, if they're even aware of the the the controversy are violently against strand notation. But and but Dyalog has strand notation and there you know right now because of you know commercial continuity etc. They they're probably they're never going to be able to get rid of it. Even if they wanted to. And then the other is, you know, they what Adám referred to as the flat versus nested array, sort of, whether the box of a scalar is nilpotent or not, so those are probably those are the three important differences. And then there are a couple of minor differences, like the way J broke reduction and scan into 2 symbols. But pretty much everything else that is done in J can be done in, it can be done in Dyalog APL. So those are three differences and I think you know in terms of the scheme of what they have in common. Those are trivial differences and. And you know. Quite frankly, a programmer who is a good programmer who who really has taken on board the idea of notation as a tool of thought, a good programmer in APL, Dyalog APL, oover a week, become just as good a programmer in J and vice versa. So as communities we should realize. That our enemy is not each other. Our enemy is and it changes from day to day 'cause there's so many fads here, but our enemy today is probably Python to make an example.

01:11:02 [CH]

Yeah, it's it's interesting to hear you say that. That that made me right there just completely remember what Henry said is when I think someone asked. We asked him when he was on the podcast about the the spelling differences, Unicode versus digraph, and he's sort of just like hand waving, he's he's he's like, you know, I I I read J so that's what I know how to read. But you know, it's just honestly I don't think spelling is that important like I think people make a big deal about it, but anyone that can read J can read APL and vice versa. It's um and he he sort of didn't really seem like he had a preference. He's you know J is the is the tool that I learned and I'm super happy with it. But you know? Of if it were one way or the other, yeah, he sort of his his remark was the same as that. Anyone that is proficient in one can very easily be proficient in the other.

01:11:50 [EI]

Yeah, I mean I get I I wanna I wanna sort of you know you it's not like you just you know if you're if you're proficient in J you don't just the next minute start reading APL. I mean it's, like it's like if it's worth doing, it's worth putting investing some effort into it and maybe like a weekend or a week. But after a weekend or a week you would be if you're a good programmer J you'll be a good programmer in APL and and vice versa. You know this this ties back to, you know, one of one of my things like so my my programming experience, I mean, like I I wrote in various machine machine language coding and then I wrote, you know, various assemblers and then I wrote in C and that I wrote in Java and I wrote, so all these different languages and those were always my primary language is so my programming I've done far more programming on that type that I have of either J or APL. I don't consider myself a J or an APL programmer. I never did consider myself an APL programmer. I don't consider myself a J programmer today because most of my experience was in those other languages, much lower level languages, but I thought you know Ken Ken in all of his books, he emphasized every one of his books the exercises, and he always I have a quote here. OK, here's a quote from "Elementary Functions", from Ken, he says: "To write programs, one must firstly learn to read programs critically", and this ties back into notation as a tool of thought. If you're a good programmer in machine language, if you understand the principles of a tool of thought, you can be a good machine language programmer. You will organize your thing so it's not spaghetti code branches all over the place. It will be modular. It will be, you know it will be structured in the ideal way to solve the problem at hand, and that applies to any language, so you can code C using all of the principles of notation as a tool of thought, and it'll be good C programming. But once you so that that applies across all programming languages. But once you start talking about languages are so close together as J and APL, I mean, to my mind, the differences really are insignificant. What you have to say is you know well if you have a paying customer, what does the customer want? Uh, if you have a a backlog of like similar applications and code that you can read and lift from and learn from in a particular language, that's your language of choice. So if you have a slight preference in one, or if you have a platform dependency, that's how you make your choice. You should not be making a choice because, well, I only code in APL and I'm not going to touch that J stuff in the middle walk.

01:14:45 [CH]

Yeah no, I I I completely agree and that's that sounds like almost an amazing way to wrap up with that that quote, I will say that we we shouldn't end without noting that that book "Elementary Functions" is available on the J software website, if I recall. Correctly, it was scanned to PDF form is that that's correct. Right Eric?

01:15:04 [EI]

Yes it is. Yeah it is there along with along with many others.

01:15:08 [CH]

Yeah, so we will definitely link that in the show notes and also to speaking of sort of, you know, translating between J and APL. I don't know the name of this website, but while I attended one of the J New York user group meetings a couple months ago, one of the attendees there had gone and created this fantastic sort of dictionary look up from, it's just like a simple table, but it's it's similar to I think there's a document on J software, like from APL to J vice versa sort of dictionary, but this one it, it's all just on a single table. If you look up the sort of English name or whatever, like alphabetical characters. So if you look up iota underbar, it has the Unicode symbol, but it also know it knows that that's called where, so you can look up where and that'll you know you just scan across the row and it'll show you that it's called indices and J and it's a capital i period and so every single time I'm going from, typically it's APL to J 'cause I know more APL. I hit up that link and it's been the best resource in terms of trying to teach myself how to convert things from APL to J. But you can do it in either direction.

01:16:13 [EI]

Quick comment there. I think. I think it is a good resource and it's a good for someone who's starting that journey from one language to the other. But it is, it is a crutch. There are enough differences and gotchas and at some point you're just going to have to if you're going to be programming, seriously in a language you have to invest some effort into it, can I I'm I'm sure we've probably gone way over time and I just throw, can I just make one other one, other comment that I sort of prepared in my my scribbled notes here and it's and it's but it's relevant to the character set. And I just want to point out sort of a it's basically the importance in historical accidents in the development of technologies, and I think there were two really critical historical accidents in the history of APL and J. The first one is that if it the IBM Selectric typewriter with the interchangeable golf ball so that you could take off a standard golf ball and put on an APL golf ball so you could now type the APL symbols. If that Selectric typewriter had not been commercially available the first year, the first time that APL 360 was coming out my bet and again, this is, you know, this is my own opinion because we we really can't go back to the original source people for for a definitive answer. But APL would have been stuck. They would not have had a way to present those glyphs. You know, the raster screens didn't exist, everything was on paper. And you had to use a typewriter, so if that that Selectric typewriter with the APL golf ball was a game changer, it allowed the first hardware implementation of APL to come out with a typewriter you could use and paper you could read. So I submit that of that Selectric typewriter, which was driven by natural language requirements, and that's electric typewriter wasn't invented to make the APL people happy. It was invented for natural language requirements. The APL people just capitalized on it. The next historical thing is I think if when we were doing the decision as to whether to keep the APL glyphs or go with an ASCII spelling in J. If Unicode had been further along Unicode existed, but if it had been a lot if it had been further along, my bet is that J would have ended up with APL like glyphs, but the fact of the matter is it was not further along and we felt constrained that we wanted something out that was usable across platforms by anybody without special hardware, etc. We took the ASCII spelling, that's it's it's. You know this. You know one historical accident led to the APL glyphs, one historical in for APL. The other historical accident led to J going with an ASCII spelling.

01:19:13 [CH]

Interesting, yeah. It's there's all these little you know, historical moments where if if the wind had blown like a slightly different direction, you know how would that have affected the fate of you know it's we're talking about array languages now, but in many times it's it's other things. But yeah, that's. It'd be interesting, you know. Clearly you wouldn't have been having that. I think the the conference was the one that you said in California was in Palo Alto. There wouldn't be that talk about is is does J qualify as an array language? 'cause if they had been looking at the Unicode symbols they would have been like Oh yeah, we we can get behind that. So yeah, I'm sure it would have led to a much different history in some regards, yeah.

01:19:55 [EI]

Yeah, a much more boring history.

01:20:00 [CH]

All right, well, unless if Bob or Adám. If you've got any last comments or questions, I think with that. We can we can.

01:20:09 [BT]

Only like so many guests we've had on, there'll be another, you know another episode where we have Eric on as a guest, 'cause there's there's so much to talk about. You know I I could suggest topics now, but we would probably get going again and then we wouldn't wrap up this episode. So and if people do want to get in touch with us, contact at arraycast dot com, that's the email address, and if you're just looking for information on the on the podcast, uh, arraycast.com and included with this episode will be a transcript and a bunch of show notes and links that you can click on and go to some of the areas that we've been talking about because, you know, if, as I know, there's a number of listeners who are relatively new to array programming languages, and that's a good way to come up to speed on it. There's a, there's a, these these waters aren't the the river isn't wide, but it's very deep here so you can dive in pretty deep pretty quick.

01:21:06 [CH]

And yeah, the last thing I'll say is just thank you so much Eric for for coming on and spending your time with us. This is yeah, like this is by far the highlight of my my week. Both, you know professional and non professional and I don't think I've ever said this before, but I listened to about, uh, I run a lot, so I have a lot of podcast time to kill and I listen to about 30 plus podcasts N - 1 of which are all programming language technical related. And my favourite one is this podcast. It's it's probably bad to say that I listen to my own podcast, but I just absolutely love delving into like program histories and learning about sort of anecdotal stories and stuff. So yeah, this is this has been a blast for me and yeah, I can't wait to have you back on again hopefully in the future so, once again, yeah, thanks for coming on, this was awesome.

01:21:55 [EI]

And thank you guys. Thank you all.

01:21:56 [CH]

All right, happy programming.

01:21:57 [All]

Happy array programming.

01:21:58 [CH]

I missed the array, I missed the array.

01:22:02 [BT]

Can't believe you missed the array.

01:22:04 [AB]

What were we talking about for the last hour and a half Conor, where were you?

01:22:07 [All]

(laughing)

01:22:10 [Music Theme]