Behind The Tech with Kevin Scott - Anders Hejlsberg: A craftsman of computer language

Episode Date: June 20, 2018

In Episode 1, Microsoft’s CTO Kevin Scott introduces us to one of his coding heroes, Anders Hejlsberg. Anders has had a 35-year career building tools that software developers love. He built Turbo Pascal, served as chief architect of Delphi, moved to Microsoft to help create C-sharp and today, spends his time as the core developer on Typescript. You may be surprised to hear how he got started in the tech industry.

. Surely, anything can be done here, right? Look at this diagram, I just drew it for you, just go make it so, right? No, coding is hard and it continues to be hard, and code gets bigger and bigger and bigger, but our brains are not getting any bigger, and this is largely a brain exercise.

. Hi, everyone. Welcome to Behind the future. Hi, everyone. Welcome to Behind the Tech. I'm your host, Kevin Scott, Chief Technology Officer for Microsoft. In this podcast, we're going to get behind the tech. We'll talk with some of the people who've made our modern tech world possible and understand what motivated them to create what they did. So join me to maybe learn a little bit about the history of computing and get a few behind-the-scenes insights into what's happening today. Stick around. In this episode of Behind the Tech, we'll meet Anders Heilsberg. Anders has always been one of my coding heroes. He built Turbo Pascal at Borland, which is the tool that I use to become a real software engineer.

At Borland, he had a long career where he was chief architect of Delphi in addition to the Turbo Pascal tools, and eventually moved over to Microsoft where he helped create C Sharp as the lead language designer, and today spends his time as the core developer on TypeScript. Anders has had a 35-year career building development tools that software developers love. And we're going to learn how he's done that today on Behind the Tech. So, welcome. Thank you. And thanks for being my first guest on this debut podcast. No, thanks for being willing to experiment.

You were a calculated first choice because I think I've told you this before, but I learned a program when I was 12 years old. My entry was, you know, basic and 6502 assembly language, Z80 assembly language. The first real programming I ever did was on Turbo Pascal. I went to a science and technology high school and took an intro to CS class, and Turbo Pascal 5.5 was the tool.

I don't think I would have chosen a career in computer science if it hadn't been for that sort of confluence of things. So, like, in a way, you're responsible for my career. That's awesome. The main reason I wanted to have you on the show is this must be the case for a huge number of folks. And we'll get into your journey as an engineer, but like what made you decide that you wanted to build programming and development tools?

Because that's sort of been your entire career. Yeah, it has. You know, I've been doing it for more than 35 years now. Yeah. It's kind of scary to think back, and it's such a long time ago now, right? I mean, and the world and the industry, well, there wasn't really an industry even, you know, but it was so different. I mean, in the industry, I got started probably in the early 80s, but I got started coding in high school back in the late 70s, probably. I was trying to think back, 78 or 70. Yeah, 78. And were you the

type of tinkerer where you were building little programming languages? No, no. So I was trying to think back, 78 or 70. Yeah, 78. And were you the type of tinkerer where you were building little programming languages? No, no. So I was born and grew up in Denmark, and I went to a high school outside of Copenhagen. And it was one of the first high schools to offer students access to a computer. Yep. What was the computer? That was an old HP 2100, it was called. It had 32K of ferrite core memory.

You could literally open it and see the ferrite cores. It was amazing. Paper tape reader. And then after a while, they got a 14-inch 1 megabyte hard drive, which was absolutely state-of-the-art. And it must have been huge. It was enormous. The read-write head on that thing had this gigantic magnet,

and, you know, everything was so primitive. You could program it. And we put that poor computer through so much torture, you know, like trying to make music by moving the read-write head on the hard drive, and it would, like, vibrate the whole table, you know, and it was... That's great. Yeah, yeah. So that was sort of a very hands-on introduction to computing.

And I do remember that you could either program it in assembly code. I think there was a Fortran compiler, but then there was an HP ALGOL compiler. Oh, interesting. And that was actually sort of how I vectored into that branch of programming languages ultimately because that was the first language I was taught. We didn't have BASIC. There was no BASIC on that computer. Do you know what I mean?

So I learned ALGOL, and this was a very primitive compiler. I mean, it didn't support recursion. Right, right. That machine had no stack. So call instructions would just store the return address in the first word, and then return was an indirect jump back to that, right? I'm probably going to get in trouble for saying it, but better than Fortran or COBOL. It was still better than Fortran.

Yeah, yeah, yeah, yeah. But anyway. How much were you all influenced by this Scandinavian programming language? So Nicholas Wirth was the designer of the Pascal programming language and then Modula later. Yeah. It's funny. In high school, I didn't know anything about any of that. And really, it was just sort of learning by doing. And then I started electrical engineering at the

Danish Engineering Academy. There, I met a guy who had just transferred from another school into the Engineering Academy. And we both liked playing cards. And he lost some money. And so I had some IOUs, so I had to get to know him. So I ended up getting involved with him in starting a computer company in Copenhagen. And we had the very first retail store where you could go in and buy a kit computer. We were right at the cusp at that time of microprocessors becoming democratized, the 8080 and the Z80. And like this is when the Sinclair ZX80 started to happen. And there was this British kit computer called a NASCOM, which had a Z80 in it.

