Patrick Collison on Stripe’s Early Choices, Smalltalk, and What Comes After Coding

0:00It's interesting to me that we haven't experimented in some sense that much with the paradigm of programming over the past 20 years. You put those together, you now have the ability to, again, at the kind of level of the individual cell, to read, think, and to write. And this starts to really feel like a new kind of Turing loop and to have its own sort of completeness. I think that's a case where the right API design, the right abstraction design, ends up having just quite significant business ramifications. I think the basic idea of as development environment and not just text editor is really the right idea.

0:38And that's the thing I want to see a return to. Patrick Collison wrote his first startup in Smalltalk. Its development environment let him fix errors mid-request, inspect stack frames, and resume execution. And he wanted that more than he wanted a mainstream language. He and his brother chose Ruby and MongoDB for Stripe instead. Those decisions still define the company 15 years and 44 seconds of annual downtime later. Now Stripe is shipping v2 APIs, rewriting core abstractions first designed in 2010. It's taken years. Defining the new APIs is the easy part. Making them work alongside everything already built on the old ones is, as Colson put it, more like an instruction set migration than a product launch.

1:20This conversation previously aired on Cursor's podcast also gets into why AI hasn't moved product TV numbers, what today's dev environment could steal from Lisp machines, and Collison's work at ARK on foundational models for biology. Michael Truel, CEO of Cursor, sits down with Patrick Collison, CEO of Stripe. Well, it's great to have you. Thanks for being here. Thanks for having me. Great to be here. I've heard that your first startup was written in small talk. Please explain. I don't know what there is to explain. It's the best programming language. Well, I'd worked on Lisp and Lisp dialects before that.

1:57And actually, I'd worked on Lisp web frameworks. And when we went to build our first startup, we first implemented it in Rails. And then I found, compared to Lisp, that development process kind of frustrating. And I mean, we don't need to get into the full details, but I thought that continuation-based web frameworks were really the right way to implement web applications. There were no continuations in, there's no continuation-based framework in Ruby. And just kind of searching around, I found that there was a good one that had just been written in Smalltalk. And so I decided to play with it a little bit.

2:36And then I found that Smalltalk is actually this extremely interesting development environment that had a lot of the aspects of Lisp that I'd really appreciated there, like, you know, and a fully interactive environment with a proper debugger so that you can edit the code while in the middle of some web request or deep in some stack trace or something. And you could, for example, encounter an error with some web request, edit the code to fix the error, and then resume higher up in the stack such that the entire web request would just complete. And so rather than this kind of annoying feedback loop of having to add some log statements and do this binary search to find the problem and eventually deploy a fixed version, a process that could take an hour, you could just literally inspect the stack frame, see which variable has the wrong value, fix it, jump back up, hit proceed, and have the whole thing work.

3:33So anyway, the point is, in the hunt for this continuation-based web framework, realized that Smalltalk in general had just a much more powerful development environment as compared to Ruby, as compared to basically every other mainstream programming language. and so we decided to use it for the company which in hindsight was, I mean I don't know if it was a terrible decision or not. The reason I think one would think it would be terrible is that it would be hard to hire people and hard to scale and whatever. It wasn't hard to hire people or rather nobody knew it but it was easy to teach them. Did they know before they joined?

4:07No, no. They learned really quickly and then you have smart people learn languages really quickly. So I don't think that's really a reason not to use a non-mainstream language. The company didn't work. I think for unrelated reasons. I think just the idea wasn't that strong. But we also chose Ruby for Stripe. So I don't know, I think maybe the gains were not quite as large as I'd hoped. And was your small talk enthusiasm shared by the acquirers of the startup? And what was the dynamic, you know, was there like this blissfully ignorant management that foisted this small talk code base on a bunch of unsuspecting developers that were then kind of like piling over, you know?

4:40Or yeah, what was the dynamic between the programmer's management? And what happened to that small talk code base? Yeah, yeah, yeah. Does it still live on somewhere? I wish. And I'm 99 % sure the answer to that is no. The company that acquired us was mainly a talent acquisition. So the code base itself was less relevant. Okay. And it was immediately sort of just gone? Yeah. Okay. I've also heard that one of your earliest programming projects was working on an AI bot written in Lisp. True. And it was something like a client for MSN. I know where you found that, but that is true. And I heard that you got kind of nerds tonight by the idea of trying to get it to pass the Turing test.

