Algorithms + Data Structures = Programs - Episode 38: Adobe STLab is Back! (with Sean Parent)

Episode Date: August 13, 2021

In this episode, Bryce and Conor interview Sean Parent about restarting the Adobe Software Technology Lab.About the Guest:Sean Parent is a principal scientist and software architect for Adobe Photoshop. Sean has been at Adobe since 1993 when he joined as a senior engineer working on Photoshop and later managed Adobe’s Software Technology Lab. In 2009 Sean spent a year at Google working on Chrome OS before returning to Adobe. From 1988 through 1993 Sean worked at Apple, where he was part of the system software team that developed the technologies allowing Apple’s successful transition to PowerPC.Date Recorded: 2021-07-28Date Released: 2021-08-13ADSP Episode 17: Special Guest Sean Parent!AlexFest: Sean Parent - Meeting AlexADSP Episode 28: Steve Jobs & Sean ParentAdobe Software Technology Lab (STLab)STLab on GithubJohn BackusEBNF - Extended Backus–Naur formA9 VideosSean Parent - Programming Conversations Lecture 5 part 1 (A9 Video)C++ std::rotateC++ std::find_ifElements of ProgrammingPacific++ 2018: Sean Parent “Generic Programming”Swift Programming LanguageSwift UICppCast Episode on STLabIntro 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

Because technology sucks. That's the answer. Well, should we hop right into the episode with that being our goal tonight? I think so. Welcome to ADSP The Podcast, Episode 38, recorded on July 28, 2021. My name is Connor, and today with my co-host Bryce, we interview Sean Parent about the Adobe Software Technology Lab. Yeah, so I guess this is the third, I mean, we've had what, five episodes probably, but that was across two different recordings.

So at this point, probably most of our listeners know who you are, Sean. But in case there are some people that have tuned in since the last time that you were on, maybe we'll start off by introduce, you can introduce yourself, just in case people are like, who is this Sean that has appeared out of nowhere? Okay. Yeah. So I'm Sean Parent. I'm a senior principal scientist at Adobe. I've been at Adobe off and on a little bit,

I guess, for over 25 years. Started on the Photoshop team and most recently, I've been working with the Photoshop team and I'm restarting Adobe Software Technology Lab, which we'll talk more about in a bit here. Before Adobe, I was at Apple for five years. I worked on QuickTry GX and then the transition to PowerPC. And in the middle, somewhere close to the middle of my Adobe career, I took a year and went to Google and worked on Chrome OS and then flamed out and came back to Adobe.

So that's who I am. All right, so I think it was episode 16 or 17 was one of the first ones we had you on. And I believe you did talk about what was it, the eight-year period with Alex Stepanov and was it Paul McJones? Where you had the initial ST Lab. But like maybe you can recount briefly sort of that period of time and you just sort of nonchalantly said that you're bringing it back um which is like it's it's with dave abrahams yeah well you took away his thunder bryce not gonna cut that out uh no so um uh uh yeah so this came about i don don't know, 2001 maybe.

Alex Stepanoff came to Adobe and gave a talk. And after his talk, it was on STL. For people who don't know, Alex Stepanoff is the person who created the standard template library for C++. And he came and gave a talk at Adobe and after his talk he and I started chatting and at the time he was a vice president at Compaq which was in transition they had just been acquired by Hewlett Packard. And so he was kind of sliding back to HP he had actually created STL while working at HP Labs. And we were chatting about work that I was doing,

and we ended up spending a long evening in my office just talking about engineering stuff. And at the end, he said, you know, this is amazing. I would love to get back into engineering, and I haven't had a conversation like this in a long time. And I said, well, why don't you? I would love to get back into engineering and I haven't had a conversation like this in a long time and I said well, why don't you and He just kind of shrugged it off But a couple weeks later he called me up and said, you know

