Comments

infoof?  Don't toy with my emotions there, bud

 

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).

Oof.. the 'e' in "ToQueryable" ended up on a separate line on the otherwise beautiful diagram.

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".

The interviewer is very loud, and Wes and Bart are very soft -- I've got the volume turned up all the way, and when I'm not deafened by one, I can barely make out the other.

 

I don't suppose we could get subtitles?

Audio was very very quiet.  I had to crank up both system and zune volume all the way to hear the speakers.  You might want to relevel the audio stream.

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.)

Actually, it's called Sing#, which includes concurrency, channels, etc.  There's a whitepaper on the project website at MSR if you're curious what it looks like.

SecretSoftware wrote:


Also, when will drivers be written in Managed code?

http://research.microsoft.com/os/singularity/

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.

IQueryable is intended for use with LINQ implementations that handle expression trees.  LINQ -- the basic, to-object, implementation -- just deals with things you can do with IEnumerable<T>.