Anders Heilzberg is one of the biggest living legends in the tech industry. He created Turbo Pascal to alpha IC 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 versus Microsoft lawsuit over Java. The behind the scenes story of TypeScript and why Open Source Engage was a huge deal inside of Microsoft.
What he's learned from 40 years of design languages, including white IDs and programming languages, go hand in hand. And many more. If you want to behind the scenes look at how three of the most used programming languages 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 the season, Antisysys. A definite trend that I'm seeing across the industry is a lot more focused 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 for 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 test myths, 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 Antisysys does. You can bring the system you work on under test and verify that it works as it should. Seems that at CD and Jain Street are doing justice, and I'm also starting to use Antisysys 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 block free. In the meantime, check out Antisysys.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 that 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. We're talking mid to late 70s now.
And I sort of got bitten by then, 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 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, 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 alcohol, Hewlett Packard's version of alcohol, which was an interesting compiler of implementation because it did 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 software team 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. So, 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 use. But it was, it was compiled to machine code. And they 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. I 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 micropositors, 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 what it didn't work.
So you've 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 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 and which was slow, but it allowed you to write programs. But I always like 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 want to check it out. And it's even supposed to be simpler than Algol, which was actually true of every language via 3A, that 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 them, 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, which 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 quadros and their turbos and whatever, you know, Turbo just met 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 IDE, a dedicated IDE 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 program.
You also edit them. You also run them. You also debug them. You also have a runtime library. It all has to like 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? But giving you the performance of our compiled language and the better semantics and syntax of Pascal versus basic. And so that was sort of the idea from day one, you know, focus on the whole cycle. And so when you were building the compiler, you were already thinking of ways that the IDE, for example, could make sense or could have helpful features for either editing or debugging, for example. Oh, absolutely.
You know, the first version of Turbo Pascal didn't have it. You know, you would just use right-line statements and then you'd just see what happened, right? But often, if you had some error and it blew up with a runtime error, we would print out the address of the runtime error, which is where was the program counter at that point. And then we had a mode in the compiler where we would say compile, but stop at this address. And so the compiler was real simple.
It would just produce object code. And then once it hit that address, it would just say, well, whatever I'm syntactically looking at right now, that must have been around where the error was. So that was like how you could go to the line where the error had occurred. You know what I mean? It's not like we had like line maps or debuggers or any of that stuff.
We just had the compiler and it was just easy to make it stop at a certain address, you know, in the object output and then show you where it was in the source code. When you think Turbo Pascal was so popular, I remember backing on this one. I first began the experience. It was at schools. It was outside of schools for production software.
And you said yourself that it spread like wildfire. It was just better than all the competition. It was faster. It was smaller. It was more interactive and it was also cheaper.
So it was like 10 times better at a tenth of the price of the competition, right? Compilers back then used to cost $500 and they were just compilers and then you have to have an editor and blah, blah, blah. And it was like this whole long winded cycle of inserting different disks with compiler pass one and two and what have you. And here was this thing that just like made it all go away and you could get it for $49.95. And for $49.95, I mean, heck, that was worth it just to get the manuals.
I came with it, right? I mean, so so there was very little piracy because it was so cheap. Although speaking of piracy, we always have the joke about the Russian site license, how we sold one copy to Russia and then that got copied everywhere. But after a Turbo Pascal, you built Delphi, which was an even bigger set of them anyways. This was now an integrated environment for Windows development.
How did you evolve ideas from Turbo Pascal and Delphi? The big thing that happened there between Turbo Pascal and Delphi was the advent of the graphical user interface, right? We switched from running DOS in text mode to running Windows in a GUI and that meant a new kind of application, right? That you had to create. And at the same time, competitively, Microsoft had created Visual Basic, which was a very impressive product.
But still had some of the very same flaws that we knew how to compete with, right? In terms of interpretive versus compiled and extensible versus not or not extensible versus hours that had classes and object orientation and blah, blah, blah. First, we set out to build a Visual Basic competitor. But then we also realized that, well, that's not really enough of an angle. And then there was this other phenomenon that was happening at the time, which was called client server applications.
And there were a whole bunch of 4GL application development tools for database connected client server apps. And so we set out to build a tool that was like as interactive and rapid application development as Visual Basic, but with a compiler behind it, target it also at client server enterprise apps. And that was what Delphi sort of was about. Right. It worked out really well.
I mean, that was a product to this day is still being used actively by a whole number of programmers. I was very surprised when I worked at Skype right after Microsoft bought it. I know, yeah. The Skype application, you probably know this, it was built in Delphi. It was 2012 or 2013.
There was a plan to rewrite it and move it onto something else. That rewrite midway a year in stopped. So I'm guessing that until the end of that Skype application was decommissioned, maybe a year ago. It's amazing, isn't it? I mean, Delphi was and is in some ways a wonderful way of building Windows desktop apps.
I mean, they had a great, you know, the VCO, the Visual Class library that allowed you to inherit components and install them on the palette and make drag and drop work for your forms, designers with components that you had built and whatever. It was, it was pretty cool. Yeah. And we already heard the Microsoft link with Visual Basic. So you joined Microsoft in 1996, you worked on a J++ and then later C-sharp.
But can you see it's back to that moment in time? What was the programming environment like? Well, the environment, particularly around the time where I joined Microsoft, the mid-90s, Java had happened. Well, the browser had happened, first of all, and Java script, but Java script, no one really paid attention to Java script because that was just this little whatever thingy that was in the browser, you know, and it was slow and it was like, and no one uses that. But then there was this Java thing that allowed you to create applets.
Oh my God. Oh, yeah. Fantastic. And right on the browser everywhere. Yeah, everywhere in the browser and everywhere, supposedly.
And this language that was like simple, yet had object orientation and byte codes and like, like was platform independent. And I mean, it was like, everyone was running around with like, with their heads got off thinking. This was the end of languages. So, you know, Java was going to flatten the universe and then we're all just going to be writing Java and Java applets and that's it. You know, and I actually came to Microsoft ostensibly to be the architect of Microsoft's Java development tool and worked on Visual J++ 6.0 was the version that they had Visual J++ 11 at the time I joined, which was basically take Visual C++ plus, get out the C++ compilers, they get a Java compiler and call it good.
But it wasn't interactive. It wasn't rapid application development. And whenever I came sort of with a whole host of knowledge of how to build interactive development tools. And that's what we set out to do with Visual J++ 6.0. And we also, of course, knew that, hey, you know, I mean, people are going to be running on Windows and they're going to want to be able to build Windows desktop apps.
And so we built a class library that allowed you to do that. This was the precursor of WinForms, you know, in some ways. How did the development of J++ go and eventually how did it lead to the idea of like, okay, let's do something else completely different. Well, you know, development of J++ went great until the big Sun Microsoft lawsuit got into it. 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 going to be a product that companies would make a bet on.
Because they full well knew that, you know, you're not going to write your app in a language that has been enjoyed 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 they were so easy to build apps, right? But performance wise had problems, extensibility wise wasn't so great.
You had 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 like modern things like garbage collection that say Java had, for example, write an 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 dotnet and to the C-sharp language. So which one was first dotnet or C-sharp 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-sharp. And then when you started out building C-sharp, what were your design goals?
You mentioned a few things with garbage collection or exception handling, but how did you come up with this language view? Well, like I said, 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-sharp, like anything could be assigned to an object. And if it's a value type, we box it, but it's a self-describing object. So reflection, you can ask an object, what are you?
And you can get all the facts about it at runtime and you can dynamically manipulate it in ways that are just don't exist in a lot of other environments. So 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 level the playing field there.
And all of those things were sort of like what was rolled up in C-sharp. You definitely know C-sharp was my first professional language where I worked with it, I think, for about five years. And I've seen both the tooling, the capabilities of language, and I still think to this date, in many ways that old version of C-sharp was ahead of some languages today in some way. So it's very interesting to see how rich that language was when it came out. And of course, the developer loved that, followed.
But can you think it's back? What did it take to build a language like? Just in the more software engineers, people were listening, they're used to building SAS apps, back in services, 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 would be using it.
How did you get to this? How did you come up with the roadmap? How big or 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. Literally, let's start from the top. What is that? We all knew what to do. 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 of 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 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, blah, blah, blah, blah. And it's all 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 due. 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 into 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. And that worked really, really well because we could just jump right in and have two hours of technical discussion. And everyone was cognizant of, OK, if someone comes up with a new idea, now it's our job to try to shoot it down.
What's wrong with this idea? You're not a man. And if it could go, if it could stand the test of that, then it was probably a decent idea. And so that was kind of how we we we ran the design. And then 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 in that compiler. But it wasn't we it wasn't until the Roslin project that we that we self hosted the C sharp compiler. And the Roslin meaning that the compiler is in C sharp, right? Exactly. Yes, that was the project that came later to to build a compiler in itself.
And also early on, you know, this is you got to remember back then, IDs were not really all that fancy. You know, I mean, we have syntax colorization. State completion was kind of like, well, some IDs 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 service thing that sort of cuts and 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 Roslin, 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 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 these really useful tools that I must mention is our season sponsor, TurboPuffer.
TurboPuffer is a ridiculously scalable, fast and cheap vector and full-text search engine built by an engineering team that I really like. The first time I heard about them was when I was talking to one of Kerstor's co-founders about how their vector database could not keep up with the number of code bases that they were adding. This was back in 2023. Kerstor did something seemingly risky. They took a bet on what was a little known and rel to the new product at the time, TurboPuffer.
But it paid off. Kerstor moved their semantic search work load over, and TurboPuffer was indeed able to handle Kerstor's massive, ever-increasing load. The reason has everything to do with smart engineering. TurboPuffer is built on top of object storage with smart caching on NVMe SSDs. Kerstor's active code bases get loaded into the cache, so searches are fast, and inactive code bases fade into object storage.
Kerstor has so many good things to say about TurboPuffer. They cut their semantic search calls by 95% when they switched. They think of TurboPuffer engineers as an immediate extension of their team in Slack. And TurboPuffer is one of the few pieces of infrastructure that they have not had to worry about as they scaled. Today, TurboPuffer indexes over four trillion documents for a vector and full-text search, and is used by the likes of Intraific, Notion, Linear, and many others.
I'm getting to know the TurboPuffer team and will share more about some of the cool things that they do behind the scenes throughout the season. If you need vector search or full-text search at scale, think TurboPuffer. Check it out at www.turbblepuffer.com.com. When it comes to useful tools, I need to also mention our season sponsor, WorkOS. One theme of today's episode with Anders is how he has spent the time frame thinking about developer productivity on a scale that most of us do not.
Decades, not monster quarters. WorkOS takes the same kind of long-term view on enterprise infrastructure. SSO, SCIM, R-Back, audit logs, they've spent years getting these right, so you do not have to spend weeks implementing them. That's why the fastest growing AI companies trust WorkOS. Visit WorkOS.com to learn more.
And with this, let's get back to building languages with Anders. And when you're building a language, as your product was, I guess, the language itself, how did you get feedback? Of course, you had the, you already said the group criticized it. Did you have an internal key to testers? Again, for like a back-end service, you would typically have dogfooding, all the testing, beta testing, and then you go public at some point, but this is not your average software service, for sure.
Yeah, I mean, luckily we had internal clients, the .NET framework, very quickly started implementing in C Sharp. They had sort of used a hacked version of C++ to implement, which was kind of odd because I mean, it was like targeting by codes, but not really. So they switched to C Sharp, and that helped a lot. And then we had other internal teams using it. And so we got a bunch of feedback that way.
And then we had, you know, the cycle was not that long, right? I mean, I think we started in late 98. And by the PDC of 2000, we had, we signed up, I mean, we basically gave away beta copies, right? And got tons of users onto it. Now, C Sharp introduced a lot of new features that were Net New, I think, to programming languages. Link is certainly one of them.
But one thing that might have been maybe one of the most influential parts that other languages adopted as inspiration was the async await setup. Looking back, what do you think you got right with this design? And why did it become so copyable across languages like JavaScript, Python, Rust, and others? Well, a lot of languages are built around cooperative multitasking in the sense that they have an event loop that sits and dispatches events. And then, you know, you handle the event and then you yield back to the event handler loop, and it all runs in a single thread cooperatively, right?
The problem with that is if you then want to do some long running work, how do I stop in the middle of this piece of long running work and yield back to the event loop cooperatively, right? And then when my result is ready, then I can come back and continue executing here. Well, in order to do that in an inverted architecture like that, you have to build a state machine. And state machines are notoriously hard for people to implement, because you've got to move all of your state off of the stack into objects. You've got to remember where and then you have a big case statement that envelopes your entire logic and it's like it's a nightmare to figure out, right? But the transformation from, seriously, executing code into a state machine,
that's this continuation processing style translation is actually one that you can do in a machine-based fashion. You can have the compiler right to state machine if you introduce syntax that allows you to indicate where you want to yield. And that's what a weight is. A weight is basically, I'm saying, I want to yield here and then when, and I want to yield this promise, and then when the promise completes, I want you to come back here and continue executing. And then the compiler right to state machine around it and it actually turns it into this big switch statement, you know, and moves all the state that survives across the awake into something that's heap allocated so it can be brought back and doing all of that work is something that compilers are great at. And so that was sort of the
idea that we have this new style of programming where we're using promises or the equivalent of promises and the ability to yield and then we have callbacks and but trying to write your program in that style. That's also what JavaScript suffers from a lot, right? It's like all this callback style stuff. And when they say, wait, you get sort of the illusion that you're just writing normal sequential code and then the compiler does the painful transformation for you. And that turns out to be really useful. Now, arguably an alternative way of doing this is to use threads in the OS.
But the problem with threads is that they come with preemptiveness and the OS has the ability to preempt you at any point in time. And that's not necessarily what you want. And your UI now, you have to be multi threaded in your UI and all sorts of other problems come along with the plus threads are heavyweight and typically not well suited for lightweight tasks like you can do with async function. So their pros and cons, you know, like, async and wait introduces this notion of function coloring, which is unfortunate where you have two kinds of functions, async functions and regular functions and all the red functions are called the blue functions, but the blue functions can't call the red functions. And so that means once you want, you know, a red function, now everything above it has to be read them. And so if you want from a sync function to call something async,
well, then you got to turn this function into an async function and it's called has to be etc, etc. Right. So that's unfortunate. And that's why some environments like go, for example, has as go routines and green threads, which are really language emulated lightweight threads that kind of do what I'm talking about, but at a much lower cost, but you avoid the function coloring. So there's a bunch of different things, but you know, but for an environment that already exists like JavaScript or like C sharp and the windows of it loop and whatever this was the right solution.
Speaking of JavaScript, as as C sharp was becoming really popular across startups, enterprises, and so on, it was exploding in popular games as well. So that's very popular with games development, but JavaScript was starting to become more popular. Can you can you take us back to your observations on how JavaScript went from, you know, like the mid 90s to this script language known really seriously to just exploring a 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
make 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 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 no one would be hold. They all run browsers with JavaScript. No one would be hold. 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
see the C-sharp team and asked us whether we would pretty please productize this thing called script shop and we go, well, what is what is script shop? 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 the 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 to 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 languages that targeted JavaScript, right?
Yes. So they were programming language, right? Which generated JavaScript, but it wasn't JavaScript itself. 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 get 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 Gautsen 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 other 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 write all references and blah, blah, blah, all that stuff, right? That germinated the idea of, hey, it's we can we could create a super set of hours. Good. That adds a type system. And then we can just compile it away. But then we have now we have the foundation for great tooling. And then we can build
a great tooling on top and actually create a wonderful development experience, right? That was sort of like what we set up 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 received as anti open source back then with windows and C sharp back in the day, of course, I'm talking about, you know, Microsoft was 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 and so that battle was we
were right in the center of that. And we've we full well knew that there was absolutely zero chance that we would appeal to the JavaScript ecosystem with a proprietary programming language license from Microsoft. No, no one was going to come. It had to be open source. There was just no two ways about 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 Lugo, who was the other co-inventor of of of of types of insisting that that was what we had to do. And so okay, there 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 Coaplex 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 and we were technically open source in the beginning, but it was not open development. We would
sort of lock the source code out and it's repository and scrape the issues off of that and put it into our internal issue tracker and then, you know, 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 moves to GitHub in 2014. And in November 2025, the GitHub
booktubers 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 our languages Python, being the other very popular one, but what captures the developers preferences as well? Well, I think, you know, it didn't just happen overnight, you know, and if you look back at that, 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 we're using JS doc or whatever, you know, and like these types and comments or that we also supported. But gradually, I think people just realized, hey, this is 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 pro where the program of 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 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 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 ID. Oddly, it isn't
until this port to go now that we're switching to LSP, we had our own precursor of LSP because that was being existed when we first integrated TypeScript into individuals to your code. But there are a lot of learnings from that. So it's been an incredibly symbiotic and fulfilling experience to build these two projects in parallel in open source. And I think it has totally changed people's view of Microsoft in the developer ecosystem. For us, developers who again are not as familiar with compilers themselves. We of course, like I use TypeScript and I'm aware that there's some compilation
going, could you give us a brief overview of what the types of compiler pipeline looks like in terms of parts and what parts you specifically focus on more? Sure. It's in many ways a very typical compiler and in many ways not pretty much every compiler has, you know, what's known as a lexer or scanner that takes text and turns it into tokens. And then typically on top of that, you have a parser that takes the tokens, checks their sequencing and then makes abstract syntax trees, which is a, you know, a tree that you can navigate that effectively is a map of the source code, you know, but broken into syntactic primitives and checked that, you know, like syntactically everything is or grammatically that everything is correct. So those are the first two stages of the pipeline.
Then we have, well, we have one extra pass that we call the binder, which is, you know, once we have the parse trees, then we bind simple information to them where we find all of the declarations of variables and whatever and build simple tables and attach them to their functions such that we can then later look up names effectively. And we also build in the binder, we build a control flow graph and I can talk about what that helps us do. And then we have the type checker, which is the largest part of our pipeline. And that's the thing that checks semantically that your program is correct. It's the thing that figures out types and checks that the types relate correctly and that you're assigning the right thing to the right thing and then that, you know, that you're calling something that actually exists and so forth. And then we have an optional stage at the end called
our miter. And normally the miter infrastructure in a compiler is also quite big because that's where you go from intermediate representation to machine code or byte code. Now in our case, we just erase types, if you will. Well, we kind of do two things in our compiler actually. Early on, it was very much about a, erasing the types, but be also down leveling your code. So we would
take newer ECMAScript features that weren't yet supported by the runtimes, for example, classes. And then we would down level them to constructor functions and whatever. And so we would rewrite the code. And that was a very popular feature early on now, pretty much every browser is evergreen and, you know, like ECMAScript features are caught up. And so that's not as important anymore.
So our miter is effectively, you know, I think that just erases type annotations and spits out the JavaScript code that can run unannotated and also can spit out declaration files, which are summary stuff, your modules and so forth. But those are sort of the stages. Now, the thing that's interesting about a compiler though is that it's built in a manner that where it can function in a highly interactive mode, which is what the ID uses. Normally, you know, like compilers, they just run through these stages and, you know, the output is just whatever gets emitted or some error messages, right? But in an IDE, you know, the compiler is a service. And what we do in that service
is we basically take a program that is perpetually broken because you're typing. And yet we try this in tactically or semantically analyze it. And because we need to know when you press dot here, what could you what could come next? Well, that means we need to know what is the type of thing you dotted on in order to figure that out. We may have to resolve stuff. We may have to look at
the STs over here and whatever. And all of that has to happen within 200 milliseconds or else people think the IDE is slow, right? Well, what if you have 500,000 lines of code? You can't compile all of those in 200 milliseconds. So you got to be super, super deferred and interactive. And so you got to
do minimal amounts of work. And that's how our compiler is built is it tries to front load, like, for example, like you have 500,000 lines of code. Well, let's say in 500 files, well, we can build the ASTs for 499 of the files and just sit on them. We don't have to rebuild those because you're not editing in those files. We just have to update the AST of the current file you're in. So that goes
500 times faster, right? Then then if we had to do all of it, and then we don't actually have to figure out all of the types in here, either we can just start where you're at and then just resolve just enough to answer the question that you're needing an answer for right now. And so everything is lazy and deferred and functional and reusable inside the compiler. And it's a very different way of writing compilers than what the textbooks will traditionally teach you. Yeah, because I guess this is now these are interactive compilers, if you will, right? It sounds like it's more than a compiler,
or a lot more difficult problem to solve. The same engine is there, but you got to build it in a manner where it can be very interactive. And that was not typically important for compilers, you know? And so TypeScript is a super self JavaScript. What are some features you would try to add if only JavaScript would allow it, or if you were able to influence JavaScript's roadmap, what is something that you feel could make TypeScript a lot better? But of course, there's going to strain
there. We track the ECMAScript committee and new language features that get developed in ECMAScript. We implement once they reach stage three or four in the standardization committee, and then we've sort of been on that train ever since the beginning. So there is a pipeline that supplies new language features in a standardized manner. We sort of see it as our purview to define the type system on top, right? So that is, if you will, our playground. Now, I still have things that I wish I could have
in the language itself. I mean, I like functional programming. I like functional programming languages, and key to them is that everything is an expression. There's really no distinction between statements and expressions. And so one of the features that JavaScript lacks in my estimate is the ability to give symbolic names to temporary results and expressions and then reuse them. This is the let
blah equals whatever in some expression that functional programming languages, you know, like camel and whatever all have. And it's nice because you could just stay in an expression context and you can just dot things together and whatever and sort of do this more fluent style of programming. But then all of a sudden you need a name for something you want to reuse and now you've got to pop out and declare a variable and turn it into state. Anyway, you know, that's one thing that I would like to fix. There's there's something 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 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 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 in versus whatever where in JavaScript, the types or the types of the types that they're purely for the development experience and the checking when the program runs, they're all gone. Now, of course, there's 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 100% 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 to types, the deeper you go and you're just
staring into the recursive abyss, 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 100%, well, heck, that's better than the zero percent of JavaScript check, right? And it gives you like language features that no other languages can provide because they can't get to 100%. 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 AI agents, AI coding tools that us, software engineers, most software engineers are using, increasing using AI agents as well, as your 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 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 that it succeeds some of the time in this port that we're doing, 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 they'll just pump out more tests than great. 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 that might argue that someone really needs to understand at least one person, the whole thing 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 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 it's random or because there's a new model or there's a whatever. It's not... It's not that it's... There's no determinate yet. We can't build applications if they have non-deterministic behavior. I mean, what would a banking act look like if it
decided to elucidate or whatever, right? So you have to have something where the rubber reach 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. Exactly. Exactly. The thing that we know most efficient... You 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. 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 with 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 flippin' 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 train except, 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 that just reinforces itself, right? And you can argue, well, the reason
TypeScript and JavaScript are popular, well, that's mostly to do with a browser, 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 the 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 that would have 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 I think we have a very nice combo there in how you can just sort of type the outermost parameter and then everything flows from there on in, right? Now one thing that AI is already revolting and again for the GitHub team share stats, so this is also open data that AI agents are 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 a project level at an aggregate level. What do you think language characteristics could become
more important in this world of just a lot more code oftentimes generated by machines? I mean, you could argue that we were 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. It gets harder and harder to suss out the stuff that you do want to include in the training set in order to actually make something more intelligent. So I think that that gradual, I mean, I'm sure people are working on it.
I could see that as becoming problematic. Languages that are suitable for AI. I think like I talk about types and inference. I think both of those are important. I think also locality is is important.
Locality? Well, what I mean by that is like don't have a bunch of global stuff where AI has to entire product. Oh, these pounding clue files that are, oh my god, well, who knows where they're in scope and then how do I put that in the context of the window or not? And then do I burn like a gazillion tokens on trying to include but if you have good locality where you're clearly stating what you're importing and whatever and you can analyze just a single source file and from that extract its protocol to the outside world without having to know anything deeper. Do you know what I mean? I think those are important aspects just simply to reduce the size of the context window
and also make it easier to summarize each module in a program. Right? This is so fascinating because I remember this was probably 15 years ago where PHP was very much critiqued or it's global and early on I didn't understand as a young developer why does it be always I was just hacking around a PHP until I had the issue of something was not working and turns out that something imported over a global and suddenly you realize that when things are defined across the codebase that global could be anywhere and there's no way for you to know when someone else is doing your now back to the state problem which you just talked about original JavaScript suffered from this problem. There were no modules right? Everything was global and anyone could just like monkey patch anything else and it was impossible to know really what am I sitting on top of here but now with ECMAScript modules and whatever we're moving towards sanity and more and more the world is written that way in the JavaScript ecosystem and that's a good thing and I think that will help us down the line with AI. AI it's just starting to become aware of the existence of language services
and agents today like to use grep and org and whatever you know to find all the places where you reference a certain thing but it's not semantic search right and so if you have a common name for this property like count or address or whatever right well it's going to find a whole bunch of properties named address and then that's not going to work so well because now you don't know that you're renaming the right one right but this is where language services come in and semantic search and I think that's going to increasingly become more important with AI and really these are services that are already provided by LSP implementations but they may need some tweaking in order for them to be more accessible to AI AI, AI likes command line tools you know and they're not really command line tools and I also wonder if for example performance will be interesting because we know that these things can can run faster so faster feedback will be helpful which we're now going back to when the reason the type strip was so popular you said the 200 milliseconds of getting you feedback right but there are ways of you know where where you could imagine you know like a server keeping a project hot and giving your LSP services you know that AI can ask semantic questions and
whatever and then once AI stops asking that the 10 minute the server just dumps it you know and whatever they're there are ways of putting this together I think where we can make some progress on because like the ability for AI to semantically validate the code that it's generating as it's generating it will increasingly become important what about the the software craft you've you've been in this industry for many decades but it's hard to unsee that these tools are just coming to everyday use similar to how at some point graphical ideas came before that I guess higher level languages came knowing that AI agents and AI tools will be part of the craft what do you think parts of software and geo craft will become less important and what might become more important in a sense we're all turning into project managers right and we can have an army of junior programmers called agents that will just spit out reams of code but someone's got to have the big picture and review all of that and so increasingly our craft is going from one of writing the code to one of reviewing the code and and building the architecture of the code and overseeing the work if you will it's a
different kind of craft it's a different kind of enjoyment I've always liked writing the code you know to me that was the fulfilling part seeing it work you know what I mean and and in a way AI robs a little bit of that right I mean because I am less interested in reviewing code but I think we could also make the process of reviewing code much more interesting than it is today right I mean today you see a list of diffs in alphabetical order and now it's up to you to make heads or tails of it I mean there are more pedagogical ways of presenting that and you could have commentary generated by the AI that tells you what the changes are and whatever and then tries to guide you along to do you know what I mean so so that symbiotic relationship I think we need to work on that more and so sort of to to keep the enjoyment in there but I think it's foolish to think that AI will just eliminate programmers and that because ultimately that's great you know like by coding is wonderful as long as it works and then the minute it goes off track then you're like you have no idea what's going on and you can't convince the AI to fix it and so what do you do you can't have solved yourself from understanding what's going on that that's not that's not programming
and ultimately also you know the responsibility for a program does not lie with the AI it lies with the programmer you're not gonna go back to the eye and say shame on you I'm gonna fire you what does that even mean right I mean now you have nothing you know it's no you need someone to have that that function of being responsible and so so that's you know so so ultimately AI is a tool to enable us to become more productive I think but it will change the way that we write our programs for sure I mean there's no point in in sitting there and typing in stuff that AI could type 100 types faster you know having created three very widely used programming languages what have you learned about developers about what they care about but when I come to programming languages and stuff that maybe they don't care too much about it and don't even think about it but you might have to think a lot about you know I think at the end of the day developers care about being productive they care about being in the zone where they feel like oh yeah this thing is just clicking for me it's doing just the right thing and it's like answering but it's it's right there it's an extension of my fingertips right so for me as a language designer I'm never just looking at the language it's you're looking
you 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 by programmers become so attached to their tools you know and their languages right I mean it's almost a religious thing for which which language you're and which tool you're using and because it's it's so ingrained in your workflow and and it's so enabled you 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 work that I've done over the years and it sounds like this is why from the very beginning you also focus on the IDE 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 as 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 statey 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 this equation you know I 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 I was very hard to do right but it seems in those you're 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 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 kind of program that my group works on like compilers tooling whatever you have people do care that's why we're spending a year and a half moving to native inference in in the cloud or on up against it I mean oh my god you know like financial fast trading whatever it's all about perf right I mean at the speed of light and like trying to
trying to move your trade faster than the other guys I'm 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 a difference and so it's just not worth optimizing there anymore it depends I think on on the kind I have your building it's a good reminder that not all use cases are born equal I'm interested what is your personal development set up 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 old that screen and a nice keyboard and that's that's what I do my coding on you know pretty much exclusively and what tools you use oh I VS code VS code and all the other years code and github all the time yes yes yes and and for for a 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 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 to 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's not quite to that level I'm also wondering if the lower you go into the stack may that be very high performance code or very concise code where all these things matter maybe the applicability starts to drop because again we know we already see the LLMs they're amazing for green field work when you have an existing large application 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 then it's got it's got to fit in there plus I mean to be honest I mean there are only so many compilers in the trading steps of of AI where there's a gazillion gooey apps we wouldn't 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 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 change jobs every three to five years or so what has kept you at a company for so long and also in a similar area for even longer well there's just something about developer tools that that is just what I love to do you know on that programming languages and they're they're they're complex algorithmically complex problems to solve and I for some reason like that they have fewer dependencies on other things so you're you're building from the bottom yourself you know I mean you don't have like sit on top of someone else's framework 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 do we programming languages you come to realize it's a long play I mean if you look back at the stuff I worked on it goes in 10 years cycles at least and TypeScript didn't really force them or see shot 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 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 way and I think like having been at a company like Microsoft is it's it's been great because to be put in a position where a company like Microsoft is putting their mic behind your efforts on creating programming 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 always have them yeah tell the developers matter it's not it's not advertisers 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 artist they work and people are paying you for it and it's it's good stuff you know that's closing what what is a book that you would recommend and why I always recommend the same book which is Nick Lovesby it'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 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 a lot of ways super relevant today the basics have not changed have they too much no no I know certainly and in particular when it comes to programming languages heck it's 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 how Anders said that programming language design is a 10 year cycle at minimum version one has issues version two fixes them version three is finally great and then you have to convince people to actually adopt it most of us devs are used to thinking in quarters and sprints this is certainly a different time frame I also found it surprising to hear how small the C sharp language design team was and how lean that they worked six to seven people three meetings per week two hours each all of them were people who had built languages before and they were criticizing each other's ideas and ideas that survived the criticism were the ones considered good enough to work just a good reminder that stand out technical work more often comes with small teams than it does from committees finally I really like how Anders said that IDs are the language from Turbo Pascal in the 1990s to TypeScript in VS code today and or says that the compiler is not the product the product is the whole edit compiled run
debug cycle this is a good reminder to any on all of us building software the product is the complete way that your customers use the product not just the screens or parts that you are responsible for if you'd like to go deeper on Microsoft developer tool routes and operating systems check out the related the pragmatic and your deep dive link in the show notes below if you enjoyed this podcast please subscribe on your favorite podcast platform and on youtube a special thank you if you're also rating on the show thanks and see you in the next one