And I started writing software for that one then, you know, and it came actually with a Microsoft ROM basic. That's cool. So what sort of software were you writing? Well, so first I started writing games. It's funny. I never liked playing games, but I liked writing games. And were these sort of text-based adventure games?

Yeah, it was like Moonlander and Star Trek and that sort of thing, right? And you could actually buy these books. I think it was like Byte Magazine had these 101 computer games where you could type it all in, right? Yep. It was great. Like, it was such a great thing. It was awesome. So I learned a lot.

But then I started actually getting into assembler coding and sort of trying to understand more about how the machine worked. And then I got curious about extending the Microsoft ROM basic because that ROM basic, it had to fit into an 8K ROM, right? So there were a bunch of commands it didn't have. There was no renumber command, which was a royal pain in the neck because if you ran out of number, now you have to, like, manually go retype every line.

But there were some extension points where you could actually sort of hook into the ROM basic. Because there was an extra slot for EPROMs on the motherboard. I wrote this little 4K ROM basic extension that gave you renumber and a bunch of other things. So that was like a little plug-in toolkit, right? And so how old were you then? This is like after university? Yeah, I was probably 20. So like very, very early in your career, you are mucking around with your programming tools. Sure.

Yep. And like, is that, you know, just sort of a sensibility thing or? I just sort of found it interesting. There are a lot of challenges there, right? And then that interest further got piqued by, you know, now that I've figured out, oh, you can actually extend. I remember, you know, still missing that ALGOL programming language. And I was telling my buddy, maybe I should write a little ALGOL thing that we could put. No, no, there's this new thing called Pascal. You really should check that out. He was going, okay, okay. And then I started looking.

Oh, this is better. Because, you know, one of the things that Niklaus did consistently through his entire career, he's the creator of Pascal, right? But he was involved with Algal, and then later Modula and Oberon, and every language got progressively simpler. Algal had all these complex, like, call by value and call by name, and then Pascal dumped a bunch of that, and then Modula dumped even more of that, and then Oberon got even more minimalistic. Yeah. I remember I've never written a real ALGOL program, but because I was a compiler guy, the ALGOL grammar was all over the place in the early compiler literature. It was so complicated. It was. So anyway, so then I set to work and wrote this little Pascal. That was effectively the nascent Turbo Pascal, if you will, right? It had a little on-screen editor and a runtime library and a compiler, and it was all squeezed into 12K in a ROM.

What gave you the idea to do that? Because that's sort of a new thing, right? That might have been the first IDE, right? Yeah, that was probably one of the very first IDEs ever. That's amazing. Well, UCSD Pascal was on the Apple II, but it was sort of different. And it was a P-code interpreter, and the IDE was not really quite as user-friendly. You know, it was more like a sort of a

semi-command-line-y IDE-like thing. And so you wrote this thing in, was it mostly in assembly? It was all in Z80 assembly. Wow. Oh, yeah. No, that was my weapon of choice at the time, right? And then that grew into a CPM 80. Obviously, that one was a subset implementation, right?

And then that grew into a fuller subset, and then finally a full implementation for CPM 80. At that point, we met the guys. Borland was founded in Denmark. A lot of people don't know that. And we knew the original founders because they had had another computer company, and it was a very small industry in Denmark, right?

And they were writing some stuff in Pascal MT+, I remember, from digital research, CPM. And that was a horrible Pascal. It was like one of those, like, insert pass one disk in drive A, right? And then it would grind, and then you'd take that out, and then it would write some temporary code, and then you'd insert the code generator disk. Yeah. You know, and it took an afternoon to compile a small program, right? And there were, like, dialects of Pascal that were just, like, not as nice as Turbo Pascal. Right.

And they were afraid of making extensions, you know, and I was never really afraid of making extensions if they were useful. Yep. So these guys, we go, wait, we got actually this implementation. You should check it out. They didn't believe a word of what we were saying because that's not possible. I just want to double-click on this point again. Coming up with one of the first integrated development environments that you had written in Z80 assembly language at that point in time, that's an unbelievable breakthrough. I suppose in retrospect, yes.

I never really thought of it that way, but, you know, it's... It's just incredible. I mean, it's like the first. What the heck? It just seemed like, heck, this is going to be so much better than having to have first load an editor

and then load a debugger. Why not just put it all there? I mean, I don't know. I never really... And especially at the time, because, I mean, again, like more framing. These are not windowed systems. Can't have multiple things open at the same time.

Like it's super tedious to switch from one program to another. So like having everything in one place is just this huge productivity win. Totally. The edit, compile, run, debug cycle just shrunk by many orders of magnitude. Yeah, and I'm embarrassed to say I've like forgotten. Was it F9 to like compile run, or was it F5? You know, I don't even remember what it was. I think it was F5, yeah.

It was, like, miraculous. Or maybe it was F3, but yeah, no, it was great. Yeah. There were all sorts of tricks in there. Like, the runtime library was the first 12K of the system, and then when producing code, I'd just copy the first 12K into the XE we were producing. There's your runtime library, right?

