The Problem With a Language That Grows

The Problem

There is no denying that C# is a very powerful language. A large contributor toward that power is that the C# language definition is regularly expanded and built upon to grow alongside the ever-changing landscape of information technology. Each iteration of the language has opened up new, powerful capabilities that either did not exist within the language prior to that release or that were only possible through the writing of many, many lines of brittle code.

The inherent problem with this kind of growth is that for programmers who didn't join the C# party early on, but rather are just arriving now, there are almost too many tools available for problem solving. Worse still, some of those tools are incredibly powerful and can be easily and accidentally abused when placed in the hands of a novice. This is an unfortunate side effect because those same tools in the hands of an experienced programmer make for compelling and powerful solutions.

An Example

One such modern language feature to which I am referring is the Type dynamic. As a C# advocate one of the features that I laud loudest is type safety. In C# if the Type you're referencing doesn't have a DoSomething() method then you can't write myObj.DoSomething(). Well you can... but it won't compile!

The Type dynamic removes that powerful precaution. It says "whatever you write, I'll trust you, but if I later try to run code that I can't then I'll crash". That's quite the deal with the Devil and should only be used by those who really know what they're signing up for and only when there is truly no other option.

In my entire career I've used the Type dynamic exactly once.

In Outsorcery when your serialized object of Type IWorkItem<T> gets to the server, unable to infer the Type T and not needing to know it because the resulting object of that Type will just be serialized and sent back to the client immediately, I use the Type dynamic to allow me to call the method DoWorkAsync() that I know exists but can't prove to the compiler without reams and reams of infrastructure code. It is an incredibly rare scenario and one that I have locked down to only a couple of lines of code, wrapped in a try/catch, in the lowest levels of my library.

More and more I've started to see novice developers diving straight onto using the Type dynamic in scenarios where other language features would give them both the type safety and the flexibility that are available within C#. I've seen people use dynamic when they should be using Interfaces, when they should be using Generics, when they should be using Type Casting and even in cases when they should just be using the Type object.

A Solution?

So the question inevitably becomes a take on the same question we see time and time again in sport, in online gaming and even in general life.

How to protect new C# developers from being overwhelmed,
without holding experienced C# developers back?

The solution that I propose is one that aims to not be overly invasive, but instead informative. Drawing on the experience of the world of online gaming, I suggest that when you write code that uses a heavy-handed feature for the first time, Visual Studio should present you with a tutorial window. Something like this:

dynamic myObj = otherObj.Operation();

Of course, veteran programmers will be able to disable this feature via the pop-up either on a per tutorial basis or as a global setting.

Having these tutorials built into the IDE shouldn't get in anybody's way, it just means that for the programmer who's just starting out, the relevant information is right next to the code they're writing. In effect, it'll be like pair programming between the novice and the collective knowledge of veteran C# developers.

What do you think?