Transcript

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

00:00:00 [Lib Gibson]

You know it's the arrays that are the huge power. It's a different way of thinking. It's a more holistic way of thinking, a less plodding way of thinking.

00:00:12 [Music]

00:00:22 [Conor Hoekstra]

Welcome to another episode of the Array Cast. I am your host Conor, and today we have a very special guest who I will introduce in a few moments. But before we do that, let's go around and do brief introductions of our panelists.

We'll start with Adam and then go to Marshall. Then go to Bob.

00:00:35 [Adám Brudzewsky]

I'm Adam Brudzewsky full-time APL programmer. I also teach people APL and help them out with various APL tasks.

00:00:44 [Marshall Lochbaum]

I'm Marshall Lochbaum, a former J programmer, then APL developer and now a BQN designer.

00:00:49 [Bob Therriault]

I'm Bob Therriault and I'm A J enthusiast and I've got lots of work that I'm doing with the J wiki.

00:00:56 [CH]

And as mentioned before, my name is Conor. I am a C++ professional/research scientist at NVIDIA, but on my free time I am an array, a language enthusiast extraordinaire. And next, I think we have a few different announcements, 2 from Adam, I think 3 from Bob and then one from me. So we'll go around and do those, right so.

00:01:17 [AB]

There's this yearly APL problem solving competition with some fantastic prizes, and the winners for this year round have just been announced. [01]

We'll leave a link to that announcement in the show notes.

Also, my dear friend and colleague Rodrigo Girão Serrão who has been doing most of the transcripts for these requests, he will not be doing those transcripts anymore. So on behalf of us and panel and listeners, a huge thank you to Rodrigo. He's been putting in so much work and you can't really notice that he's the one doing it.

It's just just been there and on time and then to go with that uh, request then for our audience and do we have someone out there who's enthusiastic about this and knowledgeable to understand all the strange words that we're using, who would be interested in doing the transcripts for us going forward.

The benefit you get over it is that you get the episodes a few days early. If you're interested, contact us at.

Contact at Array Cast dot com.

00:02:26 [BT]

And I'd just like to echo Adam's appreciation for the work that Rodrigo's done. It's it's really neat to be able to work with somebody and have the transcript show up just before we publish and it's actually quite an interesting process and you're definitely part of the team at that point, although maybe not as high profile as some of us that you hear our voices, although we have had Rodrigo on the episode as well. [02]

Anyway, off to my announcements 2 quick ones.

One is we now have access to a hi, Res Jay, nice Big Blue Jay and high resolution, which is really nice. It actually started from a request that Conor had and then we spent I think about 24 hours ramping around trying to get a nice high res version and the guy who originally developed it, Rik Sherlock then provided one.

So we have one now, and it's on the J Wiki, and we'll provide links for that. 2nd we have a J reference card now a one page reference card for J. [03] That's actually really good, and it also is on the J Wiki site.

We'll provide a link to it. It comes in A4 and US letter formats and has been developed.

And that's Victor Grigorov, I believe, is the person who put together much appreciation to Victor.

And the third announcement involves the J wiki. [04]

We have so many essays on the J Wiki that we are trying to categorize them so it's easier to find them.

And as a result, we have a request for people who might be interested in doing that to read the essays on the J wiki, at least the ones you're interested in. And then provide a category that you put at the bottom of the wiki page.

Now to do that you need to be signed into the wiki. There is a blue wiki which is the working J Wiki, and there is a yellow wiki and the Yellow Wiki has a yellow Jay instead of a blue Jay. And the yellow wiki is where we're doing our experimentation. So the yellow Wiki will be where we will be doing these category things.

If you want to be involved with the Jay Wiki, but you only want to change things that are existing with the Jay Wiki, then you'd be on the blue Jay Blue Wiki. And you do need to sign in separately from them because they are two separate Wiki, so one is a prototype. And the other is the working wiki. Anybody who's interested in this stuff, definitely we'll put a link to a video I put together about how to get involved with the J.

Like we will put a link to about the J Wiki so you know how to sign up for it, and we would welcome anybody who's interested in that.

The more people we have working on the Wiki, the better it is.

And because we're doing things like prototypes and testing, it's actually a very exciting time for the J wiki.

That is all of my.

Announcements

00:05:00 [CH]

Awesome. And just to clarify, Bob, first announcement when he said hi, Rez J. Uh, if in case if anyone confused. It's a logo that he was talking about at first. I was like high resolution Jay. Was he was this like a new 9.16 or something?

Whatever version they ran.

00:05:16 [ML]

I think the J interpreter was already at such high resolution.

00:05:22 [CH]

I am using it in the talk that I'll be giving in a couple days, which brings me to sort of my announcement, which is just a re announcement of what I said in the last episode. [05]

So when this is released, the Toronto APL meet up will have already taken place, but the September 7th one in New York is still going to be happening in the future from when this is released, so if you're in New York, check out the details in the show notes for that meet up. Which brings me to the introduction of today's guests.

If you remember from my explanation of the meet ups, in our last podcast I mentioned that one of the speakers at the Toronto APL meet up, which is happening two days from when we record this, but will have happened in the past once this comes out is Lib Gibson and I don't want to steal all her thunder 'cause I think she's going to tell us all about sort of her career history, but I'm super excited to have her on as a guest today. She started off, I believe, working at IP Sharp and Associates IPSA for almost 20 years and after that you know, went on to CEO.

multiple different companies was a strategic advisor to other CEO's and has sat on boards of, you know, plethora of companies. So that's all I'll say about her, but clearly has had a storied career and has been very, very successful, and APL was a part of that story. So I will throw it over to Lib and I think she's going to give us kind of a preview and we'll get to ask questions about what she's going to be talking about this Thursday. So take it away Lib.

00:06:43 [Lib Gibson]

OK, well I have a maybe I'll start with a a rather long description of how I fell into APL and IP Sharp.[06] I got my masters in math at Carleton University in Ottawa [07] and I wanted to be a math professor and I was accepted for my PhD and got a nice juicy scholarship and then fate struck. My husband had been working diligently at night courses to raise his grades to get accepted at a Masters program and so just as I was about to go for my pHD that came through and we had two young children, so one of us had to work. So I joined the job market and I it's an interesting thing because IBM is pretty famous for its diversity now and had one of the higher profile female CEOs in recent history, but they turned me down for a job when I applied because the job that I wanted they didn't hire women for, and that's a an exact quote. And when I asked them why, they said, well, because they can't do it. And I said, well, how do you know they can't do it if you haven't hired any? And they said we just know.

00:07:55 [CH]

Wow

00:07:57 [LG]

Yeah, so they offered me a different job, but it wasn't the job I wanted. So I ended up as a research statistician at the Department of Agriculture in Ottawa, Ottawa, you know, government town. And I pushed lots of punched cards through statistical analysis programs in working in that job. And the government had an organization called the Data Processing Institute [08]. Computing was called data processing back then this a long time ago, right?

I'm pretty old. When I went through Carleton, I didn't even have a choice of taking a computer science program because they had no computer science department. The government had this data processing institute and they had a conference every year to just bring government employees in to figure out what was going on new in the world of computing. And IP Sharp had a booth there. And as fate would have it, my husband's thesis involved a lot of analysis of geographic data using cluster analysis [09], which was a fairly new mathematical technique at the time.

