I kept out of this for the longest time, especially because people have been
quoting my blog post, but I give up now.
On zaterdag 8 juni 2019 18:14:36 CEST Giuseppe D'Angelo via Development wrote:
>
> Then, it comes a moment when "upstream" stuff has more and more
> advantages -- more speed (algorithms), more flexibility (e.g. mutex
> classes and utilities; shared_ptr; etc.), more static analysis
> tooling, and so on, than the equivalent classes offered in Qt.
Qt's problem has been that it was started as "let's make c++ accessible to
"java coding drones". So it wasn't a serious C++ library, so nobody using Qt
cared about C++ (I still don't care about C++, I don't do C++ because it's
awesome, but because I inherited a codebase that uses it), and everyone doing
"proper" C++ looked down on those undereducated morons who were using Qt,
instead of "proper" C++. And then Qt became one of the most-used C++ platforms.
Mostly because Windows developers were even more often hit by the
fire-and-motion tactics of Microsoft, and because of the web and other
languages getting useful and all of that. So now C++ people have noticed Qt,
and Qt people have noticed the C++ people, and the reaction is... Let's do more
of the stupid stuff that's been in STL. Let's write documentation that's only
accessible to CS majors, no, let's do better, let's have documentation only
accessible to CS professors!
There is NO useful documentation for STL. Just look at how ivory-tower the
documentation for std::unique_pointer is on cppreference. Good documentation
tells me "what does this, why should I care, when should I use it, how should I
use it". The cppreference documentation tells me "this is the right vocubulary
to talk about this topic, and there are these weird cornercases".
> In other words, the advantages of keeping the Qt equivalents start to be
> (seriously) questioned. We're therefore left with the question of what
> to do with these equivalents.
Like always, like I'm always being told, but dammit, we're trying to do that,
only we're not getting through gerrit, much, you should have upstreamed it. The
stl should have become Qt-like, not Qt stl-like.
> * We could play the catch-up game, but that requires a development
> investment that is simply not there any more, and is even questionable
> (is it the job of people developing Qt to rewrite algorithms widely
> available elsewhere?).
Qt never had the manpower to maintain its stuff, not even in the Nokia days.
> * We could just deprecate and tell people to migrate away. That's kind
> of the whole point of this thread, and comes with all the annoyances,
> and people reimplementing them downstream because they still want the
> convenience of a qSort(vector) over std::sort(vector.begin(), vector.end()).
It's not about annoyances. It's about not having to rewrite code, spend time,
without getting any tangible benefit in the hands of my users. The kind of
memory savings Marc Mutz keeps hammering on about are totally, utterly,
completely, devastatingly irrelevant for me. Qt churn doesn't get me any new
users, or makes any of my current users happier than they were already.
If you write a library, you only have one task: make sure your users can
deliver functionality to their users faster, better, more reliably than if they
would use another library. Making your users spend time porting, is wasting
your users time and money.
--
https://www.valdyas.org | https://www.krita.org
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