And then generate code from there on out. And you could compile to memory, you know, and we'd put the code in memory and run it, right? Or the original implementation, you could compile to tape, to floppy tape. And then you could, or sorry, to the tape recorder interface, right? And then you could load that machine code up because, I mean, there was only 64K of memory. I mean, it was crazy. Yeah. So I bought a copy of Turbo Pascal 5.5 out of a catalog called Programmer's Paradise.

This is just sort of how you used to buy software. And so I forked over my $200 or whatever it was. Oh, no, it wasn't even that much. It was $49, like $49.95. Yeah, so it was affordable because I was poor, so thank you for making cheap software. Yeah. But, like, it came on, like, this bundle

of five-and-a-quarter-inch floppy disks that, you know, I sort of fed into my... And I was lucky enough to have it. I mean, I got to give credit there to the Borland guys, to Philippe and Niels and Mogens and Ola, the original founders of Borland, because what they did, they ended up licensing this Pascal compiler that I had in my small company.

And we were selling it for 500 bucks and doing business the way business was normally done for software, right? And then they licensed it. And of course, we never thought to put a minimum price on what they were supposed to sell the product for. And then they come back and go, we're going to sell it for 49.95.

I go, what? It's just terrible. I mean, it's like it's supposed to sell for 10 times as much. But so they cut the price by 10x, and then they literally sold four or five orders of magnitude more copies of it, right? That was tremendous. Yeah. I mean, when you think about the life cycle of innovation, it's not always just about the technical thing. Right.

Like, that wouldn't have been an appropriate environment for students if it had cost $500. Right, right. And at the time, it was like, hey, if you only charge $50, why even pirate it? It's worth it just to have the manual that actually tells you how it works, right? So one of the other things that was really good about Turbo Pascal is the manuals were actually quite good. How big a push did you have in that? I had written manuals for

the Pascal compiler that we had in our company called PolyPascal, and it had a pretty extensive manual for the language. The introductory parts were not as great. Those and Ola, who wrote the documentation, Ola Rasmussen, he did a great job on turning that into something that was really a fun book to read, you know, and so a lot of people were very happy with the documentation as well. So it was just sort of a confluence of a bunch of factors that just came together, right, and the right thing at the right time, and the industry was so nascent. I mean, that was it. So going back to your university days, did you have a professor or colleagues or like someone who was really great at the programming languages and compilers part of the curriculum where they sort of lit this aha moment for you?

Not a whole lot, actually. I did electrical engineering because in order to do computer science, you would have had to have gone to the university. But I was always more of an engineering sort of focus, and I wasn't necessarily sure that programming was what I wanted to do. Do you know what I mean? And at the school at the time, they had yet to introduce personal computers. So, they had the Northern European Computing Center there, where you would turn in your stack of punch cards, you know, and then the next day you'd get the printout, which would just be a hundred pages that said, era, era, era. And then you'd have to go back and figure out why it was that, right?

It was horrible. It was like a week-long debug cycle. But then they started getting some, again, also some Z80 and CPM-based microcomputers. And by the time I left the university there, they were actually using Turbo Pascal or Poly Pascal, the one that I'd written in the introductory courses. Holy crap, that must have been great. So my professor did allow me to not attend the class. He did give me an A.

Because you read the compiler. That's great. Yeah, yeah. I think one of the things that folks may have started to take for granted now is, like, you sort of jump online. You've got Google. You've got the open source community. You've got YouTube and, like, all these video resources. So I would argue that it's, like, much easier now to bootstrap yourself as a programmer, even in sort of esoteric things, like how to build a compiler.

So how did you get your bootstrap? Like, how did you figure out how to do this stuff? You know, you learn by doing. You learn the hard way, build a compiler. So how did you get your bootstrap? Like, how did you figure out how to do this stuff? You know, you learn by doing. You learn the hard way, in a sense. I mean, and in retrospect, there were so many things that had I known that, you know, I could have gotten there a lot quicker. A couple of things, I suppose. One is you couldn't stop me from doing it. I wanted to do it. Someone once talked about how do you get really good at something? Well, it's by putting in the time. There's this talk about the 10,000 hours that you got to put in. And I was like, yep, I definitely put in 10,000 hours in the first three years that I did this because

I was obsessed. I just had to do it. I didn't care if anyone paid me. It was just the challenge of it was so interesting, you know. And it probably wasn't 10,000 glorious hours, right? You probably were like making lots of mistakes. Absolutely, absolutely. Yeah, and I didn't know how to write a compiler. But then you started looking at compilers that were written, and since my native language was machine code, you know, I mean, heck, yeah, I could disassemble other stuff and figure out how that worked, right?

And then you gradually learned. But there were still things I didn't know. Even in the first version of Turbo Pascal, I remember, all the simple tables were just stored as linear lists, which, of course, doesn't scale so well, right? And then I remember learning about hash tables. And I was like, holy cow, I got to go home and try this. And then I put it in, and I doubled the speed of the compiler, right? I remember that one of the first books that I thought was really instrumental for me