I gave it a lot of thought and I don't want to be a manager anymore. I want to be an engineer so is there a position at Adobe? And there's a bit of a long story here because he did join Adobe. I was not able to get him to join. I was working in Adobe's research group and I was not able to get him into Adobe's research group. So he joined a different group, one of our shared technology groups, and found it a bit frustrating. There was a bit of a mismatch there between somebody who's kind of a very senior researcher and mathematician and a group that's just slogging through a bunch of

bugs. And the result of that you find, I gave this story at Alex's retirement party. So there's a video of that online. Maybe you can link it in the show notes. But the end result was, I thought Alex was going to quit. He was getting frustrated, but he insisted that no, he thought that the job was worthwhile and he was enjoying it and he was going to stick it out and work with this team. And about two weeks after we had that conversation, he called me up and said, guess what? And I said, you're quitting. He's like, no, they fired me. And so

he had been fired from Adobe. And I scrambled and Greg Gilley, who I think I mentioned. I did spend like 40 minutes last time trying to find that video clip of him rambling on stage. It took me a while, but I did find it. You didn't find it? I did find it. I did find it. No, you did find it. Yeah, yeah. It's hilarious.

I hope people that listen to the podcast. You can tell Bryce does not listen to the podcast. You're a busy guy. I understand. So, so in any case, I went to Greg who, uh, uh, Greg was, uh, like, you know, director of, uh, uh, digital imaging. So he had, had Photoshop and had a bunch of products under him, different org than I was in and different organization than Alex was in. Um, uh, but I knew Greg well, and I went to Greg and I said, so this guy than Alex was in. But I knew Craig well and I went to Craig and I said so this guy Alex Stepanoff I know you probably don't even know who he is but an amazing individual he was just

fired and and you need to hire him back. And Craig was like I can't do that, it's another organization that would be going against another VP, I can't hire this guy back. And I said, well, I'll put it this way, I said, if he goes, then I go with him. And so why don't you at least take the time and go out to lunch? And have lunch with the man and see what you think. And so he went to lunch with Alex and came back and called me and said, you know, come to my office. And I came in and he said, you know, god damn you.

He said, I'm going to hire this guy back. And he said, but here's the deal. If I hire him back, you have to manage him. And so out of that, Alex and I started Adobe Software Technology Lab, which was, the name came from Hewlett-Packard Software Technology Lab, which is actually, everybody always thinks that STL stands for Standard Template Library, or some people think it's Stepanoff and Lee, because it was Alex Stepanoff and Meng Li who wrote the initial paper. But it actually, STL comes from Software Technology Lab, which is where Alex was working at HP. And so we created a group, Software Technology Lab, and it was within Adobe's digital imaging organization. And the charter of the group

was to improve software engineering practice at Adobe, but we also thought that to do that you kind of had to do it industry-wide. And we defined practice to be distinct from process, meaning that we were concerned with what engineers wrote when they sat down at the keyboard, not with things like how they ran a scrum or whether or not they were following an agile process or anything along those lines. It was concerned about what do they actually type when they sit down and write code. And we did that with a three-prong approach. So part of it was education. And so Alex was teaching a class at Adobe, and that eventually led to the publication of Elements of besides education, we had libraries and tooling.

And so that created something called the Adobe Source Libraries, which are still kicking around. They've kind of moved into my own domain, which is stlab.cc. And they're still available up on GitHub and still in wide use inside of Adobe. But that's a set of libraries that do some interesting things that we could talk about at some point. And then part of it was research. So we had ongoing collaborations with universities,

including Indiana University, where Andrew Lemstein was at, and Texas A&M, where Bjarne Stroustrup was at. And we brought in Paul McJones who, for people who don't know, Paul's been around for a long time. He worked with John Backus at IBM. He worked on the module 3 language, System R, which was an early relational database. John Backus, for those that don't know, I think that's the individual who was behind Fortran? Individual who was behind Fortran, Turing Award winner. If you've ever heard of EB&F as a way to describe grammars, that's Bacchus as the B in EB&F.