5:21Yes. And I'm curious, what did you miss? Why didn't you make ChatGPT? And, well, maybe a little bit more seriously, how did it work? And what was the state of neural networks at the time? And did you consider using any antecedents to the technology we use today? Yeah, so that was the project. It was a little critter that used MSN Messenger, which was, you know, all the rage at the time. I guess that's like maybe a specific kind of sedimentary layer in the chronology of different instant messaging solutions and probably dates me quite precisely. And it was a really simple Bayesian next word predictor.

5:56Like there was nothing really that sophisticated there to the extent there was anything sophisticated. It was maybe that it used, like the training data was the conversations itself had in MSN Messenger rather than kind of general text corp. And anyway, it worked reasonably well. and better versions looked a couple of words ahead and what have you. I mean, it never really passed the Turing test where people have actual suspicion that they're trying to exercise this discernment, but it certainly passed some weaker version of the Turing test where they were unsuspecting and people ended up having quite lengthy conversations with it.

6:30And that was part of how I discovered Lisp and I remember Paradigms of AI Programming by Peter Norvig being a really formative book and had all sorts of interesting approaches there. It didn't have anything on neural networks, I'm almost sure. And I'd read some Marvin Minsky stuff, Society of the Mind or whatever, on neural nets. But I never really seriously looked at them. I actually experimented a lot with genetic algorithms. They were, I guess, more practical on your own computer. It takes a lot of computer training in neural nets. So I experimented a lot with genetic algorithms. And actually, I used Vorjak at the keyboard layout because it's more comfortable to type on than QWERTY.

7:06but as does John, my brother so no one can ever use our computers but I wrote a genetic optimizer to figure out what the optimal keyboard layout was and it turns out it is in fact basically Vorjax using a genetic approach so I went deep down that rabbit hole but I never really played with neural networks and I guess that's why that but probably 70 other reasons is why I did not create ChatTript. There is an old video of you being interviewed, I think after selling Octomatic, where you're asked about Smalltalk. That's where I found kind of that weird effect. I think at the time, people asked you why, and one of the things you said was, I mean, you liked some features about Smalltalk, Lisp-style languages, and you predicted, and I think that this was circa maybe 2008 or something like that, that the mainline C-style programming languages would increasingly borrow ideas from these older programming languages.

8:04And that kind of has been the case in the JavaScript Python ecosystems. Do you think that there are any underrated ideas buried away in kind of older, more esoteric programming languages that should be borrowed by the main line? Yeah, it's been interesting how a lot of the ideas have been borrowed by the JavaScript ecosystem and in a strange way, like through the web inspector, where you have this, I mean, that's one of the richest runtimes in some sense that people have general exposure to. I don't think JavaScript has first-class stack frames. Maybe there's some weird extension or something where you can get that, but ECMAScript doesn't have that, I'm pretty sure.

8:44First-class stack frames actually let you do a lot of other things for kind of obvious reasons. So maybe that's kind of too specific. I mean, I think the idea of, and maybe this is what cursor becomes, I think the basic idea of as development environment and not just text editor is really the right idea. And that's the thing I want to see a return to. That's the thing that the Lisp machines had and Genera. That's the thing that, to some extent, Mathematica has. That's the thing that Smalltalk has. And I think it's just such a mistake that we have ended up with development environments where there is such a separation between the runtime and the text editing and the environment in which the code, I mean, well.

9:29The runtime and the place where the code runs can be the same or different, but there are three maybe slightly conceptually different things. And in those three environments, they can all coexist in the same place. Still to this day, I use Mathematica a lot, not because I'm doing some particularly arcane symbolic mathematics, but because it's just a more efficient development environment. Now, that's maybe a bit less true with LLens because Mathematica does not support cursor-style prompted development, but that I think is the core idea that I wish others would borrow and VS Code has been a step to some extent slightly in that direction but I think we could take it way further and it would be really what I'd love to see for example is when I hover over a line of code I would like to see profiling information about just the runtime characteristics of that code or that function or whatever I would like to see logging and error information overlaid when I hover over a variable, I would like to see how, like the most common values that it takes on in production.

