C# 3.0

A bit too early but this is an excellent introduction to what is coming
http://blogs.tedneward.com/2005/09/22/Language+Innovation+C+30+Explained.aspx

Just wondering what all people think of the additions mentioned above. Personally, I was thinking it seems these features might make code harder to read, because of lots of thing moving to the compiler rather than in the code. Note, how much automatic conversion of code to classes and run-time assigning of types to variables is being added. Will it not lead to more run-time errors? Is not it better to have intentions clear in the code, rather than compiler interpreting them?

Frankly, I have zero experience with such features and I am not even sure if there are any languages with such features. Personally, I do not care what code is their in IL ( OK, for performance reason that matters.), I mostly write the code to be readable, and for maintainance.

-cw

I went to a VS User Group meeting last night and there was short presentation on C# 3.0. Here is what I have learned so far:

1. Object is first class and you won't see much ADO.NET in code. This concept is not new because there are already many ORM out there like LLBGen, NHibernate and many more. The difference is that it kind of mixing the familiar SQL syntax right into the language which is not favorable to some people, but praise by many. Overall, it's not bad in my opinion.

2. The good thing I like about it is you can catch errors at compile time that I think is very cool. Current SQL statement can throw a nasty run-time exception which is not cool at all

3. I didn't ask the question regarding to the famous error "Type impedance mismatch" I have heard that this would solve this annoying problem.

4. You can extend it like the way you extend your classes.

This C# 3.0 sounds very exciting. The question is whether we have enough times to learn what's coming in VS 2005 before this thing pops up in our face again.

actually, for anyone who's been through a computer science course, stuff in C# 3.0 is really exciting. Concepts like closure and dynamic implicit typing are really nothing new if you worked on functional programming language before. It's more like a 'homecoming' than seeing a strange beast wandering into the cozy house of drag-and-drop programmers. What's cool is that now Microsoft is implementing these exotic constructs in a commercial language.

Of course there will be people out there lamenting that C# is becoming like C++; getting more and more exotic and hence complex. However, from a semantic point of view, imperative languages do not increase their expresive power from these exotic features. Therefore, it's possible to stick to the existing features only.

Hmm... are you guys talking about LINQ or C# 3.0? Do take note that LINQ is also available in VB.NET and it is not  specific to C# alone.

codewhiz wrote:

A bit too early but this is an excellent introduction to what is coming http://blogs.tedneward.com/2005/09/22/Language+Innovation+C+30+Explained.aspx Frankly, I have zero experience with such features and I am not even sure if there are any languages with such features. Personally, I do not care what code is their in IL ( OK, for performance reason that matters.), I mostly write the code to be readable, and for maintainance. -cw

Agree with you here.  I saw the part on "Implicitly typed variables", and it seems like we are falling back to VB6.0 and ASP days. Although there is no performance penalty here, as the IL is the same; what about code readibiliy and maintenance?  Is taking type instantisation decision away from developer a good thing?

I remember my first project that I took over.  I couldn't understand much of the previous developer's design intention, as there was no data type. Debugging was hell.

Cyrus Crypt wrote:

Agree with you here.  I saw the part on "Implicitly typed variables", and it seems like we are falling back to VB6.0 and ASP days. Although there is no performance penalty here, as the IL is the same; what about code readibiliy and maintenance?  Is taking type instantisation decision away from developer a good thing? I remember my first project that I took over.  I couldn't understand much of the previous developer's design intention, as there was no data type. Debugging was hell.

i think you're mistaken about implicity typing versus dynamic typing. What becomes available in C# 3.0 is not dynamic typing. So what is dynamic typing? Simply put, the type information is evaluated as runtime instead of compile time. So why is that a problem? Well, the compiler will not be able to catch wrongly written statements like
    var abc = "hello"; abc /= 2
This is why your code maintenance task became hell. However, in C# 3.0, implicit typing is a different thing. It means the type of variable is inferred from the context, at compile time. I also infer that this is done using unification.

Looking at this, can anyone tell me if the type of abc can be anything other than System.String ? (or string for C# purists for that matter)
       var abc = "hello"
Therefore, the type of abc is now implicitly and statically determined as System.String. The litmus test of static/dynamic typing in Orcas can be done by pressing that magical "." and see if you have Intellisense springing into action.

I think we all here understand the automagic happening here. You will get compile time errors. But what about understanding the code?Most of the time you will be using that feature not to instantiate variable like var i =0; but while return values from other functions and this feature might tend to be used in more laziness than rather good design-wise or productivity. Generics to me seem like a great addition, though implicit typing does not seem like so. It seem technically cool and thats it. Probably c# with version 2.0 reached 90% stage and 10% of problems are left. Maybe, such features should be add-ons and left to specialized groups (Read SourceForge projects) and not part of core language.

I am not very much in touch with recent developments, last I heard Java was taking different tack of making a language or add-on called Groovy with a different set of features, more closer to functional languages. That sounded like a good idea though not sure when it will bear fruit.
-cw

codewhiz wrote:

I think we all here understand the automagic happening here. You will get compile time errors. But what about understanding the code?Most of the time you will be using that feature not to instantiate variable like var i =0; but while return values from other functions and this feature might tend to be used in more laziness than rather good design-wise or productivity.

Thank you CodeWhiz for elucidating my point. 

Feelite, you're arguing a different point.

ok, i don't really get your point about the complex scenarios that are incomprehensible. love to see an illustration about that.

on code readability, i agree that the most readable code will be those that are explicitly type and commented. but somehow, this concern is addressed by modern IDEs. remember the horror of seeing

Dim strError as String

the first time you read VB code? The thinking is that putting type information in variable names gives programmers more hint of what they are dealing with. But that goes exactly against the convention that type information is deducible from OO languages. Language paradigm changes, but old habit die hard. Even today I still consistently run into VB code that are prefixed with these little hints although the C# world is much cleaner. Similarly, new language constructs might be alien in the beginning but they come into being for a reason, especially when it's done with shareholders' money. :)

I agree with feelite here. var i = whatever type you assign on the right side. It can be an object, data from database, or simply a string. It's dynamic in the coding content and strong type in the compiling content. The beauty is that after the assignment, you can't simply reassign it with a different type. The compiler will enforce the strict rule. Generic behaves in a similar fashion. Please correct my statement if anyone find that it behaves differently because I'm learning it too.

I especially like the lambda expressions. Imagine this:

 //returning even numbers

List<int> arrInt=new List<int>{1,2,3,4,5,6,7,8,9,10};//new functionality in .NET 3.5

in .NET 2.0

List<int> evenInt=arrInt.FindAll(delegate(int i) { return i%2==0;});

 in .NET 3.5

List<int> evenInt=arrInt.FindAll(x=>x%2==0);

 

 

i love those List<T> methods... all we need are more extension methods and probably .NET collections can finally be at par with Smalltalk collections