in understanding a lot of sort of the basic computer science was written by Niklas Wiest called Algorithms Plus Data Structures Equals Programs. Yep, which is a great book. Oh, my God. It is the most pragmatic computer science book I have ever seen. I was, like, never into the symbolism and the formal proofs and whatever. I just, like, give me the algorithm.

Tell me, let me understand how it works, right? And this thing explained how binary trees and binary search and hash tables and how to build a compiler with a scanner and a lexer and a parser. Do you know what I mean? A code generator and recursion. And, oh, my God, it was like I loved that book. You know, you can go back to it today, and it is still super valuable. And I've always loved books like that. Another good one, Dave Hanson, who used to work at Microsoft Research here, wrote this book called C, Interfaces and Implementations.

And I like C because it's sort of simple. I mean, it's got a bunch of hair on it, right? It does. It makes it ugly. It's easy to make mistakes. It's easy to make mistakes. You know, not the most elegant language, but it's simple. Like, you can sort of pack all the rules into your head. It does. It does. It's easy to make mistakes. super pragmatic. They had these very broad applications, and it was almost like teach and see to do crazy object-oriented sort of things that you couldn't roll your own V tables.

Yeah, yeah, yeah, yeah. No, I mean, heck, at Borland, we definitely had lots of systems that were sort of calm, like, you know, that Windows is largely based on is effectively roll your own V tables, right? So. At Borland, how did you all get feedback? How did you know you were pushing your product in the right direction? That's a good question. I mean, I think— Because the cycles were long, right? They were.

I mean, back then, there were a lot of trade magazines, and you got a lot of feedback through that, through the reviewers. Yeah, like Dr. Don's Journal. Exactly, and Byte Magazine and what have you, right? We also had bulletin boards early on, you know, like the old BBSs that we would monitor in our tech support. And so there were a variety of ways. People would write us letters and send us letters, you know. I mean, I got so many letters with suggestions for stuff. So we always had a long list of things we wanted to do. And it was really not a matter of figuring out what to do.

It was like a matter of which ones don't we do and sorting it and doing the right ones, you know. And like you mentioned, TurboScale 5.5, that was the release where we introduced object oriented programming. I do remember, oh my God, that was like the big buzzword at the time. That was sort of like the AI of the 80s, right? And it was a good implementation. So like you must have taken some inspiration from Modula. Well, Object Pascal was probably the work that Larry Tesler did at Apple.

You know, that was definitely an inspiration. Although our first implementation in Turbo Pascal 5.5 was a little bit different. It had some influences from C++ also. And then by the time we got to Delphi, I think we were sort of more true to Object Pascal. There was no difference between object references. You didn't have to use an up arrow to dereference them. And then that made the syntax a lot more gentle on the user, right? It was just foo.bar, not foo.uparrow.bar.

Yeah, I remember. So 5.5 was where I learned object-oriented programming. I think I'm sort of lucky because if you got thrown into modern Java, for instance, that was your playground for object-oriented. It's so complicated now. It is, but it's also in some ways simpler, right? Because back then, the languages that people used, by and large, did not have garbage collection built in.

And were very, very not safe, right? I mean, and had minimal runtime checking. In fact, we shipped Turbo Pascal by default with runtime checking turned off because we did better on the benchmarks that way, right? And a lot of reviewers were not smart enough to know to turn it off. And so they were comparing apples to oranges. And we just wanted to make sure that we were always in the running there. Once you introduce garbage collection, then you really sort of up the level of programming styles. You know, you can write in a style where you have much more complex function results and you don't have to worry about who deallocates this,

who owns this memory, who's supposed to get rid of it again, right? And you don't have all of these cycles that you maybe get if you implement with ref counting or whatever you do to keep track of your objects, right? So it made the world a lot simpler in a lot of ways. And then the fact that these languages can be memory safe, that removes a whole bunch of other, you know, I mean, the thing that saved us all at the time was that there was just only so much capacity. There's only so much you can do in 64K, and even though Bill said 640 was going to be enough, there's only so much you can do in 640 also, right? And so that always saved us.

It was like the complexity was never big enough that you couldn't get away with it. But once you're in this now, it's literally a bottomless pit. And there's so much going on. You take so many dependencies, and if you don't have some of these guarantees built into the system, you're going to be spending an awful lot of time just chasing down dumb bugs that really you shouldn't.

And that's not a creative process. That is just a waste of time. Yeah. So I want to get to that, but before we jump into modern type systems, let's talk a little bit about Delphi. So maybe the compiler didn't change all that much, but my God, everything on the front end. That was sort of a revolution on the IDE side. It's interesting because I've worked on a project in between that never went anywhere. It was codenamed Monet at Borland, and it was about building applications visually, which was very sort of, back then

everyone was talking about software ICs, and you could just plug and play and draw lines between the inputs and outputs on these different things. And we were building this very advanced set of components that you could just plunk down on a canvas and wire together, and, you know, making Fahrenheit to centigrade converters was super easy, right? But it turned out that making big apps was horrible, because you had lines going from everything to everything, and it just didn't scale. But I think in that process, I got a real appreciation for what does work well visually, like designing inputs and GUIs and whatever, right? And GUI was starting to happen.

