In-Depth

Visual Basic and C# at the Crossroads

How the Microsoft co-evolution strategy has shaped the two flagship languages of the .NET Framework, and what it means for developers going forward.

• By Michael Desmond
• 05/01/2011

When Microsoft released Visual Studio 2010 and the Microsoft .NET Framework 4 in April 2010, it marked the largest update to the Microsoft flagship IDE and coding framework since the .NET Framework 1.0 was launched in 2002. The 2010 releases also ushered in a critical change in strategy for Microsoft's premier programming languages, C# and Visual Basic .NET. For the first time since Microsoft retired the unmanaged Visual Basic programming language with Visual Basic 6, Microsoft was fundamentally changing the direction of its language development.

That change came in the form of the Microsoft co-evolution strategy, first articulated at the Microsoft Professional Developers Conference 2008 (PDC08), under which the company committed to enabling broad feature parity between C# and Visual Basic. As Scott Wiltamuth, Microsoft product unit manager for Visual Studio Languages, wrote in a blog post less than a month ahead of the Visual Studio 2010 launch last year, Microsoft had pursued an "explicit strategy of differentiating VB and C#." At the time, Wiltamuth wrote, Microsoft wanted Visual Basic .NET to appeal to Visual Basic 6 developers focused on business- and data-centric applications, while C# targeted Java and C++ developers programming in the enterprise and for ISVs.

There was just one problem: The strategy failed to reflect the reality for programmers working with code.

'Community Driven'
"The initial differentiation was ... based on the idea of object developers versus application developers. The problem is that, from the ground up, everything you do in .NET is an object," says VSM Tools Editor Peter Vogel, adding that the distinction Microsoft made between the languages became "a difference that made no difference."

Rockford Lhotka, chief technology evangelist for consultancy Magenic, says the language teams at Microsoft began moving toward co-evolution long before the strategy even had a name.

"I think a lot of this is community driven, more than people realize," Lhotka says, noting that the Visual Basic and C# communities each worked to gain powerful features found in the other language. Features like the My namespace started as attempts to diversify Visual Basic with unique features, yet ended up available in both languages. There were plenty of others examples, says Lhotka.

"Edit and Continue were by far the most requested features for VB by the VB community," Lhotka recalls of the features widely used in Visual Basic 6 but omitted from the first version of Visual Basic .NET. "When they started talking about Edit and Continue coming back to VB -- this was 2003, I think -- almost immediately Edit and Continue features jumped to the top of the C# wish list."

Even though Edit and Continue is an "example of an effort for divergence that failed," according to Lhotka, he agrees with the decisions made by the .NET Framework team. "These features are wonderful and why shouldn't everybody have them," he says.

Diversity and Identity
Even as Visual Basic and C# grow more alike, they're diversifying from their core as strongly and statically typed programming languages. The .NET Framework 4 introduced the Dynamic Language Runtime (DLR) and the dynamic keyword to C# 4 and Visual Basic 10, enabling characteristics found in languages like PHP, Ruby and Python. The two languages also took on elements of functional programming even earlier, with the addition of LINQ in the .NET Framework 3.5. These capabilities were extended further in the .NET Framework 4 with parallel programming resources like the Task Parallel Library (TPL) and Parallel LINQ (PLINQ).

Most recently, Microsoft has shifted focus to asynchronous programming. Microsoft Technical Fellow Anders Hejlsberg at the PDC10 event in Redmond last year singled out asynchrony as the primary theme for the next versions of C# and Visual Basic. Developers already are working with a community technology preview (CTP) of the technology, the Async CTP, and new asynch and await keywords, which vastly simplify asynchronous operations where threads must wait for remote inputs from Web and distributed cloud-based systems.

Hejlsberg, during his presentation on C# and Visual Basic at PDC10, singled out the asynchrony feature push as an example of shared language development.

"In fact, this project to build the asynchronous programming support has been a joint project between C# and VB, very much in the new spirit of co-evolution that we started in the previous release," Hejlsberg said. "It's been joint program management, joint development, a single team implementing it in both compilers. It's been great."

Rob Sanfilippo, an analyst for research firm Directions on Microsoft, is impressed with the early results. "I think the reception of the Visual Studio Async CTP has been very positive," he notes. "It will save developers a lot of tedious 'how to' code that the compiler can construct by leveraging the TPL."

Further down the road is Hejlsberg's C# "compiler as a service" effort (code-named "Roslyn"), which he has described at Microsoft PDC conferences and other venues. The years-long overhaul will recast the compiler in managed C# code and provide unprecedented transparency and customization to .NET developers. Hejlsberg has described benefits like instant compiler feedback, eliminating the need for time-consuming build and compile steps before gauging code behavior, and the ability to copy C# code to the clipboard and then paste it as Visual Basic code.

