Algorithms + Data Structures = Programs - Episode 49: Special Guest Dave Abrahams! (Part 2)

Episode Date: October 29, 2021

In this episode, Bryce and Conor interview Dave Abrahams about how he went from programming BASIC to APL to C++!About the Guest:Dave Abrahams is a contributor to the C++ standard, a founding contributor of the Boost C++ Libraries project and of the BoostCon/C++Now conference, and was a principal designer of the Swift programming language. He recently spent seven years at Apple, culminating in the creation of the declarative SwiftUI framework, worked at Google on Swift for TensorFlow, and is now a principal scientist at Adobe, where he and Sean Parent are rebooting the Software Technology Lab.Date Recorded: 2021-10-03Date Released: 2021-10-29ADSP Episode 48: Special Guest Dave Abrahams!Algorithms + Data Structures = ProgramsNiklaus WirthCombinatory LogicStepanov’s “Notes on Higher Order Programming in Scheme”PDP-8BASIC Computer Games by David AhlRutgers UniversityPDP-10TECOAPLPrinceton UniversityAaron Hsu’s Co-dfns GPU CompilerSwift Programming LanguageConor’s Galaxy Brain Programming LanguagesBen Deane’s Six languages worth knowingLisp MachineEmacsComposer’s MosaicTHINK CException handling: a false sense of security - Tom GargillIntro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0Free Download / Stream: http://bit.ly/l-miss-youMusic promoted by Audio Library https://youtu.be/iYYxnasvfx8

I was so hungry to keep programming in APL that when I went to the engineering building and discovered it to be locked, I saw that I could just stick a twig in the door and essentially unlock it and break my way in. Welcome to ADSB The Podcast, episode 49, recorded on October 3rd, 2021. My name is Connor, and today with my co-host, Price, we continue part two of our interview with Dave Abrahams, which covers topics including BASIC, APL, C++, and so much more. If you haven't seen part one, check out episode 48, which was part one of this two-part interview. Can I ask you a question?

I just realized I don't know what ADSP stands for. And so I don't know what audience we're talking to and what this podcast is about. ADSP stands for Algorithms Plus Data Structures Equals Programs, stolen from the Nicholas Wirth book. Beautiful. I'm not actually sure if we've ever described why we chose that one. You mean the real reason or the other reason?

There's two reasons? I don't even know. What are the two reasons that you know? The pragmatic reason is that when you have algorithms and data structures in your podcast title, it means that it's pretty good SEO, search engine optimization, but there's other reasons.

Oh, right. Is it the unofficial one that one of our Twitter followers pointed out that someone said it's a unofficially discussion with Sean parent? Yes. Because we've had him on, we've only talked to him three times, but we always, we always, you know, squeeze as much content out. And so we turned those three recordings into like nine episodes.

But yeah, the first four episodes of the show were us talking about our favorite algorithms and data structures. And it's, it's mostly an open-ended, sometimes we bring guests on to hear about their stories and experience. And sometimes we're just randomly, you know, right before you joined, I had been wanting to explain my love that is developing for combinatory logic and combinators, which are these little, you know, composition patterns that a few of them exist in Haskell and a lot of them exist in APL, which is like my favorite language at the moment um that was one of my first uh languages actually all right so here I'm going to turn this interview on its head because Bryce's introduction quickly dived into uh oh do you know about this boo story and I was like Bryce I said we wanted to go back to the beginning and then we just we we skipped to like all right we can go back to whatever you want to go back but i'm so i'm um i'm super curious yeah like how did you get to the you know 1998 point where boost pro and boost con

and all that stuff started and then you i don't know if it's how many chapters has it been since then but there's the c++ chapter at sort of boost pro and i'm not even sure if that was all of your time was spent at Boost Pro there, or there was some before and after. Then you had your Swift chapter at Apple. Then that chapter sort of continued or evolved into Swift for TensorFlow at Google. And now you're at Adobe.