And so there was definitely a need there. And so by the time this Monet thing did not pan out and we realized it wasn't going to pan out, then we sort of went back to basics and then go, okay, well, let's actually get into the GUI era with this product, right? And there was this thing called Visual Basic out there that taught us a lot, but also had a lot of issues. Like it didn't have object orientation. It was interpreter-based. It was generally a frowned-upon language, at least by a lot of people, right? And so we can do this.

We can do this. And we can do it better, right? That was sort of the genesis for Delphi. And then I think in the process of building Delphi, we also realized that, and this I think was Zach Erlach, our program manager, who very astutely realized that you can't just ship a RAD tool. You got to have some angle. And the angle at the time was client-server. And so we actually pivoted it into a client-server tool. And that gave us an inroad into enterprises and companies that were really building real database-connected apps. I mean, I remember competing with PowerBuilder. I don't know if you remember PowerBuilder out

there. Yeah. So that gave us a unique vantage point compared to Visual Basic. It was sort of an interesting thing. Delphi came out shortly after I graduated from college and I became a real software engineer. And I remember being so grateful for it because I did a bunch of work with it that clients were paying me for. And the tool made me look better than I actually was, right? Sure. We had made this transition from, you know, you're building these text-based apps where, like, if you're really fancy, you're sort of blasting ASCII codes into screen buffers. But Windows 95 came out.

The onus was on you. Like it looked slick. It was a pretty operating system. It was an awesome way to build client apps. It really was. And it had a bunch of fun things in it. Like I remember the two-way code generator. You could either visually design your form or you could go in and modify the code and then the form would change, right? And the way that

making that work was not or you could go in and modify the code, and then the form would change, right? And the way that... Yeah. Making that work was not easy, but once it did work, oh, my God, it was so cool, you know? That must be a gratifying thing. You've been doing this, you know, your entire career, but there's just this, you know, in my mind, a force-multiplying effect of building developer tools is you put your development effort into this thing

and then it gets into the hands of a huge number of people. That is the thing that I think, you know, in retrospect has been hugely rewarding is like when you build end-user apps, you don't build the same kind of fandom as you do when you're building developer tools because developers, they put in the hours. Do you know what I mean?

And they come to really depend on their tools. And they come to truly appreciate what they do. And then they become these ardent fans. Almost religious, right? Yeah, no, and that is so rewarding. Throughout my career, that has been so rewarding to go speak at a conference and have all these people come up and tell me how you saved my life, you did this. People have literally told me that.

I mean, it's like guys who were in Russia, you know, and couldn't put bread on the table, learned to program with Turbo Pascal, and literally, this guy's claiming I saved his family's life. You know, I mean, and I'm just, God, that is amazing. That is wonderful. That's really great. Yeah. So at the time, you sort of referenced it already. Like, there was this intense competition amongst commercial entities, companies like Borland and Microsoft and the guys who were building Power Builder.

And there were these database language things going around and literally catalogs full of shrink-wrapped software that was just for developers to help them get their job done. And so the big thing that came on the scene right after Delphi was Java. How did that factor into your move from Borland to Microsoft? Because, like, in a way, C Sharp, it seems like an address to Java. Well, there's an arc there, definitely. But I do remember, I think it was in 95 when Java made its first appearance, right? And this is where the Internet was starting to happen, right? And particularly, I think, in the development tool space and programming,

there was this collective madness around Java where everyone thought it was over. It was done. There was going to be no more programming. Java was going to take over the whole world. There was a Java fund. Remember the Java fund? Funded by hundreds of millions of dollars whose sole purpose was to just invest in companies

that were building their software in Java. As if that would make a difference, right? It was brilliant what Sun did. And I think even they had no idea what they had unleashed there, right? But it was discouraging in many ways because we felt that, yes, that's fantastic for building applets in the browser,

but you can't build real apps with this thing. But hey, you know what? There was the shiny object. There was sort of a collective craziness over the Java thing, but there were also things that I thought were interesting. I mean, this whole notion of write once and run everywhere, you know, is even today, it just so happened that it wasn't actually borne out by Java. It was borne out by JavaScript, right?

But which was there already in the browser and ignored for a decade, right? Yeah, crazy. It's crazy. We had a JBuilder tool that we built at Bornham, which actually was built in Delphi. They started with the Delphi IDE, chopped it down, and then the language service, well, they weren't really called language services, you know, at the time. But the mini compiler analyzer used by the IDE to do all of the syntactic highlighting and whatever, that was also written in Delphi. So I got to know Java as a language.

And then at the same time, there was sort of a change afoot at Borland. Borland had a bit of an identity crisis, you know, in the sense that everyone was up-leveling how business was done, you know, and it all became a game of platforms. Oracle was databases, Sun was workstations, Microsoft was the OS, and then Office became another platform. And Borland never really got the platform up-leveling, you know, it was always a bunch of separate products, and we tried to bundle them together, but it never really made sense. And the company was so singularly focused on trying to, like, get a foothold in that business

