Chat: C# 3.0 Language Enchancements, September 22nd @ 1pm Pacific Time

[Scott Nonnenberg [MSFT]]

This is really exciting stuff. We'll see you there!

It might be a good idea to do some background reading before you show up.
:0)
C# 3.0: http://msdn.microsoft.com/vcsharp/future/
The LINQ project: http://msdn.microsoft.com/netframework/future/linq/


C# 3.0 Language Enhancements
"Can't attend PDC but still want to talk to the C# team? This chat is your
chance! Join the C# team to discuss the newly announced C# 3.0 features like
extension methods, lambda expressions, type inference, anonymous types and
the .NET Language Integrated Query Framework. You've been hearing rumblings
about this for a while, now we finally talk in depth about the future of the
C# language."

The chatroom itself: http://msdn.microsoft.com/chats/chatroom.aspx
Mark your calendar with this iCalendar (.ics) file:
http://msdn.microsoft.com/chats/outlook_reminders/05_0922_MSDN_CL.ics
The official chat schedule entry:
http://msdn.microsoft.com/chats/#05_0922_MSDN_CL
The official C# chats page:
http://msdn.microsoft.com/vcsharp/community/chats/default.aspx
All upcoming developer chats: http://msdn.microsoft.com/chats/
My blog; all C# chats category (RSS available):
http://blogs.msdn.com/scottno/archive/category/10105.aspx


Scott Nonnenberg
Program Manager
Visual C# Team

 

[Alf P. Steinbach]

* Scott Nonnenberg [MSFT]:

C# 3.0 Language Enhancements
"Can't attend PDC but still want to talk to the C# team? This chat is your
chance! Join the C# team to discuss the newly announced C# 3.0 features like
extension methods, lambda expressions, type inference, anonymous types and
the .NET Language Integrated Query Framework. You've been hearing rumblings
about this for a while, now we finally talk in depth about the future of the
C# language."

It's easy to make something complex from something simple.

It's difficult to make something simple from something complex.

One should therefore refrain from adding unnecessary complexity.

C# was a nice little language. It had a few really ugly big warts, like its
property support (no way to know when to add "()" at the end of something that
might be a function call), and like its event handling, but all in all it was
a really nice little language, very much suitable for novices, and at the same
time also suitable for serious, big projects. As one would expect from the
creator of Turbo Pascal, which had the same general qualities, and was hugely
successful because of that.

Now you featuritis-ridden guys have taken over. And you don't seem to
understand one iota of the general idea. Or if you do, you don't give a damn.

 

[Alf P. Steinbach]

* Scott Nonnenberg [MSFT]:

The chatroom itself: http://msdn.microsoft.com/chats/chatroom.aspx
Mark your calendar with this iCalendar (.ics) file:
http://msdn.microsoft.com/chats/outlook_reminders/05_0922_MSDN_CL.ics

So extremely incompetent and/or inconsiderate:

Read my lips: all C# developers do not have Outlook (I only have Outlook
because I haven't taken the time to uninstall that virus-incubator).

Contents of the .ics file:

September 22, 2005
1:00 - 2:00 P.M. Pacific time
4:00 - 5:00 P.M. Eastern time
6:00 - 7:00 GMT
Join the chat room on the day of the chat:
http://msdn.microsoft.com/chats/chatroom.aspx

Now I wouldn't be suprised if that chat requires Internet Explorer...

Checking, using Firefox 1.06.

"Unable to verify the identity of profile.microsoft.com as a trusted site"
because the certificate issuer is unknown.

Then the same for the web site, which requires MSN (Microsoft Passport) login.
Jesus. You actively _filter_ so that you only get folks of The One And True
Right Faith in there -- only "yes"-people allowed in your "discussions".

I'm not going to create yet another MSN account just to find out I need my old
now long cancelled MSDN subscription (or whatever), or IE, or whatever extra
obstructions you have put in for unbelievers.

 

[Marcus Andrén]

C# was a nice little language. It had a few really ugly big warts, like its
property support (no way to know when to add "()" at the end of something that
might be a function call), and like its event handling, but all in all it was

Properties are essentially improved fields. Using method syntax for
them is in my opinion one of the bigger mistakes in Java. In most
cases it is obvious if something is a property or a function, and in
the few cases it isn't the compiler/IDE will complain if you choose
the wrong option.

C# doesn't have the syntactic sugar that VB has for eventhandling, but
in most cases attaching an event is just a single row in the
constructor and possible another row in dispose to remove it. In C#2.0
eventhandling also got a lot better with both improved syntactic sugar
and improvment of delegates.

Now you featuritis-ridden guys have taken over. And you don't seem to
understand one iota of the general idea. Or if you do, you don't give a damn.

First of all, I loved all the changes in C#2.0 since they made my code
both cleaner and faster.

I have read the C#3.0 proposal and while I don't agree with every
detail I don't think there is a feature creep going on.

Implicitly typed variables (var) should probably only work with
anonymous types, but in the long run I don't think it makes that much
of a difference.