So, yes. Quite prolific. One of the greats in the industry. And another person from Adobe's research team was Matt Marcus and he also represented Adobe on the C++ standards committee at the time and then Foster Brereton who was now a very senior engineer on the Photoshop team but he and I had worked together on the Photoshop team he had been my intern for a while on Photoshop and he joined the. So kind of the peak of the group, there were five of us. And we had a good eight-year run, and then had kind of a spectacular, very

political flame-out at the end of the eight years, and that led to me resigning, and that's how I ended up at Google for a while. And Alex and Paul left. Alex went to A9. Paul retired. At that point, what led to the flameout was actually Adobe went through a round of layoffs, and Matt Marcus had been laid off. And it was a decision that I had absolutely no say in um and i thought was was a very wrong decision i think i'm maybe i knew this but i forgot that the reason that you left adobe

uh was because of that um yeah i don't think i knew that but and it coincided with the flaming out of the ST Lab. Yep, yep. At that point, Foster had already slid over back to the Photoshop team. So he was kind of spared the whole implosion of the team. Here's a question, Sean. You were only at Google for a year, right? Yeah, just over a year. Do you regret having left? Because you came back to Adobe, so obviously it was the right place.

But do you regret having left or was it just sort of like you needed a break? And even if it maybe wasn't the right long-term decision, you felt that, like, in hindsight, it was a good thing at the time. Good thing for you. It was a good thing for me. You know, I don't see how I could have stayed at Adobe under the circumstances. I came back kind of under very different circumstances. The promise at Google was, you know, they gave me a great pitch that they were creating a new OS from the ground up, and it was a web-oriented OS, and they had read a bunch of my papers, and they liked my ideas, and they wanted me to inject my ideas into this new OS.

How do you say no to something like that? The reality was the new OS was Chrome OS, which isn't really a new OS. It's Linux with a Chrome browser tightly bonded to it. I don't really think the manager who I was speaking with had actually read my papers. He had read some of my blog posts, which meant we agreed on the problems,

but not necessarily the solutions. And so I was a bit of a mismatch with the team that I was hired into and was kind of going against the grain of both the team and Google. That said, I still very much believed in the vision of Chrome OS, and I'm still a fan of Chrome OS and kind of what it is and where it's at. I think it's an amazing product.

So, yeah, I learned a lot. I got to work with some great people. Still have friends that I made at Google, but for me personally, it was not the right fit, and it was a painful environment to work in because I'm somebody who, if you give me a problem, I will kind of keep chewing at it and keep coming back to it and keep revisiting it and just keep kind of drilling down.

And I will, you know, if it's an interesting problem, I'll obsess about things for years and just kind of keep chipping away at them. And Google was not an environment that allowed for that. It was, you know, here's the highest priority problem. Get it done enough that it's not the highest priority problem. Move on to the next problem. And I don't switch tasks like that well.

So it was not a good fit. From my point of view, it was an amazing year for you, Sean, because we're forgetting what came out of that year. Yeah. But that's where the That's a Rotate comes from, your time at Google. That is where That's a Rotate from. That was the long story of the C++ Seasoning Talk

is on A9 Videos. I went and gave it at Amazon when Alex was over at Amazon. And yes, so the back story on that, the code that I put up in the C++ Seasoning Talk is code from my very first code review at Google. Oh, wow. I did not know that part. Yeah, so at Google, you kind of have to earn gold stars. You have to, you know, get your readability certificate and your code review certificate. Even you had to? Even me. It doesn't matter how senior you are coming into the company.

So, you know, I joined the team and I'm the noogler. I've got to, you know, go through code reviews and I've got a mentor who's going to, you know, look over my shoulder during the code review to make sure I'm doing the code review correctly according to Google's guidelines. And I was given this piece of code to review. And when I do a code review, the first thing I always look at is, are there any loops? And if so, what are the loops doing? And this was a very long function with a whole bunch of loops in it that I'm reviewing. And I'm like, what in the world is this thing? oh, I see, this is a, it's basically a find if followed by rotate. And really, that was the start of it. But if you look through the rest of it, it was a find if followed by a slide,