So there's all of that stuff. But I have no idea what happens to the point where you were starting that series of chapters if you had been doing C++. So the fact that you're mentioning APL, and that's the thing is I have started to discover that these people that are known for certain things like Stepanov, known for STL, known for C++, spent a decade in scheme preaching the beauty of LISPs and has one of his talks talks about how APL with its arrays and LISPs with its, you know, homoiconic, you know, parentheses and small talk with its object model.

Like, and he, he stole ideas, stole or borrowed ideas from all of these languages. And like, I can't, I knew, I thought I knew everything about Stepanov. And then apparently there was a whole decade of his career that he spent in Scheme and even prototyped a ton of his ideas in C++ in scheme. So yeah, let's rewind to whether it's age six when you started programming or university and then take us to share as much as you want up until the point that you were doing all the Boost Pro and Boost Con stuff. All right. Okay.

It all started at a, you're not going to believe how this dates me, at a teletype with a paper tape punch and reader on the side of it. This was a terminal on a time-sharing system at my school, my middle and high school. The time-sharing system was a PDP-8, which was about a refrigerator-sized unit with a magnetic tape drive on the front, no disks. It was so timeshared basic to a bunch of teletypes positioned throughout the school. Actually, I think there was just, there was one downstairs in the lower school and then there was, and then there was a cluster in the same room as the same room as the PDPA. And it was, the operating system was essentially basic. On the front, there were, there were actual switches for, for entering binary bits. And if you wanted to program it from the front panel, you could flip a bunch of switches and then flip another switch and that would enter that binary number into the address space.

So it was running BASIC and I was introduced to it by one of my classmates. I don't even remember who. And there were a bunch of B computer games on there. In fact, they all came, if I remember right, from a book called 101 Basic Computer Games by Dave Hall, A-H-L, which was, you know, immediately hooked. And from there, there was a 6502 breadboard prototyping system from Heath kit that the school had. And I, and I took that home and I, I figured out how to program in assembly language and, and made a tiny little, you know, car racing game on the LEDs and cause yeah, games. So that was the, that was the start. This is all in high school or? Middle school is junior high. And yeah, my dad was a physicist at Rutgers. And when he saw how interested I was, he mentioned that they have PDP-10 at his lab, which was where they were doing bubble chamber research. So bubble chambers are essentially a thing in which they track particle trails after collisions. And maybe I want to check that out.

And so I went there and it was this giant room. You walked inside the computer to go inside the room. And there were a couple of hard disks the size of washing machines and lots of core memory uh you know the little magnets little uh toroidal magnets on the wires and uh and they had they had a much faster paper tape punch and reader they had uh they had a line printer which made a lot of noise a line printer chugs out it it basically sets chooses on let's see there's like 128 columns each of which has a cylinder that has all of the possible characters on it and and so each line it prints it rotates the the cylinders

to the right position and then it slams them against the paper. So that was a print a whole line at once. That's called a line printer. Makes a lot of noise. And the PDP-10 manual that I got a hold of had descriptions of several languages that they had. Obscure things like Tico, and that I think was a text editing language, but also Algol, uh, which I, I tried to learn, uh, never actually got anywhere with that. A more sophisticated version of basic that, that lab also had a, a Tektronix terminal in it on which you could play a game with,

you know, where asteroids attack your spaceship and you try and shoot them down. And that was unlike anything, you know, a few years later and you're trying to shoot them down and that was unlike anything you know a few years later you would see that stuff in the arcade but it was unlike anything i had ever seen at at that point yeah so so that was pretty exciting but it required you know a 45 minute commute with my dad into into work uh, uh, to, to do anything. And let's see, my, my mother was, uh, was a choreographer at Princeton teaching dance. And so I, I found out how I could get access to computers through her. And, uh, I got, I got some account, uh, on the Princeton university systems, which is where I discovered APL.

Was that a shorter commute? Is that why? Yeah. Sorry. I lived in Princeton. Okay. Yeah. Thanks, dad. But mom's university is closer. Yeah. Yeah. But although I think that I wasn't supposed to be using a lot of that equipment and nobody was paying much attention to where I was going, but you know, I was just a teenager, no affiliation with the university.

