Lisa Feigenbaum on Asynchrony and Language Evolution

Last week I posted a Q&A I had with Mads Torgersen, principal program manager on the C# and Visual Basic Language team at Microsoft and author of an October feature in MSDN Magazine titled "Pause and Play with Await." The article is part of a package of three features on asynchrony appearing in this month's issue. I also followed up with Lisa Feigenbaum, program manager in the Visual Studio group, whom I interviewed for my Editor's Note column ("Thinkin' About Async") this month. Here is more of our back and forth on the issue of asynchrony and some of the challenges Microsoft faces when adding important new functionality to its languages and frameworks.

Michael Desmond: Over the past few years we’ve seen C# and VB take on aspects of functional and dynamic programming languages, and now we see support for asynchronous programming. It seems like we’ve come a long way from the days when C# and VB were static, strongly-typed imperative languages. How do the teams ensure that the core identity of each language isn’t undermined in the course of this evolution?

Lisa Feigenbaum: C# and Visual Basic are general purpose programming languages and support a wide range of developers. Each release, we look for ways we can innovate in the languages to better support programmers in the top challenges they face every day. As you’ve described, we’ve certainly looked at different types of programming languages, and incorporated some of the concepts that they do best into C# and Visual Basic. However whenever we add to the C# and Visual Basic languages, we always do so in a way that best fits the style of each language.

This is interesting to observe, when you compare how these features were added to both C# and Visual Basic. For example, dynamic language interop was added to Visual Basic by taking advantage of the late binding constructs that were already part of the language. Furthermore in C# we added a static type, called dynamic.

Speaking of functional programming, when adding lambdas to Visual Basic, we used the familiar keyword syntax with Sub/End Sub and Function/End Function. However for C#, which is less verbose, we used symbols to design the syntax with ‘=>’. These designs help each language preserve its original character and remain familiar to developers as it grows.

MD: In terms of potential value, async looks like an absolute no-brainer. From cloud scenarios to multi/manycore systems, the new functionality seems to address a broad range of scenarios. So my question is, why didn’t we see this earlier?

LF: Language design is a very conservative process, and we don’t add anything to the languages until we know it is just right. We have a very high compatibility bar, and anything we add lives on for many years. To appreciate how high the bar is, we’ve even cut features after they were designed and implemented, because we weren’t happy with how they performed in usability testing!

In the case of async, there were several ingredients involved. For example, the Visual Studio vNext async designs build upon the Task type that was added to the .NET Framework in .NET 4. Using that foundation, as well as additional Framework support that is being added in the next version, we were ultimately able to design a very elegant language syntax that we were happy with for async in Visual Studio vNext. The continued growth of trends like cloud and multi/manycore systems certainly contributed to our focus in this space.

MD: From a developer-relations standpoint, how does Microsoft go about ensuring that the community fully grasps (and ultimately accepts) the new features? And in this particular case, is the challenge mitigated by the streamlined nature of the features?

LF: Driving awareness and training about new language features is certainly an important challenge that we undertake in our community efforts. Different developers learn differently, so we make sure to deliver content in a variety of formats, including samples, presentations, hands on labs, forums, reference documentation, screencast videos, interview videos, walkthroughs and more.

This goal also influences the way we design the product, in that we design the features in a way that can be most easily picked up, and that feels natural and intuitive to the user. For example, the async language feature uses a very simple design, which allows you to essentially decorate your synchronous code with async modifiers and a few targeted changes to make it run asynchronously, rather than completely re-writing your code. This allows for greater up-take of the new feature and was a core principle in its design.