Coding Lessons from Youth
Hejlsberg shares his views on Borland, managed code and what's next.
Anders Hejlsberg rose to prominence in the mid-1980s as the creator of the Turbo Pascal programming language and integrated development environment (IDE). He later spearheaded the creation of Delphi before jumping to Microsoft, where he led creation of Windows Foundation Classes (WFC), C# and most recently Language Integrated Query (LINQ). We spoke with Anders about his experiences and what he sees in the future.
When did you first realize you were headed toward a career in programming?
Probably in high school. I was born and grew up just north of Copenhagen, [Denmark] and went to high school there, and they were one of the first high schools to offer students access to, well, what were then minicomputers. This was before PCs and micros and everything. That's probably where I first ended up getting fascinated by them.
Can you talk a little bit about the development of Pascal?
At the time we had a little store in Copenhagen that sold kit computers, so you could buy your z80-based kit computers. And I ended up writing a bunch of software for that -- you know, disassemblers and whatever -- and ended up finally writing a little subset of the Pascal implementation. It was really sort of the early, early precursor of Turbo Pascal. It was only 12K, it had a compiler, a runtime library and an onscreen editor, and you could yank out the Microsoft ROM Basic that came with the kit computer and then stick in our Pascal system instead and boot up and write code right there.
That grew into an implementation for CPM-80 and CPM-86, and then I got involved with the Borland guys. And that's when that became Turbo Pascal. Of course Turbo Pascal ended up being a much bigger success than anybody had expected.
At that time development tools were sold at $500 to $1000 per clip. When Philippe [Kahn, then-CEO of Borland Software Corp.] suggested we sell this at 50 bucks, I thought he was nuts. But in retrospect he was obviously right on the money. The notion you could get software that was 10 times better at a tenth the price was just explosive.
Can you describe your initial meeting with Philippe Kahn? How did you come to meet him and what was your working relationship like?
I met Philippe for the first time I think in early '84. Philippe is such an interesting character. He's incredibly inspirational. But whatever you want to talk about you've got to get to it within the first sentence, because you have no idea where the conversation is going to go from there. But [he was] an incredible company builder. It's amazing: The guy could sell ice cubes on the North Pole -- in bulk. It was a fun time.
Your transition to Microsoft has been well documented. But did your experience at Borland prepare you for life at Microsoft, or was it something that was completely new?
You know, both. The interesting thing is that technically -- going from Borland to Microsoft from a technical level -- it was almost like a non-event. Borland's tools, at least at the time, were fully on par with anything that the industry had to offer, including Microsoft. But from a management perspective it was night and day. Microsoft is a well-run company, it has professional development and professional management. Borland had lots of professional development but always had a challenge on the management side.
||"We’ve gone from machine code to assembler to C to C++, and now we’re using managed environments like C# and Java. And at each step we move up the abstraction level."
Anders Hejlsberg, Technical Fellow,
Developer Division, Microsoft
You've overseen some truly critical projects at Microsoft. Can you talk a bit about your management style?
I always try to value simplicity. That has always been a guiding principal of mine -- that all good ideas are, at the core of it, simple.
A lot of projects are fairly well-managed in terms of how you check in your source code and when you do builds of the source and how you release it and so forth. But the design process is not particularly well-controlled.
With C# we have set up a design group, and this design group has continued to meet every Monday, Wednesday and Friday from one to three o'clock in the same room, for eight years now. Now of course different players have come in and out, but some have been there from the very beginning.
Where are development tools and programming in general going next?
We've gone from machine code to assembler to C to C++, and now we're using managed environments like C# and Java. And at each step we move up the abstraction level. We put more and more intelligence in the infrastructure, the programming languages assume more and more of the responsibility for the menial tasks like garbage collection. We have more and more guarantees about type safety and so forth, be that dynamic or static. I think that trend will continue.
There's definitely a move to more declarative styles of programming, and I think you can see LINQ as an example of that. In order to harness modern computing architectures and make programmers more productive, we need to move to a style of programming where programmers say more of the "what" and less of the "how" in their programming.
How does this relate to parallelism and multi-core systems?
There was once a hope you could just type "/parallel" in your compiler and it could take advantage of multiple processors. Well no, unfortunately that's not panning out. You need to write your program in a different way that's more amenable to execution by smarter infrastructure. And declarative programming [and] functional programming are probably the best candidates today for really taking advantage of all of that multi-core power we are getting.
How quickly will programmers be able to adapt to that change?
It's more a question of how quickly will we be able to put in place the right paradigms that they can then start adopting. We have to come up with programming models that allow programmers to express the intent -- or the "what," if you will -- and then we can hopefully put most of the concurrency and parallelism in the infrastructure or in the programming models that people can reason about.
That's why I think things like software transactional memory are getting so much research time right now. Because, finally, that might give us a better way of doing synchronization. That's why functional programming languages are all of a sudden very interesting to people.
It's kind of like the same anxiety we had when object-oriented programming happened. And now we look back and, hey, it's just another tool in the toolbox, right? I think the same will be true.
In this business, you're always working on the shoulders of giants; you're always building on the frameworks of those that came before. Can you talk about that?
There's always a temptation to [think], oh, let's just go in and build a whole new one. You're always forgetting about all the menial stuff because you get so excited about the core idea.
But really the way that you totally succeed with these things is you find ways to put them on top of the existing assets. You find ways to make the assets do more. If I can broaden the appeal of C#, without actually invalidating a single line of code that people already wrote, well, boom! That's like immediate payback right there.
What does the industry look like in ten years, or even further out, say in 2020?
Let me put it this way; if history is any guide, it's actually not going to be as dramatic as we all think. For all of the advances we see in hardware and whatever, it still is amazing how software kind of moves at a fairly slow pace. It's gotten amazingly better, and I continue to believe it'll get much more productive. The tools do fantastic things. But I don't think fundamentally that the concept of programming will dramatically change. You're seeing trends here, more declarative styles of programming, more meta programming; tools where you talk in higher level concepts using domain specific programming languages. But I also think that the more successful solutions there will always have a level of more traditional programming below them.
This seems to circle back to the issue of abstraction.
The thing that has plagued a lot of the domain specific language tools that we see in the industry today, and code generators and what have you, is that they have no escape hatch that allows you to get in and then write the lines of code when you need to. It's like an all or nothing. Either you can paint that picture or you can't paint that picture.
To me, it's all about making sure that we don't move that abstraction level up as a slider, but rather that we add levels of abstraction. Too often, we add a level and then we take a level away at the bottom.
If you could go back to the early stages of .NET, would you change anything?
There are always things you'd like to change, but I think by and large I'm pretty happy with where we are. I think .NET is standing the test of time fairly well.
Any advice for dev managers tracking nascent or promising technologies? How do you manage your bets?
I've always felt that you shouldn't do technology for technology's sake. I too often see projects being done simply because [someone says], 'well, we've got to rewrite it.' Because that's what programmers like to do -- they like to rewrite stuff. That's actually the best kind of programming, because you get to learn from all your past mistakes and get it right. But what you don't realize is that by the time you're done, you actually have made a bunch of new mistakes. You sort of have to look for meaningful inflection points and then at that point be aggressive in your technology adoption.
So, what do you do in your free time?
Have any of your kids started to write any code yet?
I like to play squash and play golf, but I don't get to much. We have three little kids from age six and under. And I tell you, life is pretty darn busy in between that and work. Of course I'm having a ball with it, but that keeps me really busy.
My oldest is definitely starting to be quite interested in computers. But he's more interested in finding Bob the Builder's Web site than writing lines of code. But that'll come, and we'll get him started on some Lego Mindstorms or whatever. But hey, I'm getting to be a kid again, through my own kids.
About the Author
Michael Desmond is an editor and writer for 1105 Media's Enterprise Computing Group.