And of course, the household mathematician was in charge of that, of that analysis. So I approached the IP Sharp booth and sort of begged for free computer time to analyze his beta, you know, on the grounds that, you know you'll be famous once you get this. You know, if you give us, you give us computer time, you'll get published.

In this thesis that's, you know, going to have an audience of at least two or three people. At any rate. They didn't buy that, but they invited me in for an interview, a job interview for this new time sharing service that they that I was begging time on. So I arrive at the IP Sharp Office one day for this interview and I get introduced to Ian Sharp and I go, Oh my God, that's the name on the door. [10] Oh, so I was really intimidated by then. Ian's interview technique was pretty unusual, you know, Bob said to me previous to this that, you know, we could probably have an hour podcast just on telling Ian Sharp stories because he's such an interesting and some, you know, phenomenal person in so many ways. So, so it is.mI believe that his interview technique consisted of putting a light meter on his desk, and then he would describe APL to you, and if you're always lit up enough, if they sparkled enough, you were hired.

And I guess my eyes sparkled enough at the description of APL, so I was hired. And I had just come from the civil service and I had two young kids and you know, civil service is pretty full of bureaucracy and I remember asking him the question, you know, so, So what happens if I get sick, you know, what's your sick day policy? He looked really puzzled and he said. Well, when you're sick, you stay home.

And I said, oh, that's good, but you know, how long can I stay home?

And he was even more bewildered. And he said, well, until you get better.

And then that was sort of one of my introductions to what IP Sharp was like it it was not rule bound.

It did have did not have procedures. It it was sort of fly by what made sense and I had another really good taste of IP, Sharp culture. I joined on a Monday in Ottawa and on Wednesday Ian happened to be passing through Ottawa.

He came in and chatted with me and I had figured out really quickly that it would be useful to know APL if I was going to look at IP Sharp. And of course I didn't know anything about APL, so.

Asked me when the next course was in APL in Ottawa and he said, oh, it's next Monday and I said, oh good, can I take it? He said, oh, you're giving it Lib? And then he left for Toronto.

And anyway, that's another another typical thing will be and to give you a very challenging, you know, almost impossible task and then just get out of your way and.

Let you do it as is he headed off to Toronto and and left me in Ottawa to learn APL in the next two days and I guess a bit of the weekend and teach it on Monday. So that was my introduction to IP Sharp and APL.

00:12:22 [CH]

Who were you teaching?

Was this just clients that were coming in for?

00:12:25 [LG]

Yeah, it it was clients and most of the people in the early days of APL. Most of the usage was by client to actually program their own APL programs, and I would say that. I wasn't really conscious of this, but I think I ended up using Ian interview technique. You would describe APL to a client as a way to solve their problem and if they caught on to it, if they got it, if their eyes sparkled, you worked with them and made them a client. And if their eyes glaze glazed over and it was clear they just couldn't understand what you were talking about. You just left them and went on to someone else to try to sell them so that you ended up selling only to enthusiasts later, as maybe we'll get into some discussion and some of the phenomenal applications that were done using APL at IP Sharp, you really had to sell the whole company. So when one person was was resistant to the idea of using APL, you couldn't leave it there because they could be a veto in getting to the whole project. But the early days were really quite a lot of fun because you were only talking to other people who are equally enthusiastic as you were.

00:13:38 [CH]

And how did the course go? Do you recall,?

00:13:40 [LG]

It was the best course I ever taught Conor 'cause.

I didn't know enough to confuse people, right. And you know, we were using the old IBM 2741's [11], you know, with the the Selectric type ball. And we had a projector on it so that you could see it up on the wall.

So someone you know would ask me a question and saying what would happen if. And I had no idea of the answer. So I'd rush over to the 2741 and I type it in and the answer would come up on the screen and by that time the answer came up, I kind of had made it up an answer. Of why that made sense. So it was, it was actually, if I do say so myself, a very good course. Because you know when you know a lot about something your biggest risk is that you try to tell people too much too quickly and you have to really constrain yourself to to make it go more slowly.

But I had no trouble with that first course.

00:14:39 [CH]

Yeah, you forget what's confusing. I feel the exact same with little educational YouTube videos I make on APL now.

Is that like, I forget that there's certain things that I really struggled with for months and then as soon as you get it, like, very quickly, my brain forgets that I ever had trouble with that. And so I just sort of skim over those details, but yeah, you you never have that issue at the beginning, 'cause you're also confused.

00:15:01 [LG]

That's right, that's right. I knew so little, I told them about 110% of what I knew in that first course.

You know, and later you're telling them 1% of what you know, right? And you have to figure out which 1%?

00:15:13 [CH]

Yeah, that's awesome.

00:15:15 [LG]

So I ended up working in Ottawa and really liking it for a few a couple of years and I was doing much, but I guess Adam was describing, I was teaching APL, I was helping clients with problems and one of my clients was Bell Northern research and one of the guys there said, you know, we we should write an e-mail system, so in 1970 I wrote I think it would win a prize as the dorkiest e-mail system ever written. It was written in a 64K workspace. There was no file system. So you passed emails through as shared workspaces that people sort of sequentially loaded. It was, you know, it was a, it was a thought experiment, not really an e-mail system, but it really pointed out the need for a file system and other people knew that too. And shortly after that, Eric Iverson [13] and Larry Breed [12] had created the APL file system, the shared file system, but you know, it's an indication of the early days a the 64K is kind of an interesting number and the fact that we really did start without a file. And then fate struck again and my husband went on to do his PhD at Waterloo. And so I was leaving IP Sharp and I had never been West of of Ottawa at that point. And so I arrived in Waterloo and I'm looking for a job in you know, they're asking about what my typing speed is, and I'm saying. But but but but I have a masters in mathematics and they'd say great, and how fast can you type?

And and by fluke, I I discovered that Guelph was really, you know, just 14 miles down the road, and one of the founders of IP Sharp David OldBaker, had gone to the University of Guelph. And so I called him and he said, you know, we're just launching an APL timesharing system at the University of Guelph. And, you know, I think you'd be a good APL coordinator, so I actually did end up with a relevant APL job at University of Of of Guelph, which was really quite a lot of fun. Probably the most interesting thing for me there was that.

Because of that I came to the attention of Ken Iverson [14] and he phoned me up one day and said would you edit APL Quote Quad [15] which was a paper, paper and ink.

Somewhat informal magazine publication that that was put out to all of the APL community, and so that was really fun and kind of got me involved in some of the language development sorts of aspects of APL.

00:18:11 [CH]

No, yes.

So so you said you when you went West to Guelph?

Were you looking for a new job outside of IP Sharp and then?

00:18:19 [LG]

Well, I P Sharp, didn't have an office there and so really I had to leave IP Sharp if I was going to live in in that area, right? So yes, I I did leave IP Sharp.

Quite, quite sadly I I have to say. But you know, as I say, fate struck and there I was, but after I'd been in Guelph for two years, I I got a phone call from IP Sharp and they said, you know, we want to open up Western.

Canada and would you go out to Calgary and you know get. IP Sharp Western branch is going.

And my husband was finished all his coursework and he had lived in Calgary when he was a kid and loved it.

