The Future Of C#, Part Five

re: The Future Of C#, Part Five

Marcel Lamothe — Fri, 07 Nov 2008 22:02:19 GMT

What about the immutability stuff you were talking about earlier this year?

re: The Future Of C#, Part Five

Gabe Moothart — Fri, 07 Nov 2008 22:22:26 GMT

Like Marcel, I was hoping for more support of concurrency-safe patterns like immutable types, etc in c# 4. Version 5 likely won't ship until at least 2012, and by then we'll all be running on 80 cores and concurrency concerns will not be "looming large" but way overdue.

re: The Future Of C#, Part Five

J. Daniel Smith — Fri, 07 Nov 2008 22:49:04 GMT

I was also surprised that there isn't anything about immutable types in C# 4.0.

re: The Future Of C#, Part Five

Eric Lippert — Fri, 07 Nov 2008 23:13:49 GMT

Well, I have been trying to message that immutability, etc, is (1) important and (2) in our future thinking, not our present thinking. Apologies if I messaged that poorly.

These things take time. A major factor in the design of work for multi-cores is that there is not a consensus in industry or academia as to what the right thing to do is. With query comprehensions, we at least had twenty years of academic research that we could look at which by and large agreed on the right way to go. With concurrent programming there are as many models as there are researchers it seems. :-)

re: The Future Of C#, Part Five

barrkel — Fri, 07 Nov 2008 23:36:53 GMT

I beg to differ on the topic of generics and anonymous delegates being unrelated. That might have been the case in design, but in practice the case is less clear.

Generics work by restricting the operations available on values of a generic type. When you want to expand on the number of available operations, you need to parameterize by the operation required. And what's the easiest way to supply operations (i.e. code) by parameters? Anonymous delegates and lambdas.

re: The Future Of C#, Part Five

Jesper — Fri, 07 Nov 2008 23:53:22 GMT

Now that the cat's out of the bag, and acknowledging that it's many months out still, periodic updates on the C#-in-C# compiler-as-a-service things Anders mentioned would be an interesting subject. I can't tell you how often I've wanted an official, sponsored full code vocabulary for talking about C# (and with dynamic programming, the cost for trying to make your own or reconcile the existing alternatives rise still). I'm very happy that not just Miguel and part of the Mono team are thinking in these terms but that Anders is involved personally in this as the language designer.

I'm happy about the C# 4 features although I would have liked more (like readonly automatic properties, an option to ignore out parameters by passing null or actual *class methods* that could be snuck into interfaces the way statics can't), but between MEF, tuples, PFX and Contracts I'm very well served by the framework improvements.

I hope everyone working on .NET are taking a second to pat themselves on the back these days. Good work!

re: The Future Of C#, Part Five

Jeremy Gray — Sat, 08 Nov 2008 02:57:02 GMT

@ Eric re: immutability and your comment of "These things take time. A major factor in the design of work for multi-cores is that there is not a consensus in industry or academia as to what the right thing to do is." I'm afraid I have to disagree. If there were to be one and only one very well-agreed-upon piece of consensus in both industry and academia, and that is that regardless of what other open issues there are around parallelism (and I admit there are plenty), it would be that the ability to declare and ensure immutability is an incredibly good thing when making any effort to go parallel, and for a myriad of reasons. And that's totally ignoring the benefits that immutable types can have even when not trying to go parallel, if only for managing side-effects in order to produce predictable behavior.

Bringing VB.net features into C# at the expense of features dedicated C# users have long been begging for (eg. non-nullable reference type variables and arguments, immutable types, etc.) is not exactly going to win any favour. Personally, I am trying as hard as I can to be happy with the gift of generic variance goodness, but it is not unlike being a child at Christmas in that it can be hard to enjoy the one good gift you might receive when you look around and all of your other gifts were grandma sweaters. ;)

re: The Future Of C#, Part Five

Patrick Lioi — Sat, 08 Nov 2008 07:23:56 GMT