10:34These kinds of like just rich, deep integrations. Are you a fan of inventing on principle and those talks? Yes, yes, yes. I think Brett leans too much. I mean, I'm a huge fan of Brett. He's such an incredible... Have you been to Dynamic Land? Yes. Okay. Yeah, and have supported it. So huge fan of Brett. But the place that I've maybe differed, or at least that just resonates with me somewhat less, is Brett is really into this idea of, obviously, of graphical and visual representations for phenomena. And I think that works very well in certain domains, like the kind of dynamical systems that he has demonstrated some of the ideas with.

11:20I think it's often very hard to find such useful, spatial, continuous representations for arbitrary systems, like for various parts of Stripe. I'm not quite sure what that would be, and I'm not sure even if we could find it, you know, exactly how useful it would be. Maybe it's just me. I reason much more kind of symbolically and sort of lexically than I do visually and graphically. It might just be personal preference, but I don't know, the kind of paradigm breaking that he's been engaged in, I think, is hugely admirable. Are you going to make a truly integrated development environment? So we are playing with ideas around letting the AI increasingly take time into the background to run its code and react to the output.

12:01And we think that this should all work well together. Like, you know, we focused a ton on inflow, speed, and control. And we think that that's really, really important for AI is, you know, to give programmers the control over everything, have them understand everything the AI is producing. Also to give them really, really fast iteration loops, programmers hate waiting for things. But in some cases, we think it's now becoming possible to go tell the AI to think for a bit and then come back to you and have the API be a little bit more like the API with another human being. And we think you want that all to work well together.

12:32So the AI can come back to you with 70 % of something and then you can bring it into the foreground really quickly, work with it, and then spin it back off to the background. And as part of having the AI spend a bunch of time thinking in the background, to make that thinking useful, you kind of need it to run the code and then react to it. or else it's just kind of staring at the thing that it wrote and thinking more. Maybe I'm supposed to be the one answering the questions rather than asking them, but do you think in five years the main thing that I'm looking at in Cursor will be code or something else?

13:06I think it might be something else. I think that there are big, big, big simplification, but kind of when you're defining what a piece of software is, there's like the logic component, which is what engineers spend a lot of time on, of designing exactly how the software works. There's also for end user applications and things that have GUIs, there's like this visual component. And I think that there is, you know, maybe it's going to be us, maybe it's going to be someone else. There is a future version of the world where the way you interact with AI is a little bit less like, you know, it's a human helper that you're delegating work to or looking over your shoulder predicting the next set of things you're going to do.

13:39And instead, it's a little bit more of an advanced compiler or interpreter technology. And it could lead you to a world where programming languages actually change. And they can start to get a little bit less formal. They can start to get a little bit higher level. They can start to be a little bit more about what you want and a little bit less about how you do it. And I think that it won't look like a Google Doc necessarily. I think that there are things you want to keep around from programming, like the naming of logic somewhere and then using that in a bunch of other places. I think that there's also this other element too of the visuals of what a piece of software looks like.

14:11And I think maybe us, maybe some other tool, But I think there's a world where kind of direct manipulation of the UI starts to play a little bit more into it. But these are kind of far-flung experimental ideas. And in general, I will say, and it's not terrible, but I feel like it's interesting to me that we haven't experimented in some sense that much with the paradigm of programming over the past 20 years. And the main things we're discussing here are from the 80s or the 70s. and there are way more developers obviously now than there ever have been in the past but in some sense the aperture of experimentation there feels like it's really not that wide.

14:54And again the JavaScript ecosystem and a couple of others have done some cool things and there's been a lot of experimentation at the language level with Rust and Go and everything else but at the development environment level I don't know why it is but maybe it's just too hard and complicated now but there's been less than I would have expected. Yeah, I agree. and I think maybe this helps. Something we're working on. Maybe this explains Cursor's success to some extent where you guys are the first people to really take it seriously in quite a while. Well, I mean, yeah, I think we also benefit a lot from the why now of like there's now this, you know, great new color to paint with or set of colors to paint with.

15:30I think also there's just a ton of lock-in with programming languages around both the neurons in your head of like programming languages are kind of complex UI for programmers to define exactly how the computer should function. And so, you know, people learn languages and those, you know, people don't like to learn that many things. And then there's also the lock-in of you have a lot of logic sitting around in one language and you need to maintain that. And I actually think that that's a pretty interesting or one of our hopes is that as AI programming gets better and better and better, one of the downsides of working on professional applications with hundreds of people dealing with many millions of lines of logic is the weight of the code base really starts to weigh on you.

