Dave Abrahams

I was I was so hungry to keep programming an APL that when I went to the engineering building and discovered it to be locked, I you know, I I s saw that I could just stick a twig in the door and and essentially unlock it and break my way in.

Conor

Welcome to ADSB the podcast episode 49, recorded on October 3rd, 2021. My name is Connor, and today with my co-host Bryce, 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.

Dave Abrahams

Can I ask you a question? I just I just realized I don't know what ADSP stands for, and so I I don't know what audience we're talking to and like what this podcast is about.

Conor

ADSP stands for algorithms plus data structures equals programs, stolen from the Nicholas Virth uh book.

Dave Abrahams

Beautiful.

Conor

Um I'm not actually sure if we've ever described why we chose that.

Bryce

Uh one you mean the real reason or the uh or the other reason?

Conor

There's two reasons. I don't even know. What are the two reasons that you know?

Bryce

The pragmatic reason is that when you have algorithms and data structures in your podcast uh title, it means that you know you're pretty it's pretty good SEO. Search search engine optimization, but there's other reasons.

Conor

Oh, right. Is it the unofficial one that one of our Twitter followers pointed out that someone said it's uh unofficially uh discussion with Sean Parent?

Bryce

Yes, that's the other acronym.

Conor

Because we've had him on we've only talked to him three times, but we always we always uh you know squeeze as much content out, and so we turn those three uh recordings into like nine episodes. Um but yeah, the the first four episodes of the show were uh us talking about our favorite algorithms and data structures. And it's it's mostly an open-ended uh 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 uh combinatory logic and combinators, which are these little you know, composition patterns that a few of them exist in a in Haskell, and a lot of them exist in APL, which is like my favorite language at the moment.

Dave Abrahams

Um that was one of my first uh languages, actually.

Conor

All right, so here I'm gonna turn this interview on its head because Bryce's introduction quickly dived into uh oh, do you know about this boost story? And I was like, Bryce, I said we wanted to go back to the beginning. And then we we just we we skipped to like well, I we can go back to what it wherever 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 continue or evolved into Swift for TensorFlow at Google, and now you're at Adobe. So there's all of that stuff, but I I have no idea what happens to the point where you were you starting that series of chapters. Um, 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 uh the beauty of Lisps and has one of his talks talks about how you know APL with its arrays and Lisp with its you know homo iconic 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 and then apparently there was a whole decade of his career that he spent in scheme, um, 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, uh and and then take us so share as much as you want up until the point that you were you know doing all the booze pro and boozcon stuff.

Dave Abrahams

All right. Uh okay, it all started uh at a you're you're not gonna 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 my school, my middle and high school. The time sharing system was a PDP eight, which was about a refrigerator-sized unit with uh with a magnetic tape drive on the front, no discs. It was so time it time shared basic to a bunch of teletypes uh positioned throughout the 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 an 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 and that would 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 basic computer games on there. In fact, they all came, if I remember right, from a book called 101 Basic Computer Games by Dave Al, A H L, which was, you know, I I wore that book out after I discovered programming. So somebody showed me how I could do a little bit of something with basic, and I was, you know, immediately hooked. And from there, there was a 6502 breadboard prototyping system from Heathkit 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 because yeah, games. So that was the that was the start. This is all in high school or middle school, middle school into high school, but yeah, but yeah, middle school. Uh middle school is junior high. And yeah, my dad was a physicist at Rutgers, and uh when he saw how interested I was, he mentioned that they have uh PDP 10 at his lab, where which was where they were doing bubble chamber research. So bubble chambers are are essentially thing in which they track particle trails after uh collisions. And maybe I want to check that out. And so I I went there and it was it was this giant room, you know, you walked inside the computer to go inside the room. And you know, there were a couple of uh couple of hard disks the size of washing machines, um, and uh lots of core memory, um, you know, the little magnets, the 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 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 the PDP 10 manual that I got a hold of had uh descriptions of several languages that they had obscure things like Tico and that that I think was a text editing language, but also LGOL, 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 Tektronics 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 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 work 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.

Conor

Was that a shorter commute?

Dave Abrahams

Is that why uh yeah, sorry, I lived in Princeton. Uh okay.

Conor

Yeah. Uh so thanks, Dad, but mom's mom's uh university is closer.

Dave Abrahams

Uh yeah, yeah, but although I think that I wasn't supposed to be using uh 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 and essentially unlock it and break my way in and go use the computers.

Conor

This is amazing. This is oh my goodness. It's APL is so addictive. You hear that? Dave Abrahams is a creator of Swift. We're talking about here. Well, not creator, you've um one of the main key contributors, uh responsible for the standard library of Swift. Uh was in love with APL. All right, wait, this is yeah, keep going. This is this is amazing.

Dave Abrahams

Yeah, so I mean uh 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 some kind of deep meaning, right, about the universe. And APL is a lot like that, right? It's full of full of little magical symbols. I guess I was still really interested in graphics and and they had a uh they had uh rooms full of these tectronics 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 this 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 sort of the kinds of things I was playing with.

