Interview with C# Lead Language Designer - Mads Torgersen
Someone once said "Don't choose a language for its features, choose a language for its feature building capabilities".
C# is undoubtedly one of the most modern, well designed, flexible and powerful languages in the world. Developers have been incredibly psyched about the new features and the possibilities the language has to offer.
Amidst C#’s ever-growing popularity, the DotNetCurry team had the opportunity to interview Mads Torgersen, C#’s Lead Language Designer, and find out what’s happening in C#, and where does it go from here.
Mads needs no introduction to the C# folks out there, but for others, here's a short bio in his own words.
1. Tell us about yourself, and about your work at Microsoft. What does your typical day look like?
Thirteen years ago, I moved with my family to Redmond, Washington from Aarhus, Denmark to be a program manager for Microsoft. I was on Anders Hejlsberg’s C# language design team from the start, and gradually took over responsibility for running the meetings, writing the notes and maintaining the language specification. About half a decade ago, Anders moved to the TypeScript team, and I have taken over as the lead designer for C#.
My most important task is driving and communicating about the design of C#. Twice a week for two hours we have C# Language Design Meetings (LDMs), and that’s where all the design decisions ultimately get made. Then there’s prep and follow-up from those meetings, there’s meetings with colleagues, partners and managers to coordinate, and of course I do a fair number of talks and conferences as well.
Image Credits: Klaus Löffelmann
2. What are you really into outside of work?
Family! I think I may be a bit boring; I don’t have any crazy hobbies or sports. I like hiking, running, reading, cooking, movies, music… But I don’t identify as a Runner, or a Foodie, or a Movie Buff – they are just things I like to do.
3. What was your journey like to get where you are? How do you learn and approach change?
I fell in love with programming languages as soon as I realized how different they could be from each other. I started out in Basic like so many people, but discovered Forth (for the Commodore 64) by a fluke, and something went POP in my brain, causing irreversible damage!
Then for many years I thought my destiny was to be in research. I went the whole way through a PhD and some years of assistant and associate professorships before I realized the most fun I had was collaborating with industry on language design; specifically on generics for Java. Once I realized, there was a bit of serendipity and good timing, in that I almost immediately met Anders Hejlsberg at a conference where I was presenting Java generics and he was presenting C# generics. That was 13 years ago, and I’ve been on the C# team ever since.
4. For our readers getting started with C# programming, help us understand why did Microsoft create C#? How do you envision its future?
I wasn’t around at the time, so this is more as seen from the outside. C# grew out of the Java and web age, where object-oriented programming was finally coming into its own, and people were looking for new, more productive tools to match a more rapidly changing landscape. For various reasons Microsoft couldn’t just jump on the Java bandwagon, and that turned out to be fortuitous, as the paths of Java and C# have diverged quite a bit over the years.
C# has a target audience of professional developers, and aims to be a productive and expressive choice for your next project in many different domains, and even as the world rapidly evolves. This means keeping C# on a pretty ambitious pace of evolution. There’s a risk of the language growing too big (since we can never really take anything out), and we try our best to counter that by being very deliberate about how we do new features, so they fit well within the spirit and feel of the language. We think this is better than stagnation – “good enough” now won’t be in five or ten years.
5. Tell us more about your team and peers. How large is the team that works on the C# language/compiler?
The language design team is about 8-10 people at any given time. Other than me, they aren’t full time language designers though. Many of them are on the C#/VB compiler team, which is a team of another 8-10 people total. An additional 7-8 people work on the IDE, and then there’s the CLI, the BCL, the CLR… it all depends on how you count.
Nowadays the community also increasingly contributes. We’re open source, and even though a compiler is one of the hardest, gnarliest code bases to contribute to, folks have done it successfully, and we are taking in language features that were implemented by people entirely outside of Microsoft.
6. What does it take to become a developer on your team?
A lot, frankly. It’s very challenging work, and you have to be quite savvy technically, as well as being a good team player.
7. If you had an option to redesign the language from scratch, what would be the pillars for this new language design?
That depends on what you mean by “the language”! C# started out very object-oriented, and has been adopting functional features over time. Starting over, I would probably try to strike a balance between the two from the get-go. I would also feel less bound by C syntax than we were at the beginning.
8. What is the most annoying (or your personal least favorite) feature that exists in C# today? How and why did it get introduced in the language, and what do you plan to do about it?
There are a few! I am not fond of delegates, which are an odd blend of function and collection types. I would have preferred a more straightforward notion of function types. They were introduced primarily to support events, which I also don’t think should have been a first-class feature of the language. They correspond to a very stateful design pattern, that is often useful, but not that useful.
We don’t take things out of the language, so the two are there to stay. It’s possible that we’ll consider a more lightweight kind of function types at some point, but they’ll have to be worth it.
9. How is progress going with C# 8? Do you have a rough estimate when it might be released?
I don’t like to give even tentative dates! Progress is good, both on the design and implementation front. Ultimately, depending on when is a good time to ship, there may be a number of the features currently considered for C# 8.0 that won’t make the cut, but it’s too early to say which.
10. One potential feature for C# 8 was Type Classes or Shapes. How likely do you think this feature will make it in C# 8?
This is one that I think needs more bake time. It is unlikely to make C# 8.0. The general idea behind the proposals in this area are being able to abstract over static members (such as operators), and also be able to apply such abstractions after the fact, as opposed to today’s interfaces, which must be applied when a class or struct is declared.
There are many ways to skin that cat, and we are currently exploring several of them. One thing they all share is that they are a pretty fundamental extension of C#’s expressiveness in the type system, so they need to be very carefully woven in with the current semantics and underlying implementation. This will take time, but I’m hopeful that we can design something that is worth the wait!
11. In the language design process, do you consult or take inspiration from other language teams in Microsoft: F# and Visual Basic, and perhaps even TypeScript?
Absolutely! We have a big overlap between the C# and Visual Basic design teams, and are in continuous coordination. Similarly, for F# we influence each other: F# is our go-to functional language for inspiration to new functional-style features such as pattern matching, and also in turn adopts many of the new C# features.
TypeScript has been a big inspiration when it comes to the nullable reference types feature we’re building for C# 8.0. We have a long history of collaboration: Anders Hejlsberg and I both came from C# to help design the first version of TypeScript, and now that we drive each our own language we still meet once a week and compare notes.
12. What other programming languages influence the design of C# today and what features (not listed in the csharplang repo currently as a proposal) would you like to see implemented eventually?
Philosophically speaking, Scala is an inspiration, in that it set out to create a true unification of the functional and object-oriented paradigms. Though we differ a lot in the specifics, that’s a vision that helps inform the way we integrate new features from a more functional realm. We try very hard to design new features so that they mesh deeply with what’s already there, the spirit and feel of C#.
There’s a crop of newer languages out there that have a lightness and pragmatism to their syntax, even without necessarily adding a lot of new expressiveness. We are keen to reduce the amount of ceremony in C# as well, again while staying within the feel of the language.
13. Looking at GitHub issues for C#, the community is constantly submitting a rather large number of proposals. How do you review and evaluate them so that you don't get overwhelmed?
We have a championing model, where a feature proposal has to be championed by a language design team member in order to get discussed in the design meeting. This is a necessary filtering mechanism. We each spend time in the repo looking at proposals, but if an idea doesn’t catch the interest of on the language’s designers, then we don’t bring it to the meeting.
14. Additional expression-bodied members in C# 7.0 were the first community member contribution that made it into the language. What was the process like in getting the contribution accepted? Are there any other contributions already considered?
It was fun! We continue to take community features; we are currently looking at one for allowing objects to be new’ed up without explicitly giving the type, when it can be inferred from context.
15. Go vs Rust vs C# vs Java. Your thoughts?
Rust is certainly interesting. By tracking lifetime in the type system they are able to guarantee memory safety without garbage collection. There are certainly low-level/systems scenarios where that is going to be interesting. Whether the trade-off with a more restrictive type system is going to pan out for higher-level code remains to be seen.
Go speaks to some as a very simple language, but for the same reason it seems to me it runs out of steam a bit. They have interesting technology with the lightweight threads and the real-time garbage collection guarantees, but most of their popularity so far has come from their association with microservices. It’ll be interesting to see if they can take hold beyond that.
Java’s evolution has been hamstrung for a long time by its myriad of vendors and stakeholders. It’s impressive that it can still evolve at all, but it does, and it has some extremely competent people driving it. The big asset for Java beyond everything else is its enormous ubiquity; making it the default option in many scenarios.
C# and .NET have undergone a transition from closed around Windows to open and everywhere. Our relative nimbleness in language and platform evolution, and the new life it has blown into our ecosystem, are certainly a draw for many. There aren’t many corners we can’t reach from a technology standpoint. Will we? We’ll see.
A metapoint about the language landscape is that there is room for many languages to succeed. It is a very different market from two decades ago when Java was sucking all the air out of the room, and language innovation all but ground to a halt across the board. There are cross-cutting trends for nimbleness, pragmatism, and eagerness to evolve. It’s an exciting and encouraging stage for languages at this point.
16. In its evolution since version 1.0, C# gained a lot of new features. Those using it from the start had the benefit of learning the new features incrementally as they were being introduced. Do you think that because of all these new features, C# is a more difficult language for someone who is only starting to learn it now? Are you taking this criterion into consideration when choosing and implementing new features?
There’s no question that the C# of 15 years ago was easier to learn. There’s also no question that today’s C# is much more useful and productive in today’s landscape. We try very hard to integrate new language features in a way that is as consistent and smooth and simple as we possibly can. There is probably some complexity that comes from the language having evolved gradually over time, but there also just is more complexity facing developers today than there was twenty years ago. Languages need broader expressiveness to accommodate that, I think.
17. Most programming languages have a life expectancy, according to John Cook (PhD) C# will die in 2034. One common tipping point is where the language becomes too complex with too many features, could you imagine this happening with C# - if so are we approaching that tipping point?
I can certainly imagine that happening with C#, but I am not sure we are anywhere close. People have said that about C++ for ages, and yet it keeps doing just fine. Our complexity budget is considerably smaller, but I do not see signs of the community starting to fracture over complexity of the language.
We’ve long ago settled on a strategy here for C#. We’ll do what it takes to keep it relevant and modern in the face of the changing demands of the developer landscape. The alternative is falling behind and eventually becoming a legacy language, not a good choice for new projects. That’s not a path I see us taking anytime soon.
18. When it's all over, how do you want to be remembered?
As someone who added light and color to people’s lives.
Thank you Mads! It was such a pleasure interacting with you.
The interview questions were curated by Damir Arh, David Pine, Suprotim Agarwal and Yacoub Massad.