Every once in a while we get a guest we can’t believe we finally get to talk to – and you can hear the delight in our voices throughout. Anders Hejlsberg is special – he is someone we idolized since we were teenagers, heard whispers and stories about his prowess and feats in our formative years at Microsoft. His resume is unrivaled – he has created programming languages used by millions of developers and used to build software used by billions.
[[SEE TRANSCRIPT AT THE END]]
In this episode, we cover: his origin story, why create a programming language, how he created Turbo Pascal 2, Delphi, C#, .NET framework, the rise and fall of Java, the need for TypeScript, Open-Source, his daily workflow, his thoughts on AI, Solidity, Rust, and more.
In this episode, we cover:
Anders Hejlsberg’s first computer, programming language, and virus
What got Anders into building his own programming language
Are 80s/90s programmers better than present-day programmers?
Turbo Pascal 2 and discovering hash tables
Delphi vs. Visual Basic
Why did Java fail?
Building C# and .NET framework: concept to implementation
The #1 design decision Anders Hejlsberg is most proud of
Dynamic programming languages and Microsoft
The problem that led to the discovery of TypeScript
Why is TypeScript so popular?
How does Anders Hejlsberg write code?
What does his coding setup + gear look like in 2023?
AI and LLMs
Unsolved problems with programming languages today
Why spend 40 years on programming language design?
Thoughts on Rust, Golang, Zig, and Solidity
His daily workflow and what he spends most of his time on
Will there be another programming language by Anders Hejlsberg?
—
Notable Quotes:
“I am self-taught in the art of writing compilers.”
“First, there was this thing called the internet, and then there was this thing called Java.”
“We were all walking around with these scared looks on our faces going, ‘Oh my God, these programming languages, are they dead? Is that the end of it? Are we all done here?’” – on the release on Java
“The first version of Visual J++ that I worked on and shipped was Visual J++ 6.0.”
“Very quickly we realized it’s not going to work for us to build our future on technology licensed from a competitor.”
“The reality is that everybody wanted the ease of use of Visual Basics RAD, and the power and expressiveness that C++ had. We could give them one or the other, but trying to marry the two was hell on wheels.”
“We knew from the onset that if we’re ever going to appeal to Java, C, or C++ users, it has to be a language in the curly brace family of languages.”
“The thing about dynamic programming languages is they dramatically lower the barrier to entry.”
“There’s no way we could build a proprietary product and appeal to the JavaScript community. I think it was a hard sell at the beginning back in 2010, but then Satya Nadella became the CEO of Microsoft and all of a sudden the mindset very much changed at Microsoft.”
“In 2014, we moved TypeScript to GitHub. That was really when things began to take off, because now, all of a sudden, it became possible for the community to actually involve itself in the development of the product.”
“Our entire TypeScript workflow is in the open. There are no secrets on this project. It’s been liberating. It is so rewarding to be right there, right next to your users. They can report bugs in the morning and you can have a fix in the main branch by afternoon. It’s just a win-win for everybody.”
“In the beginning, programming was what I did, and it was only myself. Then I learned at Borland to become a team player, and then I learned at Microsoft to become an architect and a language designer.”
“My calling is writing code, I’ve doubled down on that.”
“I’m actually a pretty simple guy. I don’t have a super, multi monitor, fancy, gaming setup. I like to work on laptops. I always work at home several days a week and that’s where I wrote most of the code. Then I go in and play ping pong and interact with people.”
“I treated work as the place where I wouldn’t work and then I go home and work.”
“I saw a tweet from Tim Sweeney who said ChatGPT is like a person with encyclopedic knowledge and the writing skills of an English professor but with the reasoning abilities of a first-grader.”
“You don’t get to do language design if you want to switch jobs or switch careers every 2-3 years, because the languages don’t work on that time horizon.”
“It’s tremendously gratifying to know that you literally have millions of programmers use stuff that you work on”
“I like the courage to try new strategies for dynamic memory management. I do not like the complexity of the outcome.”
“Solidity is not a general-purpose programming language. I would call it a domain-specific language, and I tend to spend less time on domain-specific languages.”
—
References:
Turbo Pascal, by Anders Hejlsberg
Delphi, by Anders Hejlsberg
C# Programming Language
TypeScript, JavaScript with syntax for types
HP 2100 minicomputers
BASIC programming language
IDE, Integrated Development Environment
Microsoft Visual Basic
“640K is enough for everyone”, the infamous quote associated with Bill Gates
Algorithms + Data Structures = Programs book by Niklaus Wirth
Microsoft Visual Studio 6
String functions, Visual Basic
Electron software framework
RAD (Rapid Application Development)
ActiveX Controls
Generics in Java, by Andrew Kennedy and Don Syme
F# by Don Syme
Null References: The Billion Dollar Mistake
NullPointerException in Java
E programming language
Guido van Rossum, creator of Python
Brendan Eich, creator of JavaScript
V8 JavaScript engine
JIT (Just In Time Compiler)
CodePlex, Microsoft
QuickSort algorithm
Ship of Theseus paradox
Parallel Programming Issues
—
Transcript
Sriram: All right, ladies and gentlemen, we have an absolute treat for you here today. Somebody who’s truly been a hero of ours for over 20 years. In some ways, I think his work was the reason or one of the entryways for us into the world of computers. I’ve spent thousands and thousands of hours writing code in the language he has built. It’s hard to sum up the amount of impact he’s had on our industry. I’d love to welcome Anders Hejlsberg. Let me do a quick introduction.
Anders needs no introduction as they say, but among other things, I would say you’re known from everything from Turbo Pascal and your work in Delphi in the ’90s to being the lead designer architect behind C#, the cornerstone of everything with .NET. Then a lot of things on top of C#, you’re going to get into Line, we’re going to get a lot of fun stuff on top of that, but then for the last 10 years leading the charge on TypeScript. Anders is an icon in the world of programming languages and how to think about how programs, software are written, and it’s very hard to think of more people who have had impact on how we build a software views every single day. Anders, it’s such a pleasure. Thank you so, so much for coming on our show.
Anders: Oh, you’re so welcome, and thanks for all the kind words. This will be fun. I’m excited to be here.
ANDERS ORIGIN STORY
Sriram: We are going to get into all of your amazing work, but really, I want to go back to the Anders origin story. Talk to us a little bit about how you and your brother actually got into computers, got into coding, and maybe what sparked the interest in the idea of programming languages.
Anders: Sure. I grew up in just north of Copenhagen in Denmark. A very nice middle class, unremarkable, but I was fortunate enough to attend a high school that was one of the first in Denmark to give the students access to a computer. This is way before micros. In fact, the first computer school, the only IO device was teletype and a paper punch reader and writer. Then I think the one that we had access to when I finally made it into high school, and we’re talking about the mid-’70s here, was an HP 2100 with 32K of ferrite core memory. You could literally see the right cores. It was pretty remarkable if you opened it up, and boy, trust me, we did everything to that computer.
It had a 14-inch, one-megabyte hard drive, which was just state-of-the-art. We joke or I’ve joked before that for the first two weeks, the teachers were trying to teach us how this computer works, and then for the remaining time, we taught them how it worked [laughs] because we just spent all the time we could on this dark computer and figured everything out like how to program machine code. It was an HP 2100 and came with, I think there was an implementation of [inaudible 00:03:31]. Then there was HP ALGOL, which was Hewlett Packard’s variant. I don’t know, it’s lost in history. That differed from regular ALGOL, although one thing I do remember is it did not support recursion.
You have to be careful to not have your functions call themselves because then you never saw that program again. Just because the call instruction would store the return address in the first word of the function you were calling. That only worked for one call. Anyway, we got to learn from the very bottom up how computers worked and how languages were built on top of computers and how you write programs in those languages, and what happens when they get compiled and turned into machine code and et cetera.
We learned what boot loaders were and how you could plant your own boot loaders on the hard drive and perhaps modify the attendance records when the attendance record was inserted by the school attendance. We also learned how to write viruses. We learned it all. It was fantastic and that was what got myself and my brother interested in programming. It probably helped that my dad work was, at the time, and has for his whole life really, worked for Motorola. He ran their distributorship in Denmark. He was an engineer by trade. My brother and I are of that same milk.
What got him into programming his own language?
Sriram: Do you remember what got you interested in the idea of building your own programming language or designing your own language?
Anders: Sure. When I started, I started at DTU, the Danish Technical University in ’79, and met up with some folks who had already started a small company in Copenhagen, and eventually ended up becoming a partner in that company. We had the first retail computer store in Copenhagen where you can walk in and buy, which at the time an 8-bit micro. The kit computers of the time. The Sinclair’s ZX81s and Commodores and whatever, but before that even, we sold this British kit computer that was based on a Z80. You had to put it all together yourself. I wrote an awful lot of software for that. Pretty quickly got good at machine code programming because when you only have 64K of memory, you do good with.
You got to write in machine code if you want to really squeeze features in there. I think I was interested in, there were obviously programming languages available there, but it was mostly it was Basic, Microsoft ROM Basic. It was slow and had all sorts of limitations. I had been taught ALGOL and I was interested in it’d be fun to try to write an ALGOL compiler. I was stupid, I didn’t know, and then my partner would say, “There’s this new thing called Pascal, you ought check that out. It’s supposed to be better than ALGOL, whatever.” I’m, “Oh, really?”
Taught myself something about Pascal and it turns out that one of the traits of Niklaus Wirth, who worked with ALGOL, and then invented Pascal and Modular and Oberon and a whole lineage of languages is that he kept making his languages simpler. Pascal was actually, in many ways, a simplified, cleaned-up version of ALGOL that was great as an instructional language also, but it was quite easy to implement because of the rules of the language. There were no forward declarations and whenever you do it, a one-pass compiler could do it all, so I got curious about that. Of course, I didn’t know anything about compilers, and so I had to teach myself that by experimenting.
Gradually got a subset of Pascal implemented that you could rip out the Microsoft ROM Basic and then insert our ROM instead. When you powered up your machine, you were sitting in this little onscreen that actually, it was like an IDE. When you typed run, it would actually compile it, and then run the machine code, and of course, it would run rings around the basic. Anyway.
Sriram: Wait, there’s some fun memories because one of my first non-trivial project I ever wrote was a Visual Basic compiler where I did the whole nine yards. I built Alexa passer, and then tried to spit out the sealer. I want to go back to actually that time because if you think about that era, late 80s’, 90s’, you are dealing with the fundamentals. You’re dealing with the registers, you’re dealing with the opcodes. There’s an analogy here. I watch a lot of the NBA and modern NBA players, well, old-time NBA players who look at the modern game and they say, “This game is soft” because back in the day, we really had to duke it out. There’s a lot of energy here with programmers.
Aarthi: Solving iron versus.
Sriram: Yes, a little bit like, “Hey, we knew the cost of every kilobyte and we had to go up with this one.”
Anders: Absolutely.
80s/90s programmers
Sriram: Do you think there is something fundamentally better about being so close to metal that gives the programmers from that era skills and understanding that modern programmers don’t have?
Anders: Yes and no. I think it changes programming. In order to be a good programmer, in order to write something like Turbo Pascal at the time, you had to be bang-up good at writing machine code because there was no way you could write in a high-level programming language. It definitely cut down the field to very few people, but it also forced you to do an awful lot of uninteresting housekeeping and debugging, and a whole bunch of bite-fiddling. If I can make this long jump that we have here, I could save a bite by short jumping to this short jump. It was literally like that. You were just fiddling away and, “Oh my God, this afternoon, I saved a hundred bytes.” [chuckles]
In that sense, it was a craft, but it was also very much capped at what you would ever be able to produce because 64K was ridiculously small and even 640K, even though Bill at one point said whoever needs more than that. Even that was clearly not enough. I think today, I sometimes lament the fact that this enormous capacity that computers have now is basically a bottomless pit. You can build software on top of layers of layers of layers of layers of layers and no one can see anywhere half to the bottom. It gets to be this big swamp of spaghetti code and whatever. There’s less craftsmanship, if you will, sometimes.
On the other hand, you get to leverage other people’s work way more than you could previously, so overall, I think we’ve clearly moved to the industry forward, but yes, us old guys can–[laughter] Then playing for the old days.
Turbo Pascal 2 and Hash Tables
Sriram: I think there is some, we’re going to talk later about things like GitHub co-pilot, we’re dealing with different kinds of code reuse, but I do think there’s a little bit of romance in the, for example, I idol you and folks like John Carmack. John Carmack noodling away and trying to make sure every instruction and memory access is aligned on some cash line. The amazing thing is, even today, if you look at AI at the heart of it, you have matrix multiplication and doing things with floating point numbers. Some of these things really tend to matter, which on the theme of optimization, tell us a story of Turbo Pascal 2 and you discovering hash tables because it’s legendary.
Anders: [laughs] It is a funny story. You have to remember here that I am self-taught in the art of writing compilers. Now, I have since discovered and read a lot of the literature, but at the time, I was just coding away and doing it the best way I knew how. When you create a compiler, one of the things you have to create is simple tables, or they’re not necessarily tables. They could be linked list, they could be whatever, but you have to look up names. When you’re trying to compile a code that tries to assign one to X, well, you have to figure out where is X? What memory address have I associated with X? You have to look it up the declaration of X.
In Turbo Pascal 1.0, the first version of Turbo Pascal, all of the variable declarations were just kept on a linked list because that much I knew, but of course, searching linked lists is not particularly efficient when they get large. For really large functions, that would just take an awfully long time. Then, well, maybe you could try first go by first letter, and then have 26 linked lists or whatever, and that could help a little bit. Then I remember reading the literature about these things called hash tables actually in this book by Niklaus Wirth, Algorithms +, what is it? Yes, Algorithms + Data Structures = Programs.
A great book. He explains hash tables and I go, “Oh my God, that’s amazing. I got to go try this.” I went and implemented it and boom, the compiler went twice as fast. There’s Turbo Pascal version 2.0.
[laughter]
Aarthi: Awesome.
Anders: There’s a good reason to sell upgrades.
Borland Delphi
Sriram: I want to get to your time at Borland, Delphi. Actually, I’ll tell you a story. I don’t think we shared this in public too, and you may not like the story. Which is Visual Basic 6 is the reason I think both of us, at least I have my career because what happened in the mid-’90s was that my dad back in India, he got me a pirated version of Visual Studio 6 because we couldn’t actually afford the real thing. I would install this, I’d be like, “Huh.” For me, their Basic wake actually see, and that whole thing was powerful.
Aarthi: Drag and drop.
Sriram: Drag and drop and being able to go to summaries. Then once I got a little good and I understood, I start running into limitations of VB6. It wasn’t actually, oops, and you couldn’t actually compile it and blah, blah, blah. Then I would look at these code written in Delphi, which you can always tell because you get that little distinctive green check box in the Delphi UI.
Anders: Oh, yes. UI, yes.
Sriram: You could do all these native things. For example, in Visual Basic 6, if you want to repaint the Windows in ways Windows didn’t want you to, you were spelunking into Win32 DLL in ways that man didn’t intend and God didn’t want you to. Then I’d look at the Delphi folks, you’ll be like, “Oh my gosh, here they’re doing all these amazing fancy stuff,” and I was already so jealous of the world of Borland and Delphi. Maybe with that segue, talk to me about your journey into Borland, Delphi. Maybe paint a picture for maybe those who were not around then on. Maybe the industry witness of Borland versus Java and Visual Basic around that time frame.
Anders: To complete the historical art, because of my work writing these small compilers for Z80s, we ended up in this little company. We’re in Denmark. We ended up connecting with the people who had founded Borland and it ended up creating a royalty deal where they would rebrand our compiler and sell it in the US or the US rights. That was what became Turbo Pascal. Now, they put a different editor on it, a different menu system, and so forth, and then, of course, Turbo Pascal took off. It became immensely popular much more than we had ever anticipated. That ended up being my main gig. Eventually, I joined Borland as a [unintelligible 00:16:58].
Instead of being a royalty contract, I became a full employee and stayed with Borland until the mid-’90s. The successor of Turbo Pascal, we did, I don’t know, I think six or seven versions of Turbo Pascal. Then, of course, at this time now, we’re in the early mid-’90s and graphical user interfaces are starting to become a thing. Visual Basic was this very revolutionary product that Microsoft had created that gave you this rapid application development environment where you can drag and drop controls onto forms. It was actually pretty cool how easy it was to create graphical UIs, but, of course, the language underneath was Basic. It was interpreted and it was not a very powerful language.
We felt, “Hey, maybe there’s a there there, maybe this is where we ought to have a real compiler.” Also maybe this is where we really ought to have real object during programming with classes that you can inherit from, and methods you can override, and all of the good stuff that had happened. Delphi was an amalgam of all of that. Plus, we also built a whole set of controls to allow you to build nice client-server apps because that was how you could get into the enterprise at the time. There were products like PowerBuilder and so forth, but the people who had the money were the enterprises and they wanted client server apps.
That became our way into more professional programming, if you will, but it was a fun ride. Then like you talked about like, yes, you couldn’t repaint the form, and, well, one of the things that we valued a lot in Delphi and its visual class library was that there were always escape patches that would allow you to get down to the underlying OS. You could obtain the Window handle and then the wind proc and then get down there and actually call directly to the OS and do all sorts of good stuff. People loved that because with VB, there was always this glass ceiling and you keep banging your head against it, and then you were stuck.
Sriram: With VB, it was so hard. By the way, a lot of the audience watching is like, “What are these folks talking about?” In VB, you had often this language of these B strings and things which didn’t look like B words or credible things and when you passed these things and called, if it didn’t work, and you had to change the calling convention around from __stdcall to __cdecl, the whole thing.
Anders: Oh, yes.
Why did Java fail?
Sriram: If something didn’t work, all you got was it just crash. Debugging was a nightmare. It was painful. The other narrative which played out in this era, I would say, which dominated the industry was the rise excitement, and then the fall of Java. Let me ask you this, what do you think Java did right and what do you think eventually happened?
Anders: Now we’re in the mid-’90s and I’m at Borland actually. I remember, all of a sudden, there was this thing called Java. First, there was this thing called the internet, which, of course, was huge, and then there was this thing called Java. The internet taught everybody that cross-platform all of a sudden is going to become incredibly important. Here we are, we’re all on these languages that are closely affinitized with this, that, or the other OS, and desktop and what have you. Everyone was going, “What’s programming going to be like in this new internet-dominated world?”
Sun was brilliant at positioning Java as this is the language that is basically going to rule them all on the internet. Then they have Applets and they have the little guy that looks like a penguin, or whatever.
Sriram: The coffee, the steaming–
Aarthi: The steaming cup of coffee.
Sriram: The steaming coffee and water.
Anders: Yes, right.
Sriram: Write once, run anywhere.
Anders: The industry totally went bonkers. There was the Java Fund. It was $100 million fund whose sole purpose was to invest in companies that wrote Java programs. It didn’t matter what the programs did. As long as they were written in Java, you could obtain funding. We were all walking around with these scared looks on our faces going, “Oh my God, these programming languages, are they dead? Is that the end of it? Are we all done here?” Honestly, there was a feeling for a while that that was going to be the case.
This was also at the time where Borland was starting to not do as well competitively with Microsoft, but Delphi had done well and had irritated Bill enough.
Particularly because we were stepping on Basic which was his child. Ultimately, I ended up then joining Microsoft right at that juncture ostensibly to work on Microsoft’s Java development tools, and ended up working on Visual J++. The first version of it that I worked on and shipped was Visual J++ 6.0 I remember. This is now we’re back in I think ’97. I joined in ’96. This must’ve been in ’97 I think, yes, or maybe ’98. We’d actually built a really nice product. The first product we built that was almost completely done when I got to Microsoft was VJ++ 1.1, which was just take Visual C++, take out the C compilers, take out the Java compilers instead, and call it a product.
Of course, that wasn’t quite it, but Visual J++ 6.0, it had visual programming and a whole bunch of stuff. Of course, because if ran on Windows, it also had features that made it easier to write Windows programs. Now, that turned out to be a major problem in retrospect because by Sun’s reading of the contract, we were not permitted to do that. I will, to this day, swear that the contract said we were permitted to do it, but it doesn’t matter. The product literally ended up being enjoined by a judge in San Jose and that enforced us to put a big warning dialog warning you you were about to enable unsanctioned language extensions. Do you wish to proceed? Very quickly we realized it’s not going to work for us to build our future on technology license from a competitor, right?
Aarthi: Right.
Anders: We got to build our own thing such that we can serve our customers.
Sriram: Just to paint the picture for folks, a couple of stories here. One is, for those who are too young, back in the day, if you ran a Java application on the client’s side, it was going to look and feel so different, even with Swing, their modern tools. It didn’t feel native Windows. It was slower, it took a while, it felt different. The VJ++ apps, which I’m pretty sure most people here haven’t experienced, would actually feel like native Windows too. We have a story. Our first job at Microsoft was in Hyderabad at the India Development Center, which actually, I’m not sure if you know this, took over the development-
Aarthi: Of VJ++.
Sriram: – of VJ++.
Anders: That’s correct, yes.
Sriram: As a result of some of the legal regulatory issues that had fallen out, there was this huge wall where every meeting had a lawyer, it was a whole thing.
Aarthi: I think when we joined, it was a very different Microsoft than even the late ’90s Microsoft because they’d all been through a ton of legalese in process around what can be shared, what can’t. We were all in the same building, a bunch of cubicles together, but there was this divide, this line of like, “Oh, you guys work on VJ++ and we don’t.” We used to work on Visual Studio. It was very, very different. Processes were different, who we talked to, what was the legal process like, everything was very different and was just completely divided.
Anders: You had to be black-boxed there. Yes, it was a wild world. It was a crazy time quite honestly. You’re right, I do remember the original Java with AWT, it very much showed the limitations of cross-platform. Even today, there’s this tension between frameworks that allow you to write, apps that run everywhere, but they don’t have quite the native look and feel, and customers always want apps that have the native look and feel. That tension exists still.
Sriram: Yes, because I was just reading a discussion on Hacker News the other day about electron and electron apps. This exact thing now comes up, which is, when do you write something which enters inside a browser versus something which enters natively works something on mobile. This discussion, I think, will never ever go away.
Anders: No, and it’s interesting because in some ways, it makes it easier to write the apps because you only got to write them once, but it also makes it harder to write the apps if you want them to be native look and feel, right?
Aarthi: Yes.
Anders: Because now you got to be really good at making that framework sing and dance in native ways, right?
Aarthi: Yes.
Building C# and .NET Framework
Sriram: Yes. I want to come to this part, which I think is a very unique one for Microsoft, which I would say is the design of C# and .NET. There’s a lot of constraints there, which I was just a kid, we were just kids, but one was you had to win the mindshare of the Java developer base. There was also this controversy of, are we moving people away from VB6 into this other world and losing this hobbyist RAD development? There was a lot going on in there. Talk to us maybe about C#, the design process that led into it, and maybe some of the internal discussions.
Aarthi: Also, I think the .NET Framework. We ended up working on that and on different parts of the .NET Framework itself, its integration with Visual Studio, but also, I worked on the CLR and so this was something that we were deeply passionate about. How did you think about C# from a concept to actual implementation?
Anders: I think one way to look at it at least, and I think it definitely was front and center in most of our thinking, was that we had, at Microsoft at the time, two very large constituents of developers. There was the C++ developers, the native code, and then there was the VB6 RAD guys. The reality is that everybody wanted the ease of use of Visual Basics rapid application development and everybody wanted the power and expressiveness that C++ had. We could give them one or the other, but trying to marry the two was hell on wheels. You try to write VBX controls or try to write its native code or OCXs or whatever. They were called many things, right?
Aarthi: OCX.
Sriram: ActiveX controls.
Aarthi: ActiveX, Yes.
Anders: You tried to write COM interfaces and OLE Automation and blah, blah, blah, and it was horrible. It’s too complicated.
Sriram: IDispatch, IUnknown, oh my God.
Aarthi: I think for college, I ended up writing a DCOM interface. Back when I was in college, one of the projects I did was to write a DCOM interface. I remember telling that to Sriram when he was in college and he was like, “Mother of God, why would you do that to yourself?”
[laughter]
Sriram: No, it was not easy. There were a bunch of these constituents.
Anders: Sure. We also knew that COM as a runtime, it wasn’t really a runtime, it was more like an ABI, a binary interoperability standard between apps, but there wasn’t a runtime. There was no framework, there was no shared library, there was nothing that allowed you to abstract the OS, and so you were at this hopelessly low level. There was a need both for a runtime and frameworks and there was a need for a language that somehow tried to straddle the fence there and give you both the ease of use and the power and expressiveness of these other two. That was what was in our minds when we designed .NET and C#.
We knew, with C# specifically, we knew from the onset that if we’re ever going to appeal to Java users or C users or C++ users, it has to be a language in the curly brace family of languages. It’s not going to be based on basic, but we still need basic because we need a path forward for Visual Basic users and whatever. Plus, there’s all these other languages and really wouldn’t it be cool to build a runtime that could serve all of them? A substrate that all of these could build on. For C#, the vision was create this blend of VB and C++. For .NET, it was like build a substrate that allows you to have multiple languages host on a common set of services. That’s why it’s called the CLR, the Common Language Runtime.
Sriram: Here’s a fun question for you. I don’t know how many years. It’s must be over 20 years now since C# or 22 years since the PDC 98 was when .NET was facing out.
Anders: No, PDC 2000 was when-
Aarthi: 2000.
Anders: – it was officially released, yes, but we’ve worked on it before that, obviously.
Design Decision
Sriram: It’s over 20 years. Looking back, what is one design decision that you are proud of or how it has withstood the test of time, and what is a design decision that you’re like, “I would like to maybe have that one back”?
Anders: They’re so many. I don’t know. It’s hard to say. I think we got a lot of things right. If I had to pick one thing that I thought was pretty cool, we had this unified type system where everything is an object even though we are actually a much lower-level language. That meant that from the get-go, we had concepts like boxing and unboxing built in and understood by the runtime deeply. Then in 2.0, we got generics, which I think was a wonderful feature. It was implemented by Andrew Kennedy and Don Syme who then became the creator of F#. It sprung out of Microsoft research and they did a lot of the implementation work.
Our generics implementation is pretty cool and unique in that it’s reified generics, meaning that they’re understood at runtime. You can instantiate generic types at runtime. Where Java’s later implementation of generics is based on erasure and that has some very odd effects at runtime because the generics are gone then. Anyway, I’m off on a sidetrack here. Those are things that I think we got right. I think the thing we got wrong perhaps was to sort of wholesale go with established practices and allow the null in the door.
Sriram: I actually had that. I was going to say, is it going to be nullable types is your talk? I got that right, okay.
Anders: Yes, I always felt like in retrospect, it sure would have been nice to try to exercise nulls a bit more and basically make it possible for you to have non-nullable reference types. That was the thing that was lacking in C# from the get go. Now, we’ve done some work now, but this is 20 years later, but back then, if you declared a string, any string could also be null and there was nothing you could do to save yourself from that. Any object could also be null. The compiler could not guarantee in any way whatsoever that you had initialized your object to not be null. That meant that things could blow up in your hands at any point in time. Of course, things do.
Hoare, who invented null, called this his billion-dollar mistake. I don’t know, it’s probably more like a trillion-dollar mistake when you consider how much money we’ve all spent on debugging programs because every time you ask any group of programmers who programming languages have nulls what is the most common bug you run into, it’s a NullPointerException, right?
Aarthi: That’s right.
Anders: Now, functional languages have made a lot of progress in that space. We have two in TypeScript. Now, E# even has adopted some of these ideas.
Dynamic programming languages and Microsoft
Sriram: In the 2010 era, which is C# 1.0, 2.0 which had generics, it seems like opposite. For me as a layman term, I’ll put it like two parallel tracks. That is the static compiled runtime languages, which is CLR, Java, which I think was slow on a downtrend at this time and it wasn’t really getting that often used to. Then you saw the rise of the dynamic languages. You saw Guido with Python, Guido is now with Microsoft, and Ruby, and then Ruby on Rails. Which had some concepts, dynamic types, closures, some sprinkling of some of the concepts from more [unintelligible 00:36:17] functional languages.
When you were at Microsoft, when you were watching these, what were you observing? How did you read that era of the all the open-source dynamic language ecosystem?
Anders: Dynamic languages was nothing new in a sense of Microsoft because Visual Basic is a dynamic programming language. Of course, we had our Internet Explore team and we had an implementation of Java. We had plenty of dynamic languages around. We actually had plenty of need to interact with dynamic programming languages as well. Even in, I think it was in C# 4.0, we introduced the dynamic keyword and dynamic types and the ability to do late bound calls and so forth. Of course, that doesn’t really capture why people were interested in dynamic programming languages.
The thing about dynamic programming languages is they dramatically lower the barrier to entry because, hey, you’re going to still start writing code and see what happens, right?
Aarthi: Yes.
Anders: You don’t have to say, “Oh, X is X. X is whatever it is I say it is or I can put anything into my variable here.” Of course, as program scale, that can become a little bit problematic because now, how do you check that this code is actually going to do what you want it to do when you have given no hints in the code about what kinds of things can I stuff into these data structures and variables of mine? I’m sure we’ll get to talk about TypeScript, and one of the big things there is precisely that whole problem.
Sriram: I think, every language at the time was bounded. For example, Python had the whole duck typing, if it looks like a duck, et cetera, but Python was really bound, I think, or constrained by the GIL, the Interpreter Lock, and so on. I think, in some ways, the Nirvana was going to be a way to marry the performance and optimization and the jit of something like the CLR, but with also the exclusivity and just the ease of use of something that Ruby or Python brought to board.
The origin of TypeScript
Which brings me to what we want to talk about, which is, I would say the one language that’s probably dominated in problem, which is lines of code written or used by all of us over the last 20 years, has to be the one that Brendan Eich invent it, which is JavaScript. Maybe talk to us a little bit about the origin of TypeScript through Scripts Shop, but maybe before that, JavaScript. JavaScript apps getting bigger, what you saw, what interested you, and then you’d be like, “I’m going to roll up the sleeves. I’m going to go get back into building things again,” and then making TypeScript, all that happened.
Anders: JavaScript has a long history. It was conceived at Netscape in the early ’90s. It was put together in a hurry. I don’t know if it was two or three weeks or whatever, but we need a scripting language in this browser to program. Brendan Eich was given the task of creating a programming language, which he did, and he did a marvelously good job when you consider you only had two or three weeks to do it. It’s our luck that he had been educated in functional programming and Lisp and whatever, and then understood notions of functions as first-class objects and closure over state and whatever, and actually got that right in JavaScript way back when. That has heavily been leveraged since.
It’s interesting. Then through the browser wars, there was a decade there where Microsoft and Netscape were boring, but JavaScript was never performant enough and the internet was never mature enough for it actually to be an application platform or a programming platform. It was more like a clue language. Like here, maybe 5 or 10 lines of code just to make this stuff work, but don’t ever try to actually compute anything in JavaScript, it’ll take an afternoon. That was the established dogma I would say. Then Google went and did something marvelous. They built the V8 engine and introduced the notion of JIT compilation to JavaScript.
That was actually run by a team of Danes and a guy named Lasbac, was the chief guy on that. They did a fantastic job and they proved us all wrong that JavaScript actually can be incredibly performant. Then at the same time, HTML was starting to grow up with H5 and browsers were becoming more secure. Gradually, this platform was emerging. This true cross-platform that runs everywhere was starting to come into focus. Of course, people were discovering them and they were starting to write larger and larger JavaScript applications. It was going well for a while, but then they became really large, these apps, and they have large teams of hundreds of programmers on them.
Then they would discover that they would basically slow to a crawl and at times go backwards because they simply could not scale these large JavaScript apps for a variety of reasons. One being that there were no classes so there’s no object-oriented programming in JavaScript, there was no notion of modules or anything like that. That was a big problem, but there was no type system, and it’s not possible for you in the language to specify what your intent is. You can write the code and the code will do what it does, but you can’t put in place any guides that say, “Hey, this is supposed to be a number, not a string,” or, “This is supposed to be an object with the following properties” or what have you.
That eighth means that it’s very hard for you to write code that the next program that it comes in and maintains it knows what to do with. It’s also very hard for you to verify that these apps are going to work when you run them and it’s hard to build tooling because it turns out that these types are what enable tooling. That brings me to why it was that we then got interested in TypeScript because one thing that we saw then inside Microsoft was that teams were coming to us and they were asking us if we could perhaps productize a technology called Script#. We’d heard a little bit of, there’s this guy named Nikhil who had built this.
Sriram: Who built the web metrics, web server, and ID way, way back in the day if you remember too.
Aarthi: Yes.
Anders: We were like, “Okay, Script# is this thing that allows you to write in C#, and then cross compiles it to JavaScript so you can run.” We go, “Why would anyone do that?” of course was our first reaction. It turns out their teams were doing it because it gave them access to grown-up tooling. You could write in Visual Studio, you could use modules, you could use classes, you could use interfaces, you could type-check your code before you run it, you could do all sorts of cool things.
You got statement completions and safe refactorings and code navigation and all these many use, and you got the ability to document your code by putting types in there that the next developer on the team would actually understand what your intent was. We’d go, “Wow, well, that’s fascinating. You’re actually writing in C#, but you’re not running C#, you’re treating JavaScript as an IL, basically.” We were like, “That’s nuts. Surely, if you want to appeal to JavaScript programmers, wouldn’t it be better trying to fix JavaScript and make better tooling for JavaScript but do whatever it is we need to do here to make JavaScript better? That was the genesis for TypeScript, was, let’s do that instead of– because, surely, you’re never going to be best of breed by telling JavaScript programmers that you have to program in another language and then cross the path of JavaScript. That’s only going to get a few percent, but if we could make the world better for JavaScript users boring, that could move the needle.
Why is TypeScript so popular?
Sriram: I have a theory here, which is– TypeScript just celebrated 10 years, by the way, so congratulations. I think [unintelligible 00:45:38] late October, which is amazing. Makes me feel old because I just remember like it was yesterday. I think I would love a theory on why you think TypeScript– if you look at any of the ratings of most used languages, TypeScript is always there, the top 5, top 10, incredibly popular, why it is so popular? I have a theory which is, in the 2020, ’10 era, Microsoft didn’t embrace open source, or if it did, it was very reluctant.
I keep saying we, but what Microsoft put out on GitHub or how it engaged with the community, they did but it was reluctance, but I would say or anything else in the Windows ecosystem. Now, I think in the last 10 years, and if we look at the success of Visual Studio Code, and you look at the success of TypeScript, there has been an engagement with the community, which I have a theory and I would love to– but you can tell me if I’m full of shit, which I think has played some role in success. A, why do you think TypeScript succeeded? Do you think Microsoft being more open than anything to do with it at all?
Anders: TypeScript was one of the first open-source from the get-go projects at Microsoft. I would say it was open source more by me than by anything else because we fully realized that if we’re ever going to appeal to the JavaScript community, this has to be open source, because JavaScript is everywhere. It’s like the platform that runs everywhere, not just on Windows, so there’s no way we could build a proprietary product here and appeal to the community. I think it was a hard sell at the beginning back in 2010, but then, of course, there were changes happened, like Satya became the CEO of Microsoft within a few years after that and all of a sudden the mindset very much changed at Microsoft.
I think open source has more deeply evolved into some communities than others, but the place that it evolved most deeply first was in development tools, I think, and so, already, it was evident to us back in 2010 that going forwards, you’re not going to be able to do development tools if you do not appeal to the open-source communities, so we are going to have to learn to do open source. We did not know anything about how to do open source. We thought we knew, but we didn’t. Then, in the beginning with TypeScript, we did what was technically open source in that we put the source code out there and put a license on it, so permissive license, so people can have the source code, but we didn’t actually develop it in the open. We still used our internal backtracking systems and we scrapped the feedback from– it was on CodePlex. That was Microsoft’s-
Aarthi: That’s right.
Sriram: Oh, yes. Oh, my goodness.
Anders: -open-source repository which was mostly crickets, but still, we would take the feedback from there, put it into our internal backtracking system, and then we would occasionally lob a copy of the source code back into CodePlex. We quickly realized that this does not [inaudible 00:49:12] community participation, and community participation is the hallmark of open source, right? In 2014, we moved TypeScript to GitHub. That was really when things began to take off, because now, all of a sudden, it became possible for the community to actually involve itself in the development of the product.
We’ve been there ever since now. Our entire workflow is in the open, like our design meeting notes, everything, everything. There are no secrets on this project. It’s been liberating. It’s been wonderful. For myself personally, I love that workflow. It is so rewarding to be right there, right next to your users. They can report bugs in the morning and you can have a fix in the main branch by afternoon. That is so– it’s gratifying for us doing it, and it builds tremendous excitement for the product in the community. It’s just a win-win for everybody. Even for Microsoft, it invites conversations with groups of programmers that previously we would never reach, right?
Aarthi: Right.
Sriram: Yes.
Anders: Through projects like TypeScript and Visual Studio Code now, we are bigger in the developer division than we’ve ever been, in terms of engaged users. It’s phenomenal.
Sriram: I grew up in a Microsoft where if you ever posted on any open-source program with Microsoft, you’d get the Micro$oft, or a Windows, or you’d–
Anders: Oh. Yes. M$fts, I’ve seen that, oh, man. I think Miguel de Icaza said that, but maybe others have said it before. Trust is one in drops and lost in buckets. It takes forever to win people’s trust. You got to be really careful because it takes one dumb mistake and then you’re pouring it all out of the bucket. We’re very, very serious about this journey. It’s been fantastic. It’s been so wonderful to be part of.
Sriram: Which, by the way, blows my mind when I see this forums and they say, “Oh, my favorite language is TypeScript,”-
Aarthi: TypeScript.
How does Anders Hejlsberg write code?
Sriram: -and I’m using VS Code over Emacs versus vi. You’d be amazed how many times when I said Emacs versus vi debate for the last [unintelligible 00:51:45], well, I don’t want to admit it, but I boot VS Code because it’s better than everything else. I really want to ask you this because I want to focus on Anders as a person too, because one thing that really strikes me about you is there is a risk for architects and designers to become “architecture astronauts” where you are removed, and also there are certain other maybe people at Microsoft who this might be applicable, but you are so removed from the actual thing that is being built in the way that is being built, that over time, slowly, you lose the fine details of what it is you’re designing. You have avoided that. You roll up your sleeves and you got into building TypeScript. I am curious about how you avoid the prompts of just being too out of the details and being an astronaut, and then maybe talk to us a little bit about how you write code and how you engage with writing software yourself.
Anders: It’s interesting because I’ve had a long career. It’s been 40 plus years of programming at this point. In the beginning, programming was what I did, and only programming, and it was only myself. Then I learned, I would say over time at Borland, to become a team player, and then I would say I learned at Microsoft to become an architect and a language designer. I was gradually moving up towards the stratosphere there. On C# mostly, I would write code but I would mostly write code on the .NET Framework, like I wrote a bunch of the base classes in .NET whatever, but I wasn’t actually writing the compiler, I was writing the language specification.
There was some unfulfilled part of me there. I did not realize at the time, but I was gradually less and less enthused with that. There was some itch that I wasn’t scratching without really knowing it. It wasn’t really until late in the C# project where I felt a bit burned out and took a sabbatical and then whatever and then discovered that you’ve lost your roots. You’re not actually programming the way you used to, and that’s really what makes you happy. With TypeScript, when that opportunity presented itself to get interested in this new opportunity, I decided to participate in the coding of it too. The first versions of the compiler, I did not write.
That was written by Steve Lucco. Then we had a team that tried to– [unintelligible 00:54:40] didn’t try, they wrote the first compiler we shipped, which was written in sort of C# style in JavaScript, and it was not particularly efficient and I had gotten curious about this other style of programming in JavaScript where you use functional features way more and closure and whatever. I was like, “Wow, let me let me try to just write a little parser this way. Now, let me try to write a little type checker, maybe also,” because there was not a whole lot in TypeScript at the time and discovered that you could write way more succinct code, and it ran way faster.
Eventually, that became the core of the compiler code base that we’re on right now. I’ve ended up writing a lot of code. I still write a lot of code in that code base, I’m sort of the chief committer, I would say, on the type checker, which is the more complicated part of the code base, and it’s a lot of fun. It keeps me happy. It makes me also say no to other things. I’ve never been a people manager. I’ve never risen up the ranks but I also full well know that if I had chosen that path, I would have never been as fulfilled, because this is my calling. My calling is writing code, so I’ve doubled down on that.
What does Anders’ 2023 gear + setup look like?
Sriram: This is a off requested question about you, which is, let us say you want to write a fun piece of code today, walk us through your tool set, your monitor, your keyboard, what IDE you’re going to use. Feel free to piss off half the internet with your choice of IDE language. What would Anders Hejlsberg use in 2023?
Anders: I’m actually a pretty simple guy. I don’t have a super, multi monitor, fancy, game setup. I like to work on laptops. I always work– because it’s sort of going all the way back to the beginning of time at Borland, I would always work at home several days a week and that’s where I wrote most of the code. Then I go in and play ping pong and interact with people and then whatever. I treated work as [laughs] the place where I wouldn’t work and then I go home and work. That meant I needed the ability to lock my computer with me. I had portables back when they were transportables, like Osbornes and the Kaypros and what have you, these things that were bigger than sawing machines and weighed a ton, and I would lock them back and forth, so I’ve always been on laptops, and I’m still on a laptop. The laptop I have today, it’s I think Pad P1 with a nice 4K monitor or 4K screen.
Aarthi: Nice.
Anders: A touchscreen, it’s awesome. I love their keyboards. Once you-
Sriram: Oh, yes.
Anders: -use their keyboards, you can never go back. [laughs]
Sriram: Lenovo makes the best keyboards still.
Aarthi: They still do.
Anders: The OS I use is Windows just because that’s what I grew up on and what I’m very comfortable with. I use Windows terminal, the new host for [crosstalk]-
Sriram: Oh, yes. I love it.
Anders: -and that’s awesome. I, of course, use Visual Studio heavily. My color scheme is Monokai, which I like. That’s kind of it. I used to have an external monitor but like just, oh, this plugging in and whatever and it’s like, just get a decent laptop with a big nice screen [unintelligible 00:58:42].
Sriram: The two schools of thought, for example, on the use of IDEs and how you write code, for example, there’s a whole class of people who just printf their way to debugging. Then there are others, for example, John Carmack famously fall to this category, John’s a legendary Visual Studio user, where you allow the debugger, you allow being able to put a break point, inspect the state of your program. It sounds like you are in the latter category. I’m confused about which category– Do you see appeals to both categories and do you see yourself as part of the second category?
Anders: I’m in both. It depends on what I’m trying to debug. I am absolutely guilty of using console.log and just slap it in the middle of a compiler and print out what– I guess the compiler already has internal functions that allow you to convert a type to a string representation, because we need that in error messages, so it’s trivial to just have a console.log that prints what type are you looking at here and here? What are you instantiating now or whatever if you’re looking at some generic– Then there are also cases where, you know what type systems and particularly structural generic type systems like the one we have in TypeScript?
Recursion is, you are always staring into the recursive abyss in literally every function you’d like where you’re trying to relate to types that are deep and they are generative, they keep making new types as you descend into them. It’s like there’s this parent thing, you can just keep asking for the parent, and the parent of the parent, and the parent of the parent of the parent, and it never ends, so you build up these enormous call stacks. At that point, you really need a debugger to sort out, how did I end up here? What’s the bottom of my stack look like, and what was it that got me into this cycle? You can sort that in the call stack, see, oh, this repeats 15 function calls deep. It keeps on coming around, and why is this happening and what are we going to do about it? I do both. We do profiling too. I do profiling too.
Aarthi: Nice.
Anders: Sometimes it’s like, all of a sudden, a compilation takes like, why does it take 10x longer in this release [inaudible 01:01:05]? We’ve got to figure out what is it that’s slow here, so now you need a profiler.
Aarthi: That’s awesome.
Anders: There’s no one tool that does it all, but console.log or printf whatever, definitely a path of least resistance. It worked for a long time.
Aarthi: We posted on Twitter and said, “We’re doing this interview. What would you like to ask Anders?” and one of the frequently most asked question was around large language models and AI with Copilot. What is your thinking or has your philosophy of language design shifted in the light of the proliferation of AI and how we think about Copilot and everything else?
Anders: Language design, no. Language design moves very slowly. Look at the 50 years that have gone. You go back 50 years on programming language, they didn’t even look all that different than they do now. They’re a reflection very much of the machine architecture and the capabilities of the hardware. There are different abstraction levels and you could envision languages going up the abstraction level and languages for constructing query prompts for large language models and that sort of thing, but when it comes to general-purpose programming, it’s a much longer window to answer that question and we’re not in it deep enough yet to know.
I do think it’s going to change the way we construct tooling. Absolutely. Copilot is one example of that, but there are, oh my God, so many other things that we can apply that in the tooling and we’re going to definitely– I mean, we’re looking at that every day. It is interesting with these things. These large language models are at one time mind-blowing in their capability and mind-blowing in their time stupidity. I saw a tweet from Tim Sweeney who said ChatGPT is like a person with encyclopedic knowledge and the writing skills of an English professor but with the reasoning abilities of a first-grader.
I think in many ways that’s true, because these things can cough up the– if anyone anywhere has written a piece of code or a piece of prose that sounds like what you’re trying to do here, these things can recall and improvise a bit over, but when it comes to reasoning about things, I still think we have a long way to go. I don’t know enough. I don’t think anyone knows where this ends. I do think large language models– when you think about the way we use them currently in products like Copilot or ChatGPT, where you feed a token window of here’s like 4,000 preceding tokens, or 8,000, or whatever, however big your model is, what’s the next token?
What’s the one that comes after that, and the one after that? If I reflect over how do I reason about my coding, that’s certainly not the way I think of it. I don’t arrive at my solution to my algorithm by thinking about what the next token is. Maybe we’ve discovered that these large language models can do a lot but we’re not helping them reason yet. We’re artificially constraining the problem by feeding them a bunch of tokens and asking for the next one. Maybe that only gets you so far. We don’t know yet, and we’ll see, but I think there’s still a lot of undiscovered territory here when it comes to applying AI to programming.
Sriram: I sometimes wonder whether it removes some of the romance of building code. For example, when you told us your hash table story, or when you look at maybe legendary piece of code like Karl Max QuickSort, for example, there is a little bit of man bending machine to his will, and there’s a little bit of craft to that which maybe not– it doesn’t really lend us large scale software development.
There’s a part of me, as I said, LLMs and Copilot and I see the appeal, there is a part of me which goes, is some of the romance drained away, because the next token that’s being predicted is the average of all the code written and maybe, in some way, that reduces the possibility of somebody coming up with this spark of genius to be like, “Well, why don’t we try things this way as opposed just tap complete the median of human output?” Do you ever think about that at all?
Anders: I do. Sometimes just joke that maybe we’re at the moment of peak truth right now, because what you find on the internet today was actually created by humans largely, but from here on out, we’re going to be training AI models on a bunch of AI-generated garbage that is just regurgitation of their own hallucinations. Who knows where this all ends? I do think, though, that AI can help tremendously with a lot of drudgery.
Aarthi: Exactly.
Anders: Like going to Stack Overflow and trying to parse through how do I best formulate my answer here? When these models can just cough up a great start.
Aarthi: Yes, exactly.
Anders: It does not absolve you from understanding what the code does. I don’t think that you can get away with not being a programmer just because you have something like an LLM.
Aarthi: I think you’re spot on. I think there’s something about using programming knowledge and just people being able to write code to fulfill their bandwidth towards doing something interesting and what they’re capable of, as opposed to dealing with drudgery. I feel like if you’re able to deploy AI to just deal with that, to deal with solving, say, protect legacy code, tech debt, that kind of thing, I feel like it just frees up a lot of intellectual bandwidth to focus on exciting, interesting programming problems, which I think it’s such a good promise.
Anders: Yes, I’ve always said that the thing that I’ve worked on for 40 years is programmer productivity. It’s like removing drudgery from programming, like finding your bugs or statement completion, all of these things, they give you more time to do the creative part. I think these AI models can help tremendously with that because they can just cough up, “Someone already wrote that function, here. Now go modify it to your needs,” and that’s super useful.
Sriram: Yes. For example, I think of, let’s make an example. Let’s spin up a VM on Azure. I can probably spend the next 30 minutes googling around and finding the right Stack Overflow and sticking the API key or [unintelligible 01:08:36], I know I can do it, but then I know a million people have done better than me and just shift, tab, enter, whatever, that’s so much easy. Your point on [unintelligible 01:08:45] to this, I always think is profound, because I think of the whole classic Ship of Theseus paradox, where you get one piece of the ship, the wooden piece of ship removed every single time [unintelligible 01:08:57], can you ever tell when it stops being the original ship and it’s actually something new? I think there is something there about human-generated output and AI-driven output. For example, in five years, if most of GitHub’s corpus is enhanced by Copilot, and then there is OpenAI or some company in 2028 training on that, at what time is human input totally removed from what AI is being trained on? There is a Ship of Theseus [unintelligible 01:09:30] in there somewhere.
Anders: Yes, you can construct a lot of scary scenarios here. We don’t know where this all ends, but it is fascinating.
Sriram: When you think about programming languages today, what are some low-hanging problems not just in languages, but in terms of how people write software, that you’re like, “I would love to spend the next 5, 10 years at Microsoft, outside Microsoft, or the industry, I would love for either me or industry go tackle this in how software is constructed”?
Anders: I don’t think there are any low-hanging problems, or low-hanging fruits. If there was low-hanging fruit, [unintelligible 01:10:13], we would have picked it. I mean, come on. There are still hard problems in computer science, plenty of them. Even though I’ve been in this industry now for 40 years, I don’t think we ticked off the problem of dynamic memory management. We have a bunch of different solutions, reference counting, or garbage collection, or borrow checkers like in Rust, but none of them give you cost-free, safe dynamic memory management at a systems level.
You’re always trading off something. Maybe that’s just the way it is, but it feels to me like we haven’t quite licked that one. We have not licked the problem of parallelism in programming languages, far from it. How do I parallelize this code? Then when you look at the CPU architectures we’re getting today, we’re not getting faster cores, we’re getting more cores. All the time. There’s a big problem. Declarative programming hasn’t really been– this is what we’re talking about, how do we move the level of abstraction up?
We’re making progress in the no-code, low-code space, but there’s still plenty of stuff to do there. I think, in some ways, programming languages, they’re related to the hardware, but they’re also very closely related to math, and it’s not like math just changes overnight. This is a slow, gradual evolution and discovery of new things and new constructs and new algorithms and whatever, but I think it’s a mistake to believe that there’s all of a sudden step change. I don’t think so. It’s not if history is any guide.
Sriram: I don’t know whether you spend time in crypto, but one of the spaces very interested in is the idea of how programming language design has been evolving in the world of crypto. Crypto is a very interesting space for it because the downside of getting something wrong is not that your program crashes, it’s going to be that you lose hundreds of millions of dollars.
Aarthi: Right.
Anders: That’s right.
Sriram: I don’t know whether you’ve spent time with Solidity, but there is a whole ecosystem of programming language design with Move, and there’s a bunch of others, which are all about– it’s actually very different set of design problems, which is really about safety, knowing exact verifiability, because the downside of getting something wrong is you lose a lot of money very publicly, very, very quickly. That’s another area where I think programmers, they’re seeing a lot of interesting design and evolution.
Anders: No, there’s some interesting problems there, like in static type checking and theory improvers, absolutely, have a lot of applicability in that space.
40 years on programming language design
Sriram: I have a question for you, maybe a personal question of sorts. One of the things I love about you is you’ve been in the same company for over 20 years, 25 years now, and essentially been in the same field of programming language design for 40 years. Now, I live in a world in Silicon Valley where people switch jobs every few years, and I’ve definitely switched jobs or I definitely switched the kind of job I’ve been doing.
I’ve been a venture capitalist. I used to be a product person, and there’s just something very deeply romantic about the idea of like, I’m spending 40 years working on this problem and then being one of the best in the world, if not the best in the world at this. I’m curious, just your thought process on that, which is at any time, did you go like, “Okay, well I’m done with program languages, I’m done with Microsoft, I’m going to go off and, I don’t know, build a SaaS spreadsheet software company or something else”? Just talk to us about what has kept you going in one space for so long.
Anders: Maybe it’s just because I’m incredibly boring and risk-averse, but no, I think you don’t get to do language design if you want to switch jobs or switch careers every two years or three years, because it’s just like the languages don’t work on that time horizon. I think, in a sense, my career illustrates it. Every one of the products I worked on kind of took a decade to establish their community and user base and relevance in the world. That’s the timescales you’re dealing with when you’re doing programming languages. It’s a slow work.
Like it probably takes a couple of years to bring a programming language from the get-go to a level of actual usability, and the ante keeps going up, because people now expect tooling that is way more intelligent than they used to. It’s not enough just to have a compiler with all that goes into that, and cogeneration and whatever and type checking and whatever, no, no, no, you also have to have language services, and you have to have integration in development tools, and you have to have all sorts of stuff, like, big old tool chains. It takes a while to get that built.
Then, of course, you don’t ever get it right in your first release, it is typically not until the third release that a language is truly like gotten it all sort of put in the right place and have all the right features. Now you’re like five years down the line before you even are relevant. It’s a long game, basically. I like this long game. I like noodling away at it, “Look, we can make it a little bit better here, a little bit better here.”
Once we’re five years down the line, gosh, darn it, it starts to accrue. That’s been the game with TypeScript too. We’re about to ship version 5.0, but we’ve shipped more than 40. We’ve had more than 40 releases on a typical three months cadence through the years there to get to where we are now. We are very, very capable as the language now have a lot of innovations in the type system, but it did not happen overnight. I’m the right kind of guy or the right kind of mindset for that sort of problem. That’s why–
Sriram: I love it. I think I use the word romantic and I think it’s applicable here, which is something applicable about like doing long-term work and saying, “This is going to be something, it’s going to be important. We’re going to spend years at it.” There is code written in C# running 20 years later, there’s code in VB6 still running now. There’s probably code older. These are things which last decades, people’s lifetimes even. There’s something beautiful about that, especially when we live in a world where things don’t last very long. I just love that you do that.
Anders: No, and I will tell you, it’s tremendously gratifying too to see and to know that you literally have millions of programmers use stuff that you work on and that appreciate it too, because programmers tend to be incredibly excited about their tools because they spend their entire workday in this thing, and when this thing gets better, that’s eight days of better time for me every day. They get very excited, and that’s just tremendously motivating and invigorating for those of us who work on these products.
Thoughts on Rust
Sriram: Switching gears just a little bit, and this could be a rapid fire round and maybe a bit spicier. I would love for your quick thoughts on a few programming languages, the good, the bad, anything at all. I have a few. Let’s first start off with Rust. What do you like, not like, what are your thoughts on Rust?
Anders: I like the courage to try new strategies for dynamic memory management. I do not like the complexity of the outcome.
Sriram: This is spicy content. This is going to blow up the internet right here.
Anders: No, no, I think that’s fairly well established that it takes a while to understand how Rust works. There are also limitations. There are certain typical data structures that become very hard, like a tree with parent pointers. You can’t really do that in Rust, not easily. You have to understand all the tricks to work around the borrow checker to make that work. That said, lots of respect. I think, man, that the world was overdue for some progress in systems programming languages and I think Rust delivers. [unintelligible 01:19:36].
Sriram: I’m going to make a clip of this and put it at Anders Hejlsberg dunks on Rust and try to make this go viral. Next up, Go. Golang.
Anders: I do not like the fact that there were no generics in that language and it took that long for them to get in there. I think that hampered the language dramatically. I find their approach to interfaces really interesting, this notion that there’s not as deep of a coupling between code and data and pointers will carry along with them their own V-tables for interface dispatch, so you can marry an interface and a data structure even dynamically and construct a V-table dynamically for that. Where in OOP, that tends to be much more of a fused heavy marriage and you can’t easily construct new implementations of something at runtime. There’s some interesting stuff there.
Sriram: What do you think about Go’s ideas, because hey seem to push the state-of-the-art on current programming models forward, and that may be a reflection of the Google systems programming. You don’t seem impressed.
Anders: Sure, they added primitives in the language to start off new threads of execution, but beyond that, it’s not clear that issues such as thread safety and all of the other– I’ve always said, if you’re programming with– you can have mutability or you can have parallelism, but you can’t have both together. No one understands what happens when you have both together. That’s why functional programming, great, you can do parallelism because there are no side effects. Or you can do mutability, but, boy, once you add threads to that and free threading and then whatever, oh, gosh.
Sriram: Oh gosh, yes. I remember many years ago, I tried to understand Haskell deeply, and OCaml, actually, and I tried to understand Monads and the whole theory there. The way I understood it was like, side effects are dirty, so wear gloves and touch it very, very carefully and then tell everybody these things are dirty, and then you pass it around with this big warning sign, with this big radioactive warning sign through the program, was my mental image of it.
Anders: It turns out that this notion of programming with islands of functional purity is actually really a useful way to think about a lot of problems. I am actually a fan of– I’m not necessarily a fan of Monads and Endofunctors and what have you, all this fancy terminology, but this notion that you try to park the side effects in a place where you can reason about them, and then you have whole portions of code where you just know, well, there’s no mutability over here, so that can just be parallelized and I’ll have to think about it, because no one ever modifies this data structure, so I can have as many threads banging on it as I want and nothing’s going to go wrong. It’s empowering.
Sriram: Next one. This is the cool new kid on the block, even though it’s a few years old. I don’t know whether you spend time with it, Zig?
Anders: I looked a little bit at it, but I don’t know enough about it to offer an educated opinion.
Sriram: I’ve spent very little time with it, but I think Zig is a better C in some ways. I don’t know whether it sounds blasphemous, but C fixed made simpler, easier, is how I think about it. Last one, Solidity, and the whole Ethereum Ecosystem Program, have you ever spent time looking at that?
Anders: I’ve looked at it some– Solidity is not a general-purpose programming language. I would call it a domain-specific language, and I tend to spend less time on domain-specific languages. I think it’s an interesting problem space. I think whether a whole programming language is merited there is not entirely clear to me, or whether you could have done better with a more declarative form of contracts and then gradually added the capabilities that are necessary, I’m not sure.
Sriram: Exactly sort of a religious question here on the crypto ecosystem. For example, there are other blockchains which have taken the approach that, let’s reuse the existing program. For example, Solana, which is a competitor to another alternative blockchain, part of their appeal is that you can use the Rust toolchain and it compiles to this ABI style layer, but the idea is that you get not all of Rust but enough of Rust and you can bring the skillset. We’ve definitely seen people take different approaches, but I think you’re spot on.
What’s next?
Sriram: Let me get a sense, maybe just as we get near the end of this, which is, what are you spending time on now? What are you excited by? What is the next year in the life of Anders Hejlsberg looks like?
Anders: [laughs] I’m continuingly involved in the TypeScript projects. My daily workflow is working with the TypeScript team and writing features and fixing bugs in the type checker and in the larger TypeScript code base. Then I also get to consult a lot with other teams at Microsoft, like anything that rhymes with programming language, I have a way of getting involved. I’ve helped other groups with constructing DSLs in language integration or reasoning about whether this makes sense to do or not. I try to educate myself about what happens in AI, but it’s like drinking from the fire hose and I’m not really a mathematician by trade, so I can only [chuckles] get so far. Those are some of the things I would say that are in my day.
Aarthi: Would we ever see another programming language that Anders is working on, or is it something that you’re thinking about? Is something in the works?
Anders: Whenever people ask me that, I say that the world needs another programming language, like it needs another hole in the head. I already told you, it takes 10 years for programming languages to succeed and I would be in my 70-
Aarthi: 70s.
Anders: -by the time, [chuckles] such an effort would be irrelevant, but who knows? Never say never. The whole TypeScript journey kind of fell in my lap. I wasn’t planning it, so, maybe, but there are no actual plans.
Sriram: You mentioned Tim Sweeney, the other day I saw this tweet/report that Epic is working on a new programming language for the Metaverse. They have Simon Peyton Jones that literally–
Anders: Yes, Simon Peyton Jones is there now.
Sriram: Who’s a legend in programming design. It did not occur to me that a Metaverse [unintelligible 01:27:13] a programming language, but here we are and there are some really interesting ideas. I again saw a tweet–
Anders: Us programming language designers will always like find a way to couple a new programming language to some technology. We need an AI programming language.
Aarthi: Nice.
Anders: Just like we needed an XML programming language, we needed like that and that was the [unintelligible 01:27:33].
Sriram: Oh, I got you.
Anders: There’s always–
Sriram: Today, somebody was like, “Hey, maybe for ChatGPT, the interface should be a DSL as opposed to the English language,” and I said, that–
Anders: I know. That seems to work with the– I mean, hey, I think [unintelligible 01:27:47].
Sriram: You never know.
Anders: I actually think the natural language interface is the power of ChatGPT. Prompt engineering is starting to become a bit of a pseudoscience, so maybe there is some need for something there, but too early to [unintelligible 01:28:06].
Sriram: My instinct is, the world hasn’t seen the last programming language from Anders yet. Anders, I just want to say, one-
Aarthi: This was such a blast.
Sriram: -this was such a blast. I just want to say thank you. We told you the story about how I tried to impress her 20 years ago of saying, like, “Hey, this whole [unintelligible 01:28:23] C# thing is kind of cool,” but the amount of impact you have on the software just impacts every part of our lives, the amount of impact you have on how these have been constructed is beyond measure. Thank you for everything you’ve done. Thank you for this amazing content. This was so much fun.
Aarthi: We kind of owe our early starts to our careers, at least to you. I think we started at Microsoft, we started working on Visual Studio, I worked on the CLR. Even before that, a lot of our conversations, one of the languages I had picked up very early on was Common Lisp, and we started trying to think about what would a compiler for Lisp would look like. Then we moved to Scheme. I think [unintelligible 01:29:08] got me a pirated version of SICP?
Sriram: Yes.
Aarthi: A lot of our early conversations were around programming languages and centered around you, for lack of a better word, and so thank you for everything you’ve done and thanks for employing people like us indirectly.
Anders: You’re welcome. It’s so gratifying to hear you say that this is precisely the thing that keeps me doing what I’m doing. There’s nothing more gratifying when you’re working on a product to know that people appreciate the work that you do.
Aarthi: So cool.
Anders: I’m really, really happy to hear that and thanks so much for having me on this. This was a super fun conversation, I really [unintelligible 01:29:52] too.
Sriram: This was super, super fun. Thank you so much, Anders. This was such a blast. Thank you.
Aarthi: This was great.
Sriram: Thank you.
Anders: You’re welcome. You’re welcome.
[01:29:58] [END OF AUDIO]