that they started neglecting their developer tools, which was really where the company came from, and a series of management revolving door, and I got more and more disillusioned. And then, of course, Borland ended up going through a bunch of reductions in force, if you will, and we spread a bunch of people into the universe. And a bunch of them went to the Valley, and a lot of them went to Microsoft. And then, of course, they started calling every summer when the weather is nice in Seattle,

you know, I'd get a call from Brad Silverberg, who had run R&D at Borland and now was running Windows 95 development. So I would come up and we'd talk. And the first year, I wasn't interested. But then, eventually, it was time. So I joined Microsoft in 96. And was C Sharp the first thing that you worked on? No, not at all. There was no C Sharp.

There was no.NET at that time. No, I joined to work on Microsoft's Java development tool set. Oh, interesting. Yes. And I worked on Visual J++. So at the time, we had a Java development tool. And it was really just our C++ IDE with the C++ compiler taken out and a Java compiler stuck in there, right?

That was Visual J++ 1.1, I think. And then we jumped from 1.1 to 6.0 because we realigned all of our RAT tools. VB was at version 6, right? And so it became Visual J++ 6.0. And it had a visual designer. You could design applets and whatever. But then we were also doing stuff

that made it a better language for writing Windows apps. And that ended up being very controversial. I have personally read the contract we had with Sun. It was explicitly permitted in there that as long as we ran all the standard tests, we were free to do additional inventions, you know. But that blew up, right? And literally within three months of us shipping Visual J++, our product was enjoined

by a judge in San Jose, and we were required to put in a warning dialogue, warning you are about to turn on Microsoft proprietary extensions. Are you certain you wish to proceed? Do you know what I mean? And that was just so you could use com interop. Right. That was considered so evil. I was like, this is crazy. Inside Microsoft at the time, the Java fever, it was all over the industry. And there were literally fractions of groups at Microsoft that believed that it was all going to be Java.

We should build a Java OS. It should all just be Java, right? But then that happened, the whole Sun lawsuit and whatever, and that was sort of the genesis for us understanding that, listen, it's really hard to do what's right for your customers by extending someone else's platform, right? We got to build our own that works for what it is that our customers are telling us that they want. That was the genesis of.NET.

And, of course, we needed a programming language. I so happened to find myself right at the right time at the right place for that, right? So how fun was that? Is that the first time that you had a blank slate? Totally. Yeah. I mean, can you imagine the opportunity to have a company like Microsoft put their might behind a programming language that you're going to create? I was flabbergasted that I was given that opportunity. Yeah, sure, I'd proven myself. But there were still a lot of other people at Microsoft

who had different ideas about what should be done, and then ultimately I was the one who was handed the task. So that was wonderful. And we had a great team on that early C Sharp compiler, which originally was written in C++ or C++-, actually, because we didn't use all of C++. Which is a whole other discussion. Oh, yeah, yeah, yeah, yeah.

I remember a guy named Peter Goldie wrote the core implementation of the compiler. I wrote the language spec. We had a wonderful design team process that we set up that, you know, to this day still exists, where we used to have three meetings a week for two hours where we would just do the language design, iterate on it, you know what I mean? And Scott Wiltermuth, our program manager

that I worked with for almost a decade, was the PM. So for four years, he commuted from Hawaii. We would do our design meetings on a speakerphone with him. It was a great time. Based on some of the stuff that you've talked about already and just sort of looking at C Sharp and then TypeScript, you're fairly pragmatic when it comes to language design. You're not one of these language designers that's like, oh, let's throw a Henley-Milner type system in. I've always been a believer in understanding the problem and feeling the utility of something before I want to go implement it.

Do you know what I mean? I have to believe in it. I don't just throw it in there. Oh, I need a type system. Oh, yeah, Hilden Miller or whatever. No, no, no, no. I want to understand why is it there? And does it really need to be there?

And a real programmer is going to benefit from it. And so that was the case in C Sharp, and that drove a lot of our decisions. For example, we added properties as a first-class language construct because everyone was doing properties. I mean, it was like that was how programs were written, and Java didn't have those, for example. So there were pragmatic decisions that we made. So whenever someone goes, why is this feature there?

It's not just because I thought it was fun. It's because it solves this, this, and this problem. Right. And ideally, with every language feature, this is something you come to learn over time, is people will request a lot of features, but they will always have synthesized their idea of what it is that they want.

They really come to you with an instance of a class of problems. And they tell you, I need this instance. Yeah. So the trick is to get them to really describe the problem. No, the trick is for you to understand what is the class of problem. Gotcha. And that's what you go implement.

Yeah. So I never wanted to implement a language feature unless I could see multiple good uses for it. We're not just going to implement because it does this one little corner of XML well, and that's it. Do you know what I mean? Yeah. No. I want this to be a generally useful thing that you can do other things with as well. Yep. Because it's a very serious thing to bake something into a language. Oh, the thing you come to learn about languages is you can add all you want,

