TypeScript, C# and Turbo Pascal with Anders Hejlsberg

Anders Helsberg is one of the biggest living legends in the tech industry. He created Turbo Pascal, Delphi, C Sharp and TypeScript. The impact he has had on programming languages and developer tools is immense. Today with Anders we discuss how C Sharp might have not been born if it was not for the Sun vs Microsoft lawsuit over Java. The behind-the-scenes story of TypeScript and why open-sourcing it was a huge deal inside of Microsoft. What he's learned from 40 years of designing languages, including why IDs and programming languages go hand-in-hand, and many more. If you want a behind-the-scenes look at how three of the most used programming languages in history got built and how AI might change our usage of programming languages, this episode is for you. Before we start, I'd like to introduce our presenting sponsor for this season, Antasys. A definite trend that I'm seeing across the industry is a lot more focus on testing. Unsurprisingly, thanks to AI. We know that software is hard to test and we also know that AI is making it worse. Thanks to producing increasingly more code and more complex code. The bottleneck is becoming reviewing the code, testing it, and trusting it. Or is it? We tend to think that code reviews are the bottleneck because you cannot scale human reviewers with token spend. But the problem actually goes beyond code review. Really, it's about verification. We know that AI cannot verify itself. To verify the correctness of AI-generated software, we would need to catch issues that traditional tests miss, including issues that we did not even think of in a code base that is changing at superhuman speed. Oh, and we need to do all of this before deploying to production. The only way to verify that software works is to run it with realistic faults. And this is exactly what Antasys does. You can bring the system you work on under test and verify that it works as it should. Teams at Etcd and Jane Street are doing just this. And I'm also starting to use Antasys to test real-world systems. Over the season, I'll be sharing a lot more on how it works and how it can help verify that a system is bug-free. In the meantime, check out antasys.com slash pragmatic to learn more. Anders, welcome to the podcast. Thank you. It's brilliant to meet you. You've created so many widely used programming languages, including the one that I learned first to program with Turbo Pascal. How did you get into programming? Well, I was lucky enough to attend a high school. This is back in Copenhagen, that offered students access to a computer. It was one of the first high schools in Denmark to do so. And we're talking, you know, mid to late 70s now. And I sort of got bitten by a dent. You know, just this idea that you could program this machine and make it do things. You know, the wonder of figuring out how it was put together. Of course, it was like completely ancient by modern standards. It was like this HP 2100 with 32K of ferrite core memory. You could literally open it up and see the ferrite cores. I mean, it was amazing. You know, paper tape reader. And, you know, and then we got a one megabyte, 14 inch hard drive. And that was just state of the art. The bootloader was on paper tape because there was no ROM in the machine. So it started up and knew nothing. And so you had to type in the instruction sequence to load the bootloader that would then load the OS off of the hard drive. And as a kid, what did you start to program on it? What captured your imagination? Well, this was a Hewlett Packard. So it had Fortran, which I found to be very quirky. It had a very slow, basic interpreter. But then it had ALGOL, Hewlett Packard's version of ALGOL, which was an interesting compiler implementation because it didn't support recursion, which is kind of bizarre. You know, the call instruction of that machine would store the return address in the first word of the subroutine and then just execute. And then to return, you would jump to that indirect through that word. So if you called yourself, you'd just be gone forever, you know. And of course, there were no debuggers or anything to help you figure this out. So you just had to be real careful about which algorithms you used. But it was compiled to machine code and a brand, you know, and it was like you could build games, which is what we mostly did, like Lunar Landers and what have you kind of thing, right? And so, yeah, it was fun. Back then, things were so simple, right? You could see all the way to the bottom. I mean, there was just no layering and nothing. It was right on top of the hardware. I guess you needed to see all the way to the bottom as well, pretty much, right? Back then. Well, I mean, it was just so simple that you could, right? And that was the beauty of those earlier. That was true with the 8-bit micros and even, you know, the early PCs and whatever, right? And then we've just added more and more layers over time. We have a lot of layers right now, that's for sure. We do. And how did you go from building games to actually building your first ever compiler? And what was that compiler? I started in 79 at the Danish Technical University. At that time also, you know, this was right when 8-bit micros were starting to become available. 8-bit microprocessors, right? Yes, exactly. And it was usually these kits that you bought that you had to solder together yourself. And then, of course, they didn't work. And then you have to figure out why they didn't work. So you learned a lot about the hardware too. And I bought a British Z80-based kit computer called a NASCOM. And started learning assembly programming on that one. And then I also met with some college buddies and we ended up founding a company. And we had the first computer store in Copenhagen where you could walk in and buy a computer. One of these kit computers. And later we sold Apple IIs and VIC-20s and Commodore 64s and blah, blah, blah. You know, all of those different ones, right? TRS-80s. So I did a lot of programming on those and found that programming was really the thing that I enjoyed. And, of course, they all came with Microsoft's ROM Basic. Which was slow, but it allowed you to write programs. But I always missed having a real programming language. Something like Algol or that I had been taught, right? And then my buddy, the guy that I founded the company with, he was like, well, there's this new thing called Pascal. You ought to check it out. And it's even supposed to be simpler than Algol. Which was actually true of every language we had created. They got increasingly simpler as time went on. And Pascal was not that hard to implement. And so I got interested in trying to do that. And then wrote a little compiler that fit into a 12K ROM. That would compile a subset of Pascal. And you could then yank out the Microsoft ROM Basic and stick in our ROM instead. And then when you booted your machine, you were in this little environment where you could type in Pascal programs and run them. And that was sort of the early precursor of Turbo Pascal, if you will. Many years later, you joined Borland. And I think it was in 1989. And there you created Turbo Pascal, the programming language, but also the IDE, right? Well, there's a little more to that story. In that company that we had back in Denmark, I ended up writing eventually a full implementation of Pascal for 8-bit CPM 80. And then we ended up doing a joint venture with Borland, which was also a Danish company. It was originally founded in Denmark. And we made a royalty contract where they would sell our compiler on a royalty. And that's how I got involved in Borland. And we shipped that first product in 83, the first version of Turbo Pascal. And then that took off more than any of us had expected. And eventually that ended up being the thing that I did full time. Why was it called Turbo Pascal? I understand you added things on top of Pascal that was there. Well, I mean, it was called Turbo Pascal because it was fast. Back then, Turbo was like, this was like when Audi had their Quattros and their Turbos and whatever, you know. Turbo just meant fast, right? And this thing was fast and super interactive, right? And so Turbo Pascal it was. When Turbo Pascal became big, was it big just because of the compiler? Or also there was an ID, a dedicated ID for Turbo Pascal, right? Yes, yes. That was always the idea. And that goes back even to the predecessor of Turbo Pascal. This idea that it's not just a compiler. It's an experience, right? I mean, you don't just compile your programs. You also edit them. You also run them. You also debug them. You also have a runtime library. It all has to fit together. You know what I mean? And so Turbo Pascal was always about building that whole cycle and try to make it as interactive as basic was, as an interpreted language, right? And there was, you know, and that is like, I mean, now we're talking like business and whatever, it had nothing to do with technical, but it effectively meant that Visual J++ was never gonna be a product that companies would make a bet on because they full well knew that, you know, you're not gonna, you're not gonna write your app in a language that has been enjoined by a judge in San Jose, you know, or whatever. And so we kind of realized at that point, too, that maybe it's not a great strategy to place your development platform bet on technology that's licensed from a competitor. And that in turn, along with the sort of dev situation at the time, I mean, Microsoft's main development products at the time were in two camps. There was Visual Basic, rapid application development, loved by everybody, you know, because it was so easy to build apps, right? But performance-wise, it had problems. Extensibility-wise, it wasn't so great. To write new components, you had to write them in C++, and whatever. And then we had C++ with MFC and power and expressiveness, but really what people wanted was both. They wanted something that rolled both of those up, right? And then they also wanted modern things like garbage collection that, say, Java had, for example, right? And exception handling and a more object-oriented, component-oriented way of building your apps. And all of that was part of the genesis that led to .NET and to the C# language. So which one was first, .NET or C# inside of Microsoft? Well, they were simultaneous, I would say because we knew we wanted to build a runtime that was language independent because we knew that we wanted to run Visual Basic on it, and we wanted a way of running C++ on it, and we wanted the ability for other languages to host themselves on this runtime. But we also knew that we needed to build a language that would appeal to both Visual Basic and C++ users and give you sort of that golden thing in the middle, right? And to be frank, something that could compete with Java, right? And so that's why we started out building C#. And then when you started out building C#, what were your design goals? You mentioned a few things with garbage collection or exception handling, but how did you come up with like, okay, what would this language be? Well, like I said, I mean, the overarching thing was this power and productivity of C++ with the ease of use of Visual Basic, in a sense, right? But what it also meant was, we knew we wanted to build an object-oriented language. We wanted managed code or bytecode so we could target different runtime environments. We wanted garbage collection and exception handling, but also things like a unified object system where, and that's true in C++, like anything could be assigned to an object. And if it's a value type, we box it. And it's a self-describing object. So reflection, you can ask an object, what are you? And you can get all of the facts about it at runtime, and you can dynamically manipulate it in ways that just don't exist in a lot of other environments. And we knew we wanted to go there with that. We wanted a language that made this new model of properties, methods, and events first class because that was how components were built as opposed to just sort of functions and procedures and even objects, right? And then we actually also wanted to create a language that was standardized. We wanted to give this language to a standardization committee and try to, you know, level the playing field there. And all of those things were sort of like what was rolled up in C#. You definitely did it. C# was my first professional language where I worked for that, I think, for about five years, and I've seen both the tooling, the capabilities of the language, and I still think to this date in many ways that old version of C# was ahead of some languages today in some ways. So it's very interesting to see how rich that language was when it came out, and of course, the developer love that followed. But can you take us back of what did it take to build a language like this? Just in the more, again, software engineers, people who are listening, they're used to building SaaS apps, backend services, you know, like certain projects, but we are not familiar with what it takes to build a language, especially something with such large ambitions inside Microsoft. We knew millions of developers ideally would be using it. How did you get to this? Did you, how did you come up with the roadmap? How big or a large or small team needs to work on this? I think early on, we decided that we want to have a team of people design this language, not just one. I was sort of the guy who ran the group of designers, but we put together a group of six people or so, six, seven people, and we got in a room three times a week for two hours and just started the design. You know, like literally let's start from the top. What are the, we all knew what a, I mean, these were all people who had built or worked on programming languages before, right? And had seen all of the things you're supposed to do and all the things you're not supposed to do. And quite honestly, language design is 90% the same and 10% new for pretty much every language. Every language you build still has to have a compiler. Compiler is still built in pretty much the same way. And of course, as time marched on, people demand more and more. You have to have IDEs, you have to have frameworks, you have to have blah, blah, blah, blah, blah, you know. And it's all, there, there's, so there's a lot of experience you want to pull in and there's a lot of work that you're doing that isn't really per se new, but every time around, you try to fix the problems that you've been exposed to. This language design group worked together for years on end. And it was lovely to come in to work with a new idea and then immediately have five or six people that you could sit down and have a deep discussion with without first having to spend an hour level setting. Do you know what I mean? Yeah, yeah. And that worked really, really well because, because we could just jump right in, you know, and have two hours of technical discussion. And everyone was cognizant of, okay, if someone comes up with a new idea, now it's our job to try to shoot it down. Well, what's wrong with this idea? Do you know what I mean? And if it could go, if it could stand the test of that, then it was probably a decent idea. And so, so that was kind of how we, we ran the design. And then I, I wrote the specification of the language in parallel with our design meetings. And then we had a group that was in parallel implementing the compiler. In actually implementing it in C++ or rather C++ minus, because we didn't use all of the C++ features, you know, in that compiler implementation. But it wasn't, we, it wasn't until the Roslyn project that we, that we self-hosted the C# compiler. And Roslyn meaning that the compiler is in C#, right? Exactly, yes, yes. That was a project that came later to, to build the compiler in itself. And also early on, you know, this is, you got to remember back then, IDEs were not really all that fancy, you know? I mean, we have syntax colorization. State completion was kind of like, well, some IDEs were starting to dabble in it, but it wasn't really a norm. So we built like, in a sense, a classic compiler, but then we also built this like mini language servicey thing that, that sort of cut some corners and whatever, but could do some rudimentary statement completion and syntax coloring. But in a sense, we had two implementations that we had to evolve in parallel. And over time that became quite a drag, right? Because as we added generics and added other features and Link and whatever, and it was like, oh my God, now this is like, we got to go implement all of these features twice in the real compiler and in the language service, right? And so that ultimately led us to this project called Roslyn, where we built a single compiler that really is both, it's a compiler that can both function as a command line compiler and as an interactive service inside the IDE. TypeScript is built that same way also. And there's a lot of learnings from, from doing it that way that are still not being taught in school. There are many useful things not being taught in school, even when they are useful to learn about. One of the... And the Windows event loop and whatever, this was the right solution. Speaking of JavaScript, as C Sharp was becoming really popular across startups, enterprises, and so on, it was exploding in popular games as well. To this date, it's very popular with games development. But JavaScript was starting to become more popular. Can you take us back to your observations on how JavaScript went from the mid-90s to this script language no one really took seriously to just exploding in popularity? I think it was sort of a confluence of a number of things that happened in the early 2000s, right? First of all, the JavaScript platform, execution platform, matured a lot. Like Google did their excellent work on V8 and all of a sudden made JavaScript a fairly performant programming language. HTML5 got ratified and we were getting to a point now where you could actually build real UIs in JavaScript. And there was this device revolution that the iPhone set off and all of a sudden we have all of these different form factors. It's not just Windows PCs on the desktop anymore. It's all sorts of diverse devices, but lo and behold, they all run browsers with JavaScript in. Lo and behold, the real cross-platform language isn't Java. It's JavaScript. Exactly. And so the world started opening its eyes to that and started building larger and larger applications in JavaScript. And we saw that externally, but also internally. And one of the trigger events was when the Outlook.com team came to the C Sharp team and asked us whether we would pretty please productize this thing called ScriptSharp. And we go, well, what is ScriptSharp? It's this cross-compiler that allows you to cross-compile C Sharp into JavaScript such that you can basically treat JavaScript as an instruction language and run your C Sharp apps in a browser. And I'm like, well, why would anyone want to do that? Well, because then you can get a grown-up programming language with grown-up tooling. You can use Visual Studio. You can have projects. You can do all of these wonderful things that you can't do with JavaScript because JavaScript is just this scripting language with shitty tooling. And we were like, wow, really? Well, gosh, well, perhaps a better approach would be to fix JavaScript. I mean, surely you're not going to be best of breed in the JavaScript ecosystem by telling people to write in a different programming language, although plenty of people were, like, remember CoffeeScript and all of these other, like, languages that targeted JavaScript, right? Yes, so there were programming languages, right, which generated JavaScript, but it wasn't JavaScript itself. Yes. Yes, they were super popular. I mean, like, so many different things did that. But JavaScript is actually a pretty decent little language. There are just some things missing. You got to give credit there to Brendan Eich. I mean, he understood functional programming. And Brendan Eich, the creator of JavaScript. And he got functions as first-class objects right in JavaScript, which is godsend and beautiful. But it doesn't have a type system. And we knew from experience that you cannot build good tooling without a type system. You can build decent tooling, but it's never going to scale. It's never going to scale to large teams because you can't describe your intents in the code. There's no way of formalizing any of this stuff, and there's no way of analyzing it, and there's no way of using it in an IDE to give you statement completion and refactoring and go to definition and find all references and blah, blah, blah, blah. All of that stuff, right? That germinated the idea of, hey, we could create a superset of JavaScript that adds a type system, and then we could just compile it away. But then we have the foundation for great tooling, and then we could build a great tooling on top and actually create a wonderful development experience, right? That was sort of like what we set out to do. When you set out to do this, you not only set out to do this, but you set out for some reason to do it as open source, which took everyone outside of Microsoft as a surprise because old Microsoft under Steve Ballmer was notoriously perceived as anti-open source back then with Windows and C Sharp back in the day, of course, I'm talking about. Microsoft were slowly waking up to the fact that open source was not going to go away and open source was where developers wanted to be and they were voting with their feet. Yet there's a collective DNA, you know, that has been trained to pull you in the other direction, right? And so that battle was, we were right in the center of that. And we full well knew that there was absolutely zero chance that we would appeal to the JavaScript ecosystem with a proprietary programming language licensed from Microsoft. No, no one was going to come. It had to be open source. There was just no two ways about it, right? But getting that off the ground inside Microsoft, it took some pulling and we paid some taxes. We did eventually get the okay to do open source because we had two technical fellows, myself and Steve Luko, who was the other co-inventor of TypeScript, insisting that that was what we had to do. And so, okay, people weren't going to debate that. But of course, you have to pay the tax and be on Microsoft's open source repository called CodePlex, where exactly no one was. And so we were there for the first two years and it kind of was crickets, you know? And it wasn't until 2014 when we moved on to GitHub that things really started to get moving with adoption. And also, honestly, it totally changed our workflow. You know, there's open source and there's open development. And we were technically open source in the beginning, but it was not open development. We would sort of lop the source code out in this repository and scrape the issues off of that and put it into our internal issue tracker. But once we switched to GitHub, the entire workflow moved to open development also. And that, I love that workflow. And that's, we've been there now for over a decade and it's been fantastic. And it's what made the product as good as it is. Just over a decade later, so the language moved to GitHub in 2014. And in November 2025, the GitHub Octoverse report revealed that TypeScript became the most popular language across GitHub. Outside of the type system, what do you think made TypeScript this popular? And of course, we've had other languages, Python being the other very popular one. But what captures the developers' preferences this well? Well, I think, you know, it didn't just happen overnight, you know? And if you look back at, you know, all of a sudden we surfaced as number 10 and then we climbed slowly over the years up and sat next to JavaScript, right? And, of course, if you added JavaScript and TypeScript together, then we were already number one. It's just which syntax? Were you using type annotations or not? And more and more people over time just decided to adopt that. I mean, some early on were using JSDoc or whatever, you know, like these types and comments or that we also supported. But gradually, I think people just realized, hey, this is the right way to do it. And the reason they came, I think, is absolutely because of the better tooling. And I think we were totally right there, that, like, adding an erasable type system and then using that to enable great tooling is really where the programmer productivity boost is realized. And I guess this is where we cannot, like, not mention VS Code, which shipped that great tooling also as a free-to-use for most people, or at least initially for most people, which also made a big difference. Absolutely, yeah. That's our sister project, which is written in TypeScript. And so they were one of our earliest adopters, and we've worked pretty closely with them to this day. That whole interplay, that, in turn, is also what led to the invention of LSP, the Language Server Protocol, that now pretty much every tool vendor uses to enable interactive services in the IDE. called two expressions that may or may not happen at some point, but it's taken a long time. So anyway, but I mean, generally speaking, I think JavaScript is a nice little language. It just has some issues, you know, and then, and I think we're very good at teasing them out with our type checker, right? And so, so once you have a checker that can warn you, hey, you're about to do something stupid here, then it's not so bad. The thing that makes it interesting, I think, and unlike pretty much any other programming language is the gradual typing. This notion that you can have types, but you don't have to have types. Other languages force you to type everything, right? Because they in turn use that information to generate machine code, you know, based on what the type is, you know, different instructions for float versus versus whatever, where in JavaScript, the types or in TypeScript, the types that they are purely for the development experience and the checking. When the program runs, they're all gone. Now, of course there are still types, but they're all dynamically computed, but that's kind of interesting because that means in the language, we don't necessarily have to prove 100% correctness. And a lot of language features that we have, we can't a hundred percent prove correctness. Like in a structural type system with recursive types, there are just cases that you can't analyze because the types are infinitely recurring. The more you try to relate two types, the deeper you go and you're just staring into the recursive abyss. Do you know what I mean? But you can kind of go, well, well, we've proven it to four levels. That's probably good enough. We're just going to say it's good enough. And then, you know, if everything else works out, we're going to go, sure. That you can't do if you were to go generate machine code that then would have indeterminate behavior, right? But if JavaScript has a runtime where everything is well-defined already, so if we're checking 99% instead of a hundred percent, well, heck, that's better than the 0% that JavaScript checked, right? And it gives you like language features that no other languages can provide because they can't get to a hundred percent. It's interesting how constraints lead to innovation or even limitations can lead to more innovation. Speaking of innovation, one of the biggest innovations that is everywhere is the AI agents, AI coding tools that us software engineers, most software engineers are using, increasingly using AI agents as well. As you're developing languages on a more, I guess, niche team, what kinds of AI tools are you using or how is AI helping your language development work? May that be TypeScript or C Sharp. Day to day, I work on TypeScript and I can certainly talk about how we've been in the process of moving TypeScript to native code for the last year and a half or so. In the beginning of that project, AI was nowhere near as capable as it is now, and therefore we could not really use much of it in the beginning. At this point, though, I'd say we're using, we're using AI fairly well. Obviously, we're on GitHub. We use AI to code review, pull requests. That in the beginning was not all that great, but now it's actually getting a lot better. We use AI to implement issues or fix issues, simple issues. And then it succeeds some of the time in this port that we're doing, you know, because we snapped a copy of the source code from a year and a half ago and then ported it. We have a backlog of PRs that need to be moved on to the new native compiler. And so we're using AI to help us move those pull requests. And that's actually going fairly well at this point. And then we use it for a bunch of drudgery, drudgery work like, okay, here's this feature. Please write me some tests in the same style as these other tests, right. And kaboom. It's like, no one likes writing tests. AI loves writing tests and it'll just pump out more tests and great, you know. So, so we're trying to use it to get rid of all the toil that otherwise we would spend our time on, right. But I would say we're not at a point where it absolves us from understanding what we're doing. Not at all. No. Well, plus your level at the stack, if you will, because you're building a language, it might argue that someone really needs to understand, at least one person, ideally the whole team needs to understand those fundamental parts, right? Oh, absolutely. I mean, and it's language is interesting in the world of AI because AI, like a lot of, like this conversation, we wouldn't have this conversation if it wasn't for languages because how would AI get to determinism without programming languages, right? I mean, AI is by design stochastic and indeterminate. It might give you a different answer the next time you ask it the same question, either just because random or because there's a new model or there's a whatever. It's non, it's not that it's, there's no determinism, yet we can't build applications if they're not, if they have non-deterministic behavior. I mean, what would a banking app look like if it like decided to hallucinate or whatever, right? So you have to have something that, where the rubber meets the road and where you can reason about, and where you can replicate the behavior every time you run the app, the same thing happens. Absolutely. I mean, I even see it in a bunch, I think almost all AI agents or tools these days when you ask it something to do with data, oftentimes it will start writing a Python program because I think the AI designers figured out that you at some point want to turn some non-deterministic into a deterministic, and what is the thing that we know most efficient? Yeah, don't ask it for the answer, ask it to write a program that computes the answer. And you will know that that will be deterministic. Yes, exactly. Yes. Yes. It's very interesting. But speaking of languages for AI, a question that comes up, of course, because AI is everywhere, is generating a lot more code. What is your take on either modifying existing languages for AI usage based on what you're seeing, the patterns, or potentially coming up with, would it make any sense to come up with a language that is more suited for AI agents to use? Well, my flippant answer there is, you know, the language that's most suited for AI is the language that AI has seen the most of in its training set, right? And that's why you could argue AI does really well on JavaScript and TypeScript and Python because it's seen an awful lot of it. And there's an awful lot of that still. And then, and so, and that just reinforces itself, right? And you could argue, well, the reason TypeScript and JavaScript are popular, well, that's mostly to do with the browser and not so much to do with AI, right? But it's interesting to look at why is AI targeting TypeScript versus just JavaScript. And there I think the types actually help guide the AI to producing better programs. And I think our combination of the ability to type something when there's no context, but also our ability to infer it when there is context is just the right combination, because if you were to force AI to write a type annotation on everything, then it would probably get it wrong more often because now it has to keep track of all these types and it has to just repeat itself over and over and over, right? And so types are important where there's no context, but inference is super important for the dry or do not repeat yourself principle, right? And fewer tokens generally makes AI more efficient. And so, so I think we have a very nice combo there in, in how, how you can just sort of type the outermost parameter and then everything flows from there on in, right? Now, one, one thing that AI is already resulting in, again, for the GitHub team share stats, so this is also open data that AI agents are just generating a lot more code. I mean, they're both quick to generate. They also like to be sometimes verbose. Knowing that we are already seeing a lot more code pushed everywhere and from at a project level at a, at an aggregate level, what do you think language characteristics could become more important in this world of, of just a lot more code oftentimes generated by machines? I mean, you could argue that we, we're already past peak truth on the, on the, on the internet, right? And now there's, there's just more and more garbage every, every day. I'm never just looking at the language. It's you're looking, you've got to look at the whole picture, the whole experience, because really what you're doing is you're creating an experience, an experience that programmers will spend the majority of their working life in, which is why, why programmers become so attached to their tools, you know, and their languages, right? I mean, it's, it's almost a religious thing which, which language you're on, which tool you're using, and because it's, it's so ingrained in your workflow, and, and it so enables you to, to be in the zone, right? So that, I think, is the, that's the key to focus on, and that's what I've tried to do with, with the, with the, the work that I've done over the years. And it sounds like this is why from the very beginning you also focused on the IDE, the, the tool where developers spend their time in. Yeah, you can't have one without the other. Well, you can, but, but it just not, it's not nearly as effective. Yeah, one question we're starting to see, or it's more of a question mark, is, well, how much are we going to be in the IDE all day versus these new interfaces, which might be agents where you can manage multiple things, or command line, which is again just something where we found that agents can work asynchronously, but I think we're still figuring out as an industry of, like, what, what will come next. Yeah, I don't know that we can see the steady state at this point because it's, it's evolving so much, but I still believe that, that programmers are going to be relevant in, in, in this equation, you know. I fundamentally believe that. What about performance and efficiency? Early on in your career, you just mentioned that your first computer you had on how many kilobytes it had and how you, you fit your compiler into 12 kilobytes, which these days I cannot even create a text, a text file that's smaller than that, or it's very hard to do, right? But it seems in those years, in the, you know, like a few decades ago, writing efficient programs was important, and over time, my perception is that it's becoming less of a focus. What is your take on that and do you think It's kind of fine for us developers to forget about efficiency or we're just allowed to do that because of we have more resources, or maybe this will change? I think it's a case of, it depends. There are certain classes of apps for which efficiency is absolutely key. I mean, the, the kind of program that my group works on, like compilers, tooling and whatever, you know, people do care. That's why we're spending a year and a half moving to native code. Inference in the cloud, on the, up against data, I mean, oh my God, you know, like financial, fast trading, whatever, it's all about perf, right? I mean, and the speed of light and like trying to, trying to move your trade faster than the other guys. I mean, so, so there are lots of places where perf is king, but there's increasingly also places where, where perf doesn't really matter because, you know, it's so fast anyway that if it, even if it's 10 times slower, you still can't detect the difference. And so it's just not worth optimizing there anymore. It depends, I think, on, on, on the kind of app you're building. It's a good reminder that not all use cases are, are born equal. I'm interested, what is your personal development setup like these days? Well, I'm an old Windows guy. I still, I still, Windows is my desktop. I have a Lenovo P1, you know, I like, I like just keeping everything portable, so I don't have a big screen or whatever. I just, but this is like, you know, what, 15-16 inch laptop with a nice OLED screen and a nice keyboard, and that's, that's what I do my coding on, you know, pretty much exclusively. And what tools do you use in terms of? Oh, I have VS code, VS code all the time. VS code and GitHub all the time. Yes, yes, yes. And, and for AI coding assistance? It's mostly the GitHub and VS code stuff, so which means, you know, I mean, well, you can, you get to choose your, your, your LLM there, right? I mean, but it's that workflow, I think, generally speaking. It's limited how much we've been able to use LLMs in implementing our compiler and implementing new language features. It's like, it just, it's, it's good at surfacey stuff, but when it comes to like getting the big picture and how do types and symbols and binding and parsing and all relate, then where's, what's the most efficient data structure here and whatever, it's, yeah, it, it's not quite to that level. I'm also wondering if the lower you go into the stack, maybe that'd be very high performance code or, or very concise code where all these things matter. Maybe the applicability starts to drop because again, we know, we, we already see this with LLMs, they're amazing for greenfield work when you have an existing large application. It's, it's useful, don't get me wrong, but it's not nearly as useful. Yeah, and, and we are one big brown field because, you know, we already have a huge code base, right? And it's got to, it's got to fit in there. Plus, I mean, to be honest, I mean, there are only so many compilers in the training sets of, of, of AI where, where there is a gazillion gooey apps written in React and whatever, right? So no wonder it's good at those, right? I was interested in reflecting a little bit on your career. You've now been at Microsoft for, for 30 years and you've been working on programming languages for 40. That's even a lot to say, but in this industry, it's pretty common for people to just change jobs every three to five years or so. What has kept you at a company for, for so long and also in, in a similar area for even longer? Well, there's, there's just something about developer tools that, that is just what I love to do, you know, and, and programming languages. They're, they're, they're complex, algorithmically complex problems to solve, and I, I, I, for some reason, like that. They have fewer dependencies on other things, so you're, you're, you're building from the bottom yourself. Do you know what I mean? You don't have to, like, sit on top of someone else's framework and, and swear at them when it, when it doesn't do what you want it to do, right? So, so that kind of works for me, right? But, but the thing is, like, doing programming languages, you come to realize, it's a long play. I mean, if, if you look back at the, the stuff I worked on, it, it, it goes in 10-year cycles, at least. And TypeScript didn't really, for example, or C Sharp for that matter. I mean, it took it. It takes 10 years to get to, you know, version one is great, but it has all sorts of issues, and you've got to do version two, and then it's not until version three that it really starts to be great. But then now you've got to convince people to actually adopt it and, and, and it's just, it's a long play. You got to be willing to do the long play. And I think, like, having been at a, at a company like Microsoft is, is, it's been great because to be put in a position where a company like Microsoft is putting their might behind your efforts on creating a programming language, that's not an opportunity you get in a lot of places, right? And that has been fantastic, but also, you know, the fact that Microsoft is fundamentally a developer-focused company. And they, they always have been. Yeah, yeah. Developers matter. It's not, it's not advertisers who are, who are paying the bills. It's, it's developers and enterprises that, you know, and, and I like that, like where you feel like you're doing an honest day's work and people are paying you for it and it's, it's good stuff, you know. As closing, what, what is a book that you would recommend and why? I always recommend the same book, which is Niklaus Wirth's Programs Plus Data Structures, equals algorithms. It's actually like available online now. It was written in the 70s, but that was the book that, it was a revelation for me to read this book. This is how I, how I learned about hash tables and the how to construct a small compiler and whatever, and it was, it was just wonderful. It's very light on symbolism and very rich on examples. And, and I was always an engineer, and so that book just appealed to me. And I think it's still in, in, in a lot of ways super relevant today. The basics have not changed, have they, too much? No, no, certainly. And, and particularly when it, when it comes to programming languages, heck, it's, it's a, it's a well-established discipline, quite honestly. Yeah, it's been around for 50 plus years. Well, Anders, thank you so much for this in-depth conversation. Oh, my pleasure. This was a lot of fun. I hope you enjoyed this rare conversation with Anders as much as I did. An interesting part I keep thinking back to is how Anders said that programming language design is a 10-year cycle at minimum. Version 1 has issues. Version 2