I'm primarily a Mac developer. From my outside perspective, the Windows framework churn looks enormous. The "best way" to write a Windows app went from Win32/MFC, to WinForms, to Silverlight and WPF, to WinRT, and still seems to be evolving. The preferred language has gone from C++ to C# to C++/C#/JavaScript(?), and now MS is pushing a UI framework that seems terribly ill-suited to what traditional desktop apps have done.
On the Mac side, the story has been constant since OS X first shipped: the best way to write a Mac app is to use the Cocoa frameworks, with Objective-C. There was some churn around garbage collection, and now Swift, but overall the developer story has been much more stable than with Windows.
Err we still use win32 and MFC. Plus some winforms which is a wrapper around win32 via the CLR. Not much has changed. Hell even WinRT is just a win32 wrapper. Office is a ball of win32 and MFC too.
Absolutely no one is touching WinRT or WPF apart from a few trading dashboard outfits and for win phone which is fine. It'll hang around but will still sit on top of the win32 subsystem.
Bear in mind there is very little difference between windows 1.0 code (1985) windows 8.1 code now. There's some 16 bit scum on the API but that's it.
I don't think Carbon was ever a recommended way to build OS X apps. It was basically a compatibility layer for vendors who couldn't easily rebuild their apps on Cocoa.
> Bear in mind there is very little difference between windows 1.0 code (1985) windows 8.1 code now. There's some 16 bit scum on the API but that's it.
That's like saying there's no difference between Mac OS from 1984 and Mac OS X. You're ignoring the shift from DOS-based Windows to the NT (New Technology) version which is more like VAX VMS (and had the same lead author). There were also some major changes with the introduction of .Net and the CLR.
You can take a program from the "MSDOS Encyclopaedia" which contains a windows 2.0 programming section, type it out in notepad on a windows 8.1 box, compile it and it will run now like it did in 1988. I tried it. It works.
That's what I'm talking about.
The kernel and CLR are irrelevant. Proof: the same program works on Wine on Linux after it is compiled.
I'm doing iOS now, but for Win I would choose Delphi if the price was not absurdly high. WinForms, WPF, Silverlight does not produce a self sufficent app. Qt is a great choice for Win, but about $4k per developer/year (for self sufficent app).
Cannot use Lazarus for DevExpress does not support it. Their amazing UI components and native nature of Delphi lets you build visually attractive and very fast and robust applications.
That's not a fair comparison at all. You listed pre-year-2000 tech for Microsoft, but not for Apple.
A fair comparison would include Apple's complete 180 from Mac OS 9 to OS X.
Furthermore, Microsoft has never once said that any of those are the "best way" to write a Windows app. They may give you more choices than Apple would ever give you, but they don't say "this is the best way" to write a Windows app.
Win32 is the core API of Windows and that fact hasn't changed since Windows 95. Winforms is simply a .NET wrapper around that API. You can even run pre-Windows 95 apps on Modern windows without an extremely heavy-handed emulation layer like Carbon.
I agree with your point about the time scale, but OS 9 and OS X are entirely different OSes with basically nothing in common but the name "Mac OS". It's more like releasing an entirely new OS, not shifting an OS by 180 degrees. Maybe the difference between DOS and NT is a similar comparison.
At any rate, if having a program run unchanged for the longest period of time is our gold standard, then I think MS wins. They have harmed their platform significantly by their total dedication to backward compatibility. By comparison, Apple has emphasized the quality of the platform at the expense of convenience to developers. I think Apple made the better choice for consumers (and even for developers in the long run), but it's certainly arguable.
I'd agree with millstone Every few years MS pushes a new UI framework (MFC, WTL, WinForms,WPF, WinRT, SilverLight) and abandons it after a few years. Other than Win32 which is not easy to use there really is no obvious choice which framework to use.
If I had to start a new desktop app for Windows I would probably go with Qt. I would not trust MS.
I'll concede that there was definitely more churn around the change from OS 9 to OS X. But the result was definite forward progress: the entire OS moved off of its legacy core. This was clearly a transition period, with both the legacy APIs and modern replacements clearly identified.
I don't think Microsoft's churn is like that at all. Instead it seems to reflect churn in their internal strategy. They attempt transitions, but abandon them before they are complete. There's no overall trajectory.
The latest is WinRT. Take a look at https://dev.windows.com/ . It's all about Windows 8, Windows Runtime apps, etc. Other technologies are buried. Wouldn't you agree that MS is positioning WinRT as the new preferred way to write for Windows? (If not, their messaging is terrible.)
This isn't 1998 and I'm not looking for some Mac vs PC flamewar. These are serious problems. They're making existing developers sweat, and new developers are taking a wait-and-see approach. It's hard to watch, but I'm optimistic about Nadella turning it around.
Oh, and Carbon is not an emulation layer at all, nor is it "heavy handed." Perhaps you have it confused with the Classic environment?
Have you ever actually worked professionally with Microsoft tech for any length of time? Have you followed Microsoft closely for 3 decades because your paycheck rides on knowing what's going on with them? If not, I'll forgive you for being an outsider...and yes, I meant Classic.
Microsoft has historically employed over 30,000 developers. That's a lot of people working on new software products. The "churn" you're talking about is, in fact, just more choices for you. It's crazy though you know - you don't have to use the latest thing from Microsoft! (We don't worship them like a lot of Apple-centric devs seem to do with Apple.) Sure, they're trying new things like WinRT and they'd like devs to use them. If things don't take off, they scrap them.
Who cares? You can still use a kit from 1998 (VB6) to make apps on Windows today without too much difficulty. Could you even use XCode from 2005 to make an app for OS X Mavericks? I doubt it.
According to your logic - web developers would never get anywhere because there's so much new tech/frameworks/etc being thrown at them and no corporation to tell them exactly what to choose.
I've been working professionally with Microsoft platforms since the early 2000s.
Not sure why you celebrate that Microsoft is treating everything but the latest as legacy.
His point is that after massive rework for OS X, more than 10 years ago, expertise in Cocoa has been remarkably stable and portable across their ecosystem.
Microsoft in the same time, has been through how many data access layers? How many networking/HTTP APIs? Web frameworks? GUI toolkits? All of it legacy abandonware now.
It's not free to have to continually retool to work with APIs that will still get bugs fixed.
Yes, using the 1998 API will still work. But that API will never be worked on again. Good luck if it has a bug that means something is impossible to do.
Microsoft errs on the side of throwing something out there before it's fully baked, and fixing it by introducing replacement APIs with the learnings from the first couple.
Apple's approach is to keep APIs private up until such time as they're ready to make them public, after which they commit to them and they'll be The Way To Do Things for a much longer time.
Which you prefer I guess depends on the type of developer you are.
That's a Win32 API call added for Windows 8.1 to their 1988 API!!!
As for bugs, you've never read "The Old New Thing" blog or played with the compatibility options for running executables in windows? http://blogs.msdn.com/b/oldnewthing/
They actually go as far as fixing all the bugs and backporting the actual bugs to older compatibility layers so software that relies on the bugs still functions properly when you set the compatibility OS version.
Regarding impossibility, there is literally nothing that I can't do with their APIs. Find something and I will show you.
Win32 is the only API that can be used in the long run and is maintained and improved by MS.
All the other APIs like WinForms, WPF, MFC, Silverlight, WinRT get abandoned after a few years. Yes, they still run but you end up with a codebase that uses outdated tools without a good migration path to a never API.
It would be really nice if they would actually stick to something.
On the Mac side, the story has been constant since OS X first shipped: the best way to write a Mac app is to use the Cocoa frameworks, with Objective-C. There was some churn around garbage collection, and now Swift, but overall the developer story has been much more stable than with Windows.