Language feature parity and the polyglot programmer

For the average .NET developer, language features in the other .NET language don’t matter 99% of the time.  Unless of course, you’re using a framework designed for features that don’t exist for the language you’re using.

Such is the plight for a Visual Basic.NET developer.

Major “ALT.NET” frameworks simply weren’t designed with VB.NET in mind.  This makes sense, as they are designed and used primarily in C#.  For example, Rhino Mocks makes extensive use of delegates and expressions as method parameters.  VB9 only supports single-line function lambdas, which are anonymous functions that return a value.  VB.NET makes a clear distinction between functions that return a value, with the Function keyword, and functions that don’t return a value, with the Sub keyword.

Basically, the Action family of delegates is severely limited in VB9.

This can make it especially difficult for OSS and other framework developers.  If you’re trying to build an OSS or any other framework for public consumption, do you include both major .NET languages, or target features just for one, usually C#?

I’m leaving out the question for earlier versions of languages, as VS 2008 allows you to target a framework on a project-by-project basis, so any question of “I’m only on C# 2.0” rather moot.

However, looking at the feature specs for VB10, all of these issues have simply disappeared.  With VB10 and C# 4.0, each language team is embracing “co-evolution” going forward, where a major feature added to one language will be added to the other.  In a nutshell, VB10 will include most of the common C# 3.0 features, including:

  • Auto-implemented properties
  • Single and multi-line anonymous Subs and Functions (i.e., any lambda under the sun)
  • Collection initializers

For framework developers, the introduction of VB10 and C# 4.0 mean that the differences between the languages no longer matter.  If you want to build a fluent interface with extension methods, method chaining and nested closures, you no longer need to worry about leaving VB developers behind.

The future polyglot

The polyglot programmer would no longer include the “VB vs. C#” distinction after the VS 2010 release.  Instead, we’ll see a clearer focus on broader language features, such as:

  • Static vs. dynamic
  • Functional vs. ???
  • Scripted vs. compiled

An average web developer today needs to know at least 4 different programming languages:

  • Server language (C# or VB.NET for average ASP.NET development)
  • HTML
  • CSS
  • JavaScript

JavaScript, widely used, is so completely different than C#, yet its syntax is similar, that many of the familiar operations you might like to use in JavaScript (such as the “new” operator), are strongly discouraged.  I see the future of development to shift strongly towards a polyglot world, where we’ll use specific languages in circumstances where each language shines, while some languages grow to incorporate more and more features from other worlds.

But what we won’t need to worry about is the difference between the two dominant languages in .NET.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Misc. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • > what we won’t need to worry about is the difference between the two dominant languages

    The only thing you have to go on to predict the future is yesterday’s weather. Yesterday’s weather says that we will continue to have this problem long into the future.

    Not until you sit down with the actual, final implementations of these two next gen editions of these languages could you responsibly be able to come to and promulgate any opinion of the problems that will be introduced.

    The one thing we know about Microsoft is that they screw up something new in an inconceivable and unpredictable way with every new release.

  • nightshade427

    I would rather see the languages deviate and have differentiating features and work on bringing different language communities into a more active role. Then have external 3rd party framework writers have to worry about if their framework will work on language X or Y.

    Every language will have its own idioms and even if the feature parity exists I doubt idiomatic parity will be there. Which means as a framework writer if I want my framework to work in all languages I will have to take the least common denominator as far as expressiveness goes in order to make all languages happy. I dont feel it is good to sacrifice this expressiveness just for the sake of language parity.

    So even with feature parity in place frameworks geared to be optimized for a specific language will be more natural in that language no matter what we do. So these arguments will continue on forever.

    I think this is the way it should be. If other languages like the framework then learn that language and broaden your horizens or write a similar framework with your language idioms in place.

  • I agree with @nightshade427 on this one. why would i want two different language options for the same syntax? VB and C# should be distinctive.

    noone would expect IronRuby to have the same features and functionality as C#. the programming models are so completely different – static vs. dynamic.

    just because C# and VB are both static languages, doesn’t mean they should be in feature parity. it just muddies the water of language choice.

    please, Microsoft. Do the world a favor and create languages that are meaningfully separated, not just syntactically language flavor separated.

  • @derick

    The only reason VB.NET exists is to bring existing VB6 applications over to .NET. VB and C# are a special case, where the language designers have tried to create distinct identities, but this came at a non-trivial cost.

    There are still features in one that aren’t in the other, but major features should be shared, as MS itself designs its APIs for both languages.

  • At the PDC, Anders specifically said that feature parity between VB.NET and C# is now the policy.

  • imperative… function vs. imperative!

    and since when was CSS or HTML a langauge? They are really just data formats.

  • Anonymous

    Well, I see the approaching of development to about-face acerb appear a polyglot world, area we’ll use specific languages in affairs area anniversary accent shines, while some languages abound to absorb added and added appearance from added worlds.

    toshiba coupon codes

  • Dony

    You can use most fluent interfaces from VB.NET, but -man- they really do look ugly compared to their C# counterparts. Especialy the use of lambda expressions for nearly anything creates an interface that’s accessable from VB.NET, but nothing more. Supporting another interface with lots of optional (named) parameters is much more VB.NET minded, but you won’t find it on any major project because C# cannot handle this interface so easily.

    Yes, you can use nearly every C# library from VB.NET, but that doesn’t mean it’s suited for VB.NET. And you can’t switch an entire company from VB.NET to C# just because of those o-so-beautiful fluent interfaces …