When you work with the Microsoft stack, except for a few core technologies, you have no idea if the "hot" API or current solution Redmond is pushing will be supported or abandoned in a couple of years. Combine that with stapling Metro, a tablet/phone API to the side of the desktop in Windows 8, many developers I know are tired of being thrashed and burned.
As a developer/analyst/admin that works primary in the MS application/data realms, I'm bummed out that MS can't communicate with developers and seems very disfunctional vision-wise. But as someone who also uses OSS software and OSS OSes, I'm not tied to their whims. Neither are a growing number of my clients...
This is in Microsoft's DNA. The more you're re-writing your apps "because everyone will have feature X of platform Y" the more you're not writing web apps that will ultimately make their platform irrelevant.
By iterating on non-compatible releases, you're forced to run on the upgrade/rewrite hamster wheel to take advantage of that feature the last version didn't quite have but should've.
"Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET - All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That's probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can't spend writing new features"
What are your alternatives? OSX, where Apple has no qualms about abandoning technology, hardware or software, within a matter of years (the iPad 1 was EOL'ed just shy of two years old, I believe).
XCode and (Snow) Leopard? No such luck.
Now, you do mention the Linux alternatives, which seem to be the most stable... if you can get around any infighting of QT... Gnome/KDE... etc et al.
But it doesn't seem particularly "fair" to imply that this is something of a risk when you choose Microsoft.
The Apple situation's slightly more complex than that: they're certainly ruthless with their hardware, but it's a bit of a stretch to claim they have commitment issues with their software technologies - ObjC, Foundation and AppKit's been around since the late 1980s from NeXT without serious architectural changes; UIKit'll be around for a while yet; let nothing come between them and their investment in the Apple Compiler Group. (The upshot is that they've sufficiently abstracted hardware away anyway, so hardware changes aren't showstoppers.) If anything, they're more conservative with tossing out the SDKs than most: OpenGL support, for example, is still absurdly piss-poor, even if they're getting better with their GPU driver support. But it does net you compatibility all the way down their HCL - at the bottom end, for example, is the mid-'07 iMac with the ATi 2600 PRO.
They do give not-so-subtle hints to hand over to them the cha-ching, though, when they EOL old versions of XCode - but that's usually the most you're going to encounter. So works Apple in general.
> The Apple situation's slightly more complex than that: they're certainly ruthless with their hardware, but it's a bit of a stretch to claim they have commitment issues with their software technologies - ObjC, Foundation and AppKit's been around since the late 1980s from NeXT without serious architectural changes
And if you happened to bet on those technologies instead of Carbon, you're probably very happy with that. Well, unless you were writing Cocoa apps with Java, which was pushed as a peer to Objective-C in much the same way that Carbon was presented as a peer to Foundation and AppKit. Those technologies all got killed pretty viciously, even though Apple at various points actually seemed to be promoting them over Objective-C/Cocoa.
Apple axes stuff faster than Microsoft is even capable of moving. Looking directly back from their current technology stack, it looks like mostly smooth sailing, but that's because you're not looking at the wreckage to the left and right.
(Bonus points: Remember when Apple were all about Garbage-Collected Objective-C until they weren't and suddenly ARC was the new hotness?)
Apple obsoletes older technology, but it doesn't introduce dozens of redundant technologies only to drop them. There's a difference between keeping up with a linear path of progress and jumping from API to API without any clue as to which one is the "right" one.
You can compile for Leopard and Snow Leopard by dragging the appropriate SDKs into /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/
But you can't run Xcode on Snow Leopard any more (well, the current version). Admittedly not as much of an issue, as it seems Mountain Lion solves at least some of Lion's pain points.
Option 1. Use a third-party abstraction library to make the same code work on every platform. Unity [1] is a popular commercial solution. FOSS solutions include jMonkeyEngine [2] (oriented toward PC games) and libgdx (with a focus on mobile) [3].
Option 2. Instead of writing for Windows, write for Wine. If your program runs in Wine, it should run in Windows (the reverse, alas, is not necessarily true). And you also get support for any platform Wine runs on, including not just Linux, but apparently Intel Mac [4].
I think Apple's foundational technologies have been fantastically stable since OS X came along. It's been pretty much the same solid core since 2001, from OS X 10.1 through iOS 6.
The only major piece to go away was Carbon, which was pretty much just for OS 9 backwards compatibility to begin with.
I use many of the same classes and techniques in iOS today that I did in the very beginning of learning OS X programming.
What do you mean by "abandoned"? Isn't pretty much everything Microsoft releases supported on its original platform for at least 10 years? With OSS software and OSes, do you get better support guarantees?
Thats a bonus for existing applications, but not when choosing a technology for a new one. If your technology gets shelved, you won't be able to grow with underlying framework. Now new interesting stuff for you, except if you rebuild.
Apple for example takes a different route: they have shorter support spans, but rarely invalidate whole technology stacks. Cocoa is still alive and kicking after all those years.
> Apple for example takes a different route: they have shorter support spans, but rarely invalidate whole technology stacks.
Carbon programmers beg to differ.
(Full disclosure: I was always a Cocoa guy, so this isn't sour grapes. But if you were paying attention to the OS X development scene as a whole, it was really shocking how fast Carbon went from being more actively developed and having support for more things than Cocoa to being thrown straight into the dumpster.)
Since being renamed from OpenStep, Cocoa has gotten hardware-accelerated graphics, two new (one since-deprecated) semi-automatic memory management schemes, 64-bit support, a hardware-accelerated animation system, a new fine-grained security model, closure-based concurrency, and cloud storage support. And yet it's still largely compatible with and recognizable as the framework with which the first web browser was built. And it's still a first-class citizen that Apple uses to write their own apps - it's not just being kept around in maintenance mode.
Silverlight, MFC, ATL, Active Server Pages (pre-ASP.NET), MSN Messenger, Windows 7 desktop gadgets, Windows Phone 7, Windows 8 RT (wait, I got ahead of myself - give it a few more months).
I have no problem targeting Silverlight because Silverlight is not the "stack" in that case. XAML and .NET are, both of which are viable for the foreseeable future.
Any other examples?
> When you work with the Microsoft stack, except for a few core technologies, you have no idea if the "hot" API or current solution Redmond is pushing will be supported or abandoned in a couple of years.
The situation is no different for other software vendors.
This email was sent out to DirectX/XNA MVPs today:
The XNA/DirectX expertise was created to recognize
community leaders who focused on XNA Game Studio and/or
DirectX development. Presently the XNA Game Studio is not in
active development and DirectX is no longer evolving as a
technology. Given the status within each technology, further
value and engagement cannot be offered to the MVP community.
As a result, effective April 1, 2014 XNA/DirectX will be
fully retired from the MVP Award Program.
There’s actually a fair bit of information packed in there, and I think some of it is poorly worded. The most stunning part of it was this: “DirectX is no longer evolving as a technology.” That is a phrase I did not expect to hear from Microsoft. Before going to “the sky is falling” proclamations, I don’t think this is a death sentence for DirectX, per se. It conveys two things. Number one, DirectX outside of Direct3D is completely dead. I hope this is not a shock to you. Number two, it’s a reminder that Direct3D has been absorbed into Windows core, and thus is no more a “technology” than GDI or Winsock.
The message said “DirectX is no longer evolving as a technology.”
That is definitely not true in any way, shape or form.
Microsoft is actively investing in DirectX as the unified
graphics foundation for our key platforms, including Xbox
360, Windows Phone and Windows. DirectX is evolving and
will continue to evolve. For instance, right now we’re
investing in some very cool graphics code authorizing
[sic] technology in Visual Studio. We have absolutely no
intention of stopping innovation with DirectX,
and you can quote me on that.
Can someone change the title? This is written at the bottom of the article:
Updated: Microsoft has emailed Promit Roy to say that the first email was in error, and that “DirectX is evolving and will continue to evolve.” Like Roy, though, we’re still musing as to why it took a leaked email for Microsoft to clarify its stance on DX and XNA.
The writing has been on the wall for a while about the end of XNA development by MS - none of the development tools for XNA have been updated to work in Visual Studio 2012. Fortunately, there's an open source replacement that run on a much broader range of platforms: https://github.com/mono/MonoGame
This news explains a lot about St. Gaben's new found love for Linux. Combine Microsoft's attempt to embrace and extend* into reselling software on its platform, with MS not keeping DirectX ahead of OpenGL; and it is no wonder Gaben jumped into Linux development the way he did.
XNA was a POS and honestly, DOA. Microsoft tried to simplify game development on top of C# but even indie-developers opt'd to go the C++ route with a 3rd party cross-platform engine.
Plus as a game developer, if your game is successful enough to need to build a bigger engine, wouldn't it make sense to just rewrite it on top of C++/Direct3D anyway?
Otherwise a few fixes here and there to a game you've written in XNA will still continue to run on Windows/Xbox. I mean, you can still run VB6 apps for example and that runtime DLL is almost 15 years old :-).
The Dishwasher, Elysium [EDIT: actually called Dust: An Elysian Tale], Eufloria (the first version), Terraria, Magicka, Skulls of the Shogun, Bastion, Breath of Death VII, Weapon of Choice, Fez, Sol Survivor, and The Harvest, to name ones that I can remember off the top of my head.
This doesn't include games in the pipeline that are being built in XNA.
EDIT: Forgot Penny Arcade's On the Rain-Slick Precipice of Darkness 3 and 4 (forthcoming).
What? XNA attracted many new developers to the Microsoft stack. Many of them graduated to C++/DirectX, but many nice games were also built in XNA. Now, what does Microsoft have? Convoluted C++ code and super low-level API? Thankfuly we have great OSS projects out there like SharpDX [1] (for C# lovers) and ANX [2]/MonoGame [3] (for higher-level API lovers)!
Woa. DirectX used to be the most oft updated MS product. I never got into it, but I thought the Xbox cross-platform dev and community vetting of games was cool.
As a developer/analyst/admin that works primary in the MS application/data realms, I'm bummed out that MS can't communicate with developers and seems very disfunctional vision-wise. But as someone who also uses OSS software and OSS OSes, I'm not tied to their whims. Neither are a growing number of my clients...