16:07And so the feeling of being in a net new code base where it's just everything feels effortless, goes away, everything's a chore, you have to change one thing here, brace something else here, and it becomes kind of this big ball of mud. And making that effortless, reducing the kind of weight of an existing set of logic, I think is one of the areas in which AI can make programming better. Someone said on Twitter today, maybe it was Andre Karpathy, but maybe I'm misattributing that, and made too many things to do with vibe coding get attributed to Andre, like to Churchill or Einstein or something.

16:43But I think about him. But this person, whoever was, was making an observation that it's one thing to be prompting the creation of code, but another place where AI could conceivably do a lot to help is in the beautification and the refactoring of code bases. And you can imagine that you're producing all this a little bit ungainly, not quite correctly factored detritus at the front and you have this and then nocturnally this thing comes up behind you and makes it all beautifully factored and the only CS class I ever took was this class from Jerry Sussman on it was basically focused on, he called it large scale symbolic systems but really what he was trying to focus on was the idea of creating code bases and environments and abstractions that were easy to modify and there were no assignments in the class where you'd write something from scratch, every assignment was about modifying an existing system and thinking about how could you design things in such a way that those modifications become, and they might be quite deep modifications, become straightforward.

17:47And I think that's a lovely idea. Obviously, in practice, it's often very difficult to do that given all the exigencies and pressures of the things you want to ship today and next week and so forth. But if you could have an AI, like often when you're writing this stuff, you realize, well, I really should be doing it the beautiful way, but I'm not. Maybe we could have an AI coming up behind us to change it. Yes, yes. maybe soon. One thing that happens to a lot of developers or a lot of people come to development because they care about building things. They want to make things happen on the computer screen.

18:14And so then that leads them to coding. And then something that happens to a big group of developers is they eventually realize the software they want to create is too big that they can't write all of the code themselves and they have to go to humans to help them write the code. And so maybe they then become an engineering manager or director or whatever it is. Maybe they start a company. And then most of the work becomes not typing code, it becomes coordinating amongst people. Do you think that there are any ideas from programming that are helpful for the act of kind of programming amongst the organization to get a group of people to build software together?

18:46I think taking APIs and data models really seriously. If I was to do everything at Stripe again, I mean, there's a million small things that you would do differently and even some kind of big things, but the thing that I think we could maybe foreseeably and beneficially done differently would be to have spent even more time than we did on APIs and data models. And part of the reason is the, I guess, Conway's law effect of how both of those things end up shaping the organization. So I guess if you don't deeply internalize that, then maybe you've less control over the organizational dynamics than you might otherwise like to have.

19:34But also I think it ends up shaping not only, I mean, the weak version of Conway's law is that it shapes your organization. I think the strong version is that it substantially shapes your strategy and just your business outcomes. And this isn't exactly maybe a version of that, but I often reflect on how the iOS software ecosystem for a very long time and plausibly still today was so much more vibrant and vital and successful than the Android app ecosystem. And there's a lot of things that are different across those two ecosystems. There are now way more Android devices in use, I believe, than iOS devices.

20:21But I think much of the fact that app developers tended to prefer building their apps on iOS and releasing their apps first on iOS and maybe the iOS version being better than the Android version or whatever is because the frameworks and the abstractions for iOS were just originally better than the Android ones. But I think that's a case where the right API design, the right abstraction design, ends up having just quite significant business ramifications. And I think there's kind of a sense that maybe it's not worth dwelling on these things because everything in technology changes so rapidly and whatever assumptions you make, they'll be obsolete in two years or something.

21:00I think in practice that's not true. And that's like the right API design and the right abstractions, the right data models can really endure. And for the first versions of iOS, many of the classes that one used were prefixed with NS. NS, of course, standing for next step, right? And so that's a case where the API design survived for two decades or more. And in the case of Stripe, Stripe is now 15 years old, and there were lots of things we designed 15 years ago that are still in use today, which is kind of good and bad in the sense that they endured, but also we are still under the... Living with their faults.

