The One Who Created Languages

Anders Hejlsberg is the original author of Turbo Pascal and was the chief architect of Delphi. He currently works at Microsoft as a Technical Fellow. He is also the chief designer of the C# programming language and codesigner of the TypeScript language. While attending the 2018 edition of dotJS, we talked with him about his career and the choices he made, and advice to developers.

Teaching the teachers

My first real introduction to coding was probably during high school. The one I attended was one of the first high schools in Denmark to offer students access to a computer. This was before PCs or anything like that. It was actually technically what we call a minicomputer. I think it was an HP 2100. It had 32K of ferrite core memory—you could literally open it up and see the little ferrite cores. We had a paper tape reader, a Teletype, and then we got a real CRT terminal. And I learnt to program that thing in ALGOL. For the first two weeks the teachers would teach us and then we would teach the teachers, because you had to discover it all for yourself by trial and error.

From computer store to Pascal compiler

When I started at the Technical University of Denmark I went on a trip for all the first-year students. We were playing cards, and one of the other guys was losing money and writing IOUs, so I had to get to know him. We ended up starting a small company together! We had the very first computer store in Copenhagen, where you could walk in and actually buy a computer. Back then it was mostly kit computers that you had to put together yourself. But then we also ended up selling Apple IIs and TRS-80s. I just did a lot of programming on those. To begin with, you’re sort of programming what’s there in BASIC and that can get boring pretty quickly. And then you start writing machine code because that’s when you can really get down to the metal. And then you sort of start experimenting with writing stuff for the machine, such as extensions to the ROM BASIC, a small operating system (OS), or an on-screen editor. Then eventually I wanted to write an ALGOL compiler and my friend said, “No, there’s this other thing called Pascal, you should check it out, it sounds really cool.” I ended up writing a subset of Pascal with a little on-screen editor and a little runtime package. It was only 12K of machine code and it fit into a ROM, so you could yank out the Microsoft ROM BASIC and put in the Pascal. And then when you turned your computer on, you were seeing a little on-screen editor and you had Pascal. Now, it was a subset of Pascal, but of course that then grew into a fuller implementation, an implementation for CP/M 80, the 8-bit OS that was on all the micros at the time, and eventually for PC DOS.

Turbo Pascal at Borland

Around 1982, or maybe 1983, we ended up meeting up with some other guys who had a small company in Denmark. They wanted to get out of the hardware business and into the software business and had written a couple of programs. One was called Word-Index, which could create a table of contents and index generator for WordStar, which was this popular text-processing system at the time. And they were writing in Pascal, but they were using a very crappy Pascal compiler, so we were like, “We actually have a very good Pascal compiler, you should check it out—it’s this and that fast and it has an on-screen editor.” They didn’t believe a word of it, so we said, “Here, try a copy.” And then they came back to us: “This is amazing, we should do business together.” We ended up actually doing a royalty contract and that’s how Borland ended up producing Turbo Pascal. It was our Pascal compiler rebranded as Turbo Pascal.

A new approach for success

Obviously, the fact that Turbo Pascal took the traditional edit-compile-run-debug cycle and reduced it to minutes, possibly hours, depending on what kind of compiler you were using—with some of them you have to swap disks with PASS1 and PASS2 with the compiler—made a huge difference. We reduced that to seconds. It was instantaneous and made compiled languages feel like they were dynamic or interactive languages. In retrospect, that is the right way to do it and it was clearly one of the factors in its success. The other was the fact that it would run on any piece of hardware that was contemporary at the time. Turbo Pascal was only 32K of machine code, so even on an 8-bit machine, there was memory left over for you to write programs. And then I think, finally, it was the price. At the time, products like that were typically selling for $500. We lowered the price to just $49.95. At that price, there really is no point in pirating it. For $49, it’s worth buying it just to get the manual that explains how it works. So, all of those factors combined were quite new and different at the time.

Becoming a better team player on the Delphi project

