On 6/1/19, 9:10 AM, "Development on behalf of Philippe"
<development-boun...@qt-project.org on behalf of philw...@gmail.com> wrote:
I second a recent quote from Lars Knoll :
> Qt has always had a somewhat different philosophy. Make C++ easy to use,
> no need to use Java. The fact is that 95% of the source code our users
>write will not be performance critical. You dont want to make the pay
>the price of having a difficult to use API for those 95% of the code.
And I wish to add: the vast majority of Qt developers I have met, are
not C++ wizards.
Thanks Philippe/Lars, and Giuseppe for starting this separate thread.
This discussion reminds me of Python 2 vs. Python 3, and I think there are some
important lessons to consider from Python. I'm one of those holdouts that had
a lot of Python 2 code and saw no compelling reason to move to Python 3. Until
recently I didn't fully understand the reasons for the incompatible changes, so
it looked like a bunch of (error prone) work with no clear value. While enum
support was a nice to have, there were ways to add that to python 2. It was
Python 2 nearing deprecation and some recent features (among them type safety)
in Python 3 that got me to finally convert code this year.
Diving into that conversion led me to a very helpful blog (from one of the core
developers, Nick Coghlan) on why the changes were made in the first place:
http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html#tl-dr-version.
It is a lengthy post, so let me quote a few sections I think are particularly
relevant:
"[W]e did not see any other way to ensure Python remained a viable development
platform as developer communities grow in locations where English is not the
primary spoken language."
"It is my perspective that the web and GUI developers have the right idea:
dealing with Unicode text correctly is not optional in the modern world. In
large part, the Python 3 redesign involved taking Unicode handling principles
elaborated in those parts of the community and building them into the core
design of the language."
^^^ This is the fundamental reason for the compatibility break. Three
sentences!
"Python 3 introduced backwards incompatible changes that more obviously helped
future users of the language than they did current users, so existing users
(especially library and framework developers) were being asked to devote time
and effort to a transition that would cost them more in time and energy in the
near term than it would save them for years to come."
^^^ This is one of the major reasons for slow adoption
There is a section titled "When did Python 3 become the obvious choice for new
projects?"
"I put the date for this as the release of Python 3.5, in September 2015."
^^^ I believe this was the other major reason for slow adoption, a combination
of two issues. There needed to be compelling features to drive the transition,
and frameworks people used (numpy, nltk, twisted, etc) were slow to become
available.
I don't, at this point, have any idea what the right answer for Qt is. But
there are three factors I think we need to consider with the move to Qt 6.
1) I believe there needs to be an elevator pitch (i.e., 30 seconds or less to
tell the story) of why Qt 6 is not compatible with Qt 5
It seems like this is something along the lines of "Changes in the C++
ecosystem, specifically the compiler features added into the standards for
C++11, C++14, etc, duplicate functionality provided by Qt, but in a way
officially supported (and optimized) by compilers. Leveraging these features
is necessary for Qt going forward, but requires incompatible changes to our
APIs." I know people will disagree with the wording, if not the sentiment,
here. The point is the importance of a concise reason.
2) There needs to be a reason to upgrade
I remember Lars saying at QtCS last year that Qt 6 should be the easiest
upgrade. It wouldn't include many new features, instead focusing on fixing the
elements that couldn't be addressed without breaking compatibility; deprecation
warnings in Qt 5.x would help, i.e., upgrade to 5.15, address the deprecation
warnings, and viola - ready for Qt6.
While I understand the ease part of that plan (and agreed it was the right
approach at the time), "Upgrade to Qt 6: you may notice some performance
improvements" is not a great motivator.
If there isn't a clear benefit yet, then maybe something like "This was a
required change in Qt, to leverage the benefits of C++11, C++14 and C++17,
reduce the maintenance burden on Qt, and allow Qt to focus on bringing value to
customers in other areas. New features will be coming once we've completed
this transition." Side note: is it fair to say the additions in C++17, C++20,
etc are becoming more esoteric, in the sense that incorporation into Qt would
be less likely to be incompatible? Or should people fear Qt 7 is not too far
out?
3) Be careful of "death by a thousand papercuts"
One of the changes in Python 3 that really bugged me was converting `print`
into a function. I have to find every print instance and convert it? Why? It
doesn't add any value to my code. How many people will find switching from
qmake to cmake that pain point that delays moving to Qt6?
There is an impact to the argument "we are breaking compatibility, we should
get all of the changes in now." Any one change could be particularly painful
for any specific user and cause them to hesitate in moving to Qt 6. I think
this has been touched on over the last few days with some discussion of more
incremental API breaks. While I imagine the difficulty in maintaining
compatibility in Qt is a pain point for developers of Qt itself, I do think API
stability is one of the major selling points of Qt that has kept Qt growing for
over 20 years.
Thanks for your consideration, I just want to make sure the overarching
messages don't get lost in the detailed discussion.
Regards,
Brett
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