Extension methods is probably my least favorite new feature (The
specification even warns not to use it too much). It is intended for
syntactic sugar, but it could make code less readably if used
incorrectly.

Lambda expressions on the other hand is the nice type of syntactic
sugar, as are anonymous types.

Most of the new features in c#3.0 seems to be there to support the new
built in Query language. I don't know exactly what to think about that
one yet since it is hard to judge on paper. Having a query language
built into the language isn't that usual, but I don't think it will
make code less readable, which is my prime concern when evaluating new
language constructs.

So extremely incompetent and/or inconsiderate:

Read my lips: all C# developers do not have Outlook (I only have Outlook
because I haven't taken the time to uninstall that virus-incubator).

Just for your information .ics is the extension for the standard
iCalendar file used by tools such as ICal on the Macintosh and in the
Mozilla Calendar project.

Now I wouldn't be suprised if that chat requires Internet Explorer...

You'll need to install one of the following browsers to use
Microsoft.com Chat.

Internet Explorer 4.0 and later for Windows
Netscape 6.2 and later for Windows
Safari 1.2 and later for Mac
Mozilla 1.7 and later for Windows
Firefox .9 and later for Windows

A pretty decent selection of browsers I would think.

Checking, using Firefox 1.06.

"Unable to verify the identity of profile.microsoft.com as a trusted site"
because the certificate issuer is unknown.

So you have to trust microsoft directly instead of a third party with
a root certificate.

Then the same for the web site, which requires MSN (Microsoft Passport) login.
Jesus. You actively _filter_ so that you only get folks of The One And True
Right Faith in there -- only "yes"-people allowed in your "discussions".

A majority of websites that allows posting/chatting requires an
account to participate. This is no different, and atleast with the
passport I can use the same login on all MS sites.

I'm not going to create yet another MSN account just to find out I need my old
now long cancelled MSDN subscription (or whatever), or IE, or whatever extra
obstructions you have put in for unbelievers.

You don't need an MSDN subscription, and as I said above it works fine
with firefox or safari.

 

[Kevin Spencer]

Now you featuritis-ridden guys have taken over. And you don't seem to

understand one iota of the general idea. Or if you do, you don't give a
damn.

One might say the same thing of C++ versus C. If you want simple, you might
as well go back to Assembler. Object-oriented programming in general is more
complex than procedural programming. Multi-threaded programming is extremely
more complex than single-threaded programming.

The beauty of OOP is that it EXTENDS procedural programming. Underneath all
of the complex data types, and all the complexity of C++ and C# is the
simplicity of C. And you can write an entire C++ or C# application using C
(or even Assembler) if you like.

To extend something is quite a different concept than making it more
complex. A Swiss Army Knife is a lot more complex than a simple Pocket
Knife, but the Pocket Knife IN the Swiss Army Knife is just as simple as a
pocket knife, and just as easy to use. The extensions of the C language in
C++, and the extensions of C++ in C#, and the extensions of the current
version of C# in future versions of C# do not make C, or C++, or C#, or any
future extensions of C# more complex by the same token. You may use them, or
not.

It's easy to make something complex from something simple.

This is indeed what you have done. In your own mind. There is nothing
complex about extending something. There is nothing complex about adding 2
to 1 and making 3. 1 is still there.

If you want to play the Amish Programmer, feel free to do so. But learn
something from the Amish. They like living the way they do, but they don't
criticize the rest of the world for living the way THEY do. There is wisdom
in this. Remember that there are people out there for whom any kind of
programming at all is more complex than they want to deal with. Like the
Amish, you have chosen where in the chain of increasing technological
complexity you wish to live, and it is neither at the bottom, nor at the
top. And that makes you no better and no worse than anyone else. Neither
does it make the rest of us any better or worse than you. So, lose the
attitude. It isn't doing you any favors.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
I'd rather be a hammer than a nail.

* Scott Nonnenberg [MSFT]:

C# 3.0 Language Enhancements
"Can't attend PDC but still want to talk to the C# team? This chat is
your
chance! Join the C# team to discuss the newly announced C# 3.0 features
like
extension methods, lambda expressions, type inference, anonymous types
and
the .NET Language Integrated Query Framework. You've been hearing
rumblings
about this for a while, now we finally talk in depth about the future of
the
C# language."

It's easy to make something complex from something simple.

It's difficult to make something simple from something complex.

One should therefore refrain from adding unnecessary complexity.

C# was a nice little language. It had a few really ugly big warts, like
its
property support (no way to know when to add "()" at the end of something
that
might be a function call), and like its event handling, but all in all it
was
a really nice little language, very much suitable for novices, and at the
same
time also suitable for serious, big projects. As one would expect from
the
creator of Turbo Pascal, which had the same general qualities, and was
hugely
successful because of that.

Now you featuritis-ridden guys have taken over. And you don't seem to
understand one iota of the general idea. Or if you do, you don't give a
damn.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[Alf P. Steinbach]

* Kevin Spencer:

[excessive quoting removed]

* Alf P. Steinbach:

Now you featuritis-ridden guys have taken over. And you don't seem to
understand one iota of the general idea. Or if you do, you don't give a
damn.

[snipped babble]

To extend something is quite a different concept than making it more
complex.

Adding features to a language is never a simple extension where the former
version can be used just as it was. To take your own example, C++ is not a
proper superset -- extension -- of C. Any C program can be re-coded as
valid "better C" C++, but give a non-C++ cognizant C coder a pure C++ compiler
and s/he will soon be struggling with constructs that "should" compile (as C)
but don't (as C++), constructs that don't do what they "should" (as C) but
something very different (as C++), compiler options that make no sense
whatsoever to her, and when s/he has to use code written by others, or
generated by tools, s/he will find it entirely indecipherable, not only
syntactically, but it's expressed in terms of concepts not existing in C.

And that's for a set of language extensions that have gone through a very
extensive review process where only the very fittest survived.

For C# it's now different.

And it's kind of sad when this formerly beautiful young woman C# has been is
"improved" with a third specialized arm sticking awkwardly out of her back.

All to make her better adapted to one small set of specific tasks.

[snipped suite of personal attacks, leaving just one]

Like the
Amish, you have chosen where in the chain of increasing technological
complexity you wish to live, and it is neither at the bottom, nor at the
top.

Nothing I can say can refute that convincing an argument...

 

[Kevin Spencer]

And it's kind of sad when this formerly beautiful young woman C# has been

is
"improved" with a third specialized arm sticking awkwardly out of her
back.

Well, I haven't looked very extensively at C# 3.0, but I have been working
with C# 2.0 for awhile now, and the extensions added to the language
actually make it easier to use, and not the other way around.

Take Generics, for example. Generics allow a single class or method
definition to accomodate any data type while maintaining strong data typing,
and without casting or conversion. One excellent example is the
System.Collections.ObjectModel.Collection<T> class, which is a Generic
Collection that can be used as a Collection of any data type whatsoever. It
requires no casting or conversion, as do previous versions of Collections
which were of type Object. And it is strongly typed to the type you pass to
it when declaring it. The possible ramifications of Generics have yet to be
fully exploited. I have personally, for example, extended the
System.Collections.Generic.Dictionary<TKey,TValue> by creating my own
GenericDictionaryCollection<TValue>, which always uses a string Key, but any
type of value, from that, a StringDictionaryCollection which always uses a
string as the Key and the Value, added events and event handlers to it which
can be used by derived classes for validating strings, and derived several
StringDictionaryCollections from it for use with Custom Configuration
Classes. Each of the custom StringDictionaryCollection derived classes
validates the strings entered into it in their own way. I create methods
which operate on a StringDictionaryCollection, and can use them for any of
the derived classes.

Another example is Anonymous methods. This enables the developer to, for
example, declare an Event Handler without having to create a delegate method
separately, but simply by putting in a block of statements. When an Event
Handler is used only once in the code, this simplifies the code, rather than
making it more complex.

In both of these examples, the language has been improved by allowing
developers to write and maintain less code. In essence, it allows developers
to write leaner, more concise (and less complex) code, and the larger the
project, the more beneficial this is. From what I've gleaned about C# 3.0 so
far, this trend continues in the new language enhancements.

Still, again, one can continue to use the older methodology without any
problems, if one so chooses. As for me, I like to "hang ten" with the new
stuff; call me a technological thrill-seeker. Yes, you do a bit of bleeding
on the cutting edge, but what a view!

--
;-),

Kevin Spencer
Microsoft MVP
..Net Developer
I'd rather be a hammer than a nail.

* Kevin Spencer:

[excessive quoting removed]

* Alf P. Steinbach:

Now you featuritis-ridden guys have taken over. And you don't seem to
understand one iota of the general idea. Or if you do, you don't give
a
damn.

[snipped babble]

To extend something is quite a different concept than making it more
complex.

Adding features to a language is never a simple extension where the former
version can be used just as it was. To take your own example, C++ is not
a
proper superset -- extension -- of C. Any C program can be re-coded
as
valid "better C" C++, but give a non-C++ cognizant C coder a pure C++
compiler
and s/he will soon be struggling with constructs that "should" compile (as
C)
but don't (as C++), constructs that don't do what they "should" (as C) but
something very different (as C++), compiler options that make no sense
whatsoever to her, and when s/he has to use code written by others, or
generated by tools, s/he will find it entirely indecipherable, not only
syntactically, but it's expressed in terms of concepts not existing in C.

And that's for a set of language extensions that have gone through a very
extensive review process where only the very fittest survived.

For C# it's now different.

And it's kind of sad when this formerly beautiful young woman C# has been
is
"improved" with a third specialized arm sticking awkwardly out of her
back.

All to make her better adapted to one small set of specific tasks.

[snipped suite of personal attacks, leaving just one]

Like the
Amish, you have chosen where in the chain of increasing technological
complexity you wish to live, and it is neither at the bottom, nor at the
top.

Nothing I can say can refute that convincing an argument...

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?