which is a rotate going one way or the other. And then wrapped up with a transform at the end. And so, you know, I spent an evening kind of digging through this and figuring it out. And then wrote that up in my comment and was like, okay, so this whole big massive code I'm reviewing is find if, pair of rotates, transform, done. And the person whose code it was was like, this isn't a rotate. I was like, oh no, this is a rotate.

It's an inefficient quadratic rotate, but it's a rotate. And he was like, no, it isn't a rotate. I was like, oh no, this is a rotate. It's an inefficient quadratic rotate, but it's a rotate. And he was like, no, it's not a rotate. It's doing something else. And I'm like, nope. May not be what you intended to do, but what the code is doing is a rotate. And it took me a fair amount of time,

kind of conversations on and off for two weeks with the individual who wrote the code to convince him that yes in fact it was a rotate and that a rotate would be more efficient in this case and shorten up his code and I convinced him and he was like okay I see, I understand you're right, this is so much

better. And so he rewrote the code and checked it in, or put it back in for the code review. Said, you know, Sean convinced me this is correct. And my mentor said, no, you can't submit that. It was better the way it was before. Nobody knows what a rotate is, and that's too tricky. And, you know, I argued that argument and lost. And so the code got checked into Chrome OS and Chromium. And the reason why I'm able to put that code on my slides is because Chromium is open sourced. And so that code went into the open source project and it is now part of the public record. The code actually does use rotate now.

I think that's an exclusive we just got there. Did they change it to use the rotate after the talk? After he gave you talk, Sean? As far as I know, yeah. I wonder if there's a long story of that getting back to the team or the manager and the person that wrote the code initially. Probably they had moved on at that point, but it would be so funny if they were still there

and then this story is just getting retold and the story of it getting told is getting retold and they're like you know what we should we should this is uh we got to go and change that code um well connor obviously after this after this recording you're gonna have to go find that code and do the git blame on it and see if you've changed it to a rotate and when. Yeah, you know, I would, you know, I try not to, just because, you know, I work on a product that's been around for 30 years. So a lot of times I do the git blame. I'm like, who the F wrote that?

And I'm like, oh, I did. Darn it, okay. So yeah, I mean. Yeah, I think we've all been there where we're staring at some code and, yeah, who did this? And then you find out and it's like, oh, it was me from two years ago. Ah, that's impressive. I didn't know what I was doing two years ago. I can't believe that works.

Yeah. Yeah. from being a, you know, managing a research team with some world-class computer scientists on it to kind of, you know, working as a nuclear with, you know, I would say a, you know, an organization that didn't care about your previous history. So that was a bit of a culture shock to slide into that. So where was I? Yeah, so that's what Software Technology Lab was. We had, you know, I think an amazing eight-year run. Like I said, the Adobe Source libraries are still in heavy use. I still have some ongoing university collaborations going with Jaco Yarve, who he was at Texas A&M, and now he's at, what is it?

I'm trying to blank on the name. We'll fill it in. It's a university in Finland. We worked on something called property models, which are within the library. And now I've got Dave Abrahams hooked on property models. And we wrote the book, published the book, Elements of Programming, which I think kind of had a huge influence on C++

and formalizes the ideas of generic programming. Alex Stepanov is the person who created the term generic programming. I think, Bryce, you've said that that's the only book that you've read on C++, correct? The only programming book. Not the only book that I've read. Yeah, that's what I said, yeah. It's the only programming book that I've read, though. Yeah, and actually because I'm in the middle of the move,

I'm packing up all my books right now,, I'm tempted to get rid of half of them. Cause I got all these C plus plus books that I never read, but, uh, uh, I I'm obviously not going to get rid of my elements of programming copy, which, uh, was a, it was my like 20th birthday gift from my mentor Hartmut, uh, who just appeared in the office store on the day of my birthday and he's like here you should have this and uh then I read it and I was like yeah I should have this yep and it's uh the book is open source now too so it's uh or I don't know open source freely available uh you can you can look it up online and download it I don't know, open source, freely available. You can look it up online and download it. I didn't realize that Stepanov had coined the term generic programming.

