Can you cite any precedent where a court has agreed to hear such an argument? This is not a rhetorical question - I'm genuinely curious whether civil procedure allows it. As a non-lawyer (and MSFT employee) who is interested in the law, the closest thing I can think of is a motion for declaratory judgment, but even there I think you need an actual case or controversy before the judge will hear arguments.
Well, as I tried to allude to, in those cases Apple or Google would file a motion to compel Microsoft to disclose the info. Is it even possible under the rules of civil procedure for Microsoft to file a motion to compel itself to disclose something? Again, I'm not a lawyer, but my understanding is that a judge isn't going to hear the argument if there's no case, even if Microsoft did want the same level of scrutiny.
On what grounds? IANAL (and I am a Microsoft employee), but this makes no sense to me. As far as I know, warrants are for government agencies, not companies. And assuming a civil case where they were demanding that the provider turn over the emails, wouldn't their conversation with the judge go something like this?
Microsoft: “Judge, we demand that Microsoft turn over these emails.”
Judge: “???”
(that is, can you even procedurally attempt to force discovery against yourself?)
Not to mention that the EULA seems to pretty clearly cover exactly this scenario.
Aren't there like 4 other Turing award winners at MSR that also somehow escaped poaching (and are there any at Google)? I think you may have the wrong idea about where researchers would prefer to work...
That's an impressive proof of concept, but without expression trees it can't quite measure up (e.g. you need to remember to use `.and` instead of being able to use `&&`).
F# supports value types just like C# does, so I wouldn't expect more boxing on the F# side. Some types like tuples that are used more in F# than in C# are reference types, so you might want to avoid them in your inner loops, but that generally just means writing F# that looks a bit more like C#. Likewise, as to the number of function calls, it's probably a question of style more than features, though you can do things like use the `inline` keyword to make sure that particular functions always get inlined at call sites, which can be a big win in some cases (it also allows you to write type-safe generic math code, which is an oft-lamented unsupported scenario in C#). Lots of people are making good use of F# in contexts where heavy computational requirements exist (e.g. finance or scientific computing), but I'm not too familiar with projects using it where more real-time requirements exist (though I think someone's in the midst of porting Quake III to F#, so it'll be interesting to see how that goes).
I love F# dearly, and despite having spent several years writing C# code earlier in my career, I still find switching back to C# from F# painful in lots of little ways.
But I think this post is off-base. First, it criticizes C# both for incorporating too many of F#'s features, but also of stagnating. I just don't see how anyone can consider C# to be stagnating... of the heavily-used-in-industry set of languages, is there any that's evolving faster? Java's just now getting lambdas, for instance!
Secondly, I think the lack of promotion of F# by Microsoft is somewhat lamentable (though the community has done a great job of picking up the slack). But I think Microsoft's in a bit of a bind - they've received a lot of criticism for having too much churn in the ecosystem (e.g. ADO -> ADO.NET -> LINQ-to-SQL -> LINQ-to-Entities). So how would the community react to the statement, "you should really be using F# instead of C# going forward" (even if decision makers believed that)? Undoubtedly people would feel that the investment they'd made in learning C# was not worth as much as they thought and they'd start looking into more stable ecosystems (I'm mainly referring here to LOB app developers, who seem to greatly value stability of their platform).
Furthermore, in some ways these changes make the on-ramp from C# to F# even easier, which is a good thing. And C#'s still missing so many great F# features that it doesn't make sense to get too worried about the ones that have been mimicked. And I think it's somewhat true that imitation is the sincerest form of flattery, and having many great features spreading to other languages is a good thing.
If you're seeing significantly worse performance with F#, then that's pretty unusual (most people see very similar perf characteristics, with some things slightly faster in F# and some in C#). You might want to fire an email to fsbugs@microsoft.com explaining your scenario - the F# team is quite responsive.
The RyuJIT project shows that .NET JIT performance is still on the radar, though I haven't seen any indication that SIMD is on the roadmap.
To your final point, it's clearly true that C# is familiar to a wider variety of developers than F# is. However, I've been impressed by the uptake of some F# libraries, like FAKE. F# reads so mush like pseudocode in some cases that it's easy for people to buy in even if they're not especially familiar with the language.
I see this claim fairly often, but it seems like wishful thinking to me. There's nothing stopping a language targeting .NET from erasing its own generics to `List<object>`, `Map<object>`, `T<object>` if necessary, which would achieve almost exactly what you'd get with Java's erasure. And in the meantime, Java's approach requires any generic class containing arrays to box small value types, wasting large amounts of memory when those arrays are large.
Good point - there were several problems with Microsoft's tablet approach, and you're certainly right that application software is one of them. The main thing I wanted to say is that "short attention span" and "abandonment" don't accurately describe what went wrong.
I'm not sure this is a helpful diagnosis - Microsoft didn't have a short attention when it came to tablets (as you say, they pioneered them, and they haven't abandoned them), they just didn't get the form factor right, and many of the Live services have just been rebranded. Likewise, Apple has also demonstrated a short attention span at times. Remember Ping?
How does Microsoft know if a trademark is being used with or without its owner's permission? I mean, you can make a pretty solid guess in these cases, but it seems like waiting for a takedown request from the trademark owner is reasonable. (Full disclosure: I work for Microsoft, but in a different division, and I'm definitely not a lawyer)
Yes, because the purchase hasn't closed yet, so those revenues aren't included. Also, there was near-record profit to go along with the revenue, so margins aren't down too badly.
There are lots of things that could be better, and I don't mean to imply that .NET's system is perfect. But the fact that List<byte> contains an array of bytes rather than an array of much larger objects is often important in practice, and dwarfs any complaints I might have. Not being able to use System.Void in .NET generics is an occasionally frustrating quirk, not a huge problem, in my experience. Indeed, it's quite easy to create a new type with no public constructors to achieve the equivalent result (and F# does this with the unit type).
I wouldn't call that "two systems"; statically resolved type parameters are an extension of .NET generic parameters, not a separate system. In particular, a single definition can use both statically resolved and non-statically resolved parameters (e.g. in `let inline f x y = x + x`), and statically resolved type parameters can be used freely where normal .NET generic type parameters are expected (e.g. in `let inline g x = x + id x`). And these distinctions are fairly transparent to users in most cases anyway, since type inference is usually capable of inferring the kind of parameter needed.
In any case, it is true that F#'s type systems has concepts that the CLR doesn't natively support, but I don't see how this demonstrates any weaknesses in the CLR or F#. The exact same thing is true of Scala on the JVM, as far as I can tell - how are erased generics an improvement?
It's not just that. What's the probability that 100K people are killed by terrorists vs. police next year? With fat tails, the number of people killed in the recent past isn't an accurate summary of the true statistics.
Sure. The point is, "bringing back" implies that there was a period of time where Windows 7 PCs weren't being offered by HP, which appears not to be the case.
Sure, subtyping adds additional pain points (mostly separate from overloading, BTW). But I think this is mostly orthogonal to reified vs. erased generics. As it is, the .NET runtime supports reified generics and declaration-site variance (albeit limited to interfaces and delegates), and to my knowledge there's nothing stopping a different language/runtime from implementing reified generics even with usage-site variance (and Scala's type system only has declaration-site variance, anyway, AFAIK).
Counterpoint: "HP Bringing Back Windows 7 PCs? Not so fast..."[1]. TL;DR: this is a marketing tactic, and HP is actually offering fewer systems with Windows 7 than it was last year.
I'd love to see some evidence for these claims. Personally, I think that .NET's type system is quite elegant compared to the JVM's, and that .NET's combination of value types and reified generics gives several concrete advantages (better memory usage, avoids many Java pitfalls such as "why can't I use a T[]?", etc.).
This seems inaccurate - generics aren't a problem for F# at all (the integration between the .NET and ML type systems is seamless here, as far as I'm aware). Indeed the people behind the .NET generics design (Don Syme and Andrew Kennedy in MSR) were coming from an ML background, and Don is the primary researcher behind F#. The big ML-.NET type system mismatches have to do with things like pervasive overloading in .NET making type inference difficult, nothing to do with reified generics.
In many cases it's much easier than you'd expect. See e.g. http://www.heinz.cmu.edu/~acquisti/ssnstudy/ (TL;DR: "we show that it is possible to predict individual SSNs simply from publicly available data").
Don't blame Microsoft for the death of Silverlight, blame Apple. After the iPhone's release it didn't have a future. Is there a company that better supports its old technologies than Microsoft?
Don't get me wrong, Google does lots of great research across a variety of fields. And I'm neither a biologist nor a quantum physicist, so I can't claim to know exactly how important either MSR or Google's research is in those fields, but my distinct impression is that Microsoft is investing more and doing more in each of them (again, see the Aaronson post for the take of one person familiar with the state of quantum physics research). And not that it's especially important, but for the at least the first paper you cite it doesn't look like any of the research was actually done at Google.