This is tounge in cheek, but the truth: "*Please* fundamentally change the way I think about programming every couple years!"

re: The Future Of C#, Part Five

Jay Bazuzi — Sat, 08 Nov 2008 07:52:28 GMT

I don't think that Eric intended this post as "what features do you wish we were adding in C# 4.0?", but I'm not going to pass up the opportunity to

answer that question anyway. :-)

1. Syntactic sugar for immutable data classes.

Today, if I want to make a data class, I can either take the easy route (autoprops + no ctor + object initializers), or the safe way (autoprops with private setter + ctor full of tedium + no object initializers allowed), or the very safe way (tedious get-only properties + 'readonly' fields + ctor

full of tedium + no object initializers). In the very safe way, the property/field name is mentioned 6 times, which violates DRY.

C# 4.0's named parameters reduces the need for creating multiple ctors, but the ctor is still as tedious to write as before. It also makes the "safe" and "very safe" models nicer at the call site. But I don't see anything that makes the *implementation* any nicer, so I still have to decide between easy and safe. A language change could create a "pit of success", where creating immutable data types is easy, too. (See, I said "pit of success", so now Rico will make you do it.)

2. The ability to refer to 'this' in field initializers.

I often refactor a larger class in to several smaller classes, where each one exists as a field with a specific responsibility but needs to find its way back to the main object. As the language is defined today, I have to initialize these fields in a ctor, while other fields get initialized in field initializers, making my code inconsistent and bug-prone. There are also a few patterns for converting enums to objects that are either awkward or impossible because of this language limitation, but would be great for code structure otherwise.

In both cases, it seems like a few very small changes to the language would be a big benefit, at least to me.

Eric, if you want to understand more about my thinking, drop me a mail.

re: The Future Of C#, Part Five

Lars — Sat, 08 Nov 2008 16:32:58 GMT

Just keep to the list and everything will finally be as great as it once was :)

http://www.paulgraham.com/diff.html

New and Notable 277

Sam Gentile If (DeveloperTask==Communication && OS==Windows) — Sat, 08 Nov 2008 19:49:45 GMT

jQuery/ASP.NET/ASP.NET AJAX/ASP.NET MVC Visual Studio patched for better jQuery IntelliSense . Yes! Steven

re: The Future Of C#, Part Five

RichB — Sat, 08 Nov 2008 19:55:36 GMT

> "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.

Great - so I can now call a base class method from an iterator/anonymous method in a derived class? You can't have 'fix things' as a theme unless you fix this glaring inconsistency.

re: The Future Of C#, Part Five

Patrick Smacchia — Sat, 08 Nov 2008 21:26:09 GMT

Aside the parallelism/mutability theme, which will be important anyway, another good theme for C#5 could be System.Diagnostics.Contract syntax support at language level.

re: The Future Of C#, Part Five

Tanveer Badar — Sun, 09 Nov 2008 01:28:35 GMT

If I had 100 bucks to spend on various features coming in 4.0+, I would add 10 of my own and put the bet on metaprogrammability.

re: The Future Of C#, Part Five

Eric Lippert — Sun, 09 Nov 2008 04:16:31 GMT

Re: calling base methods from anonymous methods: Yes, we fixed that.

re: The Future Of C#, Part Five

int19h — Sun, 09 Nov 2008 11:58:56 GMT

Given that BCL guys are introducing DbC ("code contracts") in .NET 4.0, at the library/instrumentation level for now, it would seem logical to me to extend this to full-fledged support on language level (the library-only solution can be rather quirky syntactically - just look at the pains one has to go to write a contract for an interfaec).

re: The Future Of C#, Part Five

Ian Marteens — Mon, 10 Nov 2008 03:52:07 GMT

<i>2. The ability to refer to 'this' in field initializers. </i>

That would be very dangerous, as you need to take evaluation order into account. As a matter of fact, I even doubt CLR would admit it... at least, if you implement it as "normal" field initialization (I mean, before calling a base constructor).

Instead, I should provide fileld-like initialization for automatic properties.

