The future of the C# language

PDC is coming up soon, and the session list has been posted.

One thing i wanted to point out was the abstract for a session that the C# team will be giving on version 3.0 of the language:

C#: Future Directions in Language Innovation from Anders Hejlsberg

Join Anders Hejlsberg, Distinguished Engineer and chief architect of the C# language, for an in-depth walkthrough of the new language features in C# 3.0. Understand how features like extension methods, lambda expressions, type inference, and anonymous types make it possible to create powerful APIs for expressing queries and interacting with objects, XML, and databases in a strongly typed, natural way.

Session Level(s): 300

Track(s): Tools & Languages

I'm trying my best to get to go to PDC, but after the JavaOne oppurtunity i don't know if i'll have time to do another round of conferences.  But do really want to see your reaction to what we've been thinking about and if you'll like it or not.

Of course, i can't really delve in deep into any of this, but after (or during) PDC i'll be sure to cover all the interesting stuff that's listed above like:

1. Extension methods
2. Lambda expressions
3. Type inference and implicit types
4. Anonymous types, (no, not anonymous inner classes).
5. Expression Trees (my favorite)

Other's like Matt will probably cover the above *and* the interesting subjects of XML and DB interaction.

These might seem like a lot of changes, but i think everyone will see how they build so naturally on C# 2.0.  Who knows... will C# become a language that draws me away from OCaml?  It just might.

I'm excited.  Are you? :-)

Comments

• Anonymous
  July 13, 2005
  I am sad, because of another long time waiting starts :-)
• Anonymous
  July 13, 2005
  If only I could attend the Heljsberg session without paying 1,700 bucks for the whole thing. That's selling knowledge, and I believe it's a privilege, a benefit, and a duty to give knowledge to people.
• Anonymous
  July 14, 2005
  The comment has been removed
• Anonymous
  July 14, 2005
  The comment has been removed
• Anonymous
  July 14, 2005
  The comment has been removed
• Anonymous
  July 14, 2005
  Cyrus Blather has in his blog a post about the upcoming PDC session
  on the future of C#. Among the things...
• Anonymous
  July 14, 2005
  Sounds cool. Of course, this is going to get everyone hyped and excited about C# 3.0... 2 months before C# 2.0 is released! Seems like a good way to dampen excitement for the latest product.
  Of course I understand anyone that will be attending PDC will have already been using C# 2.0 for at least a year. But think of all the press the new feature announcements will generate for the general public to consume. "And pretty soon, you'll be able to buy a new C#, that does NOT have these features." Frustration?
  
  Not a complaint - I love all the preview stuff. But I wonder if this kind of issue was considered.
• Anonymous
  July 14, 2005
  Aren't lambda expressions just anonymous delegates as found in 2.0?
  
  What's the difference between lispish "(lambda (x) (+ x 2))" and whidbeyish "delegate(int x) {return x + 2;}"?
  
  I suppose one difference is that the compiler has to be able to infer the delegate type of the latter, but that's more a difference between static and dynamic typing. And "anonymous types" and "type inference" make it sound as if that requirement is already lifted in 3.0.
• Anonymous
  July 14, 2005
  I remember hearing about all the new features of 2.0 a year ago when so much of that energy could have been focused on what you can do with 1.1. Our organization where I work currently uses version 1.0 and has not upgraded to 1.1 because of all the anticipation for 2.0 that we heard about everywhere.
  
  Just imagine, 2.0 is not released and now we start hearing the 3.0 hype. I wonder, if our company will wait for that because 2.0 isn't good enough or because you can do all these wonderful things in 3.0 in 2 years from now that you can't do in 2.0.
  
  This is rediculous nonsense. First, create the illusion that you believe in the current release and that others should do, focus on it, exploit it, and when another release do close to being due, discuss it.
  
  All that said, I'm waiting for the news on 4.0... Hmm... I predict we'll be hearing it about the time of 3.0 beta 1. Great.
  
  
  Thanks,
  Shawn