So I basically put my hand over the receiver and said, hey, do you want to go to Calgary and? He said yeah.

So off we went to Calgary and, you know, job negotiations were really very loose and informal, I'd be sure.

So again, I'd never been West of Guelph. By that time we headed out to Calgary and I I got there already to support the customers the way I had in Ottawa and at Guelph. And I looked around and went, ah, my goodness, there's no customers here. So I mean, it seems like an obvious thing to you. You laugh, Conor, but it it actually wasn't that obvious to me when I accepted the job.

00:19:42 [CH]

You think they would have mentioned that though that that was a part of, you know, setting up, setting up the business and and getting customers would have been even just like slightly mentioned in the conversation of?

00:19:52 [LG]

But you have to realize IP Sharp was a place where you learned by osmosis and by yourself. You were never told anything you're never directed about doing. So I got to Guelph and.

You know, it was interesting 'cause IP, Sharp again, was different from other companies. I remember going and bidding for business at one company and you know. There were three competitors in the room simultaneously, and the others had three people. You know, they had their the the branch manager, the customer service manager and the Technical Support people and all this sort of there you know as Lib Gibson and you know they they would be asked questions like what do you do in the case of bugs? And they say, Oh well, we have a procedure and we log it in this database and we do blah blah blah blah blah blah blah. And when it came, my turn to answer, they said, well, what do you do with bugs?

And I said we fix them. And you know, that was sort of typical of our young, naive approach to things, many of us had ever worked in a big company. We didn't have any of those procedures and protocols.

We just we said what made sense really. So we got that customer and another customer we got was Dome Petroleum,[16]

famous much later for getting themselves into deep trouble and defaulting on their loans and going bankrupt and so on. But in those days they were an up and coming company and they were paying GE, which was a competitive time sharing service, a big loyalty for a program that analyzed oilfield explorations and they said, well, you know, we really don't like playing this royalty. If you could build a competitive program in a week, we'd sign up with you.

So, I said. Sure we can do that. APL is really fast for programming. And of course, I've never heard of an internal rate of return or a depletion allowance or any of these special special tax considerations that oil companies get.

But just before I had got to to Calgary, I was ostensibly opening it, but but Myrna Iverson had also been hired Ken Iverson's niece. And so I came back and I said OK, Myrna, we got, we got a problem here and Myrna coded the the analysis and again there was a just in time enhancement to APL Sharp APL that arrived just then which was the ability to take a character array, a character matrix, a character table, whatever, and and transform it into a function.

So I was able to build a file system that captured case analysis and so you could you could have multiple case studies on on different different assumptions for this this oil well analysis and it was. It was very similar to the Magic program that David Keith had built when he was in Montreal, when he started the time series analysis business at IP Sharp. And that time series business was eventually what caused Reuters to swoop down and capture the IP Sharp prey, but back to Calgary that was that turned out we we did complete the program in a week and it was a mainstay of IP Sharp Calgary revenue for many years but they had bet me a bottle of Scotch that I couldn't do it. And they never gave me my bottle of Scotch.

00:23:28 [CH]

Oh, wow, that's not OK. We gotta, we gotta. We gotta. Well, I guess this was you said Dome Petroleum, which doesn't sound like exists anymore based on the troubles they had. So it would be hard to track people down to get your bottle of Scotch.

00:23:43 [LG]

Well, I I have to tell you the the second part of that story. Many years later, Dome had become an in House customer of IP Sharp, where people took a mainframe, dedicated it to APL, and hooked it onto the IP Sharp network. And so one of the Dome people was in Toronto and by this time I was the the head of the software business unit and so I was hosting him and I told him this story. So he went home and the next week I I got a bottle of Scotch in the mail with a note saying never let it be said that Dome doesn't pay its debts.

00:24:16 [CH]

There you go.

00:24:17 [LG]

And a week later, I got a little little airplane gin bottle. And the note said with interest.

So I really did get that bottle of Scotch, Conor.

00:24:31 [CH]

That's amazing.

00:24:33 [LG]

But for for you are a enthusiast, two of the people that that were key in my Calgary days were people that I hired. Ken Iverson, phoned me up one day and said, look, do you hire summer students? And I said, no, no, we don't hire summer students. I mean, there were just a couple of us in the office. And he said, oh, that's a shame, you know, I was up visiting my old buddy from Harvard, Ian Whitney, and I was showing his son Arthur [17] APL, and he seemed to catch on really quickly, so it's a shame you don't hire summer students. So I immediately. said, Yep, we hire summer students. So Arthur came down to Calgary at the ripe old age of 15. You know, there were many people in APL history that started learning APL and loving APL in their teens, and he was, you know, he was a young kid. It was really funny. I always say he had the brain of an adult and the appetite of a teen. He was a pretty voracious eater at the time. So that was our first summer student and our second summer student we hired from the University of Alberta who just missed being a teen and that was Roger Hui [18].

00:25:47 [CH]

Oh, wow.

00:25:47 [LG]

Uh, so you know we have the strings of of K and of J coming out of that out of that Calgary office which was which was pretty interesting.

00:25:58 [CH]

How did Roger Hui end up? Did you have like postings and he applied or did he also know someone?

00:26:04 [LG]

No, we had we had posted something in the Computer science department at the University of Alberta and we, I can't you know, I think we.

00:26:13 [ML]

Didn't he know APL already? He'd been reading the Dictionary of APL.

00:26:17 [LG]

Yeah, yeah. He knew some APL, and Arthur knew what you know, this fly by night Ken Iverson had taught him in his little demo. So we ended up with a pretty powerful little team coming out of coming out of that Calgary office.

00:26:34 [CH]

Wow, so you can kind of say that you're half responsible for the succession of languages that came out of APL 'cause.

If you had never gone West of Calgary and potentially there'd be no summer students and they're being K, there'd be no J.

00:26:46 [LG]

Well, that's right. But, you know, you could say Ken's the father and I'm the mother. I did feel pretty maternal about particularly Roger and sorry, particularly Arthur when he was there was such a young kid and I remember bringing him in for supper and Oh my God, you'd you'd put in double what you'd plan for your family and he'd still be hungry at the end. And then when I was in Calgary, I actually launched the Edmonton, the Saskatoon and the Winnipeg offices, and so things were going really, really well. And then fate struck again and and my husband got a job as a lecturer at the University of Victoria. So I phoned IP Sharp and I said, OK, I have to, I have to leave the company again and they said, oh, where are you going? And I said Victoria and they said, oh, we'll open a Victoria office. So that was different from the first time, Conor, when he said, you know, why did I leave? They didn't open uh for Waterloo office at that time, but when I was going to Victoria. They did open a Victoria office and and we had sort of hoped that my husband's job was going to end up as a permanent job at U Vic and it didn't. Uhm, so I'm sitting there in Victoria. There's not much going on in Victoria. And Ian had once mentioned to me, you know French, you know, maybe we should send you over to Belgium to open up the the subsidiary over there. And so I'm sort of wondering what we're going to do next, right 'cause there's really not much for me to do in Victoria, and my kids were visiting my parents at a cottage South Of Montreal and I I was with them. And so I decided that instead of going back to Victoria, I would stop off in Toronto on the way to see it. And it turned out Ian was in London at the time and so we had an instant messaging capability on on APL. So I sent an instant message to Ian and I said, Ian, you know, So what about Brussels? Is it go or no go? And he sent back a two word response. Go and then he signed off. So, you know, gain a typical IP Sharp thing. So I'm sitting in Toronto and I say, what do I be next?

