The Father of C# on the Past, Present and Future of Programming
|
Anders Hejlsberg is one of Microsoft's handful of distinguished engineers. He is known for having developed the Borland Turbo Pascal compiler and for having been chief architect of Borland's Delphi technology. Hejlsberg left Borland, where he last served as chief engineer, to join Microsoft in 1996. Since joining Microsoft, Hejlsberg's greatest claim to fame has been fathering the C# programming language. Originally code-named "Cool," C# was designed to be Microsoft's Java killer. Hejlsberg chatted in June with Microsoft Watch Editor Mary Jo Foley and eWEEK.com Senior Editor Darryl K. Taft at the recent Microsoft Tech Ed conference in Orlando about the past, present and future of the C# programming language – among other programming-language-related topics.
For tools, it's that the cockpit you sit in gets more and more capabilities. My particular interest for the past couple of years has been to really think deeply about the big impedance mismatch we have between programming languages, C# in particular, and the database world, like SQL — or, for that matter, the XML world, like XQuery and those languages that exist there.
If we just take languages like C# and SQL, whenever I talk to the C# programming crowd — and I tried it in my session (at Tech Ed) — I ask them, "How many of you access a database in your applications"? They laugh and look at me funny, and then they all raise their hands.
So from that I take away that when you're learning to program in C#, you're actually not just learning to program in C#. You're also learning SQL. And you're also learning all the APIs (application programming interfaces) that go along with bridging that gap. And you're learning a whole style of writing a distributed application. But interestingly, we've come to accept that that's just how it is. But it doesn't necessarily have to be that way. The two worlds are actually surprisingly un-integrated.
On the tools side, we're making tremendous progress on getting deeper integration between these two worlds. But I think on the language side, we also could make an enormous amount of progress.
So, there's so much stuff that we could do there to make these worlds better integrated. And that's what we've been thinking about deeply over the past couple of years. And I think you see some of the fruits of that thinking in the "Whidbey" release. Specifically, a feature like generics (which will be part of Whidbey, or Visual Studio 2005) is not only a great tool for programmers because it allows you to parameterize your types and have much more code sharing, and get better compile-time type safety and all of these things that are goodness. But it also strengthens the type system, or makes it more expressive. Next Page: Is There a Successor to C# in the Works?
We're doing a lot of work to make .Net an even better platform for dynamic languages.
I think interestingly that there's sort of a resurgence of interest in dynamic languages. When I look at it, I sort of see two different things there. And sometimes I think people confuse some of the advantages of dynamic languages. For example, some people say I love writing in Python, my favorite dynamic language, because my code is much terser and it's much easier to write, and so it goes much quicker. And sometimes people say, I think it's OK to pay the price of no type checking to get that terser code. Then I say, is it really necessary to have such strong typing in the name of tersity? I don't think it is, necessarily. I actually think that an even better world is a world where (a language) is terse, but it is still strongly typed. And I think it is quite possible to do that. Some of it, in its infancy, is in some of the type inferencing capabilities we have in C# 2.0, where, effectively, we infer the type of the variable from the way you use it. And there's much more we can do there.
I don't think there's any need to create another language at this point. Once you create another language, In the name of solving one problem, you buy yourself nine other problems. I think we can very naturally extend the languages that we have so that you can do it.
In regards to Visual Studio, do you see all the languages that are supported now evolving in parity? Will you continue to do to Visual Basic everything you do to C#? I think it is practically impossible for us to evolve in lockstep. Innovations will happen in one space and they will turn out to be great for users over here, and we'll adopt in another. But we will certainly always share all the information we can and attempt to have as much parity as we can. But I don't think it is either meaningful or possible to guarantee complete parity, just in the name of parity.
I do think there are some differences in the profiles of VB (Visual Basic) programmers and the kinds of characteristics they're interested in, and C# programmers, who are probably a little bit more interested in the bleeding edge of language technologies.
I was told — and I could be wrong — that the next version of C# (3.0) borrows a lot from FoxPro…. No. I wouldn't say that it specifically borrows from FoxPro. As I have said before, the area where we're already laying some groundwork for in Whidbey (Visual Studio 2005) is this big and largely unexplored area of deeper language and data integration. And, of course, FoxPro is a language that has been there, but also, like dBase and all of those languages, called 4GL languages — though I don't really know what that "4" meant — I think they show how closeness to data is tremendously useful for a certain class of applications.
But unfortunately, I also think that those languages, for whatever reasons, never got accepted as mainstream programming languages, largely. They lacked some capabilities that programmers, generally speaking, want.
What I'm trying to do is I'm trying to do the data thing without throwing the baby out with the bath water. And I'm being very conscious about that. Whatever we do to C# has to feel completely natural to C# programmers.
FoxPro comes at it from a different angle. They have their own run-time infrastructure and they are not hosted on .Net the same way as the other languages are. So that's the ball they have to chase. C# is already on what we think is the right run-time infrastructure but is lacking the capabilities of deeper data integration. So that's where we're looking.
The teams are actually right next to each other. I know all the folks on the FoxPro team. So we talk a lot. And they have a lot of experience in this space. I think our approach in C#, though, is going to be a little bit different. FoxPro is very tightly married to your data being data in a database. When I talk about data in this conversation, I mean data at large. It doesn't necessarily have to come from a database. It may as well come from an XML document or just be something that you moved off a bunch of objects and now you want to do set and query operations on these graphs of objects. So in that sense, we're sort of coming at it in different ways.
Next Page: How Does Hejlsberg Approach Programming?
I think you pick a big goal. Let's just say for the sake of argument that I want to make it as easy to program data in C# as it is in FoxPro. Or pick whatever goal you'd like. I'm not saying that is a particular goal. And then you start learning. You do your first approximation of the problem. And then you learn a bunch from it.
You start out by building what you think is the solution. And then from the solution you learn how there's really a more general solution to the problem…that the solution you built is just a specific instance of the more general solution. Then, effectively, you push yourself a meta-level. And that's typically how language extensions are like that. I'd be completely adverse, for example, to a language extension that tied us —(one) that said, we're going to do data integration and it's going to be SQL with SQL Servers and that's what we're going to jam into the middle. Well, that would be the kiss of death for C#. Because then, it's no longer a general-purpose programming language.
I've been interested in some of the various Microsoft Research projects around the various "Sharps," like X#, F#, Spec#. Are things that Microsoft is learning in those projects going to change what you're doing? How? Oh, absolutely. Let's take generics. I think that's a wonderful example. Generics started out as a research project done by Don Syme and Andrew Kennedy at Microsoft Research in Cambridge (UK). These two researchers effectively took the C# language and the .Net platform and added parameterization of types on top of it. They modified it. They wrote two papers about it and gained some experience with it. Their work was very credible and very applicable, since they were working with the same bits. So, all of that work worked gradually into the production (Visual Studio 2005) code. They ended up helping out and working on the production implementations of this stuff. I think the prototype (of their work) was called Gyro when it was built. This was built on the Rotor code base. It was, to me, a wonderful example of technology transfer from research into a product. I think Don and Andrew are great researchers and very pragmatic engineers. That's a great combination. I wish there were more like that.
Don is now working on this thing called F#, which is taking a deeper look at functional programming languages on the .Net platform. And certainly a lot of the stuff we're doing with C#, going forward, will learn from — and is already learning from — functional programming languages.
It's sort of interesting. In many ways, I see my job as making sure you keep up on what's happening in research and academia and bridging to real-world technologies. Because when you look at functional programming languages, like Haskell or ML or whatever, it's like, 'Oh my'! To a lot of researchers, syntax is just a necessary incarnation of semantics. Really, what they're interested in is semantics. And who cares what notation. You can make another one tomorrow, right? Well, unfortunately among programmers, syntax matters. You can see that in the religious wars over whether it should be VB (Visual Basic) or C# — which, effectively, comes down to what syntax do you prefer? Next Page: Hejlsberg: What's Hot Now?
What are the general programming language concepts and trends that interest you right now, in the grander scheme? Generally speaking, it's interesting to think about more declarative styles of programming vs. imperative styles. A lot of the stuff I've talked about are actually specific instances of that. Functional programming languages and queries are actually a more declarative style of programming. You sort of declare what you want to have done, but not exactly how you want to have it done. And in many ways, we've educated generations of programmers to think not just about what, but about how, and to explicitly state how in their programs.
In many ways, programmers have to gradually unlearn that and learn to trust that when they're just stating the "what," the machine is smart enough to do the "how" the way they want it done, or the most efficient way. (This is an edited version of a three-part interview, which kicked off in the June 20, 2005, issue of the Microsoft Watch newsletter. Want to see what other Microsoft news nuggets you might have missed? Sign up today for a free two-week trial subscription to Microsoft Watch.) |
Comments (4)
Come down from your pedestal, Anders. Your comments remind me of the attitude I've so often encountered in academia: "real" programmers write operating systems, languages or compilers, not lowly applications.
That "certain class of applications" for which "closeness to data is tremendously useful" comprise the vast majority of applications, as you discovered during your Tech Ed session. I'll never understand why Microsoft has taken so long to acknowledge that most programmers want and need the excellent data-manipulation features found in FoxPro. By the way, I frequently use these features for "data at large", not just data in a database.
Posted by Jim Wiggins | July 19, 2005 12:23 PM
Will be interesting to see how they make a database out of an XML file.
rofl
It´s a pity that so little people get to know the strengths of VFP and are just subject to trend and hype!
G
Posted by Guenter Huber | August 8, 2005 6:34 PM
@Jim Wiggins:
your refer "programmers" as a bunch of people just creating compilers and operating systems? well, generally speaking, "programmer" is a very general word, or lets say, a common noun with so many references.
take a look at an english dictionary, "programmers" are not just people creating operating systems, or some kind of computer magics but "programmer" may refer to someone creating programs for weddings, meetings, conferences, etc. (get the idea).
now, programmerwise, what do you call people who encode some source code straight-from the brain? arent they called programmers? remember that programming is a part of the process to develop automation softwares or some kind of enterprise solutions.
operating system programmers are not just the "real-programmers" but those who develop software solutions as well.
Posted by online mascot | March 24, 2007 4:20 AM
@Jim Wiggins:
your refer "programmers" as a bunch of people just creating compilers and operating systems? well, generally speaking, "programmer" is a very general word, or lets say, a common noun with so many references.
take a look at an english dictionary, "programmers" are not just people creating operating systems, or some kind of computer magics but "programmer" may refer to someone creating programs for weddings, meetings, conferences, etc. (get the idea).
now, programmerwise, what do you call people who encode some source code straight-from the brain? arent they called programmers? remember that programming is a part of the process to develop automation softwares or some kind of enterprise solutions.
operating system programmers are not just the "real-programmers" but those who develop software solutions as well.
Posted by online mascot | March 24, 2007 4:22 AM