Delphi, in many ways, was really just sort of a successor to Turbo Pascal. With the Delphi project I learnt how to be a better team player. I started out being a perfectionist, wanting to do everything myself. The entire compiler and runtime library was written by me for Turbo Pascal. There were a few other people who worked on the editor and the command driver for the IDE itself, but obviously that doesn’t scale. Eventually, you’ve got to have a team help you out and build the product.

The genesis of .NET and C#

I was hired to be the architect of Microsoft’s Java development tools. At the time there was a big push at Microsoft to do Java, and even build applications in Java or maybe even build an entire OS in Java. This was during the early days of the Internet, when Java was taking the world by storm. Microsoft didn’t have a Java development tool at all. The closest was the Visual C++ development environment, and that was not the right fit at all. So I was brought onboard to spearhead that. But it very quickly turned into a political battle between Microsoft and Sun, and the product that we built, Visual J++ 6.0, ended up earning Microsoft a court order from a judge in San Jose about our proprietary language extensions. So in a sense, all of that was the genesis for what came next, which was .NET and C#, because Microsoft as a company realized that building a future platform on top of something licensed from another partner wasn’t going to work for them or their customers. We knew from our customers that it was too hard to write code, at the time, in C++. Not enough programmers could do it. We had Visual Basic, but that wasn’t considered a grown-up, full-blown programming language and it didn’t compile to native code. So there was a really strong sense that something with the ease of use of Visual Basic but with the power of C++ was really what programmers wanted. So taking all of those factors into account, that was really sort of the genesis for building the .NET framework and, of course, on top of that, a programming language called C#.

Building TypeScript to solve JavaScript issues

It turns out that, at that time, JavaScript had all sorts of issues. There were no classes, there were no modules, and there was no static type system, so it was very hard to write large apps in JavaScript. Also, the tools for JavaScript at the time were really terrible. It felt like you were just coding in Notepad. There was no statement completion or code navigation, and no notion of statically checking your program before running it. Teams were actually choosing to write in a different language and cross-compile to JavaScript, treating JavaScript just like an IL (intermediate language). I felt like, well, if you really want to be best of breed, surely that’s not how you get to create the best possible JavaScript development environment. What if, instead, we could fix some of these issues? Why not try to figure out what the issues are, what the problems are, why the tools are crappy and what we can do to make it better? And that was, in a sense, the genesis for TypeScript.

Being closer to users with open-source TypeScript

We started out just thinking we were doing open source. We were doing everything the way we used to do it, with our internal processes, and then we would sort of lop the source code out into a repository. When people logged issues, we’d scrape the issues and put them back into our internal issue-tracking system and that was sort of that. That’s technically open source, but it’s not open development, where you’re actually doing your development in the open as well. And we switched to that after a couple of years. I think that changed everything, really. Because now we are so close to our users. They are literally there, every day. And the entire dev team is accessible and on GitHub. And that whole workflow allows you to set yourself up to be super-fast in addressing issues, so if someone reports a high-priority issue, we’ll typically have a fix during that day and the fixed version will be in the nightly build. That is so profoundly different from how we used to work, and it’s a much better way of doing it. It’s better for everybody; it’s better for the team, too, because it’s so rewarding to be that close to your users.

Developers’ enthusiasm as a reward

Development tools are the place where programmers invest an enormous amount of time—in their programming language and in their developer tools. And because they have invested so much of their time, they are of course super-passionate about these tools. So when you delight them, there’s so much enthusiasm. And ultimately seeing people’s enthusiasm in using the tools that you’ve created is very fulfilling. After 35-plus years, I still get so much from that. People are so excited about it, and I just love that.

Don’t take the dogma as a given!

Don’t let people tell you something can’t be done. A lot of people will go, “Oh we tried that, it’s not possible.” Well, that means it might not be possible for you but maybe someone else can do it, you just never know. In retrospect, you can usually see that you were thinking about it wrong or that there was a simpler way to have gone about it. So always be curious and don’t take the dogma as a given.

This article is part of Behind the Code, the media for developers, by developers. Discover more articles and videos by visiting Behind the Code!

Want to contribute? Get published!

Follow us on Twitter to stay tuned!

Illustration by WTTJ