And at some point I was, I was so hungry to keep programming an APL that, that when I went to the engineering building and discovered it to be locked, I, you know, I saw that I could just stick a twig in the door and essentially unlock it, break my way in and go use the computers. This is amazing. This is, oh my goodness. It's APL is so addictive. You hear that?

Dave Abraham's is a creator of Swift. We're talking about here. Well, not creator. One of the main key contributors responsible for the standard library of Swift. Uh, it was in love with APL. All right, wait, this is keep it going. This is, this is amazing. Yeah. So, I mean, APL appealed in part because I, you know, I would watch my dad do his work. He was a theoretical physicist. So when I watch him do his work, what he's writing down on the,

on the paper, these, all of these mysterious and magical symbols that had some kind of deep meaning about the universe. And APL is a lot like that. It's full of these Tektronix terminals where you could use APL to make graphics and APL having matrix multiplies, you know, matrix transformation built in and lots of array support for like long lists of points and things. It really lent itself well to this kind of work kind of work so i played around with that stuff i was really interested in in 3d and sort of figured out that i could that by making an angular map of the world i could actually create perspective in 2d so it's for the kinds of

things i was playing with were you just all like it sounds like you were just sneaking in and and self-teaching like did you have like an apl manual or like how would you like because it's not a simple thing to just oh i've i've seen into the meaning of this unicode symbol now i know what it means uh oh this is before unicode my man uh yeah there was no unicode back then it It was just, you know, the, you needed an APL terminal. It had APL symbols printed on the, on the keys and, and could display them. But yeah, I got my, the Princeton University bookstore was an amazing place. We would go to the U store. We called it all the time for, for various things. I, I was into like drafting and all kinds of,

all kinds of stuff I could, I could get exposed to there and they had the APL manual there. So that's how I got it. That is amazing. And is that the last time that you programmed an APL? Have you ever used APL more recently? I have not. I remember, you know, maybe two of the symbols, maybe, and what they did, but I remember the principle. I mean, there is this, if I remember right, this is where I learned about lazy evaluation. I think APL does a whole bunch of matrix stuff lazily, so you don't end up spending a lot of cycles on elements you're not going to actually observe yeah it's uh this this further adds to my confusion on how at some point people haven't taken apl and just made a gpu version i guess technically there's been a little bit of research by an individual by named aaron shu's made a GPU APL compiler, but like, I haven't

actually heard that APL was used for graphic stuff. Like it makes complete sense. Cause yeah, of all the matrix operations and whatnot, but it seems like the, the stepping stone into GPU land, but I, I guess by the time GPU showed up in the whatever nineties that APL had already started its decline. So maybe, maybe that has something to do with it. Yeah. You know, I think the very thing that, that attracted me so much is also part of the reason that people aren't pursuing it. It's the stuff that's probably of lasting value in APL are the semantic bits and the syntax is, you impossible to remember and and can be hard to read and you know so that's why i don't remember it anymore right but but yeah the the semantics

of the operations were pretty interesting you could encode all of those in something that was easier for people you know lay people to read and and that might be an interesting system right yeah all right so where did you you went you were caught connor's only slightly distraught because connor thinks apl is the most beautiful thing in the world well no so well i it's gorgeous i i want to uh i continue on the on the journey of of dave's history but in the back of my head there's a whole other conversation of you know it's like it's hard to read you know, and this, this topic has come up in multiple different, you know, podcasts, conversations, slash whatever, just chatting on zoom is, you know, readability,

like what is really readability, like readability is informed by one's experience, someone who speaks Chinese and has read Chinese growing up, like Chinese is readable to them, because that's what they learned. But to a Westerner that does not speak or read Chinese, it seems overwhelming. You have to memorize 4,000 logograms and it's not combining just a set of, you know, alphanumeric or I shouldn't say alphanumeric, just alphabetical characters. And so you have to find a way to like objectively remove experience. And then how do you answer the question of what truly is more expressive or more readable than, than one thing, just because 99% of all programming languages, you sort of use English or, you know, keywords and whatnot. Does that truly make APL less readable or is it just more unfamiliar than everything that people

