The Future of C#

[imported_Dhaval00]

Part One

New Feature: dynamic
Part Two
I liked the bit about "Thread Happiness Disease" - quite reflective. His take on OOP is also enlightening.

Part Three: Video 1/2
Part Three: Video 2/2
From the videos it seems they're already at the helm of releasing C# 4.0.

Part Four: Video 1/1

Part Five

 

[SoundTheSurrender]

Cool. I wish I understood most of it. I'm a noob.

 

[imported_Dhaval00]

Originally posted by: SoundTheSurrender
Cool. I wish I understood most of it. I'm a noob.

I am sure you'll get there some day (soon I hope).

 

[brandonb]

So they are basically resurrecting the variant data type?

 

[Markbnj]

They already did that with the var type in C# 3. Basically 95% of this stuff is needed to support LINQ. I'm not sure I'm entirely thrilled with seeing more and more loose typing and dynamic binding making its way into the language. Would be interested in how others view this.

 

[imported_Dhaval00]

Well, IMO, their idea of making types dynamic works on paper and works practically, too, but I am most interested in finding out how it impacts the performance at run-time. I am a fan of the "generic host/multiple plug-ins" architecture, so seeing contravariance and covariance 'types' is good news. We can do this right now, but we still have to stick to interfaces and reflection - which is not bad at all, but another idea that they're trying to sell is this will make COM Interop easier... Overall, I am grateful that they listened to the developer community to slow down the release cycle and give us more time to learn all the crap they already have on the market.

I still think extension methods were a hack to make LINQ work - much like the Java hack of replacing specific objects with generic objects to make generics work (I don't know much about the internals of Java, so someone correct me if I am off the mark on this one).

 

[Markbnj]

I still think extension methods were a hack to make LINQ work - much like the Java hack of replacing specific objects with generic objects to make generics work (I don't know much about the internals of Java, so someone correct me if I am off the mark on this one).

Absolutely true, as far as I am concerned. It's all a set of hacks to allow the results of inherently dynamic and loosely-typed SQL queries to be manipulated as objects at runtime. There was an interesting comment from Lippert in one of the pieces linked above, to the effect of "Don't get all OO-happy on us; we're not about creating the purest language, but rather one that helps our customers get stuff done."

I hear that, and the days when I enjoyed language-lawyering are long gone. But I still feel that every relaxation on the constraints of a strong static typing system introduces potential for errors at runtime that are difficult to pin down. So, if you buy that POV, then you look at LINQ and ask whether it is worth driving all these workarounds in the language? I never had a problem with integrating SQL into my applications, and in fact I like that there is a clean separation between the app, and the stuff that makes the database go. They're different animals.

I have a feeling that the main effects of LINQ will be to make database interaction more approachable for some people (good); while at the same time making it harder to perceive the differences between the layers, to clearly distinguish the code that moves the data back and forth from the app logic (bad).

And on the other hand I have a ton of respect for Microsoft's language designers and .NET platform architects, and a lot of people really dig LINQ, so I may just be an old curmudgeon on this one. Maybe not so different from the C guys I was trying to teach C++ to back in the 90's .

 

[Gunslinger08]

Constantly being on a deadline and not wanting to read more about work after I get off, I'm very happy that they've decided to slow down on releases. I just don't have the time at work to learn about all of these new features and put them to good use when they keep getting added so quickly. I'm just now starting to use LINQ appropriately.

 

[JasonCoder]

Originally posted by: Markbnj
They already did that with the var type in C# 3. Basically 95% of this stuff is needed to support LINQ. I'm not sure I'm entirely thrilled with seeing more and more loose typing and dynamic binding making its way into the language. Would be interested in how others view this.

No. The VARIANT data type was essentially a huge UNION. Used almost exclusively in IDispatch. The var keyword instructs the compiler, not the runtime, to infer the type of a variable. The end result IL looks exactly as if you had strongly typed the variable to begin with. No perf hit, no ugliness dealing with VARIANT bullshit.

Personally I think database integration at the language level could have stopped with Nullable<T>. That's all it took to avoid the SqlTypes namespace and magical mystery numbers that represent nulls. This is after using LINQ on several projects now. Then again LINQ is pretty powerful - composable query trees, etc. is a cool way of doing things. It isn't terrible but LINQ to SQL was essentially released stopgap because Entity Framework wasn't ready yet. It probably won't survive another release cycle. LINQ itself however is here to stay.

My 2 pennies.

 

[DaveSimmons]

Originally posted by: Markbnj
They already did that with the var type in C# 3. Basically 95% of this stuff is needed to support LINQ. I'm not sure I'm entirely thrilled with seeing more and more loose typing and dynamic binding making its way into the language. Would be interested in how others view this.

As a C/C++ geezer I also glare suspicously at loose typing in "real" languages

I'd worry about using loose typing accidentally in code without realizing it, similar to classic = vs == mistakes. I might prefer to have to mark blocks where typing is relaxed, with strict typing being the default everywhere else, i.e.

#pragma get_loose

... LINQ stuff ...

#pragma tighten_up


... but I'm still a c# n00b since we don't use it at work, so I could easily be overreacting.

 

[Markbnj]

You're right, Jason. I stand corrected. It's not the same as VARIANT. I think var introduces some portion of the same problems, given that type inference at compile time means that piece of code no longer states to a reader what kind of thing it is working with. Therefore the programmer doesn't know, and the maintainer doesn't know. When you combine var with anonymous types you get a good chunk of VARIANT's problems.

The bottom line, for me, is that I don't think making query writing a little easier and burying queries more deeply into the application programming language is worth allowing "intelligent laziness" into the language domain. Like Dave, I'm an old C/C++ guy who loves C#... and strong static type systems .

 

[wwswimming]

sounds like a good book to take on an airplane.

the security inspectors can get a little anxious about books like
"George Bush: the Un-Authorized Biography".

 

[clamum]

I do .NET development for a job (Web Forms these days) so this is pretty interesting. I'll have to read it over when I get a chance but I need to review things they have added in earlier releases, like nullable types (wasn't that Framework 2.0?). I don't use these things on a daily basis so I haven't really gotten a chance to delve into all the things the framework provides, which to me is a truckload.

I'm currently using C# 3.5 for development work and while I know of LINQ and have a general idea of what it does, we do not use it and stick to the standard Data Access (using the EntLib DAAB), Business Logic, and Business Objects layers. Even then, I don't see much of a use for the Business Logic layer in some of these applications because just about all of the logic is done in the .aspx.cs code-behind. To me it's hard doing logic in a separate project, at least for ASP.NET, when you need to reference the Session collection or the Response/Request objects and such.