but you can never take anything away, at least if you care about backwards compatibility. Yep. And we've seen lots of train wrecks where people did not care, like, say, the transition from Python 2 to 3. Even when you're just doing it in the name of cleaning up stuff that isn't right and isn't ideal or whatever, you can't do that to your user base. They have too much of an investment. It is your responsibility to ensure that their code continues to compile and work, and then you can add more on top.

And if you're not going to do that, then you might as well blow it all up and go create a whole new thing that advances the state of the art. Do you know what I mean? Yeah. The worst thing you can do is the 99% compatible thing. That is, like, absolutely the worst thing. So some of that attachment to the old is emotional, but you can very quickly have hundreds of millions of lines of code. If you're serving enterprise, well, it doesn't even matter, enterprise. It's like anyone who writes a large body of code that then gets adopted somewhere

does not want to have to spend a bunch of time changing it in random ways just so it's prettier. Do you know what I mean? No, big code bases get ugly. They all do. And programming languages do too. I sometimes joke that, show me the perfect programming language and I'll show you a language with no users.

Because only then can you go change it. I did an internship at Cray Research when I was a younger engineer still in grad school. One of the most mind-blowing things that I had ever heard up to that point was I was sitting at lunch one day. One of the most mind-blowing things that I had ever heard up to that point was I was sitting at lunch one day. One of these craved veteran engineers was describing the sales process.

So they were trying to sell a supercomputer at some point to a car manufacturer. And because they had this big Fortran code base that was doing finite element analysis so they could simulate crashes on these supercomputers, they come out with this sort of fancy new version of Unicode, and it was just going to be impossible for the car company to rewrite their Fortran code base, which was tens and tens of millions of lines of code,

to work on this operating system for this new machine. And the guy's looking there, he's like, all right, this machine's millions of dollars, and that's tens of millions of lines of code. The operating system kernel is 25,000 lines of code. Like, we'll just write a custom operating system for this. Being able to unpack where the abstraction and complexity is is really sort of an interesting skill you have to develop as an engineer. Yeah. Yeah, so pragmatism was always sort of a main driver for me, and it continues to be. What lessons as a language designer or like as a builder of development tools have you learned that you're sort of applying to TypeScript right now?

Well, we touched on a couple of them, right? You really have to respect and value backwards compatibility. Yep. Doing language design, it's interesting. There's really, in a sense, two phases to designing a language. There's 1.0, and then there's everything else. Right. And with 1.0, it's interesting. There's really, in a sense, two phases to designing a language. There's 1.0, and then there's everything else. And with 1.0, it's a green field. You can do whatever you want to do.

It's crazy fun, and you can be super inventive. But then from there on out, it becomes a very different discipline because now it's a game of trying to sneak in new features in a way that does not break backwards compatibility. And that is very different. And also, you've got to be very cognizant of, you know, every programming language sort of has a gestalt to it. Like, if it's an object-oriented programming language, you can move it towards functional

programming, but you can't make it into a functional programming language. Like, where immutability is first, right? You can put iterators in, but like, yeah. Right, but so there are certain things where you just got to go, no, if we do this, that'll just give people two ways of doing the same thing.

Right. And now there will forever be confusion about which one it is. Right. That I'm supposed to use. So we can't do that. Yep.

So after 1.0, you have to learn when to say no. Yep. And save it for the next one, which is hard because there are things you want to do, but this is not the right place to do it. And you could sink the ship if you did. And then

I think you learn also to withstand the pressures of marketing. I can't tell you how many mails I have written to defend our decision not to put XML literals into C Sharp. I literally spent a year writing that email every two weeks. And Visual Basic did put XML literals. And I was always like, listen, there are so many different ways you could write this markup. If we put it in and XML syncs, then we sync along with it. Do you know what I mean? Yes. Can you imagine if we'd had XML literals in C Sharp? I mean, and it's sometimes you just gotta like stick to your guns and the face of adversity, right? And go, no, this does not belong here. You know, I know, I understand how with the vantage point of today, it might look like it

does belong here, but it doesn't belong here long-term, right? So there are lots of interesting things that you don't realize right up front. I've always thought that the better designed programming languages were the ones where there was some coherent philosophy that was sort of developer-oriented up front. Perl, you know, which in many ways is, you know, I've written a lot of bad Perl code in my time. It's sort of easy to do, and it's my fault, right? Not the language's fault. But it had a lot of good

stuff. You know, like Larry Wall, the creator of Perl, had these sort of philosophical tenets like make the easy things easy and the hard things possible. I remember hearing Fred Brooks at one point say, one of the best things you can do in language design is figure out the things that you're not going to let people say because that's where mistakes happen. So it's always fascinating to me what these philosophical principles are because there's no one right way to design a programming language. Right, but there are lots of wrong ways, right?

And I think the one thing that people tend to forget, too, about programming languages, well, a couple of things. First of all, it's fascinating to look at how slowly they evolve and how similar the programming languages of today are to the ones we used 50 years ago. It's really quite frightening. I mean, like Pascal was invented in 1974.