• Anonymous
  July 14, 2005
  To all of those posting about the strangeness of announcing future C# work when C# 2.0 hasn't even be released:
  
  Yes, this was something that we thought a whole lot about and we considered the points that you would be making.
  
  however, we feel that the C# future that we are working on will make C# 2.0 even more attractive.
  
  I mentioned in the posting: "These might seem like a lot of changes, but i think everyone will see how they build so naturally on C# 2.0."
  
  The idea behind a lot of the stuff we're doing is that if you start adopting and embracing C# 2.0, then the future C# stuff will work effortlessly with the new code you have. However, if you avoid 2.0 because you're waqiting for the future you're going to have a whole lot of work to do when that eventually rolls around.
• Anonymous
  July 14, 2005
  Loc: After PDC this information is usually made available rather quickly. We'll also be presenting information on the C# website as well as blogs.
  
  You don't need to go to PDC to learn abou all this stuff (just like with C# 2.0)
• Anonymous
  July 14, 2005
  Stuart: The Nullable issue is being actively investigated. I can't say yet what the final release will look like though.
• Anonymous
  July 14, 2005
  Stuart: "Aren't lambda expressions just anonymous delegates as found in 2.0? "
  
  I can't tell you yet :)
  
  "but that's more a difference between static and dynamic typing. "
  
  No, it's not related to dynamic typing at all.
• Anonymous
  July 14, 2005
  Shawn: "I remember hearing about all the new features of 2.0 a year ago when so much of that energy could have been focused on what you can do with 1.1. Our organization where I work currently uses version 1.0 and has not upgraded to 1.1 because of all the anticipation for 2.0 that we heard about everywhere."
  
  Pity. 1.1 fixed a lot of bugs and made a lot of things easier. We're not going to stop thinking about the future for the very simple reason that there's so much amazing stuff we can do, and these things can make developers' lives so much easier. However, we can't do it all at once because we wouldn't have enough time and we'd never ship. Do you not buy a computer because in a year there will be better computers out there?
  
  "Just imagine, 2.0 is not released and now we start hearing the 3.0 hype. I wonder, if our company will wait for that because 2.0 isn't good enough or because you can do all these wonderful things in 3.0 in 2 years from now that you can't do in 2.0. "
  
  Perhaps. But we'll be showing how that is a very bad idea, and how embracing 2.0 asap will provide you an amazing level of benefit when the future C# arrives. If you hold off, then you might have a whole lot of work ahead of you.
  
  "This is rediculous nonsense. First, create the illusion that you believe in the current release and that others should do, focus on it, exploit it, and when another release do close to being due, discuss it. "
  
  We do believe in the current release. And I, personally, think it's unbelieveable important and fantastic. But that doesn't mean i'm going to stop thinking about hte future. About better ways the language and tools can progress. And i'm going to tell you about them because i want to communicate with teh community so that we can build a better future for eachother.
  
  "All that said, I'm waiting for the news on 4.0... Hmm... I predict we'll be hearing it about the time of 3.0 beta 1. Great. "
  
  That's quite possible. Who knows.
  
  I'd rather be open and honest about our plans, rather than keeping all of this secret and just dumping it on you with a new release every couple of years.
• Anonymous
  July 14, 2005
  Loc: "That's selling knowledge, and I believe it's a privilege, a benefit, and a duty to give knowledge to people"
  
  We will be giving this knowledge to people in every way we know how. However, you have to deal with the fact that this is a convention center and it costs and enormous amount of money to book something like for a week. People need to get paid. Things like unnlimited food is provided. Rooms are rented, screens are purchased, etc. etc. etc.
• Anonymous
  July 14, 2005
  Ooh!
  
  It's really interesting to try to guess what all these features actually mean by their names, but based on interviews, reading about Cw, and this list of features, I have a funny feeling we're going to get something just as good as multiple return values from a single method.
  
  On the other hand I'm sure Cyrus isn't allowed to confirm or deny that...
• Anonymous
  July 14, 2005
  As Brad and Cyrus point out, we have officially listed a lot of the PDC sessions. Check out...
• Anonymous
  July 14, 2005
  How about get rid of the nullable types abomination and start over from scratch.
  
  
• Anonymous
  July 14, 2005
  The comment has been removed
