So today I have the pleasure of talking with Anders Hejlsberg. He's one of the most influential designers of programming languages of our time.

And from Turbo Pascal to Delphi to C# to now TypeScript, your work shapes how millions of developers write code every single day.

My first exposure to computing was probably in high school, and I was fortunate enough to go to a high school that offered students access to a computer, and this is like, we're talking the late '70s here, and this was not a common thing.

And I got very interested in the programming aspect, and then I decided, uh, when, you know, these 8-bit micros were starting to come out, that I wanted to build my own kit computer.

Then I started writing a lot of software for that thing, and it turned out to be pretty good at it. And so I really enjoyed it.

Honestly, you know, I had no problem doing structured programming in assembly. And and of course you have to realize too that, I mean, with 64K of memory, there's only so much you can squeeze in, and you got to leave something over for the user too, right?

And so you could keep it all in your head, you know, back then.

Turbo Pascal kind of revolutionized the developer experience. It kind of speaks to a focus on shortening the developers, you know, loop, so to speak.

Exactly. And so I do want to hear how much of a deliberate philosophy that was from you from the beginning. Well, so first of all, the reason people really liked BASIC on those early machines was that shortened cycle, right?

I mean, now BASIC is an interpreter where you just type the code in and then you run it, and it runs.

But of course, it doesn't run very fast because you have to pay the price of an interpreter.

And the editor was kind of crappy because it was this line-based editor. And when you looked at word processing systems, they were all on-screen editors where you could cursor around and and whatever.

And that just seemed like a much better way to edit your source code. But this notion that you could just say run and then it would run, that seemed like the right way to do it.

And then so, but in order to do that and get performance with a compiler, well, you had to generate code first.

I think with Turbo Pascal, it was we we just turned it into you say run, it immediately compiles into memory.

It doesn't actually even touch the disk, and then it just runs the code in memory. And then if there's an error, it just drops you into the editor.

The compiler was real primitive. If you knew at what address the error had happened, you could sort of try to compile again, and then when a compiler actually got to that address and was writing code, and then you'd see where where was I in the source code.

Well, that's around here is where the error was, right?

And so so you got this incredibly interactive experience all of a sudden and that was pretty revolutionary.

Was it was it at all like um a bad experience for you or a frustrating experience for you, the idea of something taking an afternoon to compile?

>> Of course it was. No one no one likes it. >> No one likes waiting. You know, you you you, okay, it's like, now I've typed my code, I want to run it.

I don't want to sit around and wait for it to run.

>> Another thing about Turbo Pascal is I think it kind of democratized programming a little bit by being affordable. I know sometimes we don't start these things thinking they're going to impact an entire generation, but now that you're here and you're thinking back, there's an interesting story there.

So, the predecessor of Turbo Pascal was called Poly Pascal, and that was the Pascal compiler that I had developed within our little software company in Denmark.

And then we got in touch with the people who founded Borland.

They came back a week or two later, "This is amazing. We should get together and do a product together and sell it in the US." And then they decided they're going to sell it for $49.95.

And I was like, "Are you nuts? We'll never make any money." In retrospect, it was brilliant because yes, you charged a tenth as much, but you sold three to four orders of magnitude more copies, right?

And in the end, it was fantastic. The kudos there go to the old Borland founders and Philippe, you know, for doing that.

>> Let me ask a question that brings us closer to Delphi.

It also marked kind of like your transition from a solo creator to more of a collaborative team leader.

It's true that in the beginning I was very much a one-man show, you know, although I would work with two or three guys at the original Danish Borland office.

But obviously, that doesn't scale because, you know, the capacities of the machines started to dramatically increase and expectations were ever increasing, and you couldn't do it all yourself.

Um, and so I had to learn to become a team player, which I did throughout Turbo Pascal, but in particular with Delphi.

>> You said learn how to be a team player.

What were some things that you needed to learn? >> Well, you have to accept that things get done in a different way than you would have preferred to do them, right?

Or that the code doesn't look exactly like you would have liked it to look, right?