re: The Future Of C#, Part Five

Igor — Mon, 10 Nov 2008 08:29:20 GMT

Eric, if you are looking for ideas how to enable metaprogramming in C#, you should look at Nemerle where it is already done. See the following links - http://nemerle.org and http://nemerle.org/Macros

For example, Nemerle does not have if-else statement, but it defines it as a macro using quotation operator <[ … ]>

macro @if (cond, e1, e2)

syntax ("if", "(", cond, ")", e1, Optional (";"), "else", e2)

{

match ($cond) {

| true => $e1

| _ => $e2

}

re: The Future Of C#, Part Five

yumi — Mon, 10 Nov 2008 08:56:55 GMT

You need to take a look at Nemerle language (nemerle.org) for .Net. It's something like

superset of C# language with minimal core. All other features like foreach, if then else etc

made with macro-system. Its something like right Lisp for .Net :) This language now actively

supported by RSDN community. I hope that you fill find new fresh ideas about how to add

metaprogramming at C#.

re: The Future Of C#, Part Five

ggreig — Mon, 10 Nov 2008 12:46:32 GMT

While I'm sure that a meta-programming solution specifically designed for the purpose could be "better" than C++ templates, I would hope that the design would be such that it would be possible to transfer some of the years of community and personal experience from C++ into C#, given the relatively close relationship of the languages.

re: The Future Of C#, Part Five

Jon Skeet — Mon, 10 Nov 2008 13:21:31 GMT

