No, but the way MS came out with WinRT and excluded existing .NET code from executing on it certainly didn't reassure anyone.

There is a lot to criticize about WinRT, but basing it on COM was the right call. In fact I would say absolutely essential for high-performance apps. Make all the costs of .NET (GC, memory usage, JIT) optional. CLR can still call into COM objects without problems, so all the C# fans can still go nuts.

It's hard not to see this as informed by how badly Longhorn failed. Microsoft tried to make .NET the basis of their OS platform during Longhorn and failed miserably, in part because it was simply not built for that. CLR belongs as a layer on top.

[Disclaimer: I used to work at MS. Did not work on the Windows Runtime. These are my personal opinions.]

That's not what I was questioning - see my other answer for why WinRT was not "reassuring". Now it makes sense, and I can safely not care about WinRT.

As far as Longhorn failing, certainly that was both a disaster in management and not just technology. After all, MS Corp felt generics were and impractical academic and theoretical idea that couldn't be properly implemented in a language like C# or the CLR.

If that's not what you're questioning then IMO don't phrase it as a .NET problem; it is broader than that. There is a pocket of the .NET community that talks as if they shafted .NET in favor of native code, but WinRT is probably more disruptive to the existing Win32/C workflow than it is for people writing C#.

> After all, MS Corp felt generics were and impractical academic and theoretical idea that couldn't be properly implemented in a language like C# or the CLR.

What?!

Generics were only added to .NET 2.0, because it wasn't going to be done on time for the .NET 1.0/1.1 releases.

There are papers from the .NET Beta days already describing the way generics could be implemented, but additional work was still needed at the time.

Generics were only added to .NET 2.0 because MSR got it implemented. Redmond would never have done it alone, and called it academic, theoretic feature. They may have ended up with a lameass implementation of generics, ala Java.

Here's a history by Don Syme, who was one of the main people on this project:

http://blogs.msdn.com/b/dsyme/archive/2011/03/15/net-c-gener...

Quotes:

  "But I do want to say one thing straight: Generics for .NET and C# in their current form almost didn't happen: it was a very close call, and the feature almost didn't make the cut for Whidbey (Visual Studio 2005)"
  
  "being told by product team members that "generics is for academics only""
  
  "It was only through the total dedication of Microsoft Research, Cambridge during 1998-2004, to doing a complete, high quality implementation in both the CLR [...] and the C# compiler, that the project proceeded."

Microsoft's C# track record shows MC Corp's commitment to higher-level programming pretty well, IMO. LINQ got added just to hit the "LINQ" target (and Erik Meijer mighta been a big force there). But even then: the C# 3.0 were only implemented to hit LINQ, not added as general language features. One big example: declaration type inference is half-assed and only exists to facilitate anonymous types. They've had years since to clean up the design and haven't shown any indication of doing so.

(I still think C#'s the best out of the "mainstream" languages, but they could be doing a whole ton better.)

I know those papers, like any one that cares about compiler design should know.

As for MSR vs MS Corp, as you put it.

It is called Microsoft Systems Research, it is still a Microsoft unit, with researchers on Microsoft's payroll.

So it is plain and simple, Microsoft.

C# was first to introduce most mainstream functional concepts into C-like languages: generics, lambdas, LINQ etc.

I never understood where people got this idea from.

You can target WinRT with the usual set of .NET languages, the only difference being the classes one uses.

Does C stop being C, if you don't use libc?

There's multiple things at play. Until the F# stdlib was ported, F# couldn't target WinRT. Then there's the ton of fanfare JS/HTML were given, and the fact that C#'s development has been moving at a snails pace (and the "face" of C# is now working on making JS suck less) -- eh, it makes people nervous. Plus, MS's messaging wasn't all that clear. Now I see WinRT as being for cutesy tablet apps and I'm not so concerned. But before Win8, there was a lot of confusion going on.

> But before Win8, there was a lot of confusion going on.

Which was cleared for anyone that cared to access the information available after the BUILD conference.

But hey, it is easier to form opinions based in twitter spread rumours, or something like that.

WinRT was definitely a screw-up, but at this point I don't see it really effecting developers that much. WinRT has pretty much failed as a platform. At this point, is it even worth developer time to deliver an app to that platform?

If you're talking about apps in the windows app store (so-called metro-style apps or whatever the current name is), then you're right that it meant throwing out a lot of code, but it's not true that all existing .NET code was excluded. It took some rejiggering. But once again, that's only if you want to deliver via the app store.

I think you might be confusing WinRT with the Surface RT tablets. They have relatively little to do with eachother. For example, the "metro-style apps" you mention are WinRT just as well.

Uh... WinRT excluded all existing third-party code from executing on it.

EDIT: asveikau has rightly pointed out I have confused two matters.

Surely you would not confuse WinRT, the API, with Windows RT, the ARM tablet product. Why, these names are totally unambiguous!

(Microsoft is not great at naming products.)

I agree :(