And so I said, OK, instead of going back to Victoria, I'm going to Brussels. So with my cottage clothes, I flew over to Brussels and worked on getting a work permit to be allowed to work in Belgium. And I spent a little bit of time there and, you know, figured out what the schooling would be for the kids and applied for a work permit, came back to uh Victoria, packed up the house, sold the car, and about 3 1/2 weeks later we left for Belgium and my husband and I flew from Vic. I met the kids and in Montreal and flew together to Brussels and I had until that one trip to Brussels. I had never been to to to Belgium in my life. And you know again, it was typical of Ian Sharp.

Bob you wanted some Ian stories. I never asked you what salary is going to get. I never determined any conditions on on the job. I just said, OK, I'll go to Brussels and I had to e-mail Ian. The cost of living in Belgium was outrageous at the time. I had to ask him several times. I said I can't label much of paying me, so we upped the salary. And I did it again. And he trusted me that I wouldn't try to take him for a ride. And I trusted him that if I needed more money, he would. He would, he would provide it. So there I was. I ended up in in Belgium.

00:30:33 [CH]

It's crazy, the dichotomy between, you know, going from IBM's like, oh, we don't hire women for this role versus IP.

Sharp is your, I don't want to say trailblazing, but like, at a certain point you're going somewhere and it's like, oh, just set up an office there like you're empowered to. You know there is no presence just like create one and and and then sending you halfway across the world to go set up an office in a completely different just this some that is I don't know how many companies today would would have that kind of culture or you know yeah makes IP Sharp sound very very unique.

00:31:10 [LG]

And I think you know, Conor, you're very right and it also I think in today's jaded world, there wouldn't be many who would who would have that level of faith that Ian says, go to Belgium and I say, OK, yeah, it's going to take care of me, right, Ian? You know, I can trust him that he's going to, he's going to make my Life OK in in Brussels. You know, it was it was a two way street that he trusted me and I trusted him and when I was there. I was alone for most of the time in Brussels. I did hire somebody towards the end of my stay and I think I saw Ian maybe once during that time.

Everything was done by e-mail, so this is 1979 and the company ran entirely on e-mail. And, you know, I worked later in companies where, you know, they were just beginning to think that they might use e-mail as their communications methodology for the company, but we were you know from 1973, when Leslie Goldsmith created 666 Box, we were entirely an e-mail driven company and Ian, you knew you could get an answer from Ian in a day no matter where you were, and he didn't know where he was, he might have been in Australia or London or Toronto, but he would always answer his e-mail in a day and you would have no idea where where that answer had come from.

00:32:45 [CH]

Well, sounds like an extreme competitive advantage at that stage. If other companies don't even, they're just at the beginning of thinking about using it, whereas basically sounds like IP Sharp was running off of it.

00:32:56 [LG]

That's right. I often use the expression that IP Sharp was a 21st century company in the 20th century. The culture was that the the. If we talk a bit about applications later, the kinds of applications we were doing were things that people would come and talk to me about 20 years later as if they were new. And I said, Oh yeah, you know, we did that 20 years ago. So technologically we were ahead of it. Culturally, we were ahead of it. And it was a really global company. Eventually, IP Sharp had offices on and customers on every continent but Antarctica. But it was truly global, you know, the network was a packet switch network without one central hub controlling everything. And while Toronto was the hub. It didn't really control everything. You know, it was. All of these young people were just sent out, you know, go to Oslo, go to Sydney, Australia, go to Singapore and just figure out something to do there, right?

And every office would would find different kinds of applications. You know, I mentioned the oil one in Calgary, but every office would find what was useful in that environment and and solve that problem and then make a go of the office that way and once you got so many of our customers were Fortune 500, uh, global Fortune 500 companies, we would go to the cities that where they were because they said, you know, we need our Frankfurt office, we need our Dusseldorf office, we need our, you know, we didn't just go to London, we went to Sheffield and Leeds because of that old. Massey Ferguson Manufacturing Company [19] that used to be a Canadian giant, right? Have you ever heard of that, Conor?

00:34:50 [CH]

I don't think so, no.

00:34:52 [LG]

Yeah, it was, it was a, it was an agricultural machinery company, very successful Canadian company, multinational.

And so a lot of the places we went were to support Massey Ferguson and another one was we went lots of places to support Xerox and Kodak and so a lot of the expansion was not just randomly picking the biggest city in the country, but picking the city where our customers had branches and we would have a little kick start in that in that city.

00:35:22 [CH]

Yeah, what it what it must have, it must have been quite a time to be working there when when that much growth and sort of success is happening that you can just follow the business where it goes and find yourself in a completely different country.

00:35:34 [LG]

Absolutely that there, you know, one of the expressions we sometimes would would use is, you know, join IP Sharp and see the world and you know a people were sent out to open branches, people were sent on projects to different countries, cities. I always found that when I had to phone someone and ask them to travel somewhere on a project, if I most of them were young, unmarried people or or childless people, I was unusual and having older children by then, but I'd phone up, iPhone up a woman and say, you know, can you go to Amsterdam? Well, when well, could you make it tomorrow? Sure, yeah, I could do that. You'd phone a guy and you say, Conor, you know, can you go to Amsterdam?

When? Tomorrow, oh God. I couldn't. I have to do my laundry. I have no clean clothes. You gotta give me two or three days before I can get there. Yeah, isn't that isn't that an awful sexist joke to make? But I mean, it's true.

00:36:37 [CH]

I mean there's probably some truth in it that, you know, the flexibility and being able to move on the you know.

Uh, a moments notice is is.

00:36:50 [LG]

And attracting people for whom that was enticing, right? If there are people who like structure and those people didn't like IP Sharp, right 'cause there was essentially.

, virtually no structure, but people who who said, oh, there's no job description? Fantastic, I can make one up. Right. That was the kind of person that that IP Sharp appealed to.

00:37:17 [BT]

So, so Lib.

I've worked in environments with people like that and it's tremendously exciting. And I've had the privilege of being quotes in a management position, and I use air quotes when I say management because in those environments I'm not sure what management involves, but if the boat keeps going the right direction, I guess you're managing it.

You must have come up against this. A company like that is tremendously liberating, very free, but being someone who's a position of trying to keep things going the same direction, how do you do that?

00:37:53 [LG]

Well, again, as I said, Ian never gave me. I think he gave Me 2 words of advice and two bits of advice in my entire acquaintance with him. What I observed was that his style of management was really twofold. One was to be extremely customer focused. We were out to solve customer problems and if it took longer than we thought, if it was more difficult than we thought, you know, we had said we would solve the problem, so we would. I remember one time when a project at Morgan Stanley [20] had gone way over budget. It was costing us a fortune and several some people.

The company said, you know, we should abandon this project and instead of. But we told them we'd do it, you know? We shook their hand. Of course we're going to complete it. So there was an absolute commitment to the customer.

