The point I was making is that the final implementation should match the characteristics of what would be built with it. In Rx's case, Sum-as-sequence makes perfect case as you adequately explain. In IE's case, Sum-as-scale fits well with what people almost
certain end up doing. In any event, a user-study would reveal this (albeit too late to change the established SQO specifications if I'm proven wrong).
While Sum in IE/IQ could return an IE/IQ, that would actually (for most people) be unexpected design. Most people would rightly expect a summation operation to return a single item of the element type of the sequence (IE<T> -> T). They would not expect
it to return some sequence that just happens to contain a single element. The design of Sum in the enumerable/pull/synchronous world is correctly chosen.
The observable/push world is different in its asynchronicity, and that's the motivation for the design there.
@Paulo: I agree.. I've already complained to a couple folks on the team. I've suggested "IObservableQuery" since they don't like "IQueryableObservable".
My impression is that it's a well-meaning draft. Overall, however, I was dissatisfied with it.
Primarily, my concern is that there are such obvious inconsistencies -- such as a comment about pointers being unavailable in C#, soon followed by an example of using them in C# -- and glaring omissions.
In particular, while the text mentions .NET 3.5 in the present tense, I failed to see any discussion about LINQ as a pattern for data access. Indeed, the only discussion of .NET's data stack appears limited to .NET 2 -- the DataSet stack. I'm fine if you
want to be a cheerleader for NHibernate (I have no desire to use it, personally), but even NH is building a LINQ layer. It comes off as either careless (you overlooked, somehow, the single biggest feature of .NET 3.5, and pretty much the only feature which
could have stopped Orcas from shipping), or disingenuous (you intentionally failed to discuss it). I refuse to believe the latter possibility, but the former is pretty bad in itself.
My suggestion would be to have a couple hard-core technical reviewers, both ALT.NET and MS if that's your preference, who can guide you to make sure your discussion is sound and complete. You have the core of a good, informal guide (my manager is having our
new grad hire lead a discussion of it) but I wouldn't call it ready in the context of what it's purporting to discuss.
(I admit, I'm not volunteering -- I've already done my technical review for a book. I'm making up for lost sleep now.. but seriously, good luck and I hope to see your project continue in good directions.)
Nothing in theory (to my knowledge) prevents you from creating a server that accepts expression trees, except that expression trees are not, in the general case, serializeable. However, if you're willing to restrict cases, you could do so.
There are a few things not quite in the system, but IronPython, etc will drive those changes. Part of Hugunin's mandate when he was hired by Microsoft was to make the CLR friendlier to dynamic languages.
And, of course, that often translates to enabling things in static languages...
Blinq's just a web page generator. It uses LINQ to SQL underneath.
I would recommend taking a pythonic approach to perf:
1) write in the clearest, safest manner (ie, LINQ) 2) *measure* the perf 3) rewrite the bottlenecks in something more arcane 4) re-measure to see if it was actually worth the effort. If not, for god's sake revert.
and, of course
5) learn how to do multi-threaded programming, correctly. Absolute speed is often less important than perceived responsiveness.
The bottom line is to be lazy, and make use of what the framework provides. But know what you're doing and don't just assume that the rules for performance in one environment automatically apply to another environment.