• Anonymous
  July 14, 2005
  DrPizza: "How about get rid of the nullable types abomination and start over from scratch. "
  
  " It's like they actively set out to avoid a consistent orthogonal design"
  
  Starting from scratch isn't an option. C# is here, and its' here to stay. The next language we do will have the benefit of being able to "start from scratch" learning from all the mistakes we made.
  
  And sometimes even if you can't add something taht's completely perfect it's still ok to add it if the benefit is substantial enough the common case of how users will use it.
  
  I started out vehemently angry with Nullable. Then i saw how people were using it and how it made thigns so much easier for people, and i'm much happier with how it's going to ship.
  
  I also feel that it will integrate well with the future of C# and that having it in place now so that people can start using it in thier apps/systems is essential.
• Anonymous
  July 14, 2005
  Stuart: Nope. Until PDC i can't confirm or deny anything. I can say that we pay attention to the development and evolution of many languages (including C-omega), and we're always thinking about how we can utilize research to make our own language better.
  
  And by all means, go ahead and start thinking about this stuff. You might get a kick out of what possiblities it opens up.
• Anonymous
  July 14, 2005
  Will the release of C# 3.0 be tied to the release of new versions of Visual Studio and/or SQL Server as this release has? Or will C# 3.0 be able to be released as a new compiler and some patches for VS.2005
• Anonymous
  July 14, 2005
  The comment has been removed
• Anonymous
  July 14, 2005
  The comment has been removed
• Anonymous
  July 15, 2005
  The comment has been removed
• Anonymous
  July 15, 2005
  The comment has been removed
• Anonymous
  July 15, 2005
  "In one very obvious (and common!) situation, forbidding nulls requires you to violate data integrity in other ways. Representing any kind of hierarchy in a database requires a parent_id field, which is a foreign key to the id field of the same table. If this field is NOT NULL, you can't put that foreign key in place, because it's impossible to represent the roots of the hierarchy. "
  
  Then don't represent your hierarchy that way. Represent it using nested sets instead of an adjacency list. Nested sets don't require nulls.
  
• Anonymous
  July 15, 2005
  DrPizza: I'm unfamiliar with the concept of "nested sets" in the sense you're describing.
  
  Can you explain what the "nested set" equivalent would be of a simple hierarchical structure like this:
  (
  id int identity not null,
  parent_id int null,
  name nvarchar(20) not null,
  sort_order int not null
  )
  with a foreign key constraint from parent_id to id on the same table?
• Anonymous
  July 15, 2005
  Take a look at this article, for example:
  http://www.intelligententerprise.com/001020/celko1_1.jhtml
  
  
  Instead of storing the tree as a series of edge definitions (the {identity, parent_id} pair defining the edge between the two nodes) you perform a pre-order traversal of the tree, storing at each node its position in the traversal.
  
• Anonymous
  July 16, 2005
  That seems all nice and theoretically sound, but it makes some potentially common operations very expensive. Inserting and removing nodes in the usual representation requires only updating that record (and perhaps fixing up the sort orders of other records with the same parent id), but in a nested set representation it requires modifyng the lft and rgt columns of potentially the entire table.
  
  I work on a CMS that represents the page structure of the site as a hierarchy, and also supports eCommerce with a product category hierarchy - we've had customers already that have pushed both these tables into the thousands of records, and there's no reason in theory why it shouldn't be much bigger.
  
  I'm not about to implement an architecture which requires updating 5000 records just to add a new page or category.
  
  That's even ignoring the fact that IMO the nested set representation is much harder to understand and reason about. If I saw that table in somebody's code I'd never understand it without a link to an article which explains the representation. But anyone with any relational DB experience at all would understand the representation I use.