21:38Exactly. Yes, yes. And so anyway, that's maybe the thing that I would, that's the first thing that comes to mind. In fact, on that final note, I was talking with an engineering leader at kind of a preeminent, successful Silicon Valley private company. And they were talking about how their code base is largely in Scala. And they said that they like to think of kind of the beginnings of the startup as this big bang moment where these tired, overworked, maybe over-caffeinated founding team members are willy-nilly making these initial technical decisions that then dictate the lives of hundreds of professional engineers in the future.

22:17And that scholar choice is one of them. And they sort of live with the faults of that now. But what are those kind of, what were the consequential, it could be good or bad, initial conditions of the Stripe Big Bang that you guys still live with right now? I mean, I think that metaphor is, well it sounds true to me is the first thing I'd say. I mean maybe it's a little bit of kind of survivorship bias where like the actual statement is the early decisions we made that we never changed are decisions that we lived with but you know there's a kind of tautology there or something and there are certainly design decisions we made pretty early on that are not true today.

23:00So you know early versions of the dashboard or something were built extraordinarily differently to the dashboard today. And the converse is also true. So initially, we decided to use MongoDB at Stripe and we decided to use Ruby at Stripe. And those are still quite foundational technologies at Stripe. And we had to build a lot of infrastructure in order to make MongoDB as fault-tolerant and as distributed and as durable and as reliable and everything as we needed it to be and as it now is. Like we had Stripe's critical API availability last year was 99.99986%, which is 44 seconds of unavailability through the whole year, which is, we thin, and others don't publish statistics that are kind of granular, but we believe that is the best in the industry.

23:56And so everything that our storage team has built and many other teams, it ended up really working there. But that was a quite important critical decision, initial decision. And Ruby, similarly. I guess companies sometimes change languages along the way. But I feel like the initial language chosen tends to have a... I heard there were debates in Stripe about, or one of, actually, one of our co-founders, internet Stripe, early on. Or not early on in Stripe's history, early on in kind of our collective personal history. and he remembers there being documents upon documents about a potential Java migration.

24:34Yeah, so that partly happened. As in, we have rewritten a bunch of key services on Java, so some services for which throughput in particular is really important. And if you torture Ruby enough and maybe rewrite parts of it, parts of some hot paths in C or something, you can get it to be pretty fast. But you're often fighting against the allocator and various parts of even just like Ruby strings are not that efficient and stuff. So we've written certain services in Java and now we use both. Did you consider anything other than Mongo and why did you pick Mongo early on? And what was the RFC process, RFP process, decision-making process for that?

25:25It was just me and John, so we were sitting on the couch. It's like, should we use Mongo? Yeah, fine. Did they get through to you with a blog, or was it just the reputation of Mongo at the time and open-source communities, something else? I think it was, so I wrote a data store for our prior company, an object-based data store, and I didn't really like SQL. I thought it was, there was too much of a translational kind of mismatch between the domain of the application and, you know, that which SQL natively, you know, makes expressible. And so, you know, with SQL, obviously, you have to collapse down into, you know, a relatively restricted set of primitive forms.

26:11Whereas in your application, you know, you might have a concept of, I don't know, let's say in the case of Stripe, of money that doesn't like exactly comport with how the particular SQL database you're using happens to represent money or whatever the case might be. And so I just had this principled objection to SQL. I'm not endorsing this or saying it was good, but as this interview shows, I suppose, I had all sorts of strange notions about technology. And with Stripe, we wanted to be more mainstream and a little bit less heterodox in our technology choices than our prior company. and so instead of using Smalltalk, okay, we weren't going to go to Java, but we went to Ruby, which at least on a relative basis seemed more mainstream.

26:56And similarly, rather than write our own object database, we went relatively more mainstream and used Mongo, which still gave a lot of flexibility by virtue of being a kind of object datastore. So that was fine. Everything I've said might disqualify me from ever making technology choices for another company. Would you do anything differently about Stripe V2? We haven't talked that much about it publicly yet. And the answer might be a bit like, you know, there's the Zhu Enlai quote about the, or is it Deng Xiaoping, about the French Revolution. You know, it's too soon to judge. And so back in 2022, I believe, we, I mean, to this discussion about data models and abstractions, we realized that a couple of the core abstractions in Stripe were just not the right long-term abstractions, and we had to fix that.