are used to? And I don't even have the answer to that question. I just think it's a very interesting question. Yeah. I'm not saying that I'm not even sure that I said it's not readable. I don't think it's, I don't think it makes a great communication medium for a large audience because it is a challenge to learn and not many people have learned it, but you know, you also, when the imperatives get strong enough, people will learn all kinds of things. Right. Right.

And, you know, for example, Chinese, you know, very objectively computationally difficult. But if it's what, you know, you're brought up in and what you need to survive, then of course you will learn it right and i think one of the the main roles of of programming in the modern age is as it's about

communicating to people and you know i think communicating stuff to the to the computer is is fine but syntactic sugar sugar actually counts. Right. No, no. Well, there's a whole, there's a whole, I went on CPP chat one time and the title of the episode was, I really like sugar because at some point, you know, I'd heard, oh, lambdas are just sugar, you know, structure bindings are just sugar, but I never really understood that because it's sort of like saying like that, that's a bad thing, but like one, most people really enjoy sugar. And two, I think it's, it's sort of, it misses the point, like something that is more expressive or easier to digest. Like lambdas have completely changed the way that people can understand and read generic algorithms because you don't have to, Oh, there's

a function object that's been defined somewhere else. Like you can just, it's, it's there, you see the customization and it is then more readable. It's it's yes, sure. It is just sugar for a function object, but yeah, I completely agree that something that is syntactically more expressible than an equivalent thing that sure. It's just sugar. It, it changes the program, not semantically, but definitely from a readability perspective. Yeah, sure. I mean, or, you know, if you, all you care about is is the semantics we could all program in assembly language and be just as happy right but we don't so that official statement from dave abrams we should have this uh program in assembly if we only care about semantics

yeah if we don't care about syntax sugar i mean that's like all programming languages are syntax sugar, right? And at some level. And if there was a huge community of people that already understood how to read APL, I think the imperatives would be very different and maybe more research into using APL on things would happen. And some people argue, sometimes it's me, that there is like an order, two orders of magnitude in your ability to think and solve problems due to having like what, you know, Iverson originally wasn't called APL. It was called Iverson notation. And his Turing Award paper, which listeners of this, the listener of this podcast is a notation as a tool of thought. He never really wanted it to be a programming language.

It was a language, a notation for expressing algorithms. And at some point someone realized they were just like, we could probably implement the IBM 360 in this. And they were like, oh, okay, let's give it a spin. And yeah, I think it's worth learning just for the ability to be able to solve a problem differently. But yeah, we'll put a pin in this because we need, or sorry, go ahead.

And then we'll get back to what happened after APL. Was it small talk was the next chapter, but sorry. Yeah, go ahead. Yeah. Well, okay. I want to endorse your position. I mean, I, I think APL is totally worth learning. It's, it's great to have, uh, you know, new perspectives on programming. I think the operator composition that they do in APL is really, really interesting and, and expressive. And, and I also want to say I was, I was in C++ deeply for such a long time and, and the just doing Swift changed my perspective on programming language design and the trade-offs and everything so much that, uh, that I, I think it's, it's really super valuable to immerse yourself in, in something truly different than what you're used to. So if you haven't tried APL, it's worth a shot.

Yeah. There's a, I'm not even sure the quote pertains to programming languages, but I saw a quote once that was, you don't really understand fully a language until and you know, C plus plus, like don't go learn Java, like go learn prologue or APL or Lisp or something that's in a completely different paradigm. Cause Java, you'll learn a couple of things, but for the most part, it's, it's got a lot of the core that's the same, but if you go learn, you know, prologue or small talk or something, it's going to bend the way that you think about the programming world. Yep. Okay. Yeah. So let's APL chapter APL chapter has ended at Princeton. Uh, and then, and then, and then what happened next? Yeah. So, uh, so I went off to college and college. Well, I, I was, I was interested in a lot of different things and, and, uh, I remember, I remember asking, uh, all of the, all of the people that came around to hype their schools, whether that kind of studying lots of different areas was going to be supported. And I remember when I asked the Carnegie Mellon person