"Perhaps a tool like that can make it easier for teams to provide samples in both languages," says Sanfilippo. "Furthermore, that tool puts the C# versus VB argument into perspective -- just a different dialect to do the same work."

Doug Seven, senior product manager for Visual Studio Team System at Microsoft, says compiler as a service is planned for "both Visual C# and Visual Basic." However, he offers no timeline for the new functionality, noting only that Microsoft will "share more about Roslyn at future developer events."

Lhotka, for one, is impressed with what Microsoft is working on. "Compiler as a service conceptually gives Microsoft itself some really amazing capabilities," he says. "You look at things like FXCop that are doing static analysis on a code base. Wouldn't it be cool if you had a tool that literally did partial compilation of a code base, and then analyzed the result?"

Lhotka doesn't expect developers to "rush out and start customizing the compiler," but he does foresee efforts like customized versions of C# for medical or other vertical industries. Compiler as a service would enable the creation of powerful domain specific languages (DSLs) built on the robust underpinnings of C# and Visual Basic. Think DSLs on steroids.

Ilya Ryzhenkov, .NET tools product manager for tools provider JetBrains Inc., is skeptical. "Compiler as a service is a technology that will allow simple things to be done easily, but complex things will be extremely hard or near impossible," he says. "No doubt with this release we'll see a lot of simple one-two-feature extensions popping up, much the same way we saw with Visual Studio 2010 Extensions. However, this usually leads to compatibility hell, an increase in the number of crashes, slow performance of the IDE and bugs."

Lhotka doesn't argue the risks, especially with DSLs. "There are a lot of big examples of people who created their own world," Lhotka says, "most of whom failed horribly, because they're a small company that created a compiler. And a decade later they're a market of one." But, he adds, "That's not a Microsoft issue."

Unfinished Business
Microsoft has acknowledged that the effort to achieve feature parity between C# and Visual Basic will take years. Features like XML Literals in Visual Basic and unsafe code support in C# are not yet supported across both languages. Ryzhenkov says true feature parity will be hard to achieve.

"It really depends on how far this co-evolution [strategy] is going to go," he says. "VB has a lot of features that C# has never seen, such as automatic event subscription with Handles. Will this remain a unique feature to VB or will it at some point be added to C#? What about Strict On/Off and other compiler modes in VB? How about the My namespace and its generated content? Just LINQ in itself has more features in VB than it does in C#. Will we ever see them in C#?" Ryzhenkov asks.

VSM's Peter Vogel singles out LINQ as an example of a shared feature providing uneven levels of support across the two languages. "When Microsoft wanted to add LINQ to the language, they added a new library of objects/methods in the System.LINQ namespace. C# included extension methods and, as VB did not, the syntax changes for LINQ looked significantly different in the two languages," says Vogel.

He notes that this code is fine in Visual Basic:

Dim r = From y In x
               Select y
               Where y.Length > 2
               Order By y.Length

However, in C#, the select clause is required to come last:

var r = from y in x
               where y.Length > 2
               orderby y.Length
               select y;

"Will this go away?" Vogel asks. "Probably not -- it's just not a high priority."

Private Sub Button1_Click(ByVal sender As System.Object, _
  ByVal e As System.EventArgs) Handles Button1.Click
  'do something
End Sub

Dim Condition As Integer = 55
Select Case Condition
  Case 1, 3 To 5, 10, 12, 14, Is > 50
    'value 55 executes code here
  Case Else
    'values <1, 2, 6-9, 11, 13, 15-49
End Select

Dim contact As XDocument =
  <?xml version="1.0"?>
  <contact>
    <name>Joe Kunk</name>
    <column>On VB</column>
    <email type="work">joekunk@ajboggs.com</email>
  </contact>

If Condition = 12 Then
End If

Trendlines
How has the evolution of Visual Basic and C# impacted uptake of the languages? "The most reliable numbers we have on the two languages show roughly equal adoption and, together, these two languages represent the vast majority of .NET Framework usage," says Microsoft's Seven.

Surveys by developer research firm Evans Data Corp. indicate that usage of C# and Visual Basic was, in fact, closely balanced from 2006 through 2008, when 35.1 percent of respondents reported using Visual Basic and 36.2 percent reported using C#. Since then, according to Evans Data, C# has gained ground. In 2010, 46.8 percent of developers reported using C#, while 37.4 percent reported using Visual Basic. In 2011, according to Evans Data projections, C# usage will increase to 47.7 percent while Visual Basic will fall to 35.2 percent. The survey also notes that Visual Basic developers are paid 10 percent to 15 percent less than their C# counterparts, and cites that as a factor in the decline of Visual Basic adoption.

Evans Data CEO Janel Garvin says increased competition from scripting languages and other sources has cut into Visual Basic market share as well.