You haven't seen my talk, The History of Generic Programming. I guess I have. Yes. Yep. Yep. We just went past the 30th year, the 30th anniversary of generic programming. And so I gave a talk because I thought it needed to be recognized. So I gave a talk on the history of generic programming.

Yeah, that's the one you gave at Pacific C++, right? Yep. So the big news is that STLab is back. Yeah, so STLab is back. Yeah, so ST Lab is back. This time it's Dave Abrahams, for people who don't know who Dave is. In the C++ community, Dave was very well known as a Boost contributor and somebody who had, along with Eric Niebler, they had a company,

Boost Pro, which was a consulting firm around Boost. And Dave contributed many things to the standard library, and I think one of his key contributions, he gets a mention in my history of generic programming talk, was the formalism of the requirements for exception handling, the basic exception guarantees and the strong exception guarantees. That's from a paper that Dave published, which I think was was a very important piece of work. And then he kind of left the C++ community, I don't know, almost a decade ago, not too long after I had my run to Google, and went to Apple and is one of the creators of the Swift language. And then he created SwiftUI, and then he was most recently at Google

working on Swift for TensorFlow, which you can look that up. It was a project that ran for about a year at Google recently, or it had Chris Lattner started it there. Chris Lattner is the person who created LLVM for people who don't know, and also he worked at Apple and is one of the creators of the Swift language. Chris left Google and then about a year later while Dave was working there, they cancelled the Swift for TensorFlow project. And I managed to snag Dave. And it came about at a good time for Adobe. Adobe's been pushing our products onto a lot more platforms. I think you're seeing that. We have Lightroom Mobile, Lightroom Web, Photoshop Mobile at this point. You'll see Photoshop appear on other platforms. And so our products are increasingly getting brought up on increasingly diverse environments.

And one thing that we're struggling with is exploiting the hardware where we have an increasingly diverse landscape of what the hardware characteristics are. So kind of how do you code for that? And part of that is how do you code for that? Part of that is how do you deal with concurrency in a way that scales both up and down and is efficient in all configurations and doesn't cause a lot of bugs and problems. Right now concurrency is driving a lot of our quality issues.

And they're not things that ThreatSanitizer will pick up. They're not hard race conditions. They're what I refer to as logical races. Their developer made an assumption that A will happen and then B, but sometimes it happens B then A. And so that generated some impetus to say maybe I could try to get out in front of the teams and blaze a path around concurrency and follow the same charter that we had for the old software technology lab of taking a three-prong approach through

education, tooling, tooling in libraries, and research with university collaborations. And pull in Dave, and Dave has a lot of experience in this area and working on on memory safety which is closely related to concurrency issues and you know hopefully together we can we can make a dent in this and so so he's got permission. We kind of spun up the team. It's just the two of us at this point. We'll probably grow to three to five,

which is the old software technology lab peaked at five. I'd like to get in between there. We're looking at the problems that the teams are having and trying to figure out how we have an impact on them. And so we'll be restarting some classes soon. We're taking a bunch of notes and we're kind of identifying what are some of the key problem areas where we think we can come up with some solutions that can filter back down into the teams and have an impact. Is there a chance this is going to be like A9 Videos 2.0,

where they're going to get posted on YouTube at some point? I think so. We're getting a, you know, right now in the Valley, you know, in the industry, not just Silicon Valley, in the industry, hiring is very competitive. And Adobe has been growing very fast, even through the pandemic. In some ways, the pandemic's been, you know, Adobe is one of the companies that the pandemic's been good for, right? Every mom and pop shop now has to create their own website and get e-commerce online, and they're going to need, you know, Photoshop and Acrobat and our web creation tools, and they need analytics for their advertising and all of that and these are are all things all products that that adobe sells um uh so so because it's become competitive uh adobe tends not to have