Conor

Were you just all like it sounds like you were just sneaking in and self-teaching? Like, did you have like an APL manual? Or like how would you like because it's an APL is not a simple thing to just oh I've I've seen into the meaning of this Unicode symbol and now know what it means.

Dave Abrahams

Uh oh, this is before Unicode, my man. Oh yeah, there was no Unicode back then. It was just, you know, the you had 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 uh the Princeton University bookstore was an amazing place. We would go to the youth 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.

Bryce

And is that the last time that you programmed an APL? Have you ever used APL more recently?

Dave Abrahams

I have not. I remember, you know, maybe two of the symbols, maybe, and what they did, but I but I remember the principle. I mean, I there is this, if I remember right, this is where I learned about lazy evaluation. I think I think APL does a whole bunch of matrix stuff lazily, so you don't end up spending a lot of uh cycles on elements you're not gonna actually observe.

Conor

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 N named Aaron Shu, who'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 because 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 90s, that APL had already started its decline. So maybe maybe that has something to do with it.

Dave Abrahams

Um 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 know 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.

Bryce

All right, so where did you you went, you were con Connor's only slightly distraught because Connor thinks APL is the most beautiful thing in the world.

Conor

Well, no, so well, I gorgeous. I I want to uh I continue on the on the journey of of Dave's history, but uh in the back of my head, there's a whole other conversation of you know, it's like it's hard to read, but like, you know, and this this topic has come up in multiple different, you know, podcast 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 uh because that's what they learn. 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 uh you know, alphanumeric, or I shouldn't say alphanumeric, just alphabetical characters. And 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.

Dave Abrahams

Yeah, I'm not saying that that I I'm not even sure that I said it's not readable. I don't think it's uh 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 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?

Conor

No, no, yeah. Well, there's a whole uh 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 that 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 it is then more readable. It's it's yes, sure, it is just sugar for a function object, but yeah, I 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.

Dave Abrahams

Yeah, sure. I mean, or 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?

Conor

But we don't. So is that an official statement from Dave Abraham? We should harvest a uh program in assembly if we only care about semantics.

Dave Abrahams

Um 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 if there was a huge community of people that already understood how to read APL, I think the the imperatives would be very different, and maybe more research into using APL on things would would happen.

Conor

And some people argue, sometimes it's me, that there is like an order or 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 his Turing Award paper, which listeners of this the listener of this podcast is a notation as a tool of thought. It he never really wanted it to be a programming language, it was a a language, a notation for expressing algorithms.

Dave Abrahams

Yep.

Conor

And uh at some point someone realized they were just like, Oh, yeah, we could probably implement the IBM 360 in this, and they were like, Oh, okay, let's uh let's give it a spin. And and yeah, I I think it's worth learning just for the ability to be able to solve a problem differently. But yeah, that's uh we'll we'll put a pin in this because we need or or sorry, go ahead and then we'll get back to what happened after APL. Was it small talk? Was the next chapter, but uh sorry, yeah, go ahead.

Dave Abrahams

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 uh truly different than what you're used to. So if you haven't tried APL, it's worth a shot.

Conor

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 you actually know two. There's another tweet and article from Ben Dean who talks about sort of the uh seven sort of paradigms that you should, you know, if you're gonna go and learn a new language and you know C, like don't go learn Java, like go learn Prolog or APL or Lisp or something that's in a completely different paradigm because Java, you'll learn a couple 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, Prolog or Small Talk or something, it's gonna bend the way that you think about the programming world.

Dave Abrahams

Yep.

Conor

Okay, yeah. So let's APL chapter APL chapter has ended at Princeton. Uh and then and then and then what happened next?

Dave Abrahams

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 their schools, you know, whether that kind of you know studying lots of different areas was going to be supported. And I remember the uh when I asked the Carnegie Mellon person about this, they they said, well, we don't encourage dilettantism. And uh so that that school was crossed off my list, but the but the the woman who came to talk about Penn was really excited when I asked this. And and so, you know, and it when I got in and visited the campus, it just felt it felt like home. So so I 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 to start with. And they had they were they were teaching in Pascal. And so I learned Pascal for for school, and it was a UNIVAC. 1170, I believe, was the computer that everyone 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 back end 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.

Conor

Emacs. All right. So we don't need to ask the that question or start any Emacs or Vin.

Dave Abrahams

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 uh accepted to Carnegie Mellon's 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. Um and at that point I needed to get a job. And so I got my first real uh 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 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 who had built a really successful product. And so they said, okay, go and do that with this, you know, this guy, because I had never I'd never done any real professional programming before. And of course, this guy quit once he met me. No, 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.

Conor

What language is this in at the time?

Dave Abrahams

Uh 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 Byte magazine, and there was this thing you could download that was essentially a little small talk.

Conor

And so small talk does come into the picture.

Dave Abrahams