But still, you know, you don't have enough time to go in and fix it, so to speak. And honestly, fixing it probably wouldn't really change the behavior of the product anyway, right?

But I think you also have to learn to hand off responsibility.

You can't have a team unless people feel empowered, you know, empowered in whatever feature area they own and whatever part of the product they're building.

So there are lots of things to learn. How did your experience on kind of Visual J++ at Microsoft, how did that inform the goals for C# and the .

NET platform? >> So I came to Microsoft in, uh, towards the end of '96, uh, and I joined to work as the chief architect of Microsoft's Java development tool set.

We'd just shipped Visual J++ 1, which was basically take the C++ IDE, yank out the C++ compiler, stick in a Java compiler, and call it good, but it wasn't integrated.

It wasn't it wasn't there was no rapid application development cycle in there at all. So we set out to do that and that was what became Visual J++ 6.0.

We started aligning with the Visual Basic and Visual Studio numbering. I was always sort of like a pragmatist about it.

You know, hey, if we're going to do Java, but for the Microsoft platform for DOS and Windows, you know, I mean, we got to have great interoperability with that environment.

But Java was all about this like write once, run everywhere.

And then you had to go through only their sanctioned UI interfaces which was a least common denominator pretty crappy experience with these applets you could build and that weren't really any good, right?

We ended up adding some extensions that made native interop simpler and we built a class library of, you know, that encapsulated all of the Windows UI and it was just clearly this ain't going to work.

I mean, if we're going to do well by our customers, we got to like do something that allows us to actually build the best possible thing you can build for that environment.

People really wanted the ease of use of Visual Basic and the power and expressiveness of C++.

And so we sort of set out to create that combo and then put on top of the .NET platform, which was a platform that we could evolve to maximally take advantage of the stuff that our customers were running on.

Right. That was that was sort of what it was all about.

Yeah. You're talking about these competing crowds of customers, but you're also describing a situation with knowing that means you're building for both.

Mhm. >> That seems like more of an ecosystem looking at things holistically and I want to understand that.

>> Oh, I think it's you have to look at it all very holistically. Users don't care whether this is a language feature or a framework feature or a platform feature or an editor or debugger or whatever.

It's the whole thing is the experience, right?

And so it's all got to hang together. And so yes, we built the runtime, the JIT compiler, the garbage collector, all of that.

We designed the bytecode for the platform and we built the class library. I worked on the class libraries as well as the language and I worked with the guys that designed the runtime and I think the result is better for it.

You know, otherwise you get these silos and then everyone's like, well, I had this vision of how the problem was going to be solved and this had another vision and then I guess we need an interop layer or something or what have you, right?

And then it's just not best of breed anymore. And we also weren't afraid of interoperating with the underlying platform.

That was I think one of the things that Sun got wrong with Java, you know, was just like this dogmatic insistence that you couldn't do anything to advantage this platform or that platform.

It all had to be this least common denominator stuff, right?

And this is never going to get best of breed that way. If you're thinking back, was there a particular kind of like, aha, moment for you that made you realize that whatever growing pains for scaling JavaScript were a problem that needs to be solved and that you need to solve it, Microsoft needs to solve it.

>> Yeah. Well, this interesting thing started to happen in the industry where the runtimes were getting good enough.

Uh like Google had done excellent work on V8 and all of a sudden, you know, JavaScript code actually ran with decent performance.

HTML5 had gotten ratified and there was actually pretty great UI available now.

And all of a sudden there was this multitude of form factors like phones and iPads and whatever that didn't run Windows. And the world all of a sudden sort of discovered, you know, the real platform game isn't Java.

It's actually JavaScript and the browser and HTML. And then they started writing bigger and bigger and bigger apps because these new runtimes and UI technologies allowed the apps to get big.

But then everyone started discovering how insanely hard that is to do in a dynamic programming language with no good tooling, right?

And so we were seeing the strangest contortions starting to happen.

And one in particular that was when the outlook.com team came to us in .

