0
One thing I've always wanted to see is an unmanaged version of C# which doesn't use a garbage collector but another approach, such as reference counting, to destroy unused objects.
There is in fact a language called Vala, which uses C# syntax, currently under development and I wrote an article about it earlier this year:
http://www.c-sharpcorner.com/UploadFile/b942f9/5986/
I'd have liked this language better if it compiled to C++ rather than C code as that would have enabled method overloading, operator overloading and other stuff which is inconsistent with C, whilst still keeping it 'cross platform'.
Whether this language will catch on remains to be seen but it does show early promise.
0 The problem is that C# is defined as being dependent on the CLI. Certainly it is not all of .Net but the dependence of C# on the CLI causes C# to be not independent of .Net.
0 I'd draw a distinction between changes to:
1. The C# language itself
2. The .NET framework and associated APIs
3. The IDEs and tooling.
It seems to me that the changes to #1 are relatively trivial compared to the seismic shifts in #2 and #3 over recent releases.
Worse still, there's now going to be yet another seismic shift in #2 and #3 to support Metro applications under Windows 8.
Now, there is a view among some developers that C# 2.0 was optimal and that LINQ, dynamic and async/await are just 'syntactic sugar' which you can (and, indeed, should) ignore. That's fair enough and, as long as future changes to C# always preserve backwards compatibility, I don't see any reason why developers who believe this can't co-exist with those (like me) who don't believe you can afford to stand still.
However, it's clear that asynchronous operations are going to be a major part of Metro programming and you're certainly going to struggle with that if you don't use async/await.
0 This is exactly the point I am making what Dipal just said. I raised this question at the MVP Summit when MS speaker asked what they should do about the releases. My feedback was to release a major version not before every 2 years (Language, Visual Studio etc). But there are too many APIs, new versions, new features so it is difficult to keep up.
I see developers using Visual Studio 2010 but still not using any new features introduced in C# 2.0 or later. This is because they did not have enough time for the migration (learning curve). I still see 80% of developers do not use new features.
I believe, MS needs to slow things down. They add a few new features and call it a new version :).
0 there was a time when C++/Visual C++ was used for "serious" apps and Visual Basic was the tool for 'quick' apps. VB was commercial level - just so much faster to churn out apps.
we need something like that - a VB# for quick and dirty development and C# for deeper development. the versions of vb.net and c# have run almost neck-to-neck..
i think in some ways, atleast someone from MS has similar views as Mahesh's OP - they do introduce products such as LightSwitch for "simplified" development.
i would love to get a time machine which holds time stationary for a little bit, so i can take a breath and catch up with all that's out here.. (not just talking abt C# here ;))
0 I used the example of C++/CLI because it's the only version of C++ which is directly comparable with C#.
I agree that destructors in standard (unmanaged) C++ are probably as good as they can be.
0 The design of destructors in the C++ standard language is vastly different from the C++/CLI syntax for a destructor (IDisposable) and a finalizer (C# destructor). Destructors in the C++ standard language are simple and precise.
Note that my reply was worded to avoid saying that the C# language is not documented; I said explicitly "I am not saying that the C# language documentation is not adequate".
0 0 Of course they won't do what I say, but in my opinion they should stop developing the language, at least temporarily.
They should stop and document what they have already done. I am not saying that the C# language documentation is not adequate, but there is much more of what they have done that is not clearly documented. Of course if they document everything better, then there will be less need for C# Corner, but I think there will still be abundant opportunity.
The other reason I think they should stop developing C# is so they can allow greater peer review and such. People complain that improving C++ takes years, but C++ is better because of the peer review and involvemnent. I think that some things about C# and .Net (probably .Net mostly) are not designed well, such as IDisposable and related designs.
Certainly there is value in improving C# and .Net, but there is also some significant baggage that would be better left behind somehow.
0 This is a non stop business for Microsoft. As Vulpes said even though there is no major updates happens, still they release a new version every two year. Am still having projects of VS 2005 and VS 2008. Now VS 11 already in beta.
0 Personally, I don't think so.
If there are features which developers really want and which are consistent with the rest of the language, then they should try and add them. If they don't then C# will stagnate and loose ground to other languages.
Of course, they only have so much time between releases and considerable work is needed to add even minor features if backwards compatibility is to be maintained. So, they're only going to add stuff which has a high priority and/or fits in with the 'big theme' of the next release.
It looks like async/await will be the only major feature added to C# 5.0 (there was some other minor feature but I can't remember what it was) and that 'compiler as a service' will be the centrepiece of C# 6.0.