about this, they said, well, we don't encourage dilettantism. And so that school was crossed off my list but the but the the woman who came to talk about pen was really excited when i asked this and and so you know and when i got in and visited the campus it just felt it felt like home so so that's where i ended up going. And I wasn't really sure what I wanted to focus on, but I enrolled in computer science to was using. So another big mainframe with lots of terminals and yeah, let's see other programming languages during that time, I guess I was exposed to Lisp. There was actually a Lisp machine there, which was a pretty interesting thing. And I think this is probably also around the time when I picked up Emacs, which has a whole backend in Lisp and has stuck with my muscle memory ever since. So that's still how I, how I do a lot of things on a computer. Emacs. All right. So we don't need to ask that question or start any. Yeah. Emacs

are good. Yeah. Yeah. That's just, uh, you know, what already works for me. So that's what I do. After, after college, I wasn't really sure what I wanted to do, but got a, got accepted to Carnegie Mellon graduate program in computer science, spent a year there where I found myself spending at least as much time working on music and, and playing music as I did on computer science, decided I wanted to go to Berkeley College of Music, which is Berkeley with the two E's in Boston, went to Boston, spent a semester at Berkeley, realized I was really done with school. And at that point I needed to get a job. And so I got my first real professional job, which was doing computer music software for a company called Mark of the Unicorn, which they had a program called Composer and they wanted to, they wanted to improve it. I guess the person that had been working on it had

left. Maybe, maybe that was Robin. She had the, I think she left to go to Adobe strangely enough. And, you know, I, I was, I looked at it and I thought, you know, this seems a little bit clunky. Maybe I can do better. They, they had a mentor for me there who had built a really successful product. And so they said, okay, go and do that with this guy because I had never done any real professional programming before. And of course, this guy quit once he met me. Now he quit shortly thereafter. So I was basically, I was basically, you know, on my own learning how to, to write software, learning how to write a Mac application, um, with the responsibility of writing this entire application, uh, on my shoulders. What language is this in at the time?

What language was I, I think to start with, I only had C yeah, I only had C and at some point in my first year, I discovered I was reading bite magazine and there was this, this thing you could download that was essentially a little small talk. And so small talk does come into the picture. Yeah, I guess so. It wasn't actually Smalltalk. It was a tiny object-oriented language. You know, basically dynamic dispatch, you know, was the key thing.

So you had methods and you had dynamic dispatch. And something clicked with me where I thought, oh, this is how user interfaces should be built. And so I built an object-oriented programming system on top of C using horrible macros and conventions and whatnot. And so that was the back end was the backend of my product, which was eventually called Composer's Mosaic. So that was that job. I went on from that to do all kinds of other interesting things in computer music in that job and spent 11 years there, which I have to say, I've said this before. It was a hugely, it was a huge growth experience for me to spend that much time with my own code and having to, having to live with my own mistakes because you really learn what is going to work in the things I noticed, especially once, you know, the internet started to heat up and everything was a lot of people were taking jobs and working there for a year

and handing their coat off to somebody else and, and leaving. And I, I thought those people are missing out. Is there, well, advice or like, what is the, what are some of the key things that you took away that you think people are missing out from not spending that amount of time? Uh, or that is only sort of lessons you can learn, or maybe they're not things that you can be captured in a podcast bite and it's stuff you have to actually just experience. Uh, well, you know, I think, I think a lot of it could have been, I, a lot of pain I could have not gone through if I'd had somebody to mentor me at that time who knew more of these things. behavior of things, right? Getting it right is about that. And, you know, just how much to not let yourself get away with in terms of, you know, oh, it seems to work and, you know, what kinds of reinforcements to build in.

I went through a long phase around this time when I would explicitly write out asserts and about all my preconditions and insert invariants all over the place, like I was implementing contract programming in my software. And I learned a lot from that. It got to the point, you know, eventually, if you do that enough, you get to the point where you, you can see logically that your software is correct and you don't need these kinds of reinforcements. But, but that was a, that was a huge learning experience for me. Another interesting thing was just about some of the trade-offs that I made in my initial designs. My initial design for this notation software was designed around conserving every byte because memory was really constrained at that time. You know, you get a 128K Mac on your desktop.

