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.

  • I would like to be able to do the following with generics:

    class A<T> : T

    {

    }

    In C++ you can do that. In this way you can "decorate" the type T with extended functionnality that can be reused, and still being a T + A.

  • does this means that it is easier to do complex marshalling?

  • Thanks for the informative article

  • C# is a fantastic language and my congradulations to the entire team!

    Moving forward it would be nice to cleanly define types for variables for their specific purpose...

    declare Int32 Index; Index a = 5, b = 6; Int32 c = a; // throws invalid cast exception for a to c

    Perhaps LINQ also needs to be editable at run-time without requring recompile. This is the main reason I don't use it in development.

  • Well, what I really like from python is tuples, it's a nice way to store data without the tediously need of creating a class or struct just for getting the job done. It'd be great if c# could have a similar implementation, especially now it has strong support with dynamics.

    Well, guess this is just another item for the wish list...

  • Hi,

    One new feature which can be implemented is to provide [Encryption] attribute on Class, Methods, Assembly, Namespaces so that the class over which [Encryption] attributre is applied get encrypted. So that no disassembler should be able to view the class. the Decryption algorithm should be kept with CLR which only can decrypt the [encrypted] class at run time.

    The so called LINQ, Var feature is not getting used in any company. People dont use this in their application, except for some rare occasion.

    Microsoft should provide value features.

    They are not providing the feature that can help developer to code fast and easily.

  • Microsoft should provide more example soruce code with new release.

  • "please stop fundamentally changing the way I think about programming every couple years"

    I'm going to up this a bit... and move outside of C# for a moment.

    Consider what happened with Windows Apps, Windows Forms and then Windows Presentation Foundation.

    Each was an improvement over the previous in terms of functionality - but only one was a simplification in implementation (guess which one? :)

    Coming back to C#, WPF broke the Forms model and I'm still not convinced for the better. It's not easier to use. It's not elegant. It's so difficult to design around that even in VS2008, you find yourself typing in a lot of the UI elements by hand. You can use Blend - but now you have to buy a whole separate application to design parts of your app - and it's a design tool that's so different from the prexisting model that basic things that are easy to do in VS2008 directly (like - binding a database table to a data grid in a form) are bewilderingly complicated and require many levels of obscure indirection.

    WPF 'introduced' the notion of attribute manipulation and did it in a very clumsy, non-obvious way. Which was odd because C# and .Net already HAS attributes and a fairly clean and elegant way to manipulate them. WPF broke the very elegant properties model and brought back explicit set/get methods.

    Going back to your the original statement: there are ways to improve and add 'essential' features (but please, there's essential and then there's ESSENTIAL) without throwing everything out the window and starting over.

    What's needed is a feature referee who vets implementation models for new features. A continuity cop (to borrow a term from the comics industry) who reviews new features and how they're to be implemented and looks at the new feature in context of the entire picture and only lets wildly new features in if there really is no other way to fit it into the existing paradigm.

    I think most of us can handle gradual changes and big but isolated changes - LINQ is a good example - if you don't like it - you can stay with typed datasets and table adaptors. But if the only way to get access to animation is to have to completely turn your application on its head and graft in ugly things like XAML...

    Well, people will complain.

  • I am becoming increasingly alarmed at the pace of changes to the C# language.  Many of them seem to be made without a clear business justification.  

    "Because Java has it" is not a business justification for a feature.  For that matter,

    neither is "because Java doesn't have it".

    I finished my CS graduate work in 1987 and entered industry writing UNIX-based database code in C and C++.  At the time, IBM's application development frameworks dominated business computing, and yet were an insane mish-mash of partially-interoperable pieces.  The lack of clarity in IBM's vision -- it made sense to them but hardly anyone else

    -- is what made them vulnerable.

    In contrast, C, C++, UNIX, and later Windows offered refreshing clarity.  IBM's crazy quilt of aplication

    technologies quickly went from dominant to a historical footnote.  They got clobbered because

    their excessively complex vision made sense only inside their own company walls.

    Another example of a too-clever-by-half language from around that time was Ada, which again C# is beginning to resemble.  It was a patchwork quilt of features that a committee of academians and

    "O-O Hezbollah" types all thought the world needed.

    I am beginning to see a lot of similarities between Microsoft in 2008 and IBM in 1987.  I

    urge the language team to slow down, take a deep breath, and think about the C# platform

    in terms of simplicity, consistency, and coherence.  Leave the boutique language features

    to the boutique languages.  

    There is a reason that we're all not programming in Ada today.  As Jerry Seinfeld once said, "the

    road less travelled ... is less travelled for a reason".

  • I am becoming increasingly alarmed at the comments about slow down the good paced evolution of the C# language by some guys saying "i cannot go so fast, so slow down everybody". And I say "good paced" considering the need to -right now- take advantage of the emerging technologies (i.e. multi-core, multi-touch, cloud computing).

    Right a few weeks ago, I was required for develop a web application for project management (you know... tasks, schedules, time consumption, people and other resources) and was fortunate to have Silverlight 2, C#, XAML, LINQ, etc. for concluding with a very good product and on schedule.

    I think the complains about delivering frequently (in a subjective timescale) new versions of C#, tools or other techs are related to a problem of management of certain (I don't even believe the most of) companies. They should invest on training their developers, and the learning curve will be compensated by the productivity gain.

    So...  welcome the innovations on the 18 months dev cycle.

  • I'd like to see support for a ThisType in Generics.  Being able to create a factory method in my class that returns an object of that type is something that comes up on a regular basis, and it would be nice if there was a way of being able to avoid having every subclass specify its own type.  It would also make the Singleton pattern simpler to code.

  • Through my many years of programming I have concluded that it is important to use the right language for the job.  For example... when speed is critical, C or Assembly is preferred.  Lisp is good choice for computer generated code.  ... and the list goes on.  One of the fundamental beauties of Visual Stuido is the ability to program and combine many languages into one application.  

    There is an old saying... Too many hands in the pot will spoil the stew.  C# is a great language as it is today.  Trying to make it the only language in the world by adding every possible language feature that any developer would ever need is going to... spoil the stew.  

    I think that MS should focus more on making language integration easier rather than trying to shoe-horn everything into one language.  After all... all languages end up running on the same machine and in the case of Visual Studio, running through the same compiler.  Why can't they all 'just get along'?

  • I would love to see C# better address Concurent programming.

  • I would like to see more improvements on metaprogramming

    Consider this code, how to get rid of the duplication?

    namespace Utils

    {

    public static class Utils

    {

    public static Action UICtx(this Control control, Action func)

    {

    return delegate()

    {

    if (control.InvokeRequired)

    control.Invoke(func);

    else

    func();

    };

    }

    public static Action<T> UICtx<T>(this Control control, Action<T> func)

    {

    return delegate(T a)

    {

    if (control.InvokeRequired)

    control.Invoke(func, new object[] { a });

    else

    func(a);

    };

    }

    public static Action<T1, T2> UICtx<T1, T2>(this Control control, Action<T1, T2> func)

    {

    return delegate(T1 a1, T2 a2)

    {

    if (control.InvokeRequired)

    control.Invoke(func, new object[] { a1, a2 });

    else

    func(a1, a2);

    };

    }

    public static Action<T1, T2, T3> UICtx<T1, T2, T3>(this Control control, Action<T1, T2, T3> func)

    {

    return delegate(T1 a1, T2 a2, T3 a3)

    {

    if (control.InvokeRequired)

    control.Invoke(func, new object[] { a1, a2, a3 });

    else

    func(a1, a2, a3);

    };

    }

    }

  • How about finally providing and overrideable assignment operator....

    immagine a vector that represents a physical quantity -- mass, length, time, charge

    a speed would be represent by 0,1,-1,0     => length / time

    the arithmetic operators could be overriden such that a division of a speed vector 0,1,-1,0 by a time vector 0,0,1,0 would result in an acceleration 0,1,-2,0  => length/ time^2

    this can all be done now except for the dimensional checks made during the assignment -- there's current no way to insure that the result of a speed / time computation is assigned to an acceleration....

    you could even get really slick and check atrributes to insure the the correct MKS, meters kilograms, seconds and CGS centimerters, grams seconds checks were made  ( attributes work fine here).

Page 4 of 5 (74 items) 12345