And then the second thing was his management style was to simply match up a problem with a person. So an issue would come up and he would, he would. Not figure so much how could I solve this problem as who could solve this problem?

And then he would dangle that problem in front of the person, and they'd be excited and they would go off and do it.

So rather than and and I sort of adopted that management style when when I had programmers that I needed to do something, I would simply say something like. You know the customer is trying to do this and they're really stuck because the software doesn't work this way. And, you know, it would be really hard to fix that. And, you know, the next morning they'd walk in with a solution, whereas if I had said you know, go and fix this or implement a solution for this they they would have been less interested, less motivated. So that was something I think that I really learned from Ian. Is is just find the people and then present something to them as a challenge that they find irresistible. Because it was, I would say, there was a lot of leadership at IP Sharp, but virtually no management.

00:40:11 [BT]

That's a that's a great distinction, and I think the the idea of dangling a problem in front of somebody.

Two advantages. If they're going to tackle it, they're going to be very motivated to do it.

But you're also not putting in your constraints on it what you're you're letting them think about the problem.

And I think that's a key thing when it comes to working with creative people as soon as you start putting constraints, unless the constraints are a challenge to them. They're very much not as interested in solving the problem.

00:40:43 [LG]

I I don't know if you've ever heard the expression the Zoo about IP Sharp [21]. That was a systems development language implementer team at IP Sharp and I was eventually put in charge of the Zoo as well as the application software people in something called our software business unit and you know, it was that was really terrifying.

You know, I was completely intimidated by all those people and it was, you know, a game that the technique was simply to try to dangle a problem in front of them because there was no managing people in the zoo. There was just no managing people in this.

00:41:28 [CH]

This sounds like a 20th century version of what is called now nerd sniping, where you basically there's multiple ways to do it. Bryce, cohost of my other podcast is very good at doing it where. [22]Well, he'll talk to a colleague. Say hey, you mentioned you might be doing that, solving problem X at some point in time. Is that on your list of things to do? And so not really is in maybe a couple of weeks? OK, I guess I'll go do it. Myself no, no, no, no, no, no. Don't, don't. I was going to do that and he said no, it's OK. I'll find a couple hours and then before you know it, like it's six hours later. OK? OK. I prototyped something really quick because, you know, they they don't they that was what something they were going to do. It just wasn't at the top of their list. And then as you know, so it's there's different tactics, but yeah, it's the the problem dangling. And then basically getting somewhere some like reverse psychology, ING them to end up solving it for you is kind of sounds like what you were doing back then is.

You know, you dangle the problem and then, sure enough, someone. Goes and solves it for you?

00:42:27 [LG]

They could never. They would never have believed that I could have done it, though, 'cause I?

Mean I was such a feeble programmer compared to all of these people I was trying to manage, I sort of.

I knew just barely enough to not be snowed by all of them. But I I would never, I would never categorize myself as a as a good programmer I was a reasonably good understander of the problem and trying to frame the solution like that one on oil fields I I should just mention. A little intro to this, but after I'd been in Belgium for a year.

It was clear that the rest of my family didn't like Belgium as much as I did. I was having a great time. We had a time series database business at David Sharp uh David Keith had started and one of the kinds of data we had was airline data. And so I spent quite a bit of time going around Europe talking to all of the different airlines, which was, which was fun. But we did come back after a year to Toronto and I ended up doing a number of things in Toronto and the first thing I did was work for David Keith in the database group doing petroleum and oil database stuff, and one day we got an opportunity to bid for some business with McGraw Hill [23]. McGraw Hill owned the Platts oil newsletter and kept data on various indicators of the health of the oil industry. Arthur Whitney I had attracted to Toronto by then and I asked Arthur to write a prototype to show these people what they wanted to do. A trading system for oil, crude oil and petroleum products and crude oil and petroleum products are pretty hard to trade. It's not like currency where you just say, you know, here's a dollar, give me a euro you have to know the specific gravity, you have to know the sulfur content, you have to know what ship it was, translate transferred across the ocean, and there's a whole lot of data. So it was a fairly complicated system, and so Arthur was going to write a prototype to do this demo for them. And a whole bunch of guys from New York were coming up and I knew they were going to be, you know? In these New York suits. So I took Arthur aside the day before and I said, you know Arthur. By then he had adopted by the way the the the attire and personal hygiene habits of the zoo. And he rode his bike to work and we had no shower at the office, so I took him aside and he said, Arthur, you have to take the subway and you have to wear clean pants and a clean shirt. You know, you don't have to wear a suit, but you have to come clean tomorrow.

So he does his prototype demo and he just blows McGraw Hill away. And so afterwards, there's a little group of us who were at the demo who are kind of celebrating. And I said and did you see, Arthur even had a clean shirt on.

And they looked at me and said, did you look at his feet? And I said no. He had no shoes and socks on.So that was Arthur's rebellion against the one of the only instructions I ever gave him and I I realized that with programmers, you have to be very specific. I should have told him to wear shoes. Anyways, he he that prototype went on to be something called EMUSS and. McGraw Hill was one of IP Sharp's largest customers for many years doing this petroleum trading system. And sort of recall that this was back in 1980, so that's over 40 years ago that there was an online real time oil trading system supported by access to databases that had petroleum stocks and petroleum price data over time and time series that supported that trading system and it was really revolutionary. It was. It was so far ahead of its time. It shocked people to even know that it was happening.

00:46:43 [CH]

And it sounds like you mentioned a couple of times that there was, it wasn't just, you know, this one application that there was a plethora of these applications that were sort of in the same impressiveness category.

00:46:54 [LG]

Yeah, another one that that we did in the applications group is IP Sharp used to have a branch manager conference every year, which was which was really a pretty vital thing 'cause, it brought all of the branch managers from around the world into one place. Not always Toronto, usually the later it became in Toronto, but it was often in other places and so we all got to see each other. In person, which was really nice. And branch managers would stand up and describe things going on in their branch and on this particular user conference, both the Sydney, Australia branch manager and the Chicago branch manager described a similar system where banks were trying to keep track of their.

Interbank loans and what would happen is they they would maybe have these bank markets in London, New York and Singapore. And they would pass the book. And what would happen is a bank would phone up and want a loan in Singapore and they say, I'm sorry, we've reached our credit limit on you. But there was a lot of credit left in London or in New York. There just didn't happen to be any in Singapore. So what they wanted was what was called a global limit system so they could look at the the book that they had against a certain bank across all three three trading centres and decide if they could afford to lend money to this, to this. And they had all sorts of criteria.They had limits on what they would lend to a particular bank, what they would lend to banks domiciled in a certain country, what they would lend in a certain currency, that there might be 15 or more limits that they would check before they decided to make below. So these two branch managers were describing similar systems. So Ian came up to me at coffee break and he said, huh those systems look the same. Looks like there might be some potential there. How about you Jen? You design and have your team design and develop a. A standard system for this, uh? A product that we could call global limits. So I said, OK, that was the business case right there. You know, it looks like this could have potential let to do it? So I was going to London the next week and I ended up talking to a guy who had just been promoted out of the accounting department of all places, to being a salesperson. And he said, oh, that sounds interesting.

