> On 22 Aug 2019, at 01:56, Konstantin Tokarev <[email protected]> wrote: > > 22.08.2019, 02:39, "Kevin Kofler" <[email protected]>: >> André Pönitz wrote: >>> Traditionally, "ease of use" and "consistent API" have been a core values >>> of Qt, even consciously bought at the cost of some bytes and some cycles. >>> >>> Of course, this has meant that in certain parts of certain types of >>> applications Qt could not sensibly be used. Still, in most cases all, or >>> almost all of the code could be "plain Qt", benefiting for creation and >>> maintenance from those values. I do believe this was a sensible setup for >>> Qt, and I do think there's room for a general purpose framework living >>> that compromise also in today's world. >>> >>> During the last years (ok, let's say, starting around \epsilon A.J. - >>> "After Jasmin") this promise has been more or less silently broken, once >>> by "leaf" modules deviating, partially intentionally, from previous naming >>> conventions, then for real accidents that couldn't be corrected due to >>> too-late discovery and compatibility promises, and finally by attempts to >>> provide "high performance" alternatives in some places. >>> >>> In the end we lost uniform, easy-to-use interfaces, and the performance >>> gains are only present in very isolated areas of the offering with long >>> stretches in-between, hidden by obscure and continuously changing do's and >>> don'ts so that they are effectively not visible in real-world GUI-centric >>> applications.
A good framework is there to help our users create the applications they want to create. It’s a fact that most of the code our users write is not performance critical. Development time and the time it takes to debug and finish a product until it can be launched is much more crucial for most of our users than a couple of percent more performance. This is something to keep in mind. Ideally, we can combine both goals and have easy to use APIs that hide most of the complexity from the user, while at the same time delivering good performance. But in some cases it’s ok, to add a few cycles to make things easier for our users (and before someone cries out: I am not taking about anything that changes complexity of algorithms). >> >> The creeping STLization of Qt (deprecating some classes for STL >> alternatives, using STL classes in some APIs, etc.) is also part of this >> disturbing trend. It typically regresses both ease of use and API >> consistency in the name of the holy performance cow. > > If you don't need performance, don't use C++. For example, consider Qt for > Python. That’s a wrong argument. There are many reasons people want to or need to use C++. The UIs of apps are to the largest part not performance sensitive. Most of the time they are idling and waiting for user input. And yes, the 1-5% of the code that is performance sensitive is something you can and should be able to hand-optimise. The problem with our multitude of string classes is not only that we’re overcomplicating our API, but also that we’re adding implementation complexity for ourselves that we will need to maintain over the years to come. I would very much wish that we could find ways to reduce that complexity with Qt 6. And I’d be willing to pay with a few additional CPU cycles here and there to achieve that. Cheers, Lars _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