NET and Clay actually in C# mostly and asked whether we get involved in productizing this thing they had called Script# and I'm like, Script#, what's Script#?

Well, it's this thing that allows you to write in C# and then it translates that into JavaScript and then that's what you run.

And I'm like, well, why on earth would you ever want to do that?

It seems to me like the worst of both worlds, right? Well, it turns out the reason you want to do that is then you can get grown-up tooling.

Then you can actually have a type checker. You can have a team. You can write interfaces.

You can describe how these pieces of the software are going to talk to each other. And that's what we're doing, you know, because we have hundreds if not thousands of programmers that are going to work on this and they can't just like write JavaScript and and and not have something that can check the code and no tooling and no statement completion refactorings or any of that stuff, right?

And I was like, wow, is it really, is JavaScript really that broken, you know?

And and is that really the best thing we could do to fix it, right?

I mean, like tell people to write in a different language and then sort of treat JavaScript as an IR that you or bytecode that you compile to.

Surely we could do better. What what could we fix JavaScript so there were some really interesting things that became possible if you think about it that way, right?

And so so then we started exploring that and you know that it's worked out pretty well.

[laughter] >> The decision to make TypeScript kind of like a strict superset of JavaScript has, you know, had some strategic thinking into it.

How did you champion it and what advice does that, you know, allow you to give to others about this idea of meet developers where they are?

>> It's funny because whenever people come to me and go, oh, I have the, I'm thinking of creating this new programming language that's going to do this and that and fantastic thing.

I'm like, my first my first advice is the world needs another programming language like it needs another hole in the head.

Second, if you decide to do a programming language, realize that 90% of what you're going to do is the same thing that every other programming language has to do.

And that percentage just keeps going up. Like the barrier to entry just keeps getting bigger and bigger and bigger, right?

The expectations of programmers today, it's not enough just to have a compiler. You also have to have a language service that integrates into pretty much every IDE that's out there.

Now, you also have to have LSP servers that can talk to AI and what have you.

You you have to have debuggers, you have to have profilers, you have to I mean, oh my God, the list just goes on and on.

And then you got to like have probably 10 years of time because that's how long it takes for something to actually get a foothold, to get to meaningful usage numbers, right?

No one wants a brand new programming language right out of the gate. And so you're going to be starving for five years at least, you know, with with with not enough users and, "Hey, do we really want to keep funding this?

Do we really?" It's a tough business. But by extending JavaScript, in a sense, we were saying, "We're not going to create a whole new language here." That's that's pre that's precisely what what they were advocating with Script# , right?

It's like, no, we're just going to fix what's broken about it. Our language service in Visual Studio Code, it's the same for TypeScript and JavaScript.

So JavaScript to us is just TypeScript without type annotations, or maybe you're using JSDoc annotations instead or whatever.

But you know, it's the same investment. So it's not like we're building two different things. We're building one thing, and we're building only exactly what we need to build, right, in order to just make the ecosystem better.

Launching TypeScript as an open-source project on GitHub in 2012.

That was a radical move, we could say, for Microsoft at the time. I'd say we had a pretty good understanding of how that JavaScript ecosystem functioned and what the ethos was and what it required to actually engage with that community.

The history of C# and TypeScript with Anders Hejlsberg | GitHub

GitHub is the AI-powered developer platform to build, scale, and deliver secure software. We make it easier for developers to be developers: to work together, to solve challenging problems, and to create the world’s most important technologies. We foster a collaborative community that can come together—as individuals and in teams—to create the future of software and make a difference in the world.

The GitHub platform is where developers can create, share, and ship the best code possible. Our community is made up of students, hobbyists, consultants, enterprise professionals, partners, and executives, building software in the way that works best for them.

GitHub is much more than code. It is the home of open-source collaboration. It is where new developers get started and where experienced developers expand their knowledge. It is a community where developers come together to solve the unsolvable and test the limits of what software can do.


The history of C# and TypeScript with Anders Hejlsberg | GitHub

Scripts