I'd just like to add to Jesper's plea (and Jay's, indirectly) - readonly autoprops would be a significant win from my point of view, *and* give us at least an *easier* route to immutability. I can't see that it would be very hard, either - although I'm aware that what seems simple often isn't, and *any* change requires design work, etc.

Basically I'd just like to extend automatic properties such that:

public string Foo { get; readonly set; }

expanded to:

private readonly string <>_Foo;

public string Foo { get { return <>_Foo; } }

and any assignments to the property within the constructor (the only place they'd be legal) were transformed into assignments to the variable.

That, combined with the named parameters of C# 4 would make creating immutable types a lot easier. I'm happy to wait for really good support of immutability complete with a declarative syntax and compile-time checking - just help us this one little bit :)

(I suspect C# 4 is too locked down to allow anything new in at this point, but if there's the slightest chance of getting readonly autoprops, I'm happy to campaign hard for them :)

re: The Future Of C#, Part Five

stefan.wenig — Mon, 10 Nov 2008 16:24:31 GMT

Jon,

agreed, but there's more: one of the useful feature combination for C#3 was the ability to create simple classes with automatic properties only, without special constructors only using object initializer syntax for instantiation. Now can we have object initializers for immutable objects too, please? I know I'm borderlining the impossible here, because object initializers are just property assignments _after_ the default ctor has been executed. (But in case of a generated default constructor, would that make any difference? OK, maybe it would, because the class might have base classes, and depending on their being auto-generated would be a mess.) But still, getting object initializer syntax for immutable objects would do a lot to reduce code for trivial types _and_ promote immutability.

How bad would it be to have "readonly" in automatic properties mean "write only via initializers, ctors or object initializers"?

In some cases this might result in bad things, but how important is it to support the concise automatic property syntax with the proposed readonly extension for those cases? shouldn't simple things be simple, and hard ones merely possible?

But then again, this might be too surprising for average C# users who don't make it their hobby to study language specs. Just an idea, not thought through.

Stefan

re: The Future Of C#, Part Five

Jon Skeet — Mon, 10 Nov 2008 17:37:53 GMT

stefan: With optional and named parameters, you can get object initializer *style* instantiation just with a constructor. The nice thing about object initializers is that they're just translated into standard property accesses - it's pure syntactic sugar. When you break that connection, it becomes tricky.

I have other suggestions around immutability and object initializers, using builder objects, but that's a different matter (and Eric's already got that suggestion somewhere in his inbox - I'm neither expecting nor requesting any movement on that front).

I'm hoping that the less we ask for, the more likely we are to get it :)

re: The Future Of C#, Part Five

stefan.wenig — Mon, 10 Nov 2008 18:00:56 GMT

John: you're right, you can get the syntax, but if you include the class definition into the calculation, it won't be nearly as concise. Declaring an immutable class with n properties in n+1 lines (not counting curly braces) would be just great. Yes, this might still be a bad idea in the end, but without seriously discussing it we will never know. I did not ask for it though, it's just an idea.

re: The Future Of C#, Part Five

Thomas Eyde — Tue, 11 Nov 2008 02:42:41 GMT

I wonder when

var c = Click;

if (c != null) c(this, EventArgs.Empty);

will be fixed.

re: The Future Of C#, Part Five

Eric Lippert — Tue, 11 Nov 2008 02:52:51 GMT

You haven't said what's broken.

re: The Future Of C#, Part Five

Jay Bazuzi — Tue, 11 Nov 2008 07:58:50 GMT

To make my life simpler, I initialize my events like this:

event EventHandler Click = delegate {};

Now I don't have to worry about null checks & temporary local copies. Just

Click(this, EventArgs.Empty);

re: The Future Of C#, Part Five

Asad Siddiqi — Tue, 11 Nov 2008 19:24:31 GMT

*Please* Dont change the way everything works every year. .Net 1.1 to .Net 2.0 was absolutely OK since the basics were almost the same and it was a smooth transition. .Net to .Net 3.0 is a bit painful for the small scale windows applications developer (Based on WPF and not on windows forms) Yeah I know there is a whole lot more functionality to it and its very very powerful , so OK.

But please dont change the internal architecture every year, everytiume you do that you looses developers and it is hard to keep up with all the technologies.

I think including specialized development tools for targetted developers would be a better idea than to change the architecture totally. I am a fan of microsoft development tools and have been using them since 6 years and I only have admiration for them which started with VC++ 5 to .Net 3.5 .

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 (As we dont get the chance to develope with the latest all the time due to client restrictions , hardware restrictions e.t.c. )

I hope I was able to present my point of view !! I really love development and Microsoft but doesnt want C# to become "Ruby on Rails" . So please dont take all the code away and leave it to configurations, configuring is a whole new language for the developer which is difficult to understand without the underlying architecture which is changing all the time.

re: The Future Of C#, Part Five

Thomas Eyde — Tue, 11 Nov 2008 23:36:15 GMT

@Jay: Nice hack. I've forgotten that one.

@Erik: The whole observer pattern is broken. The whole point with this pattern is to broadcast information to anyone interested, without knowing how many they are.

The way events are implemented we have to resort to hacks, as Jay suggests, or we have to check if anyone is really there.

The much needed null check proves the abstraction is leaky. The need for a temporary variable proves it's not safe.

All the repetitive code we have to write should have been done by the framework.

re: The Future Of C#, Part Five

Mark Rendle — Wed, 12 Nov 2008 14:35:20 GMT

@Asad: very few of the changes to C# and the BCL are breaking changes. There's no rule that says you have to use WPF, or LINQ, or any of the (incredibly cool) new things that have been added over the last 7 years. And you can pick and choose the ones you do use; my project is still on Windows Forms but makes extensive use of LINQ.

The fact of the matter is that the software development world is moving very fast at the moment, and C#, as a leading citizen of that world, is obliged to at least try and keep up. Hence the dynamic support in C# 4.0, PFX and Contracts in .NET 4.0, and meta-programming coming in a later C#.

Personally, I've found that the new models, patterns and capabilities in each version of C# have made me a better programmer by changing the way I think about the way my code.

As the saying goes, it's better to have something and not need it than to need something and not have it.

re: The Future Of C#, Part Five

VladD2 — Wed, 12 Nov 2008 16:15:43 GMT

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?

re: The Future Of C#, Part Five

int19h — Thu, 13 Nov 2008 10:26:04 GMT

> 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.

re: The Future Of C#, Part Five

Kor Nielsen — Fri, 14 Nov 2008 06:44:24 GMT

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

re: The Future Of C#, Part Five

Néstor Sánchez — Fri, 14 Nov 2008 19:05:21 GMT

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)

re: The Future Of C#, Part Five

Marcel Popescu — Tue, 18 Nov 2008 22:59:42 GMT

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?)

re: The Future Of C#, Part Five

int19h — Wed, 19 Nov 2008 09:23:23 GMT

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

re: The Future Of C#, Part Five

Jon Skeet — Wed, 19 Nov 2008 13:22:08 GMT

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.

re: The Future Of C#, Part Five

int19h — Fri, 21 Nov 2008 12:57:38 GMT

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!

re: The Future Of C#, Part Five

Halo_Four — Fri, 21 Nov 2008 16:48:46 GMT

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.

re: The Future Of C#, Part Five

Mike Adkins — Tue, 25 Nov 2008 18:35:23 GMT

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.

re: The Future Of C#, Part Five

Fred Derf — Sat, 29 Nov 2008 08:25:25 GMT

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

re: The Future Of C#, Part Five

Ted — Mon, 01 Dec 2008 21:10:51 GMT

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.

re: The Future Of C#, Part Five

jemiller — Mon, 01 Dec 2008 22:43:00 GMT

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.

re: The Future Of C#, Part Five

Wes — Tue, 09 Dec 2008 03:27:53 GMT

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.

re: The Future Of C#, Part Five

shawn — Tue, 16 Dec 2008 23:56:34 GMT

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)!!!

