Time out today for just a bit of a rant.
Several years ago, I posted a top ten list for why you shouldn’t buy Visual Studio 2008. Most people totally got that this was all tongue in cheek. But, I was amazed how many comments I got on YouTube where people took it WAY too seriously. Sigh.. people… just goes to show how shaky this writing medium is. Ah well…
What makes most of the items I suggested in that list funny is that there really are people who believe at least one of the reasons I listed. Including the last one about using notepad and the command line. I had a student in a Java class I was teaching several years ago who told me that the lead programmer where he worked was still using VI (‘nix version of notepad) for all of his development. He was also STILL setting the CLASSPATH variable. Even though there were free tools available that had intellisense, color syntax highlighting, and the CLASSPATH environment variable had died several years prior.
Along these lines, I actually found a blog post by an ex C++ programmer indicating that he believed anonymous types would make the code unreadable. So, let’s look at that in some detail this morning.
First, let’s acknowledge right from the start that the reason anonymous types exist at all is because they were needed to make LINQ work. If Microsoft had decided to hide this feature from the rest of us, we’d complain because we couldn’t use it. So, making the feature available to us or removing it “for our own protection.” was a no win situation for Microsoft.
Second, anonymous types exist so that we can use them when they make sense. Not so that we can use them all of the time. The best example I can think of that we already have as part of the language is the ternary operator. The VB guys just had this added into the language, but the CSharp guys and anyone using Java, C++, or any of several other curly brace languages have had this feature for a while.
The ternary operator in most curly brace languages looks like this:
variable = booleanExpression ? returnExpressionIfTrue : returnExpressionIfFalse;
It does the same thing as:
if (booleanExpression) variable = returnExpressionIfTrue; else variable = returnExpressionIfFalse;
But, when you are writing some code where you need to pass “variable” in as a parameter to a function it is much easier, and I would argue, much more readable to say:
fooFunction(booleanExpression ? returnExpressionIfTrue : returnExpressionIfFalse);
Than it is to write:
if (booleanExpression) variable = returnExpressionIfTrue; else variable = returnExpressionIfFalse; fooFunction(variable);
Which is what you’d have to do if you didn’t have the ternary operator.
However, you shouldn’t us the ternary operator when you are going to need to do that same operation several times in your code. In that case, spelling it all out using standard if/then/else notation and assigning the result to a variable is not only clearer, it will ultimately make your code run faster because you will be doing the operation once instead of multiple times.
I believe we are going to find that the anonymous types work the same way. Yesterday, I illustrated on example of how and why they might be used. In that example, I think it is pretty clear that using anonymous types makes a heck of a lot more sense than creating a brand new class. In fact, creating that new class would not only take more time, but would probably make the code slightly less readable in the same way that using an if/then/else construct would make the code slightly less readable than using the ternary operator.
In my 20 years of programming, this issue has come up over and over again. There are those who will always want to protect the newbies from writing unreadable code and will therefore restrict, or try to restrict the language set they can use. In the end, this does a disservice to both the programmer and the application they are working on. It is a lot like continuing to feed a baby milk because we are afraid they might choke on solid food.
Restricting the food a baby can eat and restricting the language features that a programmer can use, makes both malnourished and ultimately leaves you with a weak child, in the case of a baby and a weak programmer. The very thing you were trying to avoid.