Apparently, there is some considerable confusion over all the new C# language features.
People who I would hope are reasonably intelligent are completely misunderstanding
some C# fundamentals. Agreed, a lot of the new concepts introduced to C# 3.0 are might
seem relatively foreign to C# users. Microsoft's marketing related to LINQ doesn't
help much either. I'm going to try to clarify the top few things I've seen. I'll reference
the C# spec (http://msdn2.microsoft.com/en-us/library/ms364047(vs.80).aspx)
so you can know I'm being accurate.
Myth: LINQ is just a data access technology
While data access is obviously a large part of LINQ (even the name stands for Language
Integrated Query), you can do a lot more than just access data. Re-using a previous
example:
args
.Select(s
=> newThread(()
=> SomeLongProcess(s)))
.Process(t
=> t.Start())
.ToList()
.ForEach(t
=> t.Join());
There's no sign of data access there! The practical functional C# articles on my site
go into more detail on this. Suffice to say, while a lot of new features were added
to "make LINQ possible", much, much, more is possible than just creating queries.
(Alternatively, you might chose to limit the meaning of LINQ, as I'd like to do. In
this case, I wouldn't consider using lambdas, extensions, etc. as LINQ. Others may
disagree. Marketing?)
Implicitly typed local variables (var keyword)
C# is still statically and strongly typed. But, there's a new feature that lets you
declare local variables without specifying the type, if the type can be inferred from
the initializing expression. From the spec:
var i = 5;
var s = "Hello";
var d = 1.0;
var numbers = new int[] {1, 2, 3};
var orders = new Dictionary<int,Order>();
The implicitly typed local variable
declarations above are precisely equivalent to the following explicitly typed declarations:
int i = 5;
string s = "Hello";
double d = 1.0;
int[] numbers = new int[] {1, 2, 3};
Dictionary<int,Order> orders = new Dictionary<int,Order>();
Oddly enough, the C# spec doesn't even mention LINQ or anonymous types when it talks
about "var" locals. Why is there confusion about this simple feature? Let's examine
anonymous types:
C# anonymous types allow you to declare a type just by specifying its fields. From
the spec: "C# 3.0 permits the new operator
to be used with an anonymous object initializer to create an object of an anonymous
type." For instance, the following code is a valid expression:
new { Name = "Michael" }
This produces an object of a new, anonymous, type, containing a single string property
called Name. Hence, this code works:
Console.WriteLine(new {
Name = "Michael" }.Name);
However, how can you assign such an object to a variable? Yes, that is the only "need"
for the var keyword. There's no way to name the type, since it's anonymous. Regardless
if you agree with anonymous types (versus a Tuple class), this is the place where
you *need* to use var: assigning an anonymous type to a local.
As you may have noticed, I still haven't mentioned LINQ. Anonymous types are not LINQ
specific. They are, however, particularly helpful for certain LINQ queries:
var topCustomers = MyDatabase.Customers.Where(c => c.GoldStar == true).Select(c
=> new {c.CustomerId, c.Name});
Because of this, people start to associate anonymous types only with LINQ queries
and hence, var with LINQ only. The truth is that these features can be used anywhere.
What's the takeaway here? The var keyword simply allows the compiler to infer
the type of the variable so you don't have to specify it. Nothing more, nothing
less. Some people still want to explicitly annotate every single variable – hey, that's
their choice. But don't be locked into this just because there was no option before.
Me? I'll take more concise code any day!
As a side note (if this wasn't clear), the var keyword is NOT dynamic typing, just
implicit typing (type inference).
Dynamic C#
Seems there's a lot of confusion about C# being dynamic. C# is not dynamically typed,
as some seem to imply. I think perhaps some of the confusion comes from all the nice
type inference that C# provides. Using the var keyword as shown above might make some
people feel "oh, I'm saying var just like Javascript!". Adding to the confusion is
the fact that C# is now a "semi"-functional language. For instance, from "why's
(poignant) guide to ruby", we see this Ruby code:
5
.
times
{
print
"
Odelay!
"
}
C# allows us to write in a similar style:
5.Times(() => Console.WriteLine("Odelay!"));
The next Ruby example in that guide goes like this:
exit
unless "
restaurant
".
include?
"
aura
"
In C#, we can write:
exit.Unless(() => "restaurant".Contains("aura"));
The Wikipedia article on Functional
Programming lists a few features that dynamic languages usually have:
Eval
Sorta… you can create Expression<T> and execute them. On the other hand, you
can't do anything like eval(myString) (which is just asking for runtime failure).
Higher-order functions
Definitely in there.
Runtime alteration of object or type system
No, not really. (I.e., maybe you can hack around with certain APIs to try to do some
magic, but it's not a language feature.)
Functional Programming
Yes. But still, functions aren't really first class citizens…yet. Once we can start
using method groups as Actions and Funcs, implicitly, then it'll get even better.
This is an interesting presentation from Andrew Kennedy, Microsoft Research: C#
is a functional programming language.
Closures
Yep, since anonymous methods were introduced in C# 2.0.
Continuations
Extremely limited, in the form of yield return.
Introspection
Not just reflection, but actually inspecting the actual code. C# 3.0 has this in the
form of Expression<T> (see below).
Macros
No, not crappy C-style macros. Here, I'm thinking more like macros that'd let you
create things like C# query comprehensions, *in source code*. (Which is what I was
actually hoping when I saw the new query comprehension syntax… no such luck).
In summary, C# lets you gain a lot of benefits usually associated
with dynamic programming, but without the nasty parts of dynamic typing.
A great paper on this subject is Static
Typing Where Possible, Dynamic Typing When Needed: The End of the Cold War Between
Programming Languages, by Erik Meijer and Peter Drayton of Microsoft.
Myth: Extension methods add methods to a class
This is a tricky one, since extension methods appear to be exactly that. This myth
is also somewhat perpetuated by the C# spec: "In effect, extension methods make it
possible to extend existing types and constructed types with additional methods."
But, right before that, the real explanation is given: "Extension methods are static
methods that can be invoked using instance method syntax."
Essentially, Extension methods allow us to use infixnotation
with certain methods. This explains the line from the spec "in effect". A more helpful
way to think of this is by thinking of the "." operator as an overloaded operator
that also allows passing the first operand given to it as the first argument to specially
marked methods.
An alternative* would be to define an operator like the F# pipeline operator (|>).
In C#, this would let us write stuff like:
customers |> Seq.Where(c => c.Name == "Michael")
That doesn't look like an improvement. BUT, we no longer need to mark methods in a
special way. We can just use them:
myArray |> Array.BinarySearch("s")
Why do we need infix notation anyways? Well, the normal prefix notation can be difficult
to read:
Select(Where(customers, c => c.Cool == true), c => c.Name)
Array.BinarySearch(items, "S")
Extension methods just make those functions easier to pipeline. That's all folks.
Think of them like this, and save yourself a headache about what "extending a type"
means.
*My guess as to why extension methods are done they way they are is because it could
confuse people if you have something like "item |> Stuff.SomeMethod("X")" where
SomeMethod returns a function. Or, where you have "item |> Stuff.SomeMethod("X").SomethingElse("y").
I'm still annoyed that I can't use infix semantics where *I* want, but oh well.
Lambda expressions and Expression<T>
Spec: "Lambda expressions provide a more concise, functional syntax for writing anonymous
methods.". Spec: "Expression trees permit lambda expressions to be represented as
data structures instead of executable code. A lambda expression that is convertible
to a delegate type D is also convertible to an expression tree of type System.Query.Expression<D>."
So, "lambda expressions" can either be just code (i.e., directly executable IL) OR
they can get turned into a data structure, Expression<T>.
Adding to the confusion, a lambda expression can contain just an expression (i=>
i + 1), or it can be a block of statements ( i => {Write(i); i++; Write(i); return
i+1;} ). However, a lambda expression with a statement block body cannot become
an Expression<T>. (As far as I know, VB's lambdas only allow for expression
bodies, not blocks.)
An example:
Expression<Func<int, int>>
inc = i => i + 1;
Is equivalent to:
ParameterExpression param_i
= Expression.Parameter(typeof(int), "i");
var inc2 = Expression.Lambda<Func<int, int>>(
Expression.Add(
param_i,
Expression.Constant(1, typeof(int))),
param_i);
At runtime, you can then go inspect the actual code and decide what to do with it.
This is exactly the premise for LINQ to SQL. When you create a LINQ-to-SQL query,
it is turned into an expression like shown above. Then the LINQ-to-SQL APIs inspect
and convert that expression tree into SQL statements.
Here, I can understand the confusion. The word "expression" is used in three distinct
manners. Rightfully, Expression Trees should be referred to as Expression or Expression<T>,
which could help clear up some of the confusion. Additionally, it doesn't help that
lambdas have these different conversion rules (although working around it could be
ugly, possibly).
Are there any other features that you've seen misused or you've had questions
about? Let me know! I love comments, insults, and suggestions.
Want to correct me on something? Go right ahead! But, if you're going
to say something like "C# doesn't have type inference", please make sure to either
be an expert on the matter or be able to quote an authoritative source or show a proof.
Thanks!
