Linked by Thom Holwerda on Fri 13th Jul 2012 23:39 UTC
Thread beginning with comment 526886
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: Too many platforms
by PieterGen on Sun 15th Jul 2012 14:38
in reply to "RE[4]: Too many platforms"
"The more serious problem on Linux is fragmentation........As a result, the experience is rarely consistent"
I am not a coder. I am a power user, and I do some sys admin and user interface work. So excuse me if I am wrong - here we go - Actually I find Windows more fragmented then Linux. Windows has xp, vista, 7, 8; various servers; WinPhone 7; winphone8; now we have a seperate ARM version (was there a lack of Windows-versions??); home/student/enterprise/professional/media/ etc versions; English/French/Spanish (Windows has seperate programs for every language - the concept of language packs was too simple I suppose?); a jungle of licenses and activations; and a general tendency to make simple things very complicated.
The linux landscape is for me (as a non-expert) much simpler. Yes, some applications requiere certain frameworks, but I never had problems with that..... might be different if you code though.
Edited 2012-07-15 14:42 UTC
RE[6]: Too many platforms
by moondevil on Mon 16th Jul 2012 05:59
in reply to "RE[5]: Too many platforms"
Windows has xp, vista, 7, 8; various servers; WinPhone 7; winphone8; now we have a seperate ARM version
Have you ever counted the amount of Linux distributions available in Distrowatch, each with different set of APIs, many ignorant of the LSB, disparate packet systems, development tools, ...?
Just today I can see around 300.





Member since:
2012-07-15
You are now mixing ABI compatibility, API compatibility, and familiarity in the same argument. Qt 4 is very similar to previous Qt versions. I have been programming in Qt since the early Qt 3 versions, and the switch from Qt 3 to Qt 4 was simple for programmers in terms of familiarity. The leap from an older Qt version to Qt 4 will be very small compared to e.g. the Win32 API to WPF.
API compatibility between Qt3 and Qt4 is not perfect, but acceptable. For many classes that were deprecated, there are (Q3*) classes, so that the old functionality is still available.
The ABI compatibility between Qt versions is not so good, e.g. 4.8 is guaranteed to be binary compatible with 4.7, but that is all you get. Of course, you can still run older precompiled applications using older Qt libraries.
In the preceding discussion the argument was around familiarity. People say that Microsoft asks developers to learn a new API every few years or so. The transition between Qt versions was non-disruptive, evolutionary, and simple. So, I don't think that the argument that Qt released 4 major versions in the last 15 years really applies. It's not as if Qt programmer had to learn a completely new framework.
The more serious problem on Linux is fragmentation. People do not just use Qt, they use Qt, GTK+, wxWidgets, or even Tk and many permutations of other libraries. As a result, the experience is rarely consistent.
The APIs of Windows are more clouded in this respect. Some people will argue that WinRT and WPF both use XAML, and consequently are very similar. Others will argue that they are completely different APIs. For companies making a new product, it is a difficult choice, Metro could be the future, so developing an application using WPF could be deprecated soon. On the other hand, if Metro flops, having developed a WinRT application would've been a waste of time.
On the other hand, although I am not a Windows developer, I think such arguments tend to be overstated. In a serious application, UI code will only be a fraction of an application. If the underlying application is written in a .NET language, it's probably not too hard to target WPF or WinRT at will.
Right. People often forget Carbon, or how Apple pushed Cocoa on Java, to deprecate it just a few years later. Or how Objective-C garbage collection was the next great thing, to deprecate it in no-time for ARC. The gcc -> llvm-gcc -> clang switch in a short amount of time was also not pretty, with everything from small codebases or Haskell compilers breaking every few months.