• Anonymous
  July 16, 2005
  "That seems all nice and theoretically sound, but it makes some potentially common operations very expensive."
  It also makes some incredibly cheap, unlike the adjacency list. For example, if your hierarchy represents a parts list, the nested sets make it very easy to see the total cost of a part including all its constituent parts. Adjacency lists don't.
  
  "Inserting and removing nodes in the usual representation requires only updating that record (and perhaps fixing up the sort orders of other records with the same parent id), but in a nested set representation it requires modifyng the lft and rgt columns of potentially the entire table. "
  Unless your hierarchy is huge and updated often (which for things like a traditional hierarchical product catalogue isn't usually the case) that's not a problem worth fretting over.
  
  "That's even ignoring the fact that IMO the nested set representation is much harder to understand and reason about."
  It's much easier to reason about, not least because it uses a set-oriented language (SQL) to perform set operations.
  
  "If I saw that table in somebody's code I'd never understand it without a link to an article which explains the representation. But anyone with any relational DB experience at all would understand the representation I use. "
  If I ever saw the code you wrote to traverse your tree (for example, to sum all the children to tell me how much something costs) I'd probably say the same.
  
  Even if you insist on using an adjacency list, there are ways to store it which don't need nulls; storing nodes and edges separately, for example.
• Anonymous
  July 16, 2005
  Damien: "Will the release of C# 3.0 be tied to the release of new versions of Visual Studio and/or SQL Server as this release has? Or will C# 3.0 be able to be released as a new compiler and some patches for VS.2005"
  
  That information will be made public at PDC.
• Anonymous
  July 18, 2005
  I have to agree with DrPizza on the nested sets. We use them for our categorization on our site. While inserts and updates may be slightly more expensive than a traditional hierarchy; selecting out the data you need is far easier and much cheaper. Our admins our doing the inserts and updates, so performance isn't a huge issue (although we've never had a problem with it anyhow). It's our customers and users that are viewing the data. With that model, the nested sets make perfect sense.
• Anonymous
  July 19, 2005
  Another question about nested sets (since I really am curious about whether these could improve matters in my code - I have quite a few hierarchies in there).
  
  Even when selecting the data, the most common operation I do is probably selecting the direct children of a particular node. In the adjacency list representation, this is an easy "select * from page where parent_id = @whatever".
  
  Since the parent_id field is indexed, this is extremely efficient.
  
  What would be the equivalent in a nested set representation? I can see the way to get "all descendants all the way down" (although that still seems to need a join if all you have is the id of the parent) but not a way to limit it to direct children only.
• Anonymous
  July 19, 2005
  "What would be the equivalent in a nested set representation? I can see the way to get "all descendants all the way down" (although that still seems to need a join if all you have is the id of the parent) but not a way to limit it to direct children only. "
  
  Perhaps do something such as Select subordinates whose indentation level is one greater then your current level.
• Anonymous
  July 19, 2005
  The comment has been removed
• Anonymous
  July 19, 2005
  The comment has been removed
• Anonymous
  July 19, 2005
  Wow - looks like extension methods might be something akin to lisp macros and allow the user to define new syntax for their domain. Very cool.
• Anonymous
  July 20, 2005
  So going on the theory that Extension Methods are a way to create a Domain-Specific Language (something MS is already experimenting with), that leaves Lambda Expressions and Expression Trees. Lambda Expressions sound like their Python equivalent. Expression TREES, however, sound like Lightweight Expression Generation. Essentially, declaring a non-compiled parse tree, and being able to pass it around or manipulate it, then using it as a template for evaluation. Something right out of my RPL days.
  
  If we consider Whidbey as an introduction to declarative programming (ASP.NET 2 DataSources, Generics, Avalon CTP, etc). Orcas could be taking it to intentional programming, as I understand it (creation of code generators, [hopefully] Cw query functionality).
  
  It makes me wonder what Hawaii's going to be about. Again, I'll insert the plug for MC#: the ability of the runtime to coordinate with other instances of the runtime on other machines, to act more or less seamlessly as a grid, would be a next-logical-step in .NET.
  
  For that matter, it makes me wonder what will succeed C#n, after they've had the chance to do the post-mortem on the first 2-3 versions.
  
• Anonymous
  July 20, 2005
  The comment has been removed
• Anonymous
  July 21, 2005
  drpizza
  
  MC# is at http://u.pereslavl.ru/~vadim/MCSharp/
• Anonymous
  July 27, 2005
  lim(version->oo) C# = ML