"VB was designed to be an easily accessible language, and appealed to the more 'lightweight' developer and had no effective competition in that market," Garvin says. "However, now there's a plethora of easily accessible languages from PHP to Ruby, and even the use of content-management systems may have the ability to erode VB usage."

Garvin notes that C# is approaching 50 percent total usership, which she says could be a peak for the language. "We've seen several cycles with other languages, like Java and C++, for example, where the language reaches just above that level but can't sustain growth after that."

A Web survey last month of more than 1,200 Visual Studio Magazine readers seems to mirror the results from Evans Data. In the April survey, 44.1 percent of respondents reported doing somewhat less or much less work in Visual Basic now, compared to five years ago, versus 20.3 percent who reported doing somewhat or much more work in Visual Basic over that span (see Figure 1). The same survey also indicates that a slightly larger portion of surveyed developers (31.9 percent) work predominantly in C# compared to Visual Basic (27.4 percent), as shown in Figure 2.

[Click on image for larger view.]

Figure 1. Of our VSM reader survey respondents, 44 percent report using Visual Basic less now than they did five years ago. Only 20 percent say they're using Visual Basic more now than before.

'First Among Equals'
One issue that may impact Visual Basic adoption among .NET developers is the level of support Microsoft provides to Visual Basic relative to C#. Leslie Koohan, a .NET trainer in Kansas City who teaches both languages, says Microsoft "treats C# as first among equals" and notes that books on .NET development almost always publish code samples in C# rather than in Visual Basic.

[Click on image for larger view.]

Figure 2. The VSM reader survey indicates that developers may be more likely to work predominantly in C# than in Visual Basic.

Jeffrey Hammond, principal analyst at Forrester Research Inc., concurs. "VB still seems to be the lower priority when it comes to guidance and code samples. It's rare to see documentation that provides a VB example but not a C# example; the opposite is much more likely," he says, adding that Microsoft enabled C# development for Windows Phone 7 "months before it was supported on VB."

William Vaughn is founder of consultancy Beta V Corp. and a former Microsoft product manager and developer liaison who was on the Visual Basic 6 team when it launched. He says he's been a "VB fan since before VB" and that he wrote "deadly serious code in MBASIC-80 in the CP/M days." Vaughn describes Visual Basic .NET as a first-class language that nonetheless suffers from institutional neglect.

public static IEnumerable<int> AllTheOdds(int low, int high)
{
  for (var n = low; n <= high; n++)
  {
    if( n % 2 != 0)
    {
      yield return n;
    }
  }
}

"We've talked to the VB team about this for some time. They really want to make VB a first-class language, but their toughest customer is Microsoft on the internal side," Vaughn explains. "All their internal managed code is pretty much in C# or C++. In practical reality that's not going to change. It wouldn't be practical for Microsoft to go in and say half of their code is going to have to be written in VB."

Stay or Switch
Vaughn says there's no need for organizations to consider a switch from Visual Basic to C# or any other language, as Visual Basic offers functionality that's largely equivalent with C#. "Do I think you can do anything in VB you can do in C#? I think the answer is 99 percent yes," Vaughn says. "The problem is you have to think about the problem in a different way in VB than you do in C#."

Still, he worries that dev shops may abandon their Visual Basic code base as a result of perceived slights. "The question is, how many people are going to make irrational decisions based on what they think is going to happen to VB? And people are making those decisions, and they're spending money needlessly to make the switch."

Forrester's Hammond says he fields questions from customers every quarter about the choice between Visual Basic and C#. "Most seem to be looking toward doing more in C# and less in VB.NET, if only because of the close syntactical similarity to Java and a perception that Microsoft itself favors C#," he says.

Magenic's Lhotka, who for years maintained the popular CSLA application development framework on both C# and Visual Basic, sees no functional issue that would mandate a move away from Visual Basic in favor of C#.

"I spent five years maintaining a very large and complicated code base in both languages and I feel very comfortable saying there was really no difference between the two," says Lhotka. "There are partisans out there on both sides, and I tend to irritate people when I say this: If you're trying to put down VB based on its feature set, you are just naïve."

For developers like Lhotka, Visual Basic and C# have traveled a winding road that will no doubt continue to show sharp curves. Looking ahead, Lhotka sees a need for programming languages to support three emerging scenarios: Mobile devices and tablets, multi- and many-core systems, and the emergence of distributed computing. Mobile scenarios, for instance, demand compilers that can optimize for less memory and CPU power while leveraging existing code assets. Distributed computing, Lhotka says, will place a premium on immutable messages and memory constructs, as well as synchronization.

"It's one of those things where many of us wish [Microsoft] would move faster," he says, "and a lot of us are grateful they are taking their time. And being careful."