@wkempf: Of course not. As long as there are nullable types this operator makes sense. It makes sense on optional values too, I think.
This looks similar to F# constructor syntax
Wasn't this null-safe operator part of Cω? It looks very useful indeed. In F# it's less of an issue because types have to be declared as nullable - except for all other "foreign" types that are also nullable.
Really exceptions/etc. are all just a type of syntax for the more fundamental maybe construct explicitly found in some purely functional languages. Using something derived from maybe is the only way I can see to implement something like IEnumerable without introducing the side effects in question.
Nitpick: Maybe has nothing to do with purely functional languages per se. C# has the Nullable type (albeit limited to value types; because reference types are unfortunately always nullable in C#) whereas F#, SML and others have a more generalized option type (which has a nice synergy with default non-nullable reference types in F#).
Also, I wouldn't say Maybe/option is a good way to model exceptions. Because either you get a value or you don't - but then you don't know why you didn't get one! No, in general discriminated unions could be used instead - but that's another story.
I wonder whether, in a side-effect controlled language (or verified subsets), there couldn't be a static compile-time query optimizer for something like LINQ to objects (LINQ over IEnumerable sequences). There are some expressions that look elegant with LINQ to Objects but don't perform well. It would be nice to have the cake and eat it too. This would of course mean a much more involved compilation phase.
Nov 14, 2013 at 8:47 AM
Surely we will get this for regular Windows desktop apps, right?
To counter-balance this thread a little...
Well even though functional programmers realized the connection to functional operators when they first saw the LINQ syntax (at least select is map and where is filter) the adapted naming could have helped popularize LINQ because it then looks more than SQL. I don't know if that's true but some irony it would be if that now makes it stand out as different among a family of "LINQ-like" implementations. These are just names though.
Also, does SQL have to be based on sets to be sound? (Order Theory?)
I use both and started to use outlook.com because UX is very good in my oppinion (also first had a hotmail.com account back when Internet use was most common via the public library).
Keyword-based advertisement matching is definitely not news - and the practice is open and transparent (it's kind of hard not to notice). But it's one way to market a product in these privacy-challenged times.
Whether one is more "professional" than the other seems like a very subjective question. Both services work very well.
Interesting times for photography. We are seeing 40MP and dual-flash camera phones. Impressive new DSLR imaging sensors - and much better on the horizon, fast post-processing chips and software, lightfield cameras (Lytro), HDR techniques, etc.
Now some researches have found a way to "improve" lens performance via post-processing:
Lens-correction is not new but this appears to take it a step further.