Thoughts on C# 4.0

It looks like VB.NET.

Dynamic late-bound typing.

Optional parameters.

Am I missing something?  Or does this just look like what VB.NET had since .NET 1.0? Option Strict Off – that’s a trick we’ve had for a long time.  It doesn’t help when a lot of the scenarios demonstrated are of Office COM integration – that’s what VB.NET was good at.

Named parameters are nice, but optional parameters are things we avoided like the plague, simply because versioning killed them.  Optional parameter default values were bound to the version they were compiled against, not what they were run against.  This led to really strange behavior if you ever changed the default values, similar to using consts versus static fields.  Honestly, the big reason I went away from VB.NET so many years ago besides its verbosity and its crazy line continuator baloney was the lack of ReSharper support at the time.

Personally, I’m still waiting for a true hash implementation a la Ruby, first class regular expressions, and a real Void type that could put to sleep the strange separation between the Action and Func delegate types.

A good step, but not nearly as big as C# 3.0 was.

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 C#. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Jeremy Gray

    I have to agree with you. The CLR was created so that languages with different needs could each flourish in their own areas and with their own specialties. Now we’re polluting C# with a whack of VB-isms that were some of the largest reasons I left VB work in the first place. This is a big step down a rather slippery slope.

    As far as I can tell, C# 4 is giving me one and only one new language feature that I remotely care about: generic variance.

    To paraphrase loosely, “this was supposed to be the future. where are my non-nullable arguments?”

  • Well, when you look at the primary scenario for the hash syntax in Ruby within application frameworks, you’re looking at named parameters.

  • The things you’re bemoaning here are part of what makes Ruby desirable to ruby programmers.

  • @Scott

    I wasn’t really trying to point out that these features are bad, but that all of the fuss about these two in particular seems ironic, given that VB.NET has had them for so long.

    Aren’t hashes as parameters something like optional+named parameters as a mix? I understand the scenario, but I’d still rather have just hashes over a bunch of crazy compiler tricks.