The Future Of C#, Part Five

The Future Of C#, Part Five

Rate This
  • Comments 74

When we're designing a new version of the language, something we think about a lot is whether the proposed new features "hang together". Having a consistent "theme" to a release makes it easier for us to prioritize and organize proposals, it makes it easier for our marketing and user education people to effectively communicate with customers, it's just all-around goodness.

If you look at C# 2.0, it was a bit of a grab-bag. The big features were clustered around the notion of enabling rich, typesafe programming with abstract data types that represent collections of data -- and thus generic types and iterator blocks. But there was a whole lot of other stuff in there as well: implementing anonymous methods was a major feature that doesn't fit well with this theme. And there were other more minor features as well: partial classes, improvements to properties, and so on.

With C# 3.0, the theme was very clear: language-integrated query. Anything that did not directly support LINQ was immediately made lower priority. It is rather amazing to me that partial methods and auto-implemented properties got in at all; that they were relatively easy features to design, implement, test and document was what saved them.

What then is the theme of C# 4.0? Again, it seems like rather a grab-bag: covariance and contravariance, improved interop with dynamic languages, improved interop with legacy COM object models, named and optional parameters. It also seems like a pretty small set of new features compared to generics or query comprehensions.

That was deliberate. Some feedback that we received loud and clear throught the C# 3.0 ship cycle was "this is awesome, we need these language features immediately!" and, somewhat contradictorily, "please stop fundamentally changing the way I think about programming every couple years!" Rather than trying to find some way to yet again radically increase the expressiveness and power of the language, we decided to spend a cycle on making what we already have work better with the other stuff in our programming platform infrastructure.

"Now actually works the way you'd expect it to" is not really a theme that gets people excited, but sometimes you've got to stop running forward at full speed and take some time to fix the existing stuff that is annoying a lot of people. (When I was on the VSTO team I petitioned the C# team to please, please make ref parameters optional on calls to legacy COM object models, but they were too busy with designing LINQ; I'm delighted that we've finally gotten that in.)

We also want to make sure that we are anticipating the problems that people are about to face and mitigate them now. We know that dynamic languages and object models designed with dynamism in mind are becoming increasingly popular. Given that there will be stronger demand for statically typed C# to interoperate with them in the future, let's get dynamic programming interoperability in there proactively, rather than be reactive about it later.

