Delightful, delicious, DLINQ
As you've probably already heard, at long last we've announced the new features that we're planning on delivering in C# 3.0. Our primary goal for 3.0 is to enable programmers to concisely represent complex query logic on arbitrary collections in C#. That's great, and as a C# user who spent the last three years playing around with data access in C#, I'm excited about that. But as Cyrus points out, what's more exciting to me is how we're going to get there. In order to build the kind of language integrated query system we want, we're going to have to add features to C# that I've been wanting for years: lambdas, type inference, anonymous types, and so on. These have applications far broader than integrated query.
The reason that we tell you guys about the secret goodies long before we're ready to ship is because we want your feedback as early as possible. It costs a considerable number of dollars to implement this stuff and we want to be very sure that we're building the features that really do make your lives as programmers easier. So please, please, write blogs, send me email, leave comments, attend chats, be vocal. If you're excited by this stuff, let us know. If you think that the goal is good but the proposed implementation is lousy, let us know. We want to hear it!
*****************
In unrelated news, I have always wondered how the magic sunglasses in the classic John Carpenter movie They Live worked. Perhaps this partially explains it?
Comments
- Anonymous
September 14, 2005
You want to know if the proposed implementation is lousy, right? Well, where are the outer join operators? - Anonymous
September 14, 2005
I find implicitly typed variables a little scary, especially in a language like C#. Sure, the type is inferred but in the source a developer is not forced to think about the type of expression or the enumerated type in 'foreach' statement. Anonymous types seem just as bad because you're now creating types on the fly instead of defining types up front. - Anonymous
September 14, 2005
The comment has been removed - Anonymous
September 14, 2005
That was a bit long and intense. I have some pent-up language regret! - Anonymous
September 14, 2005
Re: outer join operators -- the DLinq guys are at PDC right now, so it'll be hard for me to ask them whether this is an oversight. I suspect that there will be all the operators you expect. Even if there are omissions, the operators are not a fixed set, but rather are extension methods behind the scenes. There is no reason whatsoever that you couldn't define your own outer join method on your collection object. - Anonymous
September 14, 2005
Re: implicit typing is scary.
Let me play devil's advocate here.
This scares me:
x = a() + b * c;
All kinds of anonymous stuff is going on in there! temporary variables with no names are being created, filled in with values and destroyed. And who knows what registers they're using. It would be much more clear if this were written in a language without anonymous local variables. Something like
int temp1 = a();
int temp2 = b * c;
x = temp1 + temp2;
That's much clearer!
OK, seriously now, I see your point. But as computer languages have evolved, something we've seen over and over again is that fewer and fewer things need to be explicitly named. Often what matters is the structure or function of a thing, rather than what it is called.
C came along and freed developers from having to name every temporary. Lisp came along and freed people from having to name their functions. ML frees people from having to name their structs, Java has anonymous classes, and so on. If you feel more comfortable naming stuff, then continue to do so -- but once you get used to not having to name everything, it is very freeing. - Anonymous
September 14, 2005
Hey Nicholas,
That's an excellent point, and one that deserves a more thought-out answer than I can give today. The short version is that I think that our efforts to make the standardization process very public and to get the spec out there early help tools vendors. It's not like VBScript, where there are loads of secret gotchas in the parser.
Now, let me address your "hundreds of people" claim. There certainly aren't even a hundred devs, testers, pms and managers in the entire C# product unit, and the C# team owns the debugging portions of VS as well. The language compiler/IDE dev team is about a dozen people.
Also, I think you mean unintended nonorthogonality. I'm sure that I'll be discovering plenty of that as I actually implement the spec, and we'll figure it out. It'll be a hard problem, to be sure. - Anonymous
September 14, 2005
The comment has been removed - Anonymous
September 18, 2005
I have always wanted a language with a built-in relational algebra. I have my own half-baked pages covering this type of thing, but they are over 5 years old now and it seems I will never have the time to complete the thought.
But, just adding relational algebra semantics to a language are not enough. The self-join is too often used in programming to ignore; so some sort of relational algebra extension is needed to cover this common case.
On the other hand, maybe you should be adding a real (read lispy) macro system instead. It almost looks like it would be easier.
At the very least there should be a default process (in the form of a ?macro?) for converting from relational algebra down to C# 2.0.
Some other requests:
1) Please treat null as just another value.
2) SQL blows mostly because self-joins are not handled gracefully, but also because of its use of nulls
3) Do not force the programmer to explicitly state whether conditions are to be applied during JOIN or after-the-fact in the WHERE clause (T-SQL does this). The ON clause add needless complexity to a query when the WHERE clause should be sufficient. PL-SQL does it right.
4) Look at WHY outer joins are used. I suspect they are not as important as others insist. I only use outer joins for a few patterns that could have their own semantics instead. Check out an old (Mac based) database program called 4th dimension; I heard they had an alternate solution to outer joins. - Anonymous
September 19, 2005
The comment has been removed - Anonymous
September 19, 2005
The comment has been removed - Anonymous
November 10, 2005
The comment has been removed