re: The Future Of C#, Part Five

Ionel Munoz — Wed, 17 Dec 2008 20:40:06 GMT

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.

re: The Future Of C#, Part Five

Reynard — Sun, 21 Dec 2008 08:52:46 GMT

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

re: The Future Of C#, Part Five

SEO Elite — Sun, 21 Dec 2008 09:34:11 GMT

Thanks for the informative article

re: The Future Of C#, Part Five

DevExec — Mon, 22 Dec 2008 09:56:23 GMT

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.

re: The Future Of C#, Part Five

°(n.n)° — Tue, 23 Dec 2008 02:30:14 GMT

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...

re: The Future Of C#, Part Five

Vijendra.1007 — Tue, 23 Dec 2008 15:01:46 GMT

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.

re: The Future Of C#, Part Five

Masum — Tue, 23 Dec 2008 15:22:28 GMT

Microsoft should provide more example soruce code with new release.

re: The Future Of C#, Part Five

Jeff Lewis — Sun, 28 Dec 2008 01:30:28 GMT

"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.

re: The Future Of C#, Part Five

SkyBeaver — Mon, 29 Dec 2008 18:22:42 GMT

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".

re: The Future Of C#, Part Five

Néstor Sánchez — Mon, 29 Dec 2008 21:44:37 GMT

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.

re: The Future Of C#, Part Five

Andrew Ducker — Wed, 31 Dec 2008 00:29:31 GMT

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.

re: The Future Of C#, Part Five

K Ray — Wed, 31 Dec 2008 17:37:14 GMT

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'?

re: The Future Of C#, Part Five

Edgar — Wed, 31 Dec 2008 22:59:54 GMT

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

re: The Future Of C#, Part Five

jyr — Fri, 02 Jan 2009 12:45:10 GMT

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);

};

}

re: The Future Of C#, Part Five

GuyO — Sun, 04 Jan 2009 15:40:12 GMT

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).

re: The Future Of C#, Part Five

Joe Reddy — Mon, 05 Jan 2009 20:29:17 GMT

I know Microsoft likes to go for the grand and the exciting, but how about more practical stuff?

I don't have the largest developers circle, but I know of absolutely no one in a circle of 50 or so who uses LINQ, or cares about binding to anything on a user interface, etc.

How about something as simple as an optional compiler warning telling me when an argument is not being used in a method, or if the value returned by a method (function) does not have a variable assigned, etc.

And ditto what Sky Beaver said.