I mean, so we're talking, what, like 40-some years here. Yep. And it doesn't really look all that different. Yeah, okay, we've had a few, okay, object orientation, but then Pascal sort of kind of looks a bit like a functional programming language. It doesn't have pattern matching, it doesn't have lambdas or whatever, but it has some of it, like functions and then data being separate. Anyway, so that's one thing you come to realize. I think another one is that it's very easy to focus on one shiny thing that your programming language is going to do, right? But then you always forget about the 90-something other percent

that every programming language has to have. And that 90-other-something percent keeps getting bigger and bigger now because people need tools. They need IDEs. They need statement completion. They need code navigation. They need blah, blah, blah. And so whenever you're like, oh, I got to have my little DSL-like thingy here just for configuring this thing.

Oh, wouldn't it be cool? Well, are you going to build an IDE for it? Are you going to build two? Oh, no, they're never going to get big enough for these programs. Well, every configuration file grows up to be its own crappy programming language eventually if you don't watch out. And then they get bigger and bigger and bigger, and now you need tools, and now there we are repeating history again, right? I mean, some of the hardest things that I've had to do as someone leading teams of engineers is to

be the bad guy coming in saying, okay, we're not going to use this shiny new language. And it's precisely for that reason. When you're figuring out what development tools you're going to use to empower all of your engineers to build great things, you have to make choices because all of the apparatus that you build around them to support them, what's the build system going to look like when you've got hundreds of millions of lines of code and thousands of engineers? How do you do continuous integration and continuous deployment? What does your testing regime look like? So you build all this automation that sort of sits around

the programming language. The engineers can sometimes have this notion in their head. It's like, oh, it can't be that hard. I'll just write my one thing in this and it'll be okay. Yeah, that can happen to you. Particularly, the higher you rise in the engineering ranks and the less code you write, the more possible you think the impossible is, right? Eventually, you become an architecture astronaut where surely anything can be done here, right? And look at this diagram. I just drew it for you. Just go make it so, right? No.

Coding is hard, and it continues to be hard. And code gets bigger and bigger and bigger, but our brains are not getting any bigger. And this is largely a brain exercise. I mean, so. Yeah. So one of the things that I end up talking with fellow engineers about a lot over the past several years is where we are now as a discipline, as a profession compared to where we were before. And so in some ways, the programming languages from a language perspective aren't that much different now than they were. But you do have these crazy things like cloud computing and open source software where I can't tell you how many times when I was a young engineer,

I re-implemented chain hashing implementation. It's like I could probably still write the code just out of finger memory. Right, right. But like so much of this stuff is accounted for you. So you've got really robust SDKs and like standard class libraries for programming languages.

And then you got like all of this infrastructure. What you can sit down in a weekend and write in terms of a internet service application, you know, compile it, press the button and ship it to a cloud and then expose it to the world. It's like crazy. No, it's phenomenal what's happened there. Open Source has done a tremendous amount to shorten the distance between individual programmers and between users of someone implementing a tool and someone using a tool. We're this close. I mean, I feel it on my body every day, right?

I sit in the GitHub issue tracker on TypeScript, and I'm talking to the very people who are using it, and if they report a bug, we can have it turned around and have it in the nightly build that evening, right? Which is great. That used to be a two-year cycle with our like old proprietary style. So the pace of advance there and iteration is just gone up so much. That is also that you're doing it in the open, right? So like so many people are making so much of this stuff available for low or no cost. Yeah, that is still a strange phenomenon because ultimately someone's got to pay, right? And I don't know where that's going to all land eventually,

but I have to say I do love the process of doing it. It's sort of like a return to the things that really matter about programming. I mean, our team, it's not a big team, but it allows us to be craftsmen, and it allows us to really just continue to iterate. I was always a great fan of, you don't just build a product and then throw it out there and then you move on to a whole new

thing. No, you got to come back and polish it and iterate on it and make it better, make it better. It doesn't get beautiful just out of the box. It gets beautiful over a period of years of constant iteration and care. Do you know what I mean? Yes. That's something that this ecosystem allows us to do at such a phenomenal pace that it's just beautiful. We could have never done what we're doing now with Visual Studio Code and TypeScript

in the old proprietary world. It simply would have taken 100 years to get that amount of feedback incorporated on the kinds of cycles that we were on back then, right? So that's great. That's awesome. And I think maybe that's a good point to stop. We've gone from core memories to this sort of near

infinite rate of change that we've got in open source software. So thank you so much. Oh, my pleasure. It was great. Awesome. Such fun. Fun talk, yeah. Thanks for joining me for Behind the Tech. It was a lot of fun speaking with Anders. And, you know, I had some surprises in there.

Like, I didn't realize that he had written a precursor to Turbo Pascal while he was still in university. That may very well be the first integrated development environment in the entire world. And, like, you know, he's so modest about it, like, oh, I never thought of it. It's like, God almighty. This is one of the more important breakthroughs from the point of view of a developer that has happened in the history of computing. So many thanks to Anders for being on the program. Next time on Behind the Tech, we'll hear from Alice Steinglass, who heads up Code.org.

We'll hear about how she's working to make sure every kid has the opportunity to take computer science classes in school. Be sure to tell your friends about our new podcast, Behind the Tech, and to subscribe. See you next time.