Editor's Note

Is C# the Only Language that Matters?

Is C# winning vs. VB.NET?

When Microsoft launched Visual Studio .NET, one of the main points it emphasized was that you could plug in any supported language you want to leverage the power of its new technology. Language should be a matter of choice, it said, and to that end, you had your choice of quite a few languages: a pair Microsoft wrote—C# and VB.NET—and a host of others created by third-party vendors, including .NET versions of Python, Eiffel, Fortran, Java/Jscript, COBOL, Pascal, Fortran, Scheme, Perl, and quite a few others.

The idea behind letting different languages plug into the .NET Framework was simple: Why learn a new language if you like the one you know, and it lets you get the job done? But the chinks in this approach appeared almost immediately.

First, the two Microsoft-authored languages were on a different plane than other languages. The corporate world trusted the languages from Microsoft more than others. This world is risk-averse, and these companies are not inclined to allow developers to use something they think might not be around two or three years from now.

Second, there is a significant difference in the perception of the two Microsoft-authored languages that dates back to the original .NET announcements. C# was new and exciting. Derived from C and developed by Anders Hejlsberg, C# seemed to have stolen the hearts of developers at Microsoft. New .NET code samples from Microsoft appeared first in C#, and some months later, after some prodding and pleading, in VB.NET. Sometimes. Microsoft heard these complaints, and you saw some adjustment in the amount of time it took something to be translated from C# to VB.NET. Significant code samples still appeared in C# first, but the time to translate it to VB.NET shortened over time.

Microsoft has made some progress on these points, but the damage was done. Developers saw this, and assumed that C# was first among equals, as these languages go. Developers also saw that C# developers earned more than VB.NET developers, even though the languages were nearly functionally equivalent. Even before the two languages shipped, you heard developers and pundits saying that C# was the only language that mattered.

Such pronouncements were premature. And still are.

Visual Basic .NET and C# were intended to fill different niches from the outset. Microsoft pitched C# as the managed language for developers who wanted higher speed and performance. VB.NET was the "productivity" language, picking up where VB6 left off, and letting you create solutions quickly and more easily. Unfortunately, these distinctions weren't really borne out in the initial implementations, which were functionally equivalent, with a couple exceptions. VB gained a lot from its incorporation into .NET. It became a viable tool for Web development, it inherited the .NET security model, and it let you create entire classes of applications that were previously not possible with VB6. It provided inheritance and other power-developer features that VB had always lacked.

That said, the effort in VB.NET 1.0 went into getting VB onto the .NET platform, and VB lost some of its character in the transition. When porting VB to the .NET platform, developers at Microsoft implemented several changes to make the programming experience in VB more consistent with the C# experience. Some features were lost, including deterministic finalization and edit-and-continue.

With Whidbey, you can see some separation in the languages. C# continues to mature in Whidbey, gaining generics and other performance and power features. VB.NET in Whidbey gets things a bit more on track with My.Classes, the return of edit-and-continue, and other productivity-related features, but the consensus among both readers and those who write for VSM is that it still comes up short from a productivity standpoint. The new changes just don't have the imagination and reach of earlier productivity enhancements introduced in VB. Edit-and-continue gets you back to where you were pre-.NET, and, while My.Classes are a significant new feature, you still can't go too far without having to fall back on knowledge of the underlying .NET Framework. That VB.NET in Whidbey comes up short is disappointing, but not surprising. It often takes Microsoft three versions to nail something.

I don't know how many more chances VB.NET gets from developers looking to build on what they had in VB6. My guess is one—the next version is make or break for this crowd. C# isn't the only .NET language that matters at this time, but it could be if the third time isn't the productivity and ease-of-use charm for VB.NET. Without such differentiation from C#—and whether VB.NET appeals to classic VB developers or not—there just isn't enough benefit to giving developers a C#-like language with VB-like syntax to justify maintaining both languages for .NET.

About the Author

Patrick Meader is editor in chief of Visual Studio Magazine.

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube