The issue, as I see it, is that many developers in the Microsoft ecosystem consider Microsoft to be a trusted benefactor and are detached from the realities around software engineering today. Such developers often won't touch concepts and implementations which have been proven outside of Microsoft until they get the blessing from Redmond with a Microsoft-built implementation.
The net result is that for at least a decade or more, many Microsoft developers have lost the independent judgement needed to filter solid technologies from the over-hyped ones.
The truth is, Microsoft is a business like every other. And they have changed with the times in that they experiment a little more and admit failures a little sooner. The challenge for Microsoft is that they are still viewed as the "safe bet" by many in their own community and they have to reconcile this reputation among their base with their own ability to evolve.
I suspect that a deeper issue here is that Microsoft developers believe that Microsoft is as permanent as things get in software, and by extension that everything Microsoft releases will last forever.
Realistically, most EOL'd Microsoft development platforms had been in their period of being officially supported for no less time than it takes an open source platform to go from being the hot new thing to something that's barely worth mentioning on your resume anymore. And Microsoft still offers a lot of continuity - XNA and Silverlight may be dead and WPF might be on the way out. But those C# skills you learn on the old platforms are still usable all over the place, including in Unity (for game developers) and with Xamarin (for mobile). And those XAML skills will still hopefully be useful with WinRT. By contrast, it'll probably be a much bigger deal to switch platforms when Ruby finally becomes passe. For one, it'll take learning a whole new programming language.
Before I get jumped on, I should hasten to say that my intent isn't to criticize any open source for anything. It's to criticize the Microsoft community for developing an attitude of complacency and perhaps even entitlement.
When they're not innovating, it's a problem. When they're throwing things against the wall to see what sticks, it's a problem too. I feel like they really can't win here. Is XNA really that far off from other Microsoft platforms anyway?
It's not. You can transition to DirectX in a couple of weekends. You can transition to OpenGL (which I would call a better move) in a week or two.
The principles are all the same, everywhere you go. The names change and the exact implementation details differ, but it's the same stuff with a different hat.
> When they're not innovating, it's a problem. When they're throwing things against the wall to see what sticks, it's a problem too. I feel like they really can't win here.
There's perhaps some truth to that, but they could handle things so much better.
Some of these technologies should perhaps be in perpetual beta or something, until they decide they're going to support it long-term. The problem is that Microsoft flogs them as the blessed platform, puts out the rallying cry for all developers to come running and use this cool new thing, and then drops them like a bad habit.
Long story short: Microsoft realized that Entity Framework was taking longer than expected. But they really wanted an ORM to ship with LINQ. So they took a smaller mini-ORM project that was really written for testing LINQ and was never intended for production, hastily dressed it up, and pushed it onto the market as a stopgap. Entity Framework was still happening, mind you - Microsoft never actually planned to support LINQ to SQL long-term.
But they never really mentioned that was their plan. So a great many developers had already written data access layers based on it by the time Microsoft announced they were going to stop supporting it approximately 11 months after it was initially released.
There are always winners, losers and progress. It's fair to be skeptical about MS's future but it's only habitual because they've been at it 3 decades.
Carbon was a stopgap measure for two big companies (Microsoft and Adobe). It was very clear from Apple's actions with other technologies these companies didn't use (e.g. OpenDoc) and its messaging to developers that Carbon was not a permanent solution. Why people were surprise in the 64-bit conversion to see Carbon absent was beyond me.
Now, Apple has a whole hoard of technologies that Adobe and Microsoft didn't use that did not make the jump from OS 9.0 to OS X. OpenDoc is most famous for the youtube video where the angry developer questioned Steve Jobs. I suppose you could add Newton OS to that list, but it is more the closing of a whole platform.
In more modern times, if you started using GC, then you had to convert to ARC pretty soon thereafter.
It certainly seems clear to me (and seemed just as clear to me at the time) that Cocoa was being presented as the API of the future. Sure, Carbon is on the same slide, but so is Classic!
I could see them downplaying it early on - wasn't it the case that they only reluctantly introduced it in the first place? i.e. Rhapsody was originally envisioned with just the NeXT stuff, and it wasn't until they heard from developers that they decided to make some subset portable to the new environment.
I also seem to recall (though I'm not an expert and I certainly don't have inside knowledge) that in those first few releases both Cocoa and Carbon were evolving, sometimes at different rates in different areas. Then I remember when Core Foundation and similar C-only APIs became a thing that people talked about, which as an onlooker of the platform kind of confused me at the time - was it an admission of some inadequacy of objc?
Exactly. As I have heard it, they originally tried to sell their big developers (e.g. Adobe) on total rewrites for Rhapsody/NS/Cocoa and were more or less laughed out of the room. Carbon was a compromise.
I don't think the evolution of C vs ObjC APIs was a good proxy for the future viability of Carbon vs. Cocoa. If an API was intended for Carbon apps, it had to be C. If it was exposing core OS services already implemented in C, it was more likely to be C. Even fairly new APIs like Grand Central Dispatch have both C- and ObjC-intefaced components, based on the level of abstraction.
Just to shed some light on this. Carbon to Cocoa was a nice transition. Not as bad as how Microsoft has handled it.
I got in when it was still supported, but obsolete.
Adobe Flex and Flash are far from dead and getting better and better. There have been quite a few new developments lately, like a brand new ActionScript compiler or the insanely cool Adobe Scout profiler (http://vimeo.com/54808142), new releases of Flash player with version 11.6 in beta right now. Visit http://flashdaily.net/ to find out how "dead" Flash is right now.
Well, they killed off the non-Chrome Linux flash player, and then they completely killed off Linux AIR support out of nowhere (too bad if you bought into the whole cross development AIR platform, have fun porting your mxml to a different language and framework!), and just recently they even killed off development of "Flash Player 'Next'". They also decided to require license keys per deployment to unlock the client player if you were using stage3d and the alchemy compiler in a single app (and then they changed their minds again just a few months later).
So building products and applications on the flash player these days is quite the gamble.