the visibility in in the industry that say you you know, Facebook, Apple, Google, Netflix, the FANG companies, as the kids say. The FANG companies, yep. Yep, that the FANG companies have. So we tend to lose a lot of potential good hires to the FANG companies. And I think part of the issue there is that kind of outside of me talking at developer conferences, Adobe doesn't have a really strong presence in the C++ community or even in the broader just software development community. You know, if you go to the Vision AI, you know, SIGGRAPH areas,

you know, Adobe has dozens of SIGGRAPH papers. They usually get submitted every year, and we have a strong presence in those communities, but not in kind of your, you know, day-to-day. We need a great C++ engineer to pull them in. And so part of the charter for this group is to raise external visibility for some of the interesting stuff that's happening at Adobe. And so I think you'll see, you know,

both Dave and I speaking at conferences and promoting Adobe a bit and, uh, uh, trying to, to raise awareness and encouraging others at Adobe to also submit papers and speak at more conferences. Cool. So does this mean that we'll see, does this mean that Dave is returning to C++? Open-ended question. Maybe Adobe is switching to Swift. We don't know what the answer to that is.

Certainly, Adobe has a huge investment in c plus plus and and and a very large amount of code in c plus plus and so any answer to these problems has to include c plus plus so so there's going to be you know a a connection there um but at this point, we're not ruling out, you know, we're trying not to over-constrain the solution set, right? So, but yeah, I think, you know, Dave is going to have his hands more in C++, and it's very clear he's, you know, he kind of left the community pre-C++11 and so he's got a little bit of a culture shock stepping back in and just seeing how far C++ has moved in that time frame

it's one thing to kind of be looking at the news articles it's another thing to kind of be looking at the news articles. It's another thing to be stepping into big code bases and going, wow, this has a significant impact in how people are writing code. Yeah, it's definitely evolved. One thing I was thinking, too, about the visibility is unlike Microsoft, which Bryce and I have talked about this on a past episode, Microsoft doesn't fit into the FANG acronym. But Adobe and NVIDIA, we could just have a triple A FANG and a double N, just make that acronym, and Adobe's logo is a legitimate A. I think we should make a new acronym for the cool C++ places. And so it would be Microsoft, Adobe, and NVIDIA.

Now, there is one word that those spell, but it probably does not send the right message, the acronym to be MAN. We got to just add a couple letters. What word do we want to spell? We could spell AMAN. We could spell MAIN. We got to think of a cool word, reverse word do we want to spell? We could spell amen. We could spell Maine. We got to think of a cool word, reverse engineer it, and then just go find that or like go tell a company with that letter.

Maine. I like Maine. What's a company with an I that rises to the same level of cool? I was thinking E, like the horse's Maine, but okay. Okay. Give me okay company with an E I guess Maine makes more sense because of the Maine branch on GitHub I don't know any companies that start with the letter I

we'll leave it to our listeners if you'd like to be in our new acronym tweet at us and you can be the eye or if you've got suggestions on extending our acronym is not going to be man i'll tell you that it'll be it'll be now yeah yeah well it's it's interesting because because uh adobe you know i think of adobe as being one of the old school like classic c++ shops because you know back in the, you know, I think of Adobe as being one of the old school, like, classic C++ shops.

Because, you know, back in the day, you know, like A9 in particular, there was Stepanov. You know, Tony Van Erd went through Adobe. I think Niall Douglas was at Adobe. I don't know. Maybe it was Niall and Tony were both at BlackBerry. Louie was there. A bunch of, like, a bunch of old school C++ people went through Adobe. And it's got a big C++ code base.

Sean, I recall you once telling a story that involved the number of lines of code and Photoshop and all the plugins. And I remember it was a surprisingly large amount of code. Yeah, yeah. We recently reran the stats. I don't have them at my fingertips here. But yeah, it's millions of lines.

I don't think, unless you're kind of a professional Photoshop user, I think a lot of people don't have a full deep appreciation for just how much stuff is in Photoshop, right? I mean, Photoshop can edit videos, Photoshop can edit 3D. It's a very broad, broad product that gets used in a lot of different markets, both in graphics art and in science and engineering. So it's a very big and deep product. Thanks for listening. We hope you enjoyed and have a great day.