And he got appointments that week with three of the top five UK banks. So at this point, I know nothing about banking. I know nothing like what I told you. I knew none of that. So I went to these meetings and I just sort of tried to keep quiet and said could you describe the problem? And of course, each meeting you learn something, so you're a little bit more knowledgeable for the next meeting and they would say, well, your system does it, do it.

This way or does it do it that way? And I'd say, well, it's unbiased in that regard. It's just easy to say when you don't have a system. So anyways, I came back to Toronto with, you know, a lot of things in my head about the specs of what a global limit system would look like. And two people, Allison Atkey, who had been running the Saskatoon office, and Rohan Jayasekera, who maybe we'll talk about later, actually became the Co developers of a of a global limit system. These people would be on the phone, they'd have to give an answer to their counterparty and another bank in in 2 seconds. This was a global system at the time, as I recall the transatlantic line to Europe from Toronto. Was still running at are y'all sitting down. 1200 baud. And we were able to deliver 12102 second response time. You know, there was not none of this graphic interface and pretty colors. It was, you know, typing the data, get a response. So that was done in, I guess, about 1982, maybe again 40 years ago I had people approach me many, many decades later, decades later, actually saying, you know, could we do something like this and I'd say, yeah, yeah, yeah.

We we did that a long time ago, but that was typical of the IP Sharp applications that got popular.

They they were global application. They involve multiple locations which we're going to communicate over the IP Sharp network. They're talking well. You know, way, way ahead of their time, we also someone out of the Toronto branch actually pioneered developing something called Instant, which was a stock trading system across different countries.

At that time you really couldn't only easily trade in your own country, and it might be days before you could execute a trade in Australia, say, on an instant was designed to do real time stock trading globally, which was another big system the the system that. The global limit system got very customized and was actually developed in. But in in Zurich for Credit Suisse and in Frankfurt for Deutsche Bank, very highly customized almost to the point of not using the base product anymore, but they became huge customers of IP Sharp as well. So these kinds of real time global systems were pretty, pretty unusual at that time.

00:52:45 [BT]

So, Lib, you got this company IP Sharp, and they're using this language APL, and they're doing things that are literally, well, I won't say 40 years ahead of their time, because it probably hasn't, you know, been like, these things aren't happening just for the first time now, but it's a good 10 or 15 years ahead of their time. And yet we're doing a podcast about the array languages because they're not all that popular. Now, to me, there's a mix between those two things. You've got this incredibly powerful thing that is at least 15 years ahead of its time in what it can deliver. And yet it it goes on delivering, it's still doing in these industries today, but it's not popular amongst more general coders or programmers. Do you have any sense about where those two things missed each other?

00:53:38 [LG]

Yeah, and and this is going to be difficult to do without a picture. Let me try. Uhm, basically I I was pretty lucky in my life in working for and with really brilliant people, you know? Ian Sharp, Ken Iverson. There were others in my later career and one of the the people I got to work with was a guy called Clay Christensen. [24] I don't know if you've heard of him. He was a rock star business Prof at Harvard and he wrote the book called The Innovator's Dilemma. [25] It was declared the, you know, one of the six best business books of all time by The Economist.

He was named the top business thinker in the world for for many years. And his book, The Innovator's Dilemma? It was like a Bible on the desks of people like Jeff Bezos and Steve Jobs and and many, if not most, of the innovators in the technology realm so many years later, I was at the Globe and Mail running their digital properties, and the Globe and Mail was owned by Thompson Newspapers and they invited Clay Christensen to give a talk to a lot of people from Thompson newspapers, and I went to it and I saw for the first time Christensen's theory of innovation.

And let me try to describe it in words. So originally a product, or let's say in this case we're talking about a computer language gets introduced to the market and overtime it gets continuously enhanced and this happens very quickly to the due to the pace of technology innovation and requests from customers. So picture in Axis picture graph with time along the X axis and capability and features along the Y axis. And this product is is zooming up from the lower left to the upper right with a very steep slope because technology enhancements happen so quickly.

Meanwhile, there's another line on that chart, which is the line which represents customer new customers or users, their need for the for features, their appetite and ability to absorb new features, and their willingness to pay for new features and that line grows much more slowly. We all know that most people are resistant to change, and that.

Eventually the product overshoots what they need or what they're willing to absorb. You know, there are many jokes about grandparents like me asking their grandkids how to program the PVR, right, because the the that technology has become too complex for the majority of people. So what happens is your best customers, your most lucrative ones, are the most demanding, so an IP Sharp case that was Morgan Stanley say they were very demanding clients and many of our enhancements were designed to satisfy them. But what happens is eventually a new product enters the market, or new language, or need technology, and it's crummy are it's not nearly as good. But it's down there at the bottom, it's cheaper, it's easier to absorb. It's, it's a, it's it sort of satisfies a certain number of people.

So think here of the PC and C. I know you're C language programmer Conor, but you know, see was relative to APL, less capable, way less powerful but it was good enough to do a bunch of things. And so when the PC was first introduced and and it was, it was cheaper because you didn't have to pay these what we're becoming, it's all that time sharing bills on time sharing systems, it was less intimidating. You didn't. You weren't using APL with all these funny symbols. You were using things that looked more like language you actually had in that day, long before Excel.[27]

You had Visi Calc which was the first spreadsheet to implementation and so that product is is not good. But it's good enough to catch some people and then it starts on a trajectory of fast enhancements and it eventually crosses the line of customer needs and it addresses the majority of the market. Meanwhile, the older product is still catering to the upper end of that normal curve around the number of users up in the top right, if you can still picture this in your head. And so it's getting more and more complex and it actually goes beyond people's willingness to absorb or willingness to pay. OK. So I use as an example here myself. You know, I taught APL for many years.

I've I've admitted I'm not a great programmer, I can do a little bit and I managed people, but when operators came along that was more than I was willing to absorb at that point. [28] APL went beyond what I was willing to absorb.

So when we started with APL, we often used to joke that only about 10% of the programmers in the world took to APL.

And I think by the end of this, only 1% of the programmers of the world or maybe less, take to APL because of its level of complexity. So in the hands of those that take to it, it's enormously powerful. It's just. You know, it's unbeatable. But it is. It is a niche product now and I think the other array languages which I'm less familiar with.The other array languages have that same attribute, so that's my sort of long answer. I wish I had a picture to

show you that would make this more clear, but that's my long answer as to why APL isn't the most popular language in the world, even though it's the best language in the world.

00:59:57 [BT]

And at this point, Adam is just has shown us the screen sharing from the innovator salon of Clayton

Christensen [26] and we will include that with our show notes as well. So if you want to go back and you go to the show notes, there should be a link to this so that you can listen to Lib's description, which is exceptionally good and match it exactly to the image that you're she's describing. And yeah, it it well the thing I'm wondering about and it go it actually goes back to the first thing you were talking about teaching in a course Uhm, you know, teaching APL for that first time, and you talked about the fact that you didn't know enough to confuse people because if you didn't know what they didn't know. I'm wondering whether a big part of making these languages more popular is not focusing on the high end. It will always be there, or it will be there as long as the language is being used by people who want to use the high end. But instead of focusing on the high end, maybe the thing is to focus on the lower end, maybe the power of it is to just get people interested in the fact that it's an incredibly flexible calculator.

01:01:06 [LG]