This is what people were doing this work with. And so I developed this really compact encoding for the notation. But then what I discovered in the long run was actually to be able to manipulate this notation stuff, I needed to build a much more expensive dynamic data structure on top of it with just essentially a decompressed version of it. But it was very hard ever to get rid of this underlying encoding that I had. So just being able to think about,

think about, you know, what it's going to cost you to optimize over here. That was one of the, one of the big lessons. So you, you spend 11 years, you said, uh, working on that. And then what caught, what caught, what, or slash, what's the kind of time period and what caused you to, to, you were looking for your next challenge or. Yeah. Well, so it was toward the end of my my stay there that well this is like c++ is sort of starting to come into its own so the the

language we're using next after c at mark of the unicorn was something called think c which which was essentially c with with a kind of dynamic dispatch object system on top of it kind of objective c like and uh and then c++ comes along and during this time so i i my friend next door mark waxler, showed me the interview with Alex Stepanov and Dr. Dobbs. And I was like, oh, this STL thing, I've got to get this. Because I don't think people understand, but at that time, there were no libraries. There were really no libraries. Like if you wanted to do anything, you had to write it yourself. Okay. There was Q sort, right? There was C's Q sort. There were no, there were no frameworks for, for user interfaces. There were, there were basically, so there was nothing. So, so we were

developing everything from scratch and and you know i wrote binary search wrong about 50 times okay uh did uh to skip ahead did sean give you that question upon hiring you at adobe uh to write a binary search yeah that's the one that they asked a modified binary search or did you said he was going to exempt me from it oh okay so could have been a different outcome if he had asked you to write it yeah that's true that's true you think you would have gotten it right uh that time uh probably at this point uh i i yeah i think i think if i didn't rush through it i think i wouldn't have rushed through it actually because because i still remember getting it wrong so many times yeah right um but yeah now now I believe I know how to think about

binary search. So when I saw this article on the STL, and then I discovered that the thing actually had documented requirements and guarantees, unlike any of the code that I had written, because I'm writing music software. It's't, I'm, it's not my, it's not what I'm not being paid to, to write a binary search. I'm not being paid to be good at, at sort. I'm being paid to be good, to be a, actually, you know, it's a tiny niche, but I was a world-class expert in music software. Okay. And I think this is, I think this is, is typical and, and correct that, you know, people get paid to become domain experts and, and do something they're really good at and apply that expertise. And you can't be an expert in everything. And so this is one

of the reasons, you know, I think I was so enamored when Boost came along that libraries are so important. In any case, I find this STL and it's got documented requirements and guarantees and complexity. And I'm like, what? I can actually think about when I put these two pieces together, what the overall cost is going to be. Is it going to be efficient? You know, this was amazing. This is not what anybody did. And sadly, I would say it's still not what anybody does.

Pretty much. Well, you know, maybe I think it got into the C++ culture a bit. So that's good. But I think if you look in industry, I think in general, people are not careful about documenting requirements, guarantees, and especially complexity. But this made a huge difference for me. But I looked at this and we were still working on systems without virtual memory. And so running out of memory was a real thing. And what was C++'s answer to running out of memory? It was to throw an exception. And at the time when I got the STL, the language that came with it said, the documentation said, if an exception is thrown inside of any of this, if you throw an exception while sorting, whatever, all bets are off,

your program is going to crash. Maybe if you're lucky, right? If you're unlucky, it launches the missiles. So being in this environment where we had to deal with out of memory, I already had some idea of how to handle errors. And I looked at this and I thought, well, this is just not that hard. Just do what I always do for handling errors. Well, it turned out to be a more sophisticated thing than that, but it was basically, I thought we could solve this problem. So I actually wrote a message to Alex, found Alex's address and, and said, you know, I'm thinking I could fix this problem. And, and he said, he wrote back and said, I, I think that's great. But you should be aware that they're like already two years behind in finalizing the

