The one who created languages

  • February 11, 2019

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 the chief designer of the C# programming language and co-designer of the TypeScript language. He talks about his career, the choices he made and gives advice to developers.

Hi, I’m Anders Hejlsberg and I’m a Microsoft Technical Fellow.

Teach the teachers

My first sort of real introduction to coding was probably in high school. The high school I attended was one of the first high schools in Denmark to offer the students access to a computer. This is 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. 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 just had to discover it all for yourself by trial and error.

From computers store to Pascal compiler

When I started at the Technical University I met another fellow. We were on a trip for all the first-year students and we were playing cards, he was losing some money and he was writing some IOU 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 later. I did a lot of just programming on these things. In the beginning you’re sort of programming once a day in BASIC and that’s 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 like extensions to the ROM BASIC, a small Operating System or an on-screen editor. Then eventually I wanted to write an Algol compiler and my friend was going “No, there’s this other thing called Pascal, you should check it out, that 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 your 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 then that 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

I think around 1982 or maybe 1983, we ended up meeting up with some other guys that had a small company in Denmark. They wanted to get out of the hardware business and into the software business. They had written a couple of programs. One was called Word-Index which could create table-of-contents and index generator for WordStar which was this popular text processing system at the time. And they were writing in Pascal. They were using a very crappy Pascal compiler. And we go “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 : “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 to succeed

Obviously, the fact that it took the traditional edit-compile-run-debug cycle and squeezed it from minutes if not hours depending on what kind of compiler you were using, with some of them you will have to swap disks with pass1 and pass2 with the compiler. We just brought that down to seconds. It was instantaneous and it made compiled languages feel like they were dynamic or interactive languages. That is, in retrospect, the right way to do it. That clearly was one of the factors. 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 typically sold for $500. We lowered the price by an order of magnitude down to $49.95. At that point, there is really no point in pirating it. For $49, it’s worth it just to get the manual that explains how it works. So all of those in combination 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, personally, 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 that 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 really a big push inside Microsoft to do Java, and even build applications in Java or maybe even build an entire OS in Java. It was like the time when Java was just taking the world by storm in the early Internet days. Microsoft didn’t have a Java development tool at all. The closest was the Visual C++ development environment and that was really not at all the right fit. So I was brought on to spearhead that. But it very quickly turned into a political battle between Microsoft and Sun, and the product that we had built, Visual J++ 6.0 ended up having a judge in San Jose enjoined requiring us to put a warning dialogs about Microsoft’s proprietary language extensions. So in a sense that all was the genesis for what came next which was .NET and C#, because Microsoft as a company realized that it’s not going to work for us, and for our customers, to build our future platform on top of something that we have licensed from some other partner. We knew from our customers that it was too hard to write code, at the time, in C++. Just not enough programmers could do it. We did have at the time 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 all of those, you take them together,and 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 no modules and there was no static type system. So it was very hard to write large apps in JavaScript. And 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, code navigation, or no notion of statically checking your program before you run it. Teams were actually choosing to write in a different language and cross compile to JavaScript, just treat JavaScript 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 be the best possible JavaScript development environment. What if, instead, we could fix some of these issues, let’s try to figure out what are the issues, what are the problems, why are the tools crappy and what can we do to make it better? And that was, in a sense, the genesis for TypeScript.

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 in 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, everyday. 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 do our work, and it’s a much better way to do it. It’s better for everybody, it’s better for the team too, because it is 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 such a big investment, they are in the same manner super passionate about these tools. So when you delight them there is so much enthusiasm. And ultimately the rewards you get from seeing people’s enthusiasm and using the tools that you’ve created, it’s just very fulfilling. At the end of the day, after 35+ years, it still makes it worthwhile for me to do it. People are so excited about that and I just love that.

Don’t take the dogma for given!

Don’t let people tell you that it 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 never know. We always sort of see, in retrospect, that you were thinking about it wrong or that there is this simpler way you could have gone about it. So always be curious and don’t take the dogma for 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

Anne-Laure Civeyrac

Tech Editor @ WTTJ

  • Partager sur Facebook
  • Partager sur Twitter
  • Partager sur Linkedin

Suivez-nous!

Chaque semaine dans votre boite mail, un condensé de conseils et de nouvelles entreprises qui recrutent.

Et sur nos réseaux sociaux :