There have been lots of announcements at PDC - the Azure initiative seems to have more substance than I was expecting. It will be interesting to see how their cloud infrastructure progresses - in many ways a movement to cloud based systems is a threat to their desktop and Office monopoly. So it makes one wonder what their real commitment to Azure will be.

Directly related to the Fan - we finally get a glimpse of what C# 4.0 might hold. The most interesting thing is that C# is embracing a hybrid static/dynamic model very much like Fan. I think that is very cool that one of the major OO languages is moving in this direction. The big difference between C# and Fan is that Fan lets you use dynamic calls on any object, but C# will require you to type things as dynamic.

I actually think Fan model works better because experience with it shows that very often you use dynamic calls with typed objects. This allows you call normal statically checked methods against the type, but also use dynamic calls when it makes sense. The C# approach doesn't really let me mix the two - I have to cast the object to dynamic before I can make a dynamic call. So I really think they could use a -> operator.

There also seems to be a caveat that you can't use lambda expressions as arguments to dynamic calls. That makes sense based on what I learned at the JVM Summit that things are inferred by the method being called. Although it seems like that could really limit how dynamic and functional programming are mixed together.

The dynamic feature is tied into the Dynamic Language Runtime. And it sounds like we can plug into the dynamic infrastructure with the IDynamicObject interface. So we should be able to cleanly expose Fan's dynamic features to C# code - that is definitely very cool.

C# will also finally be getting default parameters. This is such an incredibly useful feature, I'm surprised Java and C# haven't had it from the beginning. It is very easy to implement, and plays a huge role in cutting down on the surface area of APIs.

C# will also allow named parameters - that is something we might want to consider for Fan. The front end wouldn't be too hard to implement since I maintain the parameter names for reflection. The trick would be how to compile it - right now parameter defaults are compiled into the overloaded methods on the parent class. They are not compiled into the call site. This is a bit more future proof because you can change a parameter default and client code automatically gets the change. Named parameters are more difficult to handle since you can't just call an overloaded method - you are almost required to compile the default expr into the call site. Although honestly I haven't really run across a case where I really wanted this yet.

Their generics co/contravariance support looks a lot more like Scala's system than Java's wildcards, but they use readable keywords in and out instead of + and -, not sure if that's respectively or not (part of the problem with too many symbols instead of words). Very interesting.

I'm still of the opinion that automatic co/contravariance is best despite the lack of static type safety. (And I prefer this even to Fan's avoidance of generics, but that's been discussed before. I'm just mentioning in passing.)

@tompalmer:

in is for types used for input (e.g. parameter of methods) so it means contravariant, out is for output (e.g. return-type) so it means covariant. Pretty simple and obvious. In Scala + means covariant, - means contravariant. Once you know that it's just as easy.

Example with a concrete type: In the next version Func will be defined like this:

Func<in TArg, out TReturn>

I like this variance annotation system a lot more than Java's user side variance annotations. With Scala's/C#'s system you just have to think once about it when you design the libaray and you're done. Sometimes it can even show you some waknesses in your design. With Java's system every user has to think about variance and write it down every time he want's to use it. It's a little bit more flexible but IMO absolutly not worth it.

@brian:

At first glance I like -> more than dynamic, too.

But Fan doesn't have those realy dynamic things. AFAIK, currently you can't create an object that represents a row of a csv file where you can access the values as fields with the column's name or other stuff like that.

// file.csv
Foo;Bar
1;4
2;6

// pseudo Fan
csvFile := readCsvFile("file.csv")
x := csvFile[0]->Bar   // 4

I think in combination with a dynamic language like IronRuby you could get such an object in C# 4 and use it through dynamic.

But Fan doesn't have those realy dynamic things. Currently you can't create an object that represents a row of a csv file where you can access the values as fields

Actually you can do that. Because -> is really just a call to trap you can handle it however you like. In fact this is how the sql API works - you get rows as sql::Row objects and you can access them like JDBC - or you can just use the -> to access the row using its column name. That actually is a perfect case where allowing you to mix and match the . and -> operators is useful. See sql docs.

OK, sorry, my fault.

If you didn't see this...

http://channel9.msdn.com/pdc2008/TL16/