re: The Future Of C#, Part Five

Brian Womack, PhD — Mon, 05 Jan 2009 21:39:00 GMT

I'd REALLY like to see support for generic classes and operators as first class entities. To see what I mean, try to write a generic class for Matrices that support all operators you might want to overload: +, -, *, /, ^. This is not allowed in C# 3.0. You end up creating two copies of the class for float and double.

I believe this can be done with a 'where' clause in the class declaration that lets you list the types supported: i.e. where T is float, double, int, long, uint, ulong.

re: The Future Of C#, Part Five

Svavar — Tue, 06 Jan 2009 18:11:08 GMT

I'd like to put my vote in for parallelism (however it's implemented).

Quad core processors will be ubiquitous in the next 12 months (if not sooner) and dual-quad as well as 6 & 8 core processors are just around the corner so I'd say parallelism is already here.

re: The Future Of C#, Part Five

Thomas — Fri, 09 Jan 2009 19:56:36 GMT

I love the extensions for 3.0, I hope the extensions for 4.0 get just as good!

@other Thomas & Jay. In C# 3.0 this can be done very nicely like so:

Extension method

public static class EventStuff

{

public static void Raise(this EventHandler handler, object sender, EventArgs args)

{ if (handler != null) handler(sender, args); }

//and others

}

and call your events like this

{

public event EventHandler MyEvent;

protected virtual void OnMyEvent(EventArgs args)

{ MyEvent.Raise(this, args); }

}

In this way you don't waste memory and CPU time.

Personaly I'd realy like a non-nullable reference type. Something like:

object! x = null; //generates an exception

And an extended coalesce operator. possibly:

int x = a.b.c.d.e !! 0 ; //x would become 0 if any of a, b, c, d or e would be null.

Treat lambda's, delegates and methods like values properly.

So that their hash values don't only depend on the signature and delegates generated with the

same code tree can be sensibly compared for equality.

re: The Future Of C#, Part Five

Reineir Post — Mon, 12 Jan 2009 12:15:40 GMT

GuyO: nooo! Now I can read assignments and understand what they mean without having to be familiar with the classes involved. Please, C#, keep it that way.

re: The Future Of C#, Part Five

Robert Goerss — Thu, 29 Jan 2009 21:12:43 GMT

Interesting article, Eric.

Finding the happy medium between sweeping change and stagnation is a consideration that we are all faced with as developers regardless of who our target audience is. I found it surprising to hear just the extent of this issue as it relates to further C# development given the relatively advanced target audience that your team has. It prompted me to share some of my own thoughts and perspective on the topic as someone whose target audience is often not even computer literate: http://icrontic.com/forum/blog.php?b=115

Regards,

Rob

re: The Future Of C#, Part Five

Nick — Wed, 25 Feb 2009 15:36:15 GMT

Virtual Constructors would be real nice.

Pity Anders didnt bring this concept in from Delphi.

re: The Future Of C#, Part Five

Lee Grissom — Wed, 25 Feb 2009 23:51:03 GMT

To build on top of what Nick said, "Virtual Class Methods" would solve a few problems that I've had over the years with C#. I could then do virtual static classes. Anders Hejlsberg designed this capability into Delphi, so I'm curious as to why it has been omitted from C# for so long.

re: The Future Of C#, Part Five

Peter Herschel — Thu, 05 Mar 2009 17:39:01 GMT

Disposal

I'd love to see the need for directly calling Dispose() go away. So much code plumbing code in such an advanced language! There must be away to improve this whole issue. Maybe Dispose could be called automaticlly.

That's what the "using" statement is for -- Eric

Object Oriented

I'd love to see improvements in the language that help limit scope. Example: class fields that are used to serve up properties.

How is that different from auto props? -- Eric

Deterministic Lifetimes

A language feature to add to a class? Is there a role in C# for this concept and still maintain performance.

That's what the "using" statement is for -- Eric

Revisit Existing Features

There is a tendacy to forget about features that were released in previous version. These are often the basis for much of the languages use:

* SqlClient
* Forms
* Click Once
* Crsytal Reports

These would greatly benifit from some updating.

Sure. But none of those are language features. -- Eric

-Pete

re: The Future Of C#, Part Five

mastermemorex — Tue, 17 Mar 2009 19:40:57 GMT

A scope about the popularity of different programming languages can be found here:

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

In my opinion that improvemets, although interested, unlikely sky rocks today's low popularity of C#. I would like to change "please stop fundamentally changing the way I think about programming every couple years!" for "please stop telling me what you think is the best way of programming and give me a language for programming the way I would like". In my opinion, any improvement that is not stick with the best performance is not worthly enough.

I would like to see solved "the struct pointer juju problem"

static void Foo<T>(T value) where T is struct

{

uint size = sizeof(T); //Error 1. Cannot take the address of, get the sizeof…

}

This is a basic and large demanded feature that of the language. Also some level of inheritation of fields for structures would be a huge improvement of the language.

re: The Future Of C#, Part Five

Alan — Mon, 06 Apr 2009 04:36:16 GMT

We are witnessing a machine processing performance explosion in action today and over the next few years it is set to accelerate - increasing core count, Larabbee etc are prime examples. The days of boost via GHz uplift are gone. One (not the only one I grant you) of the historic arguments for C and C++ over C# and other CLR based languages has always been their efficiency. For many classes of applications this advantage is likely to shift more from code level efficiency to who can best implement optimisation at the higher level - i.e. Parallelism. In future, performance optimisation effort in developing our applications may possibly be best spent at this level and it will need best of breed support to do so.

At a lower level, for some classes of application the parallelism boost will also come from wide vector SIMD processing - 128 bits on today's CPUs and 512 bits on Larrabee I'm lead to believe - and how long before it is made wider on mainstream CPUs? This is currently completely ignored by the CLR targeting languages including the CLR version of C++ - why?

The battle ground for future Applications winning or losing may well be fought over who best leverages these increasingly accelerating processing resources. I actually like what some have described as the "boutique" C# language changes, but I am also fearful for C#'s future - if it cannot provide ease and reliable leveraging of the huge processing potential, then C# apps will fail to compete in both the applications generated from it and C# will fail in its battle with the other languages.

My customers do not care if my staff are using Linq under the bonnet to talk to the database or internal data or not, or using the latest Generic Constructs, or more elegantly implemented patterns. They will care when my competitors reliably bring out a 5, 10 or 20 (in 10 years?)... times performance boost. I have always liked C# as a developer and C# for its productivity as a company owner, and I have always hated the fact that it always plays second fiddle to C and C++ for crunching power and perceived performance.

I appreciate the new "Parallel For" etc, but the C# team (and CLR and VS team) need to continue to heavily invest effort in parallel processing leverage (coding, debugging, parallel processing run time analysis etc) and although I appreciate that C# (and CLR) have some of its roots in the "safe programming" and metal independent paradigm, I would really like to see it recognise the blossoming SIMD capabilities of the hardware.

Let's put on hold for a little while some of the more " boutique" or "ivory tower" language changes and really arm C# with the weapons for the performance battle that is coming.

re: The Future Of C#, Part Five

Bryan — Fri, 28 Aug 2009 21:15:08 GMT

@mastermemorex: you can do this:

static void Foo<T>(T value) where T is struct

{

int size = Marshal.SizeOf(value);

// or Marshal.SizeOf(typeof(T));

}

re: The Future Of C#, Part Five

ShuggyCoUk — Tue, 15 Sep 2009 20:23:40 GMT

* non nullable types backed into the language would be the biggest win for me. (I would favour a compiler switch to move a project to not nullable by default and then allow the ! syntax (or ? for consistency with Nullable, albeit perhaps with confusion so ambivalent there) for nullable parameters and variables.

* After than enum constraint (though Jon's unconstrained melody might work around that for quite a few scenarios)

* generic constraints on static operators will full JIT optimization down to specific instructions for native types