I think you're right and what happened at IP Sharp particularly is that upper right corner are your most lucrative and your most demanding customers. And I did say that one of the tremendous values at IP Sharp was this part of our value system was to cater to customer. But the more you cater to customer needs, the less attention you pay to the people who aren't customers. So you end up sort of narrowing your focus and and and I think that's what we did. So it it happens in many companies and and the most interesting things are up there. You know what, Conor? If you were working in APL today, you don't want to work at one of those low end applications you want to be building. You know, the global limit systems of the future or, you know, the way some of the the stuff that Affinity was doing.

The Leslie Goldsmith and Hugh Heinemann were building you know, global systems, interconnected network systems to to manage energy consumption. You know, as opposed to we did a lot of financial in that day, this was energy stuff.

Those are the interesting problems. Those are the problems that the best people want to work on. Not, not the, not the mundane things, Bob. So I think you end up with that. That desire of the existing people in the industry want to keep in hand. Mixing and catering to the to the most interesting problems and the most interesting customers.

01:02:35 [BT]

And you mentioned with Ian Sharp, one of the sort of the guidelines of leadership was to be focused on the customer.

And I think that's a really powerful one, because everybody who's working on a project, if they know that that is the focus and it's consistent, you can internalize that everybody can internalize. That they all have a role in that they all know what their direction is in that process, which is very, very powerful. Is the question that right now if we were looking to popularize these languages that we are not focusing on the customer, we're focusing on customer, you're saying you want to work on the real high end stuff, well you do if that's your customer, but if your customer is at that lower end of the curve your customer is very people who have very low experience, maybe with computers and I I know in the past Roger Hui had said one of the experiences he had going to his son Nicholas, Grade five class, was how fast the kids caught on to APL because they don't have anything to unlearn, it's very, very quick.[29]

01:03:45 [LG]

Yeah, that's interesting but, you know, you can sometimes not see those people. You know, there's a famous story about when WII was introduced, before WII [30] came onto the market, you know, there was this big, big.

Uh, between the big gaming, you know, Xbox and PlayStation, I guess, and and they were catering to their users and they knew that the users were, you know, young male 12 hour day game players and they were focusing on better and better graphics and and very high end customers and the majority of people who are not gamers. And WII came along because they said, look, we're going to try to build a product for the people who aren't gamers and we think there are a lot of them and it doesn't need as fancy graphics. It it had one new feature that you know the the ability to.

And is it haptic or whatever you know the the one new ability to be able to move with it but they they were able to ignore their existing customers who were not going to be interested in we and but that was where the market was takes a lot of effort to look away from the easy place where there are customers and look at, you know, a white space where there are no customers and and as you say, put aside your prejudices and your assumptions and unlearn what you know and go for a a different, a completely different market.

01:05:21 [ML]

Yeah, well, APL does have. It has the problem both ways in that. Both APL designers are often not looking at less experienced programmers, but also the less experienced programmers are much less likely to even hear about APL, so.

Maybe if they could be introduced to it, they would be potential users, but as it is, they're not being introduced to it.

01:05:41 [LG]

That's right. There's there's both the people not being introduced to it and, you know, let's we're among friends here. Let let's say that I think the intellectual horsepower required to wield APL as a really great tool. Is a little bit higher than for other languages.

01:06:00 [ML]

Yeah, in an array style, definitely.

01:06:02 [LG]

Yeah, so there's, there's that. The sort of snottiness and disdain for people who don't get it as much because there is admittedly, you know, a range of intellectual horsepower of different people and the highest intellectual horsepower or many higher. The people in APL tend to be higher intellectual horsepower. And so they they don't. They don't value. The other people as much as as they should, you know.

01:06:34 [BT]

But that's that's true of mathematics as well. At the high end, it's barely understandable to you know, most of us mere mortals that Terry Tao [31] is people like that. You just go wow, I. Just your brain. It's it's a it's I'm in awe, I'm in wonder of it. It's amazing. It's lovely that I live on this planet where somebody has such a tool. To be able to use I I don't feel capable to reach that level. But that doesn't mean we don't teach arithmetic.

01:07:02 [LG]

My masters thesis was called the axiomatic foundations of algebraic topology and and I had a guy who who is a PhD working for me one time, and he said.

You know, Lib. I'd really like to read your thesis. I yeah, yeah, I haven't looked at it for decades. Anyways, he convinced me to pull it out and I looked at it and I did not understand one word of it. You know nothing I learned beyond first year math was of any use to me except as a bit of street cred. You know, as a woman, you're really you're really up against it in the technology world and much more so when I started and having a masters in math was was helpful in that people were less likely to totally dismiss me out of hand. And it was, you know, was not, it was not a good assumption 'cause. I didn't even understand that stuff anymore. But, you know, there was that little bit of a marker behind my name.

01:08:04 [BT]

Well, there is a gender component to it as well, isn't there? I mean, the I I'm hoping this is changing, but there has been traditionally a male domination of programming and coding and there's that product, you know, the images people get of, of programmers or coders, I think. Typically they lean towards male and I don't think it's right.

01:08:28 [LG]

Yeah, they didn't as much in the old days, Bob. You know, in the old days there were no programmers, there were hardly any computer science programs. And so basically my view was they would take anybody they could get.

Even if it was a woman was sort of my expression about. I don't know if that's entirely fair, but you know, I know Ada Lovelace is often talked about as the first programmer, but there there were ... the percentage of female coders has gone down from the early early days.

01:09:04 [ML]

We do have statistics from like the Stack Overflow survey, and they're seeing well over 90% or today's male.

01:09:11 [AB]

So, but it wasn't like this. If you look at how coders came to be before, there were computers that were electronic, there were computers that were human and that was the same, the same type of ladies that were the telephone ladies and the secretaries and so on they were doing the computations for.[32]

01:09:22 [LG]

Right.

01:09:31 [AB]

All the men in power, just like they were writing the letters for the men in power, and they were the first ones to begin automating computing. As to assist themselves in the work that they were doing right, so then and then they got these machines. You could rotate the handle and it would calculate things for them, and then they were electrified and winning eventually became electronics. So in the early days, I think there were a lot more women than men doing what we would call computing today. And then somehow things changed.

01:10:03 [LG]

Well, what changed was salaries, roles for people who were, who were coders. And as soon as the salaries rose, Oh well, we couldn't pay women those salaries, so. It became a male dominant profession that I've I've read some research that shows that the salary increases were what eventually attracted the men and then drove the women out because the men got very aggressive about being coders.

01:10:28 [AB]

That that's very interesting, that that's kind of turning things in the head from, I think, what people normally think.

I don't.

People say you know the men code as being paid more than the women and here we are saying code is being paid and the men are taking over those jobs.

01:10:40 [LG]

Yes, that's what I've read that it it it's counter intuitive, isn't it? In a way, but not entirely unreasonable, yeah.

01:10:46 [BT]

But if you think about Clay Christensen innovator's dilemma. That is exactly the innovator's dilemma. The men went, when it went higher in, the men swooped in to get it and and the main population is no longer being served by it.

So whenever there's that curve happens, there's an opportunity, right?

01:11:07 [ML]

Yep, but I will say Uhm 1 interesting thing has happened with BQN. I think at least a BQN is a lot more usable as a regular programming language. I mean more in a in a Python style. And what I've seen is a few people have come on and asked you know can I have some help with my program and then they write this program and it doesn't use a single array or it has one array and did loops over it. It works one number at a time or something like that and and of course I say, well, you know you can simplify this thing here if you use arrays or whatever, but I think that's pretty interesting that that people are picking up QN and then they're writing code the same way that they might write JavaScript, which eventually I'd like didn't not to do but and then they don't see anything wrong with DQN as a language apparently. So they say, well. It's dumb. This is fine it works as a programming language, so I like that I have that thing that can scale to both users who are. I mean, I I don't think using some arrays is particularly difficult, but who are at least not used to using arrays, but it can also scale to, you know me who can write an entire compiler with flat arrays. That's pretty cool.

01:12:17 [LG]

Yeah, yeah.

And I think, you know, it's, it was said often, it's talked about in the early days, you know, was it was it a mistake to make everything italic, even to all the symbols? But, you know, it was interesting. I, you know, I've been away from APL for a long time. I I was writing a few thoughts down when I was doing this, and sort of having to italicize every time I come across the word APL, even in text, you know, just little wee hurdles all along the way to make it a little bit more forbidding, a little bit more intimidating. And, you know, something like David Keith when he wrote Magic, which was a meta language that handled arrays, that was built on top of APL. And it was, you know, simple language. The the Gopher thing we wrote in in Alberta was about that way, but it would say something like, you know. Oil well is oil well is so many thousand barrels declining, you know 10% a year and and you'd build an array and then you'd work on that array. But it was it was done in an English language, so you had the array idea in your head very, very strongly. But you didn't have one of the inhibitors of APL, which was the number of symbols and the and the the character set. Anyways, there we are. There we are.

01:13:48 [CH]

It's it's. I think it's really, it's really, really valuable food for thought. What you mentioned when you said you know when operators came along, sort of that was that was your line and I think as whether you are a programming language designer or you know an advocate for the array languages. I think it like that the fact that you know, you'd mention, you know, whether it's a 10% or 1% of folks that really learn how to wield the languages is that we should be using the greater populace of people and how they think and how they would naturally approach a language as like informing how we are trying to educate or advocate for these languages. And we've kind of talked about this in previous episodes of what's the better model when it comes to leading or trailing access and we don't need to go into the details, but like I think. A lot of the times I. My favorite language is BQN [33], and when it comes to functional programming like, I prefer there to be less implied defaults so that it anything that causes you to think more up front, but that leads to like a more generic or beautiful or sort of regular system like.

I like that, but that does require more thinking up front and and there's something to be said.

About the fact that you know Python And JavaScript and all these really popular languages are dynamic and they're, you know, can be interpreted and so like you know languages that are compiled and give you more errors and warnings.

You know, there's something to be learned from having an easier on ramp that is technically, you know, might be considered a compromise in terms of like what's the most beautiful, perfect sort of array language versus like what is making people, you know what? What is it making? What's the easier path to people learning and picking this language up that might be a compromise to like what is most beautiful or or most perfect?

01:15:41 [LG]

And I think you you brought up a good point earlier when you said people can use a language without using the array concept, and in many ways I think that what has turned this group of people on is that way of thinking in arrays, right and maybe Conor it's it's the most important thing maybe is to figure out a way to help people think in arrays.

'cause that's that's you know and you've appropriately called this this podcast about array languages, but you know it's the arrays that are the huge power. It's a different way of thinking. It's a more holistic way of thinking, a less plodding way of thinking. You know, if we, if we describe. What you said, Marshall. Where you go one element at a time through an array. That's a pretty painful way to use an array language, right? So so anyways, yeah, I I think, I think, you know, I really like the way you have honed in on expressing this about array languages.

01:16:53 [CH]

I feel like we're going to, we're going to have to have you back on because I feel like we only got halfway through your career story. We didn't even get to the chapter where you were CEOing. You know, one company, then another company, then advising CEO's, then sitting on boards. But we are a couple minutes away from from the end here, so I guess I'll say to Lib first, is there anything you sort of you want to wrap up with or say and then maybe if there's any question, final questions from folks and then we'll kind of try to end on that note.

01:17:21 [LG]

Yeah, I'll just dangle one thing and as you say, we may talk about it at some point in the future, but one thing we didn't really talk about was the fact that IP Sharp people were digital natives before the the word was coined and something we should talk about in the future is how extremely influential APL, sorry, IP Sharp was in creating and stimulating the early Internet in Canada. It was IP Sharp people who really drove the Internet in the early?

It's not surprising when you think back on it, but a very little known fact. So that would be the only other little thing I would dangle. And then the other thing I would say is just thank you very much. It's been so much fun to talk about these things and to think back about some of the things we did in the past, and I really applaud your initiation of of this kind of discussion and I'm so pleased to see new people coming into the world of array languages. So thank you very much, Conor and all the rest of you. On the panel.

01:18:31 [CH]

Now, you definitely do not have to thank us. It is our pleasure to host you and I love these conversations that we get to have with folks that have, you know, decades of experience and the stories that folks get to tell.

01:18:43 [BT]

I'll just mention before we go, there are show notes for this, and show notes are very valuable.They have information that fill in and in this particular episode, the show notes will include a link to Clay Christeansen Innovators Dilemma graph, which may, although Lib did a wonderful job describing it, may make it even easier to understand what he's talking about and also finally for me, I thank you to Rodrigo for all the work he's done over the time on the transcripts and how important those are. And if anybody is interested in getting involved with this that way, let us know. [34] We will continue with transcripts one way or another, but if there is somebody out there is an interest in doing that. Get in touch with this at contact at arrraycast dot com and we'll bring you online and we will do the the Ian Sharp thing, will throw a, uh, rough transcript at you and you can clean it up and and and it takes some time and effort, but there's definitely a benefit from that.

01:19:45 [AB]

Adam, I'd like to say thank you to Lib because for all that we're doing, apparently we wouldn't have been able to do it without you.

01:19:52 [LG]

Well, there were people far more important than me. I, as I said, I was sort of on the periphery of all this and just lucked out to be working with such incredibly wonderful.

01:20:03 [CH]

No, I would definitely echo what Adam has said is I think I've said this to Morton as well. You know, his work that he's done with a dialogue limited and keeping sort of APL alive. Not that it would have totally perished, but the reason I stumbled across APL and fell in love with the paradigm and all these languages was because of the trypal.org website. [35] So there's, you know, a series of folks that have, you know, led to this point where you know, in 20.

I don't know 19 or whatever it was I was able to easily try APL. Well, I think Lib, you're definitely a part of that story. And yeah, once again, thank you so much for spending your time with us and sharing your stories. I will say that I think we're going to try and in some fashion record libs talk in a couple days at the Toronto meet up. So it might not be available immediately. But if we are successful in recording that you know in the next couple of weeks hopefully folks that aren't able to attend in person, we'll be able to watch a sort of version of that recording online. And with that, yeah, I guess I'll get to hopefully meet you in person in a couple days Lib and.

01:21:03 [LG]

I hope so.

01:21:04 [CH]

Yeah, that'll be awesome.

So with that, we'll say happy array programming.

01:21:08 [ALL]

Happy array programming.

01:21:10 [MUSIC]