Yeah, I guess so. I I it wasn't actually small talk, it was a tiny object-oriented language. Okay. Um you know, basically dynamic dispatch, you know, was the was the key thing. So you had methods and you had dynamic dispatch. And something something clicked with me where I thought, oh, this is this is how user interfaces should be built. Um and uh so uh I built an object-oriented programming system on top of C using horrible macros and and conventions and whatnot. And so that was the that was the back end 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 uh in that job and spent 11 years there, which I have to say, I I've said this before. It was a hugely uh 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 long term and what isn't. Um, and one of the things I noticed, especially once you know the internet started to heat up and and everything, was a lot of people were taking jobs and working there for a year and handing their code off to somebody else and and leaving. And I I thought those people are missing out.

Conor

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 byte and it's it's stuff you have to actually just experience.

Dave Abrahams

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 who to mentor me at that time who knew more of these things. But I think, you know, it comes back to in some ways, I think there's nothing new under the sun to to learn about programming. Programming is about, you know, creating a solid foundation in which you can locally reason about the behavior of things, right? Getting getting it right is about that. And, you know, just how much to not let yourself get away with in terms of in terms of, you know, oh, it seems to work and you know, what kinds of reinforcements to build in. Uh, I went through a a long phase around this time when I would explicitly write out asserts and and uh uh about all my preconditions and and inserted variants all over the place, like I was implementing contract programming in my in my software, and I learned a lot from that. Um 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 I made in my initial designs. My initial design for 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, and this is what people were were doing this work with. And um, and so I developed this really compact encoding for the notation. But then what I discovered in the long run was and 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 you know, just essentially a decompressed version of it. And the but it was very hard ever to get rid of this this underlying encoding that I had. So just being able to think about think about you know what it's gonna cost you to optimize over here, that was one of the one of the big lessons.

Conor

So you you spent 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.

Dave Abrahams

So the the language we're using next after C at Market the Unicorn was something called Think C, which which was essentially C with a kind of dynamic uh 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 the interview with Alex Stepanov and Dr. Dobbs. Uh and I was like, oh, this STL thing, I've got to get this. Because you don't, 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.

Conor

Uh to skip ahead, did Sean give you that question upon uh hiring you at Adobe? Uh to write a binary search. Yeah, that's the one that they asked some modified binary search, or did you he said he was gonna 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. I think you would have gotten it right uh that time, uh, probably at this point.

Dave Abrahams

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 I I believe I know how to think about binary search. So when I saw this, uh when I saw this article on the STL, and then I discovered that the the thing actually had documented requirements and guarantees, unlike any of the code that I had written, because I'm you know, I'm writing I'm writing music software. I don'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 uh actually, you know, it's a tiny niche, but I was a world-class expert in music software. Okay. Um and I think this is uh I think this is is typical and and correct that you know people get uh 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 uh I was so enamored when Boos came along that libraries are so important. In any case, I find this SDL 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 gonna be efficient? You know, this was 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 this made a a huge difference for me. But I I looked at this and we were still 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 is to throw an exception. And at the time when I got the STL, the the language that came with it said, you know, the 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's gonna 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 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 uh and he said he wrote back and said, I I think that's great, uh, 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 um, and you know, you're gonna have a hard sell to make any changes at this point. And uh, but uh 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 the what they called the reflectors. Is is the committee still using reflectors?

Bryce

Yeah, we we still call them that, and it's probably still hosted in the same place.

Dave Abrahams

Yeah, okay. Uh yeah, mail man.

Bryce

Yep.

Dave Abrahams

All right, cool. Um so I got on the reflectors and started uh started talking about this on the library working group, and and one of the things so I I definitely heard from a lot of people, you know, 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 uh from this article, the way people read this article by Tom Cargill, which which was a classic uh 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, um he pointed out a lot of problems, and a lot of uh a lot of people read this to be a demonstration that it just you know wasn't tractable. So there was this is you know, or 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, said, Well, that's all very well and good, but you're not gonna 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 I don't know that the culture has really the stories I've heard of have not been good uh recently about 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 the things I had argued. And I tried to, you know, I I realized this was not my domain, so I was not trying to like tread in heavy, but it was it was a really different feeling than my professional experience. I felt I felt hugely validated by this. And so that contrast was the beginning of the end of my work at Market the Unicorn because you know I really saw that I wanted more of what we were doing in the committee.

Conor

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.

Dave Abrahams

Well, I'm happy to come back. I hope, I hope it was all actually interesting and I wasn't just chronic on taking up time.

Conor

Oh my goodness, are you kidding 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 he 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 Marcus not sneaking around to sneaking into and and also yeah, breaking uh breaking into that's oh man, that's definitely gonna be the 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 room. That is just oh my goodness. Oh my goodness.

Dave Abrahams

It wasn't it wasn't much to break. I mean, you could see like the 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.

Conor

I might consider uh in 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 uh at one point break the window, you know. This is uh his mom got in trouble from the university for all the damage from property. Um that's where APL will take you if you're not curious.

Dave Abrahams

Well, this this almost I almost did get I 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 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.

Conor

As a high school student, you were doing work for some of the grad students at Princeton.

Dave Abrahams

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

Conor

We hope you enjoyed and have a great day.