5 ms·

Disagree. Been building "apps" since when they were called programs for windows, Unix and Mac. Windows is the great constant, has the greatest overall power and

Disagree. Been building "apps" since when they were called programs for windows, Unix and Mac. Windows is the great constant, has the greatest overall power and flexibility. Unix is a mess of portability and build problems, mac has incredibly high framework churn and low longevity but as I've said already, stuff I wrote for NT4 in 1996 works today absolutely fine and I reckon it will in another 20 years. Not only that, the market for well paying customers is huge if you ignore the volatile and unprofitable "store" model and sell bespoke and specialised stuff. Don't solve popular problems, solve well paying ones :) As for the web it's getting there but a lot of bigger clients won't touch it yet.

millstone 12y ago
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.
- monstermonster 12y ago
  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. Mac... You forgot carbon...
  - snowwrestler 12y ago
    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.
  - 72deluxe 12y ago
    I too occasionally use MFC but my word do I hate it.
  - scholia 12y ago
    > 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.
    - monstermonster 12y ago
      Actually no. 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.
      - scholia 12y ago
        And a bran new Intel Core-M chip will execute an antique x86 instruction. So obviously that proves nothing has changed ;-)
- mihaela 12y ago
  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).
  - blub 12y ago
    Actually I would suggest the LGPL Qt if you can use that license. And it should be about 1500 EUR per year nowadays.
  - 72deluxe 12y ago
    Ever tried Lazarus and Free Pascal? That might be a cheaper route for your Delphi/Windows paradise, no?
    - mihaela 12y ago
      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.
- ZanyProgrammer 12y ago
  Don't forget VB6!
- WorldWideWayne 12y ago
  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.
  - maxxxxx 12y ago
    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.
    - monstermonster 12y ago
      We still use win32 with a light weight C++ abstraction we wrote ourselves (like MFC but better). It's not really complicated or hard. MFC+Win32+WinForms are equivalent with different wrappers. So is WPF/WinRT/Silverlight so that's actually only two tech platforms.
      - maxxxxx 12y ago
        I agree that going with Win32 + your own wrapper is probably best in the long run. As far as WPF/WinRT/Silverlight go, they are different enough that it's hard to exchange any code between them or port from to another.
  - millstone 12y ago
    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/ 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.) Characterizing these development options as MS giving developers "choices" is crap. WPF developers aren't excited about having WinRT as another choice, they're worried that WPF is abandoned and their investment is obsolete. They saw it happen to Silverlight. See http://pragmateek.com/is-wpf-dead-the-present-and-future-of-wpf/ http://pragmateek.com/is-wpf-dead-the-present-and-future-of-... for example. See http://channel9.msdn.com/Events/Build/2014/2-563 http://channel9.msdn.com/Events/Build/2014/2-563 too. 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?
pyre 12y ago
> stuff I wrote for NT4 in 1996 works today absolutely fine and I reckon it will in another 20 years What about: - Plays For Sure? - Silverlight? - ActiveX? - 16-bit apps? - DOS apps? - etc... I'm sure any of the stuff that you wrote for Windows For Workgroups doesn't still work. I think that your 20 years prediction is entirely too optimistic.
- monstermonster 12y ago
  Plays for sure was no different to iTunes DRM and m4p files. It died because no one wanted it. Silverlight was a dead end I agree but it is still officially supported. ActiveX is still supported. It's just COM. 16-bit apps and DOS apps worked until everything went 64-bit. Win7 32-bit could run DOS apps. This is a processor limitation. NT had a VDM subsystem for this. Win32 abstracts away WFWG stuff so I'm not sure what your point is. I'm writing this on a windows NT machine with 512Mb of RAM running win32 and WPF for ref (win phone).
  - pyre 12y ago
    > Silverlight was a dead end I agree but it is still officially supported. For how long though? The parent post was talking about everything working 20 years into the future. > ActiveX is still supported. It's just COM. Are you disputing that there are companies still out there that have internal apps reliant on IE6? I'm not saying it's smart, but at this point keeping IE6 going has to be work. If they could upgrade, why wouldn't they? > This is a processor limitation. When you are predicting that your 18 year old app will continue to function out-of-the-box for another 20 years, how is hardware not a factor?
    - monstermonster 12y ago
      Yes 20 years no problems for windows API. Look how old the Unix API is. Not Silverlight although most of that is portable straight to c#+WPF deployed via ClickOnce with a few hours' work. We have a company that has IE6 and XP deployed to over 1000 workstations. IE11 does ActiveX still. We use it via WebTwain to scan documents from a web app via a drum scanner. It works very well. Hardware is not a factor. Don't forget that x86 is well over 30 years old already, isn't even CISC under ISA any more and there is virtualization and emulation as well. I saw windows 95 booting on a wrist watch in the tech press the other day.
72deluxe 12y ago
"high framework churn" - an excellent description of the relentless API changes in Apple land, if I may say so. It is comforting to be able to run ancient applications on Windows compared to the inability to run apps built for Leopard on Mavericks (or even Snow Leopard), let alone anything from the Rosetta days (Homeworld 2 is now a useless game to me on Mac OSX).
- to3m 12y ago
  On a similar note, there's a little note about garbage collection's grim future here, at the end: https://developer.apple.com/library/mac/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html https://developer.apple.com/library/mac/releasenotes/Objecti...
  - 72deluxe 12y ago
    Would you say that ARC is a suitable alternative? I'm not "in the know" about such things.

millstone 12y ago

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.

monstermonster 12y ago
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. Mac... You forgot carbon...
- snowwrestler 12y ago
  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.
- 72deluxe 12y ago
  I too occasionally use MFC but my word do I hate it.
- scholia 12y ago
  > 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.
  - monstermonster 12y ago
    Actually no. 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.
    - scholia 12y ago
      And a bran new Intel Core-M chip will execute an antique x86 instruction. So obviously that proves nothing has changed ;-)
mihaela 12y ago
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).
- blub 12y ago
  Actually I would suggest the LGPL Qt if you can use that license. And it should be about 1500 EUR per year nowadays.
- 72deluxe 12y ago
  Ever tried Lazarus and Free Pascal? That might be a cheaper route for your Delphi/Windows paradise, no?
  - mihaela 12y ago
    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.
ZanyProgrammer 12y ago
Don't forget VB6!
WorldWideWayne 12y ago
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.
- maxxxxx 12y ago
  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.
  - monstermonster 12y ago
    We still use win32 with a light weight C++ abstraction we wrote ourselves (like MFC but better). It's not really complicated or hard. MFC+Win32+WinForms are equivalent with different wrappers. So is WPF/WinRT/Silverlight so that's actually only two tech platforms.
    - maxxxxx 12y ago
      I agree that going with Win32 + your own wrapper is probably best in the long run. As far as WPF/WinRT/Silverlight go, they are different enough that it's hard to exchange any code between them or port from to another.
- millstone 12y ago
  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/ 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.) Characterizing these development options as MS giving developers "choices" is crap. WPF developers aren't excited about having WinRT as another choice, they're worried that WPF is abandoned and their investment is obsolete. They saw it happen to Silverlight. See http://pragmateek.com/is-wpf-dead-the-present-and-future-of-wpf/ http://pragmateek.com/is-wpf-dead-the-present-and-future-of-... for example. See http://channel9.msdn.com/Events/Build/2014/2-563 http://channel9.msdn.com/Events/Build/2014/2-563 too. 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?

pyre 12y ago

> stuff I wrote for NT4 in 1996 works today absolutely fine and I reckon it will in another 20 years What about: - Plays For Sure? - Silverlight? - ActiveX? - 16-bit apps? - DOS apps? - etc... I'm sure any of the stuff that you wrote for Windows For Workgroups doesn't still work. I think that your 20 years prediction is entirely too optimistic.

monstermonster 12y ago
Plays for sure was no different to iTunes DRM and m4p files. It died because no one wanted it. Silverlight was a dead end I agree but it is still officially supported. ActiveX is still supported. It's just COM. 16-bit apps and DOS apps worked until everything went 64-bit. Win7 32-bit could run DOS apps. This is a processor limitation. NT had a VDM subsystem for this. Win32 abstracts away WFWG stuff so I'm not sure what your point is. I'm writing this on a windows NT machine with 512Mb of RAM running win32 and WPF for ref (win phone).
- pyre 12y ago
  > Silverlight was a dead end I agree but it is still officially supported. For how long though? The parent post was talking about everything working 20 years into the future. > ActiveX is still supported. It's just COM. Are you disputing that there are companies still out there that have internal apps reliant on IE6? I'm not saying it's smart, but at this point keeping IE6 going has to be work. If they could upgrade, why wouldn't they? > This is a processor limitation. When you are predicting that your 18 year old app will continue to function out-of-the-box for another 20 years, how is hardware not a factor?
  - monstermonster 12y ago
    Yes 20 years no problems for windows API. Look how old the Unix API is. Not Silverlight although most of that is portable straight to c#+WPF deployed via ClickOnce with a few hours' work. We have a company that has IE6 and XP deployed to over 1000 workstations. IE11 does ActiveX still. We use it via WebTwain to scan documents from a web app via a drum scanner. It works very well. Hardware is not a factor. Don't forget that x86 is well over 30 years old already, isn't even CISC under ISA any more and there is virtualization and emulation as well. I saw windows 95 booting on a wrist watch in the tech press the other day.

72deluxe 12y ago

"high framework churn" - an excellent description of the relentless API changes in Apple land, if I may say so. It is comforting to be able to run ancient applications on Windows compared to the inability to run apps built for Leopard on Mavericks (or even Snow Leopard), let alone anything from the Rosetta days (Homeworld 2 is now a useless game to me on Mac OSX).

to3m 12y ago
On a similar note, there's a little note about garbage collection's grim future here, at the end: https://developer.apple.com/library/mac/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html https://developer.apple.com/library/mac/releasenotes/Objecti...
- 72deluxe 12y ago
  Would you say that ARC is a suitable alternative? I'm not "in the know" about such things.