Looking forward, it's not clear what exactly the theme of future (hypothetical!) versions of the language will be. The expected onslaught of cheap hardware parallelism looms large in our minds, so that's a possible theme. Enabling metaprogramming is another possible theme on our minds, thought it is not at all clear how that would happen. (Make C# its own metalanguage? Extend expression trees to statement trees, declaration trees, and so on? Open up the internals of the compiler and provide an object model that lets people generate programs directly? It is hard to say what direction is the right one to go in here.) Fortunately, people way smarter than I am are thinking about these things.

  • About last section (about metaprogramming)...

    Eric, excuse me, you ignore two question about Nemerle.

    You can say, you know this language?

    You try to install it (http://nemerle.org/Download#CTP_packages)?

    What you think about metasystem of this language?

  • > But I do realize now that things are moving way to fast and my concepts are shaken up REALLY SHAKEN UP with every new release. Things are not the way they used to be !! I think we really need to stabilize a bit + have the support for previous architectures as well

    My impression so far for .NET 4.0 & C# 4.0 is that it is largely what is going on. It is certainly less "revolutionary" than .NET 3.5 (+SP1) / C# 3.0 - more incremental changes, more cleanups, reintegration of currently separate components into the base framework (DLR, PLINQ etc) and so on.

  • Another vote for immutability syntactic sugar...even if that were the only new feature in c# 4.0, I would be very happy.

  • My vote too for an immutability feature for C# 4.0.

    Also, I would like to have that "Eval" method shown in the PDC (and not wait until 2012 as suggested by Miguel de Icaza suggested while shown the same (?) in Mono)

  • Jon, what's wrong with

    public int Something { get; private set; }

    as far as readonly properties go? The fact that you can assign them in methods of this object? (As in, make sure I don't do something stupid with this property?)

  • Marcel, it's both that and the fact that there's no inline initializer for autoproperties.

  • Marcel:

    1) It's not readonly within the class itself - so you have to make sure you're not stupid.

    2) As int19h said, it would also be nice to be able to provide a default value, although that's not quite as big an issue for me.

    3) It's just not immutable then - anything that checks for immutability would either fail on a type with these properties, or have to check to see that the setter really was only called during the constructor.

    4) It can't be a readonly field in the IL while it's got a setter. This may mean the CLR can't make certain optimisations.

    5) It doesn't show intent - I will quite often have a public getter and a private setter for things which I genuinely want to be mutable via other properties/methods. It should be obvious from the code that this is a different matter - that it's a genuinely readonly property which will be set in the constructor and then never touched again.

  • Immutability is certainly part of the contract  (something that C++ "const" misses, by the way) - it's  the distinction between "you can't change it, but it might change by itself (or by someone else)" and "it can't be changed by anyone, period". At the moment, it's implicit in the code, and you have to explicitly state in the documentation that your type (or a particular property) is really, truly immutable. For fields, that's what "readonly" does (with some caveats, such as "... after constructor runs"). It's just strange that there's no equivalent for properties and classes as a whole.

    Note also that there is a distinction between "all properties are immutable" and "type as a whole is immutable". This has to do with versioning - if I write a method that returns a reference to my object, which I think is immutable, because all its properties are immutable (but its author thinks otherwise), I might be unpleasantly surprised if, in the next version of that object, it suddenly gets some read/write properties, and my callers will be able to change my internal state!

  • I really wish that Microsoft would pull a few more language enhancements from the Microsoft Research Cω (C-Omega) project, particularly the concurrency abstractions based on join calculus.  In my opinion those language enhancements represent the most elegant solution to many complex concurrency situations.

    http://research.microsoft.com/comega/

    Asynchronous Methods:

    public async DoSomeWork() { }  // async methods automatically execute within another thread

    Joins/Chords:

    public async Put(int y);  // at least one async method without a body that acts as a signal queue

    public int Get() & Put(int y) { return y; } // a normal method combined with one or more async methods.  Calls to Get require a corresponding call to Put and will block until/unless such a call is queued.  The parameters from both methods are available in the method body

    I would also like to see support for explicitly declaring an anonymous type:

    List<struct { int i; string s; }> list = Enumerable.Range(1, 10).Select(val => new struct { int i; string s; } { val, val.ToString() };

    I would like to see the ability to define mutable members of an anonymous type, which VB.NET already supports:

    var person = new { ID = 1, ref Name = "Bill Gates" };  // Name is a mutable member and is not used when calculating GetHashCode or evaluating equality.

    I would like to see syntax to define an anonymous delegate type, even if it just maps to the corresponding Func<> or Action<> delegate:

    int(int,int) add = (x, y) => x + y;

    I think some of the tuple functionality from Cω would be useful.  I know that .NET 4.0 is due to get official tuple type support that is to be shared between languages (including F#) so perhaps this functionality could be considered?

    var item = new { x = 5, y = "Hello", z = new { a = 42; b = new Button() } };

    foreach(int number in item.int::*) { ... }  // selects all of the int members from the anonymous type, 5 and 42

    The Cω project was an excellent project from which quite a few C# features were derived.  I think it still contains a few useful treasures that would benefit us.

  • Assad - I agree with you completely.

    Mark Rendle - You're right also - we are not required to use new technologies like LINQ or WPF. The problem is that as developers we know that there is probably a good chance that these new developments will reduce coding time and offer new features in the long run but we don't know if they are ready for prime time yet.

    I find myself doing a couple of things whenever a new technology like LINQ is made available,

    #1. Does this technology do everything that I can currently with System.Data classes?

    #2. Learn the technology.

    To me No. 1 takes as long as No. 2. It would be nice if whenver a new technology (or syntax change) were incorporated, we didn't have to spend so much time figuring out if it was so much better than currently available stuff. Kind of like the reviews you read on NewEgg when purchasing hardware. The MS development team guys should just come right out and say "YES" or "NO" you need to switch to a new particular methodology. I should be able to go to the main page for LINQ and read the review which says "LINQ is the way to go right now." or "LINQ is great but you probably shouldn't port everything to LINQ just yet because it lacks support for...".

    In the end however, I do appreciate the effort the gang at MS and on the blogs is putting into moving forward. It's just seems to get harder to keep up as I get older.

  • How about "fixing" what once was the promise of dot net: program once, deploy many - in other words, a CLR for MacOS.

  • Releasing a .NET/C# combintation that replaces 90% of all win32 api calls.  This is within striking distance given that many win32 based technologies are at  or near end of life (e.g., com) and could be replaced with a .NET to win32 api thunk layer.  

    SQL Server is a model for this since the've rewritten SQL Server 4.2 (sybase 4.9) from scratch over the SQL Server 7, 8 and 9 releases).  MS should be able to do this for large chunks of the win32 api call with the next few service packs to Vista and Server 2008.

  • This isn't really a language issue, but, since some people brought up concurrency, I would like to see classes like ObservableCollection<T> improved so that they can be used from multiple threads. i.e. you should be able add items to an ObservableCollection on a background thread and have it update the UI/WPF automatically.

  • Why not just use snippets for some of the complaints about immutability?  It's pretty easy to make a readonly property snippet.  I'd then use a code generator myself for all the constructor magic & partial classes, but that's only if I understand the problem correctly.

  • I would rather see a release of c# that integrates with SQL Server and Windows in a way that's supports and shares the same view for things like datatypes and hardware devices; through a standard api for stuff like sound and video processing.

    We need api's for multi-touch, speech/sound/video processing, webcam devices etc etc

    WPF and Dynamic syntax is great and all, but adding new stuff is not always what is needed.

    We need better support for things that already exist but are only accessible via criptic Win DLL's and RegEdit settings (or not at all)!!!

Page 3 of 5 (74 items) 12345