standard. It was supposed to be done in 96 or 95 or something like that. And, and, you know, you're going to have a hard sell to make any changes at this point. And, but, but he said, here, let me put you in touch with, I think it was Greg Colvin that he put me in touch with, possibly. He either put me in touch with him or Andy Koenig. And at some point I got onto what they called the reflectors. Is the committee still using reflectors? We still call them that. And it's probably still hosted in the same place.

Yeah. Okay. Yeah. Mailman? Yep. All right. Yeah. Okay. Yeah. Mailman. Yep. All right. Cool. So I got on the reflectors and started talking about this on the library working group. And one of the things, so I definitely heard from a lot of people, we don't have time to deal with this. We're already behind. I also heard this is well known to be an impossible problem to solve. I'm paraphrasing.

I don't know whether they actually said impossible, but it was, there was a common wisdom that exception safety was not something that we could handle. And a lot of it came from this article, the way people read this article by Tom Cargill, which was a classic at that point about why especially generics and exception safety was a difficult problem. And while Cargill didn't say it was impossible to solve, he pointed out a lot of problems. And a lot of people read this to be a demonstration that it just wasn't tractable. So actually getting exception safety into the standard is how I developed my appreciation for the consensus process, I think, in large part. At some point, so I made my arguments on the reflector. At some point, Andy Koenig said, well, that's all very well and good, but you're not going to get anything accomplished unless you

show up at a meeting. I was like, wow. Well, fortunately the next meeting was, I was in Massachusetts. It was just in New Hampshire and I got the time off work to go there. And that was, that was a really amazing experience. And, you know, I don't know that the culture has really, the stories I've heard have not been good recently about the culture and committee meetings. But at that time, one of the things I was most impressed with was how a group of such smart people with such divergent viewpoints could treat each other with such respect. And especially that I got a lot of respect, even for the things I had argued. And I tried to, you know, I realized this was not my domain. So I was not trying to like tread in heavy, but it was a really different feeling than my professional experience. I felt hugely

validated by this. And so that contrast was the beginning of the end of my work at Mark of the Unicorn because I really saw that I wanted more of what we were doing in the committee. At this point, we had to stop recording due to time constraints, but we will definitely have Dave Abrahams back on to tell the rest of his story. Until then, enjoy this three minutes of bonus content from behind the scenes. Well, I'm happy to come back. I hope it was all actually interesting and I wasn't just droning on taking up time. me are you kidding me holy smokes the internet i'm just i'm gonna be putting together a team of like people that you know we're putting a team together and the person's gonna say no i'm not interested in joining but they're still gonna unofficially be on that team of uh people that used to do apl um and you were doing it in high school like oh man that was uh you was breaking into mainframes to do it in high school.

That is such a, you, yeah, you were, you were sneaking around Princeton. Um, and, uh, Mark is not sneaking around to sneaking into and, and also, yeah, breaking, uh, breaking into that's, oh man, that's definitely going to be intro to whatever part one or part two of where it was just, I was so hungry for APL that I, I broke into the, that is just, oh my goodness. Oh my goodness. It wasn't, it wasn't much to break. I mean, you could see like that this was old style security, right? There's a gap between the doors and you can see the little hook. It's just like, oh, all I have to do is wiggle

that thing. I consider uh cutting in uh unfortunately at this point uh dave's mic cut out but uh he had this real elaborate you know he had to at one point break the window you know this is uh his mom got in trouble from the university for all the damage property um that's where apl will take you if you're not well this this almost i almost did get i did get uh yeah at one point somebody got in trouble because because i was not not broken into the engineering building but i was using a terminal i wasn't supposed to use in fact i think i was using an account I wasn't supposed to use because some graduate student had me, he wanted to build some statistical charts. So he had me program that and he let me use this, this account that I was supposed to stop using. As a high school student, you were doing work for some of the grad students at Princeton?

I guess so. I mean, it was, he didn't pay me or anything. So, you know, who knows if this was even like, you know, he was legal or not to do that. I don't even know if he was supposed to do that work or whatever. Thanks for listening. We hope you enjoyed and have a great day.