Transcript
Thanks to Rodrigo Girão Serrão for providing the transcript.
[ ] reference numbers refer to Show Notes
00:00:00 Morten Kromberg
You know, I'm also really hoping that that one day I'll be able to sit in my rocking chair and and say that I helped, or at least did not hinder the beginning of careers of the people who will be the great array language implementers of the future.
00:00:24 Conor Hoekstra
Welcome to another episode of Array Cast.
00:00:27 [CH]
I'm your host Conor. And today with you we have a repeat guest that I will announce in a second, but before we do that, we'll go around and briefly do quick introductions. We'll start with Bob, then go to Stephen and then go to Rich.
00:00:38 Bob Therriault
I'm Bob Therriault, I'm a J enthusiast. And I'm now involved with building the J Wiki or rebuilding the J Wiki, which is a challenging thing and we're we're making some progress with that, but more about that later.
00:00:50 Stephen Taylor
I'm Stephen Taylor, I'm an APLer from way back and currently the Kx librarian.
00:00:56 Rich Park
I'm Rich Park. I'm a APL evangelist and working on training materials, tutorials and such, and I work for today's guests at Dyalog Ltd.
00:01:08 [CH]
And as mentioned before, my name is Conor. I'm your host professional C++ day to day, but in all my free time Array languages and combinator enthusiast at large and excited to talk to our guest today who we had on previously but didn't really delve into his personal background. But before we introduce him, we'll throw it to Bob, who's got a couple short announcements and then we'll hop into today's interview.
00:01:32 [BT]
I'll be really quick. We have been working on the J Wiki and one of the things that this podcast actually people on this podcast we're pushing us into was trying to develop something like tryAPL, [1] which is what Dyalog does, which is really cool, and it's a quick way to get access to APL through the browser. And J didn't have that. And now we are in the process of putting together the front end too. We've actually got J running in JavaScript, which means you don't need to download anything, you just fire up your browser and you can run J, which is really quite a big deal and lots of work by by Will and John and Joe and John and and lots of people have got that put together. So that's been really good. And the other thing is I'm looking for feedback. I put a video [2] up on an introduction to J last week and it caught a little bit of attention, but I am looking for feedback for it. So in the show notes then there will be show notes, then there will be a transcript, actually last week guest Rodrigo mentioned that we probably should mention this off the top that we have show notes and we have transcripts. And we can be reached at contact at ArrayCast dot com and having done all that now I've taken up far too much time and back over to you, Conor.
00:02:47 [CH]
Awesome yeah, that'll be exciting. I think the tryapl.org is. It's actually how I basically fell ended up falling in love with APL 'cause I heard about it on a podcast once and went and Googled it stumbled upon it and having like a web based REPL that you can just start playing with, I think is a really lowers the barrier to entry for any language. Whether that's APL, C++, J, et cetera. So awesome that that's going to be coming for J soon. With all that said, today our returning guests is Morten Kromberg, the former CXO and current CTO of Dyalog Ltd. I apologize for all the times in the past i've referred to the company as Dyalog APL, which is not the name of the company, but I always interchange the two. Morten is going to be bringing us back in time to talk a little bit about about his time at IP Sharp and associates and then his time currently at Dyalog Ltd and then also we're going to talk a bit about the future of Dyalog Ltd and APL. So go as far back in time as you'd like to and super curious to hear what you have to say today.
00:03:48 [MK]
OK, thanks it's it's great to be back. I mean all of the the the work that you guys do. I'll come back as many times as you ask me. So I'm going to go back even before IP Sharp Associates tell a little bit about how I discovered APL. It started off very promising. I was born in 1962, which is the same year that Ken Iverson published "A Programming Language". But right after that my parents whisked me off to a country called Botswana between South Africa and what's now Zimbabwe. And I grew up there with, I think an AM radio, probably the most advanced tech in the house. But when I was 15 I was back in Norway about 1977 I guess, and at the end of high school I got a a BASIC [3] course for two weeks as part of a math course. And shortly after that I noticed in the local newspaper that the first Commodore PET [4] in Norway was on display in the the biggest department store in Norway, downtown Oslo. Only a 20 minute tram ride from my house. So I headed down there and curiously, the department manager let me sit and play with it after school pretty much every day for months, presumably because a kid sitting in front of it made it look a bit less intimidating, and it looked a bit, I don't know if you've seen pictures of the Commodore PET, it looks a bit like sort of a white Darth Vader helmet perched on a on a box. Uhm, so I, I spent months learning BASIC , wrote Moonlander as one does game and uh, I spent so much time there even today I remember the taste of the the chocolate milkshakes they served in the restaurant at the department store. After that I I wanted my own machine so I started getting hold of little 6502 or Z80 based machines and doing hand assembled programming. Uh, I played with an HP calculator that taught me that reverse Polish was really not what I wanted to do. And then I started a really big project. I bought something from the UK, a Nascom One [5], which was a kit that arrived in a box with a single printed circuit board and little bags full of resistors and capacitors, integrated circuits and I had to do 3000 solder points and for a kid who just bought his first soldering iron that wasn't really a good project. It did boot up, but there was a dry solder somewhere, which meant that every time I hit the reset button to return control to the debugger, a random column of RAM was was corrupted. And when you have no way to save and load programs, you have to type it all in again. That's a bit discouraging, so I don't know why I still enjoy coding to Electric Light Orchestra's "New World" record, even though that's what I was listening to then. Uhm, so somehow I enjoyed it. But then APL arrived in my life. Fortunately, in 1979 a Canadian company called IP Sharp Associates [6] who were involved in the initial APL 360 implementation for IBM were now offering APL timesharing on mainframes located in Toronto. They were sending one or two people out to very many capitals in Europe to set up data concentrators so that large corporate clients like Ranked, Xerox, and Kodak could do reporting via local dial-up lines into the IP Sharp network. So they got email and and reporting applications and the crew who arrived in Oslo for IP Sharp Associates moved into a flat that my dad was moving out of and I helped them carry some furniture and they heard I was interested in in computers and they said why don't you come down to the office and they showed me, you know the the 1 2 3 + 4 5 6 that we've heard about so many times. And you know, I remember a small wow, but you know nothing impresses kids. I just sort of concluded that this was a natural progression, right? There's assembler. And then there's BASIC. And then there's APL. And pretty soon BASIC would be history I presumed. And now more than 40 years later, I'm still puzzled about the state of the of the universe, but I fortunately managed to use APL ever since then, so you know, I wrote my own adventure game, and perhaps the least useful program ever written: a very very partial BASIC interpreter written in APL, and today I still feel that those those couple of years there where I was just messing around is where I actually learned 90% of the skills that I have to this day as as an APL programmer. Uhm, and a funny story from that time. I actually managed to sign up a timesharing customer for IP Sharp Associates. During that time there was a a lady in the horoscope business. I don't think I'll call her an astrologer, but she noticed me playing with a PC at some show and she had a book with a BASIC program listing in it to compute planetary positions and asked if I could implement that. So I typed in these 50 pages of of BASIC code, but the resulting planetary positions were all over the place because the BASIC interpreter on this machine used single prison single precision arithmetic unless you forked out the cache for the floating point coprocessor, which cost about as much as the the PC had cost to begin with. But curiously, the serial IO adapter cost an order of magnitude less. So I figured out I could write the code in Sharp APL and then just have the BASIC interpreter dial up and type in the birth coordinates and get the planetary positions back consuming $0.10 worth of CPU time and then producing a report that was sold for $10.00 so that was good business for for her and probably not very interesting business for IP Sharp, but but that was my first taste of client server computing. I guess back in 1979 or something like that. And then there there were a couple more years of where I was essentially an item of furniture in the IP Sharp Oslo office. They let me come and go as I please and make coffee and but eventually they decided they could rent me out to customers. So I did things like, uh, back in Norway, then they were modeling the profitability of North Sea oil exploration, and I I also wrote a crew scheduling system for an airline. Everything was made by hand back then. It was it was a wonderful time to to be a programmer. And so I finished high school and I tried studying maths and computer science but really struggled with motivation because APL, working for IP Sharp was just so much fun. I even tried tricks like moving 500 kilometers out of Oslo to Sondheim and the Norwegian Institute of Technology, to get away from the IP Sharp office. But of course, the airline with the crew scheduling system just flew me down South when they needed tweaks to the system. Up until one day I showed up to a meeting with them in a tracksuit and the head of IT decided that it was too embarrassing to to have them relying on something written by a kid, and he'd better, he better take care of it, but that's how I remember it anyway, and I'm telling this story and at that point, sort of a big change, Gitte, Gitte Christensen, who was on a few episodes ago [7] explained that she imported me to Denmark. But there's a little bit more to it than that. In fact, I used data mining I used APL to data mine Gitte. Because at that time IP Sharp Associates was entirely managed by email. Perhaps one of the first companies in the world to be driven that way. And I was stuck there alone in the Oslo office, miles away from anybody else. And I decided that in order to find out what was going on in the company, I needed to write a program that spooled the entire email directory out to file once a week and then do a diff because then I could see which email groups had been created and who had joined the company. And in addition to the whois function that the email system had, I could write a whowas function that would tell you about people who were who were no longer there. And suddenly one day I noticed a very interesting looking person, only 500 kilometers South of where I was and the IP Sharp system had a text messaging facility, the right paren MSG system command. And shortly after that Gitte did import me to Denmark. Uhm, it is the girls who call the shots most of the time anyway. So I got to to Copenhagen, I tried to resume an academic career there, but although I learned Simula in Oslo and Pascal and COBOL in Copenhagen, we got pregnant and I finally had the excuse I needed to abandon my academic career, which was which I you know, to be honest, I was ill suited to anyway although 35 years later I did have the pleasure of returning to the very same building that I dropped out of because I was invited back to the University of Copenhagen to give a course in APL to the Futhark team. I don't know if you've heard of Futhark [8], it's a functional array oriented compiler. And they realized there were APL people nearby, so that was a lot of fun teaching them APL.
00:13:31 [CH]
How many people were in that class?
00:13:32 [MK]
Oh, I think it was I don't know four or five masters students working on the compiler.
00:13:38 [CH]
Wow, that's so cool. I had no idea.
00:13:40 [MK]
Yeah, that was that was fun. The only the only unfun thing was walking through the canteen and feeling very very old. Anyway, so uhm at that point, I, you know, abandoned academic career. I became a full time APL consultant at IP Sharp Copenhagen, and very quickly settled into a pattern where Gitte would talk to clients, understand requirements and write application code while I concentrated on building infrastructure and tools sort of multidimensional databases in APL. And interesting, during that time we also met Adám's dad, Henri Brudzewsky, who was a leading figure in the APL community in Denmark at that time, consultant like us not working for for IP Sharp. And we had two pairs of children, each at pretty much the same time, and we lived near each other and our families became close friends. And that's part of the reason why you know we we would we babysat Adám at APL conferences and his mother looked after our kids. Because we were at all the APL conferences back then every year. Uhm, yeah. And then so that went on for a while uh, towards the end of the time at IP side I sort of, I managed to get to work with the people in Toronto in the Ivory tower on tools that were used outside the Danish office, like 3270 UI prototyping tools and converters from other APL systems to Sharp APL, which was something we did a fair amount of at IP Sharp Associates. And getting to interact with people well, like Stephen, the last time even was maybe in Australia at that point, but certainly interact via the email system with Leslie Goldsmith and and Lib Gibson and the key application developers at IPSA. But then, just as as things were getting really interesting at IPSA, it just suddenly disappeared overnight from under our feet as the the bottom dropped out of the mainframe timesharing business. IP Sharp was also selling their APL interpreter on mainframes at the time, but that people didn't want to use mainframes anywhere near as much as before, and we were all laid off, and an IP Sharp just from our perspective at least disappeared.
00:16:12 [CH]
What year was this taking place in? This was like late 80s, early 90s.
00:16:16 [MK]
This was 1989.
00:16:20 [CH]
OK.
00:16:21 [MK]
I think I think Reuters acquired IPSA in 1987 or 88 and then spent about a year deciding to get rid of all the people who were not in Toronto working on databases, 'cause Reuters I think Gitte talks much more about this about how Reuters wanted the historical time series databases that that IP Sharp had collected over a couple of decades at that point. Reuters had no historical information, but Reuters was not interested in being a software company. They just wanted the the data. So those of us who were doing APL application development in the in the, you know, far away from Toronto, we we were all laid off overnight pretty much. I always, really funny, actually, I'm I don't know if I don't have time. Yeah, they're, being fired by Reuters was one of the most fun things that's ever happened to me because IP Sharp was this company where what was I? I was 23 or 4 at the time. 5 maybe. And they they really didn't want to upset anybody, so they gave us this package. You know, a retraining package. And so they they asked for our job descriptions and when I was 24/25 at IP Sharp Associates, I had the kind of responsibility that you would have to be one of the you know top managers at Reuters to be, you know, I could I could buy things and take decisions. So they concluded that we were all senior management types and they gave us this fantastic retirement package with you know, talking to psychologists and being given guidance on what to do next and you know. And we you know, we we did it all, because it was fun. But then we said, but you know, we're going to form our own company anyway. So essentially, IP Sharp Copenhagen just continued. We bought all the furniture and then continued business the day after as if nothing had happened because the customer still needed us for for a while anyway. So the technical staff of IP Sharp Copenhagen, which was Gitte and myself and Kim Andreas. We formed this company called Insight Systems in 1990 and just carried on doing APL consulting. Now focusing on on workstations rather than mainframes. There was still a couple of years of mainframe consultancy to do where we made just a ton of money, but we could see that that was all that was all dying. So early 1990s you had the arrival of Windows and OS2 and graphical user interfaces, and that was a real worry because it made the existing APL systems at the time really looked like dead ends. The the first GUI interface for APL+ really, you know, didn't look promising. It essentially gave APL programmers direct access to the win 32 API. And if you cast anything correctly from APL, that was just the end of your APL session as something that APL programmers really couldn't could not deal with, right? A completely untyped language, trying to make win32 API calls is is never going to work, so we investigated Smalltalk [9], which quite a few APL programmers at the time went off and did I think probably at least half a dozen people I know went off and did did Smalltalk.
00:19:53 [CH]
Really?
00:19:53 [MK]
Yeah, because it was seen as sort of the nearest thing. If you couldn't have APL, what're you gonna do? Uh, well, Smalltalk. Seemed like the obvious choice at the time for a lot of people.
00:20:03 [CH]
That is a crazy piece of programming language lore that in the 90s...
00:20:09 [MK]
Is it?
00:20:10 [CH]
Yeah
00:20:11 [MK]
you need to talk to, you need to invite Romilly Cocking [10] on the show.
00:20:14 [CH]
OK.
00:20:15 [MK]
Uh, because he ran a very successful consulting firm in the UK, Cocking and Drury. And they I think they switched the whole company to doing Smalltalk for a while and he can tell you more. He can tell you about that. We only looked at it very briefly and and we looked at things like, I mean, most of you know half half of you weren't around then there was Gupta SQL base. And there were tools called Application Manager for OS2 [11]. I remember OS2 was a big thing at the time as well, but then none of those were really, it didn't turn us on at all. At that time Dyalog you know Dyadic Systems put out Dyalog APL and we suddenly had hope that that APL would be a viable platform for Windows GUI. So we stuck to our guns in yeah early 90s. Now we're talking. But the big problem we had was that we really had skills to do consulting for large companies to do data analytics on their corporate data is what we've been doing for the last decade. And we didn't have access to the data. So one of the things that Insight Systems did was team up with a Belgian company called Technosys who had a product called SQL Link, which was, I think a precursor to ODBC [12], so they were actually selling ODBC as a something very similar to ODBC as a package. Uh, their big trick was connecting Macs to AS400s [13] because nobody else could do that. And we wrote, uh, an adapter for APL, for that which we managed to sell to Dyalog, so it was available for Dyalog, APL, APL+ , and Sharp APL. There was a version for APL2 as well, but IBM decided it was easier for them to write their own to get it through the legal department to use our tool. And and then later we adapt it to ODBC. It's the same interface that's in Dyalog APL today the the SQL interface was built back in the early 90s. And then ODBC was supposed to die, but of course it never did. Well, it sort of died on Windows, but then it became the standard on Linux and it's really weird. Anyway, uhm. So, so we had to invent that tool in order to have access to the corporate data from the from the workstations. And through that, of course, we got really well connected with with a lot of people in the industry, the the vendors and did consulting projects for a lot of lot of major corporations. Uhm, but we were getting really tired of trying to sell our skills as small companies and just being a four man consulting band was was really, really tiring. There was always either way too much work or much too little work to do. So we wanted to become part of something bigger. We we we nearly sold ourselves to Technosys, but then they were acquired by Progress very shortly after. So we're really happy we we didn't do that. Umm, but then as as sort of related to having become the the ODBC or the the client server people. We were hired by a company called Adaytum [14] who had a, uh DOS-based, at the time, business intelligence package. And they hired me as a consultant to sort of give them an architectural blueprint for how they should move that over and become a Windows system. But halfway through that consulting project, it was abandoned in favor of hiring me as the new CTO of of Adaytum and Gitte as the Nordic sales manager. So we then built a company in Denmark with about 25 people who were booming doing a combination of development in Dyalog APL of this business intelligence package and then selling it in the in the Nordic region. And that company was driven by an ex-SAS Special Armed Services uh soldier from New Zealand who had been in satellite TV and now wanted to to conquer the world with this and he had 50% year on year growth for five years heading for NASDAQ IPO and in the last two years come under the loving strokes of venture capitalists who who looked at us and told us you're doing your risk, your R&D budget is too small. It should be three times higher. Hire some people. And eventually we decided to bail out of that. And and in fact, just after we left, the company missed the the IPO because the .com bubble burst. So that was in what was that close to 2000? They just missed it, but it it was the story had a happy ending anyway, 'cause they sold the company to Cognos [15] for quite a lot of money. And that's where we get, and I earned the money that we later used to buy our share of of Dyalog. There's also a really funny story on the end of the day, Tim, which is that the Adaytum was sold to Cognos. Cognos was then sold to IBM. And I don't know exactly what the numbers were, but probably something like IBM ended up paying more than $100 million to buy back an APL application which used to be an internal IBM planning system that they had let the original author, George Konzal, take with him as part of an early retirement package.
00:25:58 [CH]
That's awesome.
00:25:59 [MK]
So funny story and they are well, maybe I shouldn't so I shouldn't speak about this, but that that system is not dead yet. Yeah, so Adaytum ended and we spent a few years as APL consultants, again in sort of the general market and at one a few years later a couple of the major customers of Dyalog or Dyadic as it was at the time felt that something was something needed to be done to avoid the risk of Dyadic being acquired by one of the major customers. Uh, a big oil company in the US was mentioned as a potential buyer and they were really worried that the Dyalog APL would become some internal tool and and effectively disappear from the market. So these two companies, Simcorp [16] and APL Italiana, they they were competitors at the time and they teamed up to find new management and to fund the acquisition of Dyalog and then install new management and that became Gitte and and myself. So that's when the story started at that Dyalog in 2005.
00:27:14 [CH]
So wait, what happened? Simcorp and APL Italiana? They didn't, I don't think they acquired Dyalog APL, but it sounded or Dyalog Ltd., but it sounded like...
00:27:24 [MK]
No, well, they did actually what the the way what happened was they actually they approached Gitte and myself and asked whether we could act as headhunters to find new management for for Dyalog because they knew, you know, we knew everybody in the market, basically. And I suspect Carlos Bonnici at APL Italiana, had already worked out what was going to happen that we would fail, and then we would fall on our swords and say, well, OK, we'll we'll do it. I think he knew secretly I wanted to do that anyway, so I wanted to get back in the APL business uh, having started out at IP Sharp Associates so we were, you know, absolutely delighted to fail in the search uhm, and get together with, so APL Italiana and Simcorp put up about 3/4 of the funds and we put up 1/4 to acquire Dyalog Ltd. in 2005.
00:28:22 [CH]
Oh, I see.
00:28:23 [MK]
So there were three owners at that time, and of course our so so that's sort of the beginning of the Dyalog story, the the the Dyalog company. At that time, the APL group of it, it was actually a company that also had a big IBM AIX RS6000 reseller unit. And that it was split up and the parts were sold separately. But the APL side was about five people at the time, and obviously our mandate was to start by, you know, replenishing a very small development team, half of which was rapidly reaching retirement age approaching retirement age. So we we did a road trip. We visited all the major customers. And they've told us afterwards they expected that we would just walk into a room and tell them how many months they had to get out of Dyalog APL, because we were acting on behalf of some major company that had had bought it. But uhm, we explained our vision and we started. We told them we'd offer services like escrow and support for cherry pick fixes to customer specific branches and architectural reviews and tuning and reacting projects and so on and changed, change the pricing so that people had to pay for the usage. So before you would just buy a copy of a developer license, but at that time we revised the pricing so that pretty much all the revenue came from support contracts which are some function of the usage of Dyalog APL at the customer site. So the number of internal users or the number of APL based seats that they sold of their application? Or it was really up to the customers to come up with some number that they already had, ideally that they were comfortable using as the as the baseline for the support contract and there were lots of people in the UK in particular who sort of shouted that the Vikings have come, and they're, you know they're going to loot and pillage dyalog and it will soon be gone, but in fact the major customers were absolutely delighted because they were making Plan B, which was going to cost double figure $1,000,000 uh. And would had had very high likelihood of failure. So the the customers were really happy to to pay more and to pay based on their usage. Uhm, and this had the effect of not just increasing the revenue, but also making it very much more predictable, which allowed us to feel comfortable hiring people. So since then the revenue has just grown, uhm fast to begin with, but it's still it's still growing because these companies are successful and selling more seats, and there's a steady trickle of migrants from other other APL vendors. It's also interesting, I think that since that one price adjustment we made in 2006 we have not increased our prices. We have not adjusted them for inflation. So the the price of the new 64 bit system that was introduced at the time, which was 50% more than the the old 32 bit system. But where that fee included both 32 bit and 64 bit because most people would need both for a for a transition period is the same now in real terms as the 32 bit system cost back then, I think if you were to adjust more for inflation.
00:32:02 [BT]
A few years ago and with web applications, there was a big outcry when people switched over from buying an application going to subscription basis. It sounds like you guys hit the subscription idea, you know, 15 years ahead.
00:32:14 [MK]
Well, it was the only way to, uh, and and it's fair. I mean, it's, uh. I I mean, of course it depends on how big the numbers are of course whether something is fair or not, but I think the the customers are are very happy with with what they got.
00:32:28 [ST]
You mentioned conversion projects that the is the Plan B. They had to get off APL and you said that there's a high risk of failure in those. Do I recall that you have some some war stories from that.
00:32:42 [MK]
Uhm, I don't know that I have any I can repeat since they're all fairly ugly. I mean, some of the customers, of course involved had already tried this, right? So they knew very well that it was going to fail. And there are other companies who just said, well, we OK so we can get out of APL if we get rid of, uh, 50% of the functionality of the application, but we want to do that anyway because, because of reasons, uh, which may be good or or or not. But anyway, so so in that first that first few years we, uh, we increased the revenue significantly, and we were probably a dozen, a bit more than a dozen people after three or four years and we you know we had the people we were starting to train the people who would take over eventually from Scholes and Streeter. And of course we have all of the original people still on the team today except John Scholes [17], who who passed away, of course. But Geoff [18] is still there, the original implementer of Dyalog APL is still there working part time and even Pete Donnelly [19], who was the the Managing Director, works on testing and writing parts of our documentation to this day. Uhm, so you know the annual user meetings were growing and I think in general all the customers had stopped worrying about whether where the Dyalog was, you know, we would be there for as long as any of their planning horizons. They started hiring people. We invested in Mastering Dyalog [20], the Bible, the 800 page. I once swore I would never ever learn, a programming language that had an 800 page manual and then I became a Co-author. Uh, so Bernard Legrande did most of the work, and a few of us were involved. And of course now really happy to see Rodrigo [21] doing a proper job of of modernizing it. But anyway, so you know first five years, customers relaxing, hiring new people, thinking about extending their APL systems instead of getting rid of them. Back in yeah just before 2010. And and of course, having been for the last 15 years before we joined, Dyalog consultants and building our own product in Dyalog APL, we also came with a to do list of things that we really thought the product needed in order to become competitive. So and with the new developers on board, we could then really start on on that. So we completed the 64 bit uh, conversion and the object oriented features which those were actually pretty much done by the time we arrived. John Daintree [22] design pretty much C, implementing C# object model in Dyalog APL because of course at the time it was the .NET framework that was the big thing. If you wanted to do any, web programming, you basically wanted to write ASP.NET [23] applications and John did all the work to allow you to write ASP .NET plugins in Dyalog APL and so on, and therefore the OO needed to be quite closely aligned with C#, or at least that was the thinking back then. And and then we we added Unicode support uh, early, very early on and I'm really proud of that implementation. We use proper character arrays, not UTF-8 strings. And we managed to design it in such a way that existing clients could move over to to Unicode almost without making any code changes. And and I'm pretty confident we got that right. 'cause the Russian client said it was good so and they moved very quickly. And and if they if they thought that, I think that's the ultimate the ultimate proof. And and then of course quickly following on from that was was, uh, putting APL source code in Unicode files, which is something we've been working on for more than a decade, and I still wouldn't claim that we've got it right, but we're getting we're getting somewhere now. Tooling for efficient conversion of XML and then later JSON and CSV files. And then sort of towards the end of that Phase I guess seven or eight years into the Dyalog story, really understanding the ascendancy of Linux as part of cloud computing, and the fact that in the future probably everything would be Linux, and there would be a Microsoft Linux and there is today, so introducing the RIDE and and just generally trying to make sure that all the tooling that we put in so like the CSV the XML. Everything should work the same way on Windows and Linux and Mac, if we possibly could. Anything that made sense in all the environments would be the same everywhere. Adding support for secure sockets in our TCP layer and and of course, adding the Mac OS and the Raspberry Pi versions and then sort of the first little stab at attracting new real new users was running the annual problem solving competition [24], which also started in that well, actually very early on in the in the middle period and and on the language side, of course us old Sharpies wanted to bring in some of the great ideas from Sharp APL and J into Dyalog aPL, and fortunately managed to connect with Roger [25] and and that was really wonderful so we could have the best of both worlds. We could have our OO and our floating arrays, but we could also have the rank operator and key and extend dyadic iota to higher ranks and and stuff like that. Oh, and futures and isolates also went in in that period, so you could have this user controlled parallelism that's also nearly ten years ago now. So that was sort of the middle, the expansion phase after the The Big Bang if you like and then the last five years or so, we've started to feel that dyalog APL is reasonably competitive, you know you can you can show it to a programmer of of some other language, and they will they will notice some warts in the tooling and so on. There's there's much more work to do. But you could really it was worthwhile now trying to understand how to attract a new generation of users. And and interestingly, in the last five years we've I think it's true that technologically, it's a period where the biggest, the very biggest customers and the new users, the more technically oriented users are actually asking us for the same thing, so they want you know ways to do cloud computing and continuous integration and all that stuff, and that definitely wasn't true if you go back 10 or 15 years, there was much more of a disconnect between what the big customers and and the new users want. So what what have we been doing? You know? Well, really, continuing mostly so much more investment in this cross platform development. So making the RIDE a really capable development tool, the HTML renderer, which is sort of like I don't know Node.js for for APL, where you can you can pop up a window and populate it with the HTML, JavaScript and works on all platforms and then deciding how to to run Dyalog APL in containers effectively. Making text files full source mainstream understanding GitHub and then starting to think about on this. Again, this is something where we still have a way to go. Project managers, package managers and so on things that other programming languages take for granted where we're just starting to see the 1st, some promising tools emerging? Uhm, and although we can't yet see a way to to make Dyalog APL itself open source, and that's something we can talk about a bit later if if you'd like we are trying to publish more and more of our or the coding with the APL code that we produce, so all the tooling layers that are done in APL, under MIT license, typically on GitHub, because we think that that part of of what we do works really well with open source. While the interpreter I think there are good reasons why it doesn't work well, certainly not right now, maybe it could could in the future. Yeah, and then we we discovered through participation originally in Functional Conf [26] and then later LambdaConf [27] that there is nice overlap between some of the features of APL and functional programming, so we've really been able to present APL as a pragmatic, functional array oriented language. You know it's not a not a pure functional thing, but it's it has it's much easier to explain APL and the the benefits of array oriented programming to a functional audience than it is to to other types of programmers. They pretty much you know they get what you're talking about quite quickly because it it maps nicely to some of the things they're doing, so we've been putting in function trains and more well, more functions. Maybe that's not really so much functional but Where, Interval index, At, Stencil. Things that all work nicely. Uh, we're doing functional programming. And then we've been in the last few years, it's really pleasing to see we've managed to recruit quite a few people from outside the APL community. And really help start building a modern array community. Uhm, that's really good. Some of them, you know you're already there. You're very familiar with Adám, Aaron [28], Rich, who's here, Rodrigo, who's been on and you know, Marshall Lochbaum, who was at Dyalog for a while before he moved on, essentially because he wanted to go faster than we were able to do. And the average age of the Dyalog team has come down dramatically. Uh, that's really great. And the you know we introduced the the free, personal and noncommercial license. And I don't know Bob, maybe I'll ask you to delete this before publication in a week, but we're actually trying to look now at whether we can create a license where we actually get rid of the noncommercial license, then just put a lower fee, a sort of a lower limit on the on the what is it the royalty license so that you can use a Dyalog APL you can, you can distribute it as you wish up to a certain level of revenue without contacting Dyalog for permission to do that. But we're still seeing whether the whether the lawyers can get that to work. It's interesting. This is actually coming out of deploying APL and Docker containers 'cause people are creating samples that they want to share with each other. And if you do that via Docker container, now you're in violation of our non commercial license which says you can't redistribute Dyalog APL, and obviously, that's that's a very bad thing. So we want to do something about that, and you know in general make it easier to get hold of Dyalog APL. But we can't shoot off our own feet, uhm, obviously...
00:44:46 [BT]
It it's a balancing act, isn't it, really because you're trying to promote, but at the same time, and I guess maybe this comes back to some of the open source stuff as well, you need to keep proprietary control over that part, which is the core of your company, but you also want to promote and you do promote other ways, but as you say you you've done it by some of the add-ons, making them open source.
00:45:10 [MK]
Yeah, well and making the non commercial free. I yeah. I mean maybe we should, you know wait a bit and then talk about open source. I think we still have some time. So that's sort of the history of Dyalog up to up to today. And then so where we stand today is, we've got, you know, the compared to the five people who were there 17 years ago, there's now somewhere between 20 and 25 people, depending on how you count it, where the company was owned, 75% by clients and 25% by by management back then, it's now 25% by the users and 50% by the management and 25% by the employees roughly. And and you know, although the the clients no longer own the company uhm, our emphasis is still on keeping the existing clients happy, because you know they're they're paying for what we do, and we also expect any potential new clients to go and ask the existing users what it's like to be a customer. Maybe that's a very old fashioned idea these days. People don't do that with software, but we still believe fundamentally in paying for what you use is a is a healthy way to run society. And and and that this focus on things being free is actually going to go away again, right? I mean APL is not here for years or decades. It's here for centuries. And yeah, we can talk more about that in a bit, but of course. The existing users understand that attracting new users certainly now now that they've sort of all started to reinvest, and they need to hire people. They really need us to work on attracting the next generation and making APL look like a modern, respectable tool. So they're actually happy for us to do that. I don't think they worry that we're not putting enough into the into the product compared to chasing after new users so you know our intention now is you know, ramp up the community building. Uhm, we realize we need to write much more documentation. It's sort of our Achilles heel at the moment I think is it's a the tool is much better than you can find out easily, and there's actually I mean, there's sort of a historical reason for that, which is that IBM STC and IP Sharp sold all the new APL systems and then as their mainframe business or as their businesses started to fade and Dyadic invested in this technologically superior APL interpreter, people migrated to Dyalog APL, but they all knew APL already, so Dyadic systems never really needed to train new users, they just got, they would just serve to us on a plate. And so there's this, there's this hole in in what we're doing, and you know, that's why Rich is here.
00:48:16 [RP]
Walking around trying to fill fill holes, or more accurately to yank the information out of the existing and knowledgeable people brains and put it into a form that other people can find without literally having to ask.
00:48:30 [MK]
Yeah, and some of it's actually written down. It's just written down in places that you can't find. Uh, yeah. So that you know that's that's a growing part of what we do, but then you know there's technical stuff to do as well for, so for version 19, we've just started really talking. So that's the release that will be out in in a year, uhm, there's the bridge to what I don't know. Conor, maybe you know what's the correct term for the platform previously known as .NET Core. That's at .NET 6.0.
00:49:05 [RP]
I think they're just calling it .NET. Yeah, it's just the versions.
00:49:08 [MK]
And and so we have a a bridge for the framework. But now we need to sort of rebuild the equivalent for the for .NET, and we think one of the things we might want to do is to add some language support for async features that have become a very big thing in in .NET in the last five years or so, I think everything has an async interface now. Uhm, we're working on revising sort of fundamentally rewriting our IO handling to better support shell scripting that we have some shell scripting in the version that's just going out now, 18.2, but you can't attach right to it to debug. And there's all sorts of things that that don't work very well with redirected IO, and that's all part of being able to use Docker containers, and in general run headless better. So we've got a bit of technological catching up to do there that that will hopefully be in the next release. We've got the 64 bit ARM systems that are now starting to become a thing, so there's the the M1 Max and the Raspberry Pi. Now I think is going 64 bit. Uhm Android, we don't quite know what to do with yet. Uhm, we're on the fence. Uhm, better understand Linux and Mac users 'cause you know we we started out on Unix and then DOS and then for two decades Windows was where all the users were and now that's changing again. Linux and Mac, or certainly Linux are becoming much, much more important, and are the future I think. And we have a lot of learning and and we have work on keyboards and fonts because Linux users don't seem particularly happy with how we handle that. Maybe that's a more general problem. And let's see what else. Well, more of more of the open source APL tools and packages we really want to open that up wide now and push as much out as we can. And I'm also thinking that some of the interface layers that we have that are written in C, like the wrapper we have for the chromium embedded framework. We might want to open source that so that it's easier for people to contribute to the parts of the system that are moving the fastest, and where people might want to port to another platform, and that's hard for us to do. Yeah, I know we talked about this further simplification of the licensing. I hope that that happens now in 18.2, but it it may be next next release. So that that's the next release and then longer term we we have some uh, sort of bigger things we're working on. We've been struggling for probably a decade to understand how we can work 64 bit integers into our numeric, the 64 bit integers are currently voodoo because they have higher precision than than double precision floating point. So if you do, if you round off by saying floor 0.5 + X. You go to uh, yeah, you might have an integer with more than 53 bits and then it goes to double land and when it comes back it could be way you know somewhere else in the universe and we have some ideas for how we will introduce, we think, multiple numeric towers, so each array is tagged with whether it's in the fast tower we call it, which is the binary one that we have now, or the decimal tower, which will include 64 bit integers and our quadruple precision decimal Floating Points. And then the third tower only actually having one type in it, which is a rational numbers for it. So we have the infinite precision as well. We think we have some ideas for how we can get those to interact in a way that APL programmers will find reasonably easy to understand, but uh, that that's more of a a long term research project at two or three years out at least. Uhm, there's the literal array notation, which Adám has done presentations on, and I think exists in, I don't know, there are models of it, I don't know if it's in BQN or dzaima/APL that there are models of it in some APL systems or array language systems, we want to get that into into Dyalog APL soon. And then there's you know, the the defects and the missing features that, uh, that are being experimented with in BQN. For example, you know we know that we need more inserts and folds. We need to figure out exactly what to do.
00:54:09 [CH]
What was the last thing you said inserts and folds?
00:54:11 [MK]
Inserts and folds right? I mean the reductions that we have in regular APL are lacking. You've talked about that a couple of times, I think, Conor.
00:54:21 [CH]
I have?
00:54:22 [RP]
J somewhat recently introduced a few more types of fold. And people who come from the functional land they know about foldl foldr and blah blah blah. But Dyalog has fold which does the one type of fold. But also it's slightly weird because of the right to left, but Iverson had his reasons back then. But now the functional people come over and go "It's called fold, but it's not the same as pascal's fold and it's making me confused and angry".
00:54:52 [MK]
Yeah, and you know J has some of them. Might be BQN has has others, uh, I mean, the whole sort of prefix thinking uhm, that I'm not an expert in. You'll get much more mileage talking to Adám and and Rich, but it's you know there there is stuff there that's missing and and there's, you know, things like the slash the the schizophrenic slashes in in Dyalog APL, which I'm sure you're familiar Conor, with Conor if you've been trying to write trains in Dyalog APL.
00:55:25 [CH]
Yeah, I'm actually not sure what my number one APL, Dyalog APL request would it be? Would it be somehow fixing that so it's unambiguous, which for the listener that's not keeping up: you, depending on how you use like the back slash is not only a reduction, it's also compress or or filter, and it can be, it can be ambiguous, and so at times you need to add a couple extra Unicode characters to disambiguate, so that's that's one thing. And there's also that BQN uses the logical AND and OR as in the Monadic case for sort. I'm actually not sure which one.
00:56:07 [MK]
Right, the sort, yeah.
00:56:08 [CH]
If I could only choose one, which one would I want more? It's a good question, I don't know. I I would ask. I would ask Santa for both.
00:56:17 [MK]
Watching the ArrayCasts is for me very valuable. I'll probably learn something even when I listen to my own episode. So, so I mean, we you know that we are aware of those, those defects and you know we we can't move as fast as as the other guys you know? J preceded us by a decade or two. BQN is experimenting and it's wonderful to have something like BQN to observe where you can see, well, you know what can you do if you don't have the backwards compatibility requirement, what could you do and does it work? And then you know we can come along and you know the the in the commercial juggernauts sweep up the the good ideas.
00:57:04 [CH]
Still, there's still a lot of things that that you know I pick and choose now when I solve little programming problems. If it's whether it's Perl Weekly Challenge or LeetCode, I will choose the language J, APL, or BQN based on because none of them have like a superset, so APL, Dyalog APL still has the decode and encode and also has GCD, which BQN doesn't have. So like if my problem if my solution requires GCD while I'm going straight to Dyalog APL because...
00:57:33 [MK]
Well, you're in a very envious position that you don't actually have to write code for in these in these languages for a living, but I mean, well, you know where we want to be is that in in three years? Four years? I can't say how long it will be. You would pick Dyalog APL every time.
00:57:54 [CH]
Yeah, that'd be awesome.
00:57:55 [BT]
Morten, talking about supporting for, you know, the companies that you know, use Dyalog APL. Has there been any thought about, say, freezing a version and then doing exploration past that for a different version? I guess that means you end up having to support 2 versions. That's not what you want to do is that right?
00:58:16 [MK]
No, I mean John Scholes, did, we, we did put out, John Scholes put out a version once that he did it deliberately based on a, I don't know, 3 version old out of support version of Dyalog APL where he experimented with closures, and functions returning functions and stuff like that. Uhm, I have this dream which I don't know whether is realistic. I mean we have. I don't know if you've looked at our implementation of futures and isolates, but basically in Dyalog APL an isolate is a namespace, which appears to be in your workspace, but if you dot into it and do anything that's actually processed in another process, and you immediately get a future back as a placeholder and you can pass that around as an argument to other functions. Or, you know, making close the race with hundreds of different futures and as long as the interpreter doesn't need to know the actual value of the future, you can do what you want and then when you eventually say well, display it or add one to it or something, then the interpreter just blocks. And I think that there's an experimental version of J that Henry Rich was was involved in, which has something very similar. I mean, the implementation is completely different, but the ideas are are similar. What I'm hoping we might do is set up a system where you can have multiple versions of Dyalog APL that are connected together in this fashion, so you might have actually several versions of Dyalog APL, possibly incompatible, all appearing available to you at once. And and that would allow us to experiment in a way where users can, you know, they can keep their legacy code or running in the old interpreter. But it's terribly dangerous as soon as you, as soon as you announce a new version of something. The users get scared, confused, bewildered. They stop doing things until they understand where you're going. I mean, we have the one, let me see what what else have I got on my To Do List before I I get into that discussion? So, I mean, there's no, no, you know more of the same. And we've got the Co-Dfns compiler, of course, which Aaron has been working on as a research project, and hopefully we can bring that in. And again, this namespace connectivity might be exactly the way we hook that in. In fact, the way Co-Dfns compiler currently integrates with Dyalog APL is exactly the same sort of you you'd give it a namespace and it compiles the namespace and you end up with something that looks identical to the APL user as what you had before. But now the functions are being executed by by Co-Dfns, so that it could, the namespace idea, which has been in Dyalog APL for for a very long time has proven itself to be adaptable to GUI, object oriented programming, etc. It's really perhaps the main reason why Dyalog APL is here today is the existence of of namespaces. Uhm, but anyway, one one of the things I have in my notes is this section titled "Avoid being seduced by shiny things". Because you know, you don't want to end up like IP, IP Sharp Associates who who, I mean, it's a sad story, right? The APL users were all happily doing personal computing on the mainframe. They were not, they didn't feel that the name the mainframe had any problems, right? It cost, yeah, but it, backups were taken, it just it always worked and then along comes the PC and everybody else is going wild: oh wow, you know now I have my own computing environment! I can I can do whatever I want! and the APL programmers are going, "Yeah, well, so what? You know, I'm already doing everything I want, what's the point?". And as a result, the APL community completely missed the significance of the PC. And suddenly, you know, a guy came along with the car, took their IBM 3270 terminal and wheeled it off and they just sat there going what? And so so you know you want to be aware of what's going on around you so you don't end up there, but you also have to be careful not to move too fast, right? So if you go back to the early the early 2000s, our main competitor APL, what are what they called at the time APL 2000 [29]. Hm, they they were told by the US government and so on that if they weren't running entirely managed code in a small number of years, they'd be out of business. So they immediately created a second APL interpreter, competing with their existing one, which was a based on the .NET CLR. So they had two competing aPL interpreters and massive confusion, and they diluted their efforts, and in the end, none of the customers switched to the .NET version. And the old one prevailed, but was now, you know, had lost five years relative to Dyalog, who had just pushed on with with the version they had. So you know that's a meme there before that. Actually, when when Windows went 32 bit. STC, I think they were called at the time, they put out a 32 bit version of APL+, based on something Microsoft produced called Win 32 S, which was a little thing you could add into your Windows system that gave you a preview of the, of the windows system, the coming 32 bit Windows and and in Europe all the big banks and insurance companies, the users of APL had gone for OS2. And purely by accident, Dyalog APL worked in the OS2 16 bit Windows compatibility box and APL+ did because it was built on on this new technology. And I mean, there's so many things like that that make me sort of a bit conservative about chasing quickly after after new technologies. If you want to be around for a long time, it's better to occasionally appear a little bit a little bit slow, particularly because you have a a user community. You are a luddite, essentially. I mean it's a little bit, uh, and the probably the listeners of of this podcast, and a lot of the new people attracted to APL are actually very much up on functional programming and and all the new things that are happening in in software engineering. But the people who have had the most benefit from APL through the ages and to pay most of our bills are people who are every kind of engineer other than a software engineer, and they are not interested in rewriting their code unless it's because there's new tax legislation, where they have to rewrite their insurance policy computations, because it's a legal requirement and they'll do that in half an hour. But if they have to rewrite it because now there's some new GUI widget library... Yeah, it really yeah doesn't turn them on. But anyway, so that was maybe a bit of a, uh rabbit hole there. I mean, there's there's so many examples of APL vendors chasing after things that turned out to be very expensive. There was a very, very good APL product called Micro APL [30], which was cross platform, you know, on the Mac, on Linux, on Windows, and they bet the farm on a particular cross platform GUI library that disappeared.
01:06:14 [CH]
That's too bad.
01:06:15 [MK]
And they just, they just gave up. It was like it was such a big I don't know the J people have been doing QT for a while and I've been going here well, is QT gonna survive and so on. And maybe I called that one wrong. Maybe QT looks like it's quite strong. Actually, it might, might last forever, maybe. Maybe we should look at QT. Should we look at Windows Assembly, yeah, web assembly.
01:06:43 [CH]
I was just going to say I'll add that the Micro APL documentation is the best APL documentation.
01:06:49 [MK]
It is superb, yeah.
01:06:50 [CH]
Only because it's so simple like Dyalog's is great, but like a lot of the times, if I know it's like an, an OG, you know, aPL symbol, i'll just go and try, it's very hard to track down, but if you if you search Micro APL reduce that will always get you to the Micro APL website.
01:07:07 [MK]
And Rich's as far as I know we we have permission from Richard Nabavi and the Micro APL team to use their documentation as we please.
01:07:17 [RP]
Is that so?
01:07:18 [MK]
So you don't, yeah, remember that! I'll write to Richard and ask him to be sure, but I'm pretty sure, you know, they gave, they essentially gave Micro APL to us to host, so that anybody who was still who still wanted it could download it, and it's somewhere on our website. Anyway, I think we're we're, uh, I've. I've been talking enough. I mean, I have I have some notes here on interesting discussions like free and open source and backwards compatibility. And is APL notation or a programming language? And and maybe we should, we should return to those later, unless there's one that you would really like to pick off now. I think we have what 10 minutes left or something like that.
01:08:04 [CH]
Yeah, we've just got over. I'd say yeah, 5 to 10 minutes left. I would probably say let's let's hang on to all those topics and you know we'll definitely have you on in a future episode. But in the last few minutes here, maybe we open up the questions. This is a one that has, uh, hopefully a short answer. You can just say yes, no or maybe. You mentioned GitHub at one point and one of the nice things, to bring up SmallTalk again, was SmallTalk was a similar language in many respects and that they have the workspace images and it's hard to adopt that model to GitHub where you're just storing everything in source files, 'cause that's not how SmallTalk and APL work. They did come up with in their latest Pharo editor, a sort of file format that you can very easily integrate and just, say, you know, choose GitLab, GitHub, Bitbucket and puff, it'll you know you give it a repo, it shows up. Is that something that would ever be possible, like I know, tart tartan or tartan.
01:09:05 [RP]
In 18.2 coming out soon, there's an experimental user command. And that's a bit overpowered in some sense, as it's called "]get" and and it's ostensibly because you know there's lots of ways to bring different types of either APL source code or data into the workspace, and you need to know which magic incantation is for which, whereas ]get is a kind of wrapper which tries its best to figure out that for you, but it also has really nice feature, which I'm hoping will allow people to share code quite nicely. You can point it at a GitHub repository or a hosted URL of a workspace or even a zipped folder, a zip file that contains a linkable a set of APL text source and it will pull that off the Internet, unzip it for you and bring it into your workspace.
01:09:57 [CH]
Does it do the reverse of being able to push to a GitHub repo.
01:10:02 [RP]
No, sorry so no. So the two things I know that, well, no: one I know definitely does that is Carlysle Group's dADO, Dyalog development operations thing, has Git integration, but also its packages are entirely like a package is a thing on GitHub is how it's defined, it...
01:10:22 [MK]
Yeah, but I I think I think though Conor is looking, Conor is looking for something where the what's put up on GitHub is text right? So that it diffs nicely?
01:10:34 [RP]
No, that yeah get can do that.
01:10:36 [MK]
So but but I'm so at the moment our our model is that each function or each namespace maybe becomes a single text file we we're not thinking that people really want to write the entire workspace. I mean we have users who have 100 megabytes of source code that they might load into the workspace, and having that as a single text file is probably not very, yeah... Is that what you were you were asking, Conor?
01:11:06 [CH]
Well, no, yeah, so it does it does sound like it's on the horizon though, that that Dyalog is thinking about it.
01:11:11 [MK]
Yeah, I mean, have you, have you looked at this this tool we have called Link [31] which is the, our current best shot at at loading text into a workspace and then if you ever edit a function the the text file gets updated immediately and you have a nice folder full of files that you can easily manage on Git.
01:11:31 [CH]
So I've seen the I saw the Dyalog 2021 presentation on it, but I have not played around with it yet, so.
01:11:39 [MK]
Right, yeah, so yeah, have a look at that and tell me whether you you know what what's missing from that.
01:11:43 [CH]
Do we have any final questions from Bob, Richard, Stephen, or should we just throw back to...
01:11:48 [BT]
Morten, I think it's been fascinating to hear the history and the background 'cause it it gives me a lot more depth into some of the challenges that you see you're adapting to like having the antenna out for things that are changing without having to jump in that direction makes perfect sense to me, but it's it's a really difficult balancing act and it's it, it's really hard.
01:12:07 [MK]
And and also as an APL vendor because you have these non technical users a lot, they're actually looking for you to be the Oracle who decides. You know, they're not going to look at a new technology until we make a Quad-something that that maps to it, but until then, they're going to ignore it, and so they're relying on Dyalog to come along and say when it's time to to learn something new, but I mean it's it's uh, I'm so grateful, right that I've been able to essentially get paid to do my my hobby for more than, you know, I've been, I've been doing happy array programming for 45 years. Uh, I did a Socket Functional Conf about APL and sort of a little bit about myself, and then the coffee break, this guy comes up to me and he says "Are you telling me you've been using the same programming language for more than 35 years and you're still smiling like that?" Was that you know, completely unthinkable? And and and and one of the things I'm really happy with in the time of Dyalog is that we've been able to bring together so many of the people who historically were forced by their corporations to be enemies, right? So the the Jim Brown at at IBM and Eric Iverson, Ken Iverson, Roger, these people who were at war and, and we've been actually able to work with all of them in the last 15 years, and and and really make use of a lot of the ideas that have been generated. Try and bring them together in the same place. And that we managed to get across what I think historically has been a very technologically challenging period from the beginning of GUI until today, where things are sort of starting to settle down, although JavaScript frameworks are still mutating faster than viruses, but you know I'm also really hoping that that one day I'll be able to sit in my rocking chair and and say that I helped, or at least did not hinder the beginning of careers of the people who will be the great array language implementers of the future. And that's not just the people who were at Dyalog today, but you know, Nick Nikolov [32] was at Dyalog before he did ngn/APL and and Marshall worked for us for a while before he he needed to move faster and and it's perhaps a very strange thing to bring up, but I'd like to mention it, even though this is a technical podcast, I'm really hoping that the new generation of APL implementers will also have more gender diversity 'cause at Dyalog, well, I think we're we're we're developing reasonable cultural diversity, but at the moment it's still, you know, the the girls run the company and the boys tinker with code. And of course, I'm dating myself by only having two categories there, but I really hope it'll you know, become much more inclusive and we'll see more kinds of people working with APL in the future in general.
01:15:09 [CH]
Yeah, I can completely agree with that. It's a problem that C++ also has. I think a lot of programming languages have, yeah, IP Sharp, apparently you know they they got it right and then something happened along the way.
01:15:23 [MK]
Yeah, so even at IP Sharp the women quickly migrate towards they migrate towards management much faster than the boys. And and you know rightly so, they're better at it, but no, it seems, yeah, sorry. It seems to me that that that women demand that there's somehow more meaningful content in what you're doing, whereas the guys are happier to go and chase, you know, the wheels of cars that run past and stuff like that, but hopefully that's I think it's changing. I mean that is changing, I believe it is and...
01:16:04 [CH]
Yeah, on that note, so that's a call to action to if you, uh, if you want to write your own programming language, the CTO of Dyalog Ltd. just said, you know, please go ahead.
01:16:17 [MK]
Oh, or if you would like to be a language implementer and you're not one of the boys, give me a call. OK, 'cause we will be hiring soon. [33]
01:16:25 [CH]
Oh yeah, we'll put links in the in the show notes for not just that, but for everything that we've said in this podcast, but yeah, I guess we did... Our ArrayCast's at contact, contact at ArrayCast dot com at the beginning, so we don't need to say that. So yeah, we'll just say, once again, thank you so much Morten for coming on as, as always with many of our guests. Or all of our guests, I should say, you know, we'll we'll definitely want to have you back in the future and that list of topics you mentioned is, i'm sure it could fill not just one but a number of podcasts, so we'll we'll definitely have to have you back on and thank you both to you and get on everyone at Dyalog Ltd. I think I've said this before on past podcasts, but you know, I would have never discovered these languages if it hadn't been for Dyalog APL and you know, continuing to carry the torch and setting up, you know the website tryapl.org. It is greatly enhanced my love of you know programming and programming languages, having discovered APL and I don't think it would have happened if it hadn't have been for for your company. So thank you so much.
01:17:27 [MK]
Yeah, thank you. That makes it all worthwhile.
01:17:29 [CH]
And with that, I guess we'll say happy array programming.
01:17:32 [All]
Happy array programming.