>>I'd say MS has the NEED - otherwise the ARM side of Win8 is doomed IMHO.
>>Making XNA/C# dev less than first class seat as developer, as is hinted for WP8 (C and C++ rules again)
>
>I don't know where you got this idea. C# is still very much a first class citizen. What Microsoft did, was make it easier for C++ to use XAML, and other technologies. They didn't reduce the role of C# in any way.

When WinRT was shown, C#/Dotnet was downplayed. Now XNA is downplayed - while games may be irrelevant to us,
axing parts of the framework is not a good sign. As some games engines are in Ruby or Python, going down to C only
in some critical portions, asking devs to code the whole game in C/C++ seems crazy.
M.J.Foley is not what I call a good source, but others showed similar takes.

>>will drive a stake through future earnings - silverlight getting shafted instead of enforcing Xamarin was bad,
>
>Huh? Xamarin? What does that have to do with Microsoft? If you're implying Moonlight, that's pretty much dead. Xamarin's agreement with Novell/Attachmate did not include Moonlight. Xamarin has no plans to do anything with Moonlight.

Ok, too much mental shorthand. Silverlight/Moonlight killing was necessary due to those crazy load times at startup.
Nobody would allow such wait times. But the idea of having Dotnet apps available on android and iPhone had some merit.
MS is keeping the desktop, but the desktop is loosing in a big way the lure of "personal computer" - that is becoming the
smart device everybody cariies. Having a foot there via monoDroid/monoTouch without the smell of "other company"
might lure some of the iPhone developers targeting all mobile platforms to Dotnet: IMHO one of the best platforms
if you include the Xamarin offerings.
>

>>Perhaps MS should have earmarked more CPU cycles for better code quality of compiled/linked app
>>instead of squandering it away on code generation, which is a bad way to go IMHO IAC.
>
>I don't even know what you're saying here.

One of the things Google optimizes with the GWT Java>>JS crosscompiling is agressively eliminating unneeded code,
making the amount downloaded more palatable. Something similar might have saved Silverlight.

And too much of the VS expirience is still linked to creating screens with top-level names the way VB5 did -
and en passant generating oodles of other code, which is hidden in codebehind.
Wasteful - if the dev has to read/debug for once or the code has to downloaded on hit instead of on install.