[Development] Views

[Lars Knoll]

On 6 Jun 2019, at 11:08, Simon Hausmann <Simon.Hausmann at qt.io<mailto:Simon.Hausmann at qt.io>> wrote:


Am 06.06.19 um 10:42 schrieb Mutz, Marc via Development:
On 2019-06-06 09:47, Simon Hausmann wrote:
[...]
However I don't find your arguments that find_if/lower_bound is not
harder to read convincing. I continue to agree with Joerg and Tor Arne
and feel that the API of the associative containers results in code that
is more compact, visually less noisy and consequently easier to read.
[...]

Well, yes, put that way, sure, it's more (source) code, and more noisy.

*But* it's not "hard to read" in the sense that you stare at it and
can't figure out what the hell the code is doing. For that, you need
to go to qgesturemanager.cpp (which, incidentally uses all the nice Qt
container APIs to make an unreadable mess of things). Algorithms need
some getting used to, but if people would stop fighting the urge to
bash everything looking even remotely STL-ish as unreadable, they
would find that it's quite ok.

The question I have, after all this talk about readability, however,
is this:

Do you guys _actually_ think that readability of Qt code trumps
_everything_?


For me the answer is "no". I believe that for the majority of Qt code we
should strike for a compromise - as opposed to "trumping everything" -
and certainly use more low-level code in areas that we know are
particularly performance sensitive. That includes for example the
software rasterize, the inside of QString or the text shaping.

I fully agree here. Readability doesn’t trump everything and I don’t think anybody ever claimed that. But _maintainability_ of our code base does matter, especially given that we do not have an unlimited amount of developers working on Qt.



I'd rather agree with our Chief Maintainer who said, on
https://codereview.qt-project.org/c/qt/qtbase/+/114327:

IMO, we should use whatever is most efficient for our internal data
structures.

I stand by that comment. But please remember that this still means that our internal code has to be maintainable. It doesn’t help us if someone writes a super efficient implementation that nobody understands or can work with.

In my experience, more efficient data structures will in many cases lead to better and more readable code. If they don’t, one should re-evaluate whether the change is the correct thing to do and also weight in ease of maintenance.

IMO, that hits the nail on the head: we have an obligation to our
users to use the most efficient data structure (and, by extension,
looping construct) we possibly can, and can't just pop in the first
data structure that comes to mind.

IMNSHO, you can optimize for readability in your own app and see
whether you sustain in the market. In a library, used on millions of
machines every day, spending 8KiB (or 4KiB, or just 1KiB) just to use
a slightly less noisy code version is - sorry - selfish. If you
contribute to Qt, you should be putting yourself in the service of
it's users.


Yes, we have an obligation to our users and we have an obligation to the
rest of the community that's developing Qt. I strongly suspect that you
are in fact in agreement with me that the code that we have in code must
strike that compromise so that others in the project continue to feel
comfortable to read, understand and modify the code and yet we can
deliver a product to our users that's competitive in terms of
performance (run-time, code size, etc.).

What we appear to disagree on is the exact line of complexity / style /
noise. We also don't have to see eye to eye on this, I think. I think
that simply leaves us with the established decision making process,
where with our changes we have to appeal to the approvers in the project
and rely on the lazy concensus here. In the context of that, I note your
strong objection to Joerg's statement while I agree with Joerg.

As said above, I don’t think better performance has to conflict with readability of the code. If it does, maybe think whether you could solve this differently.


I have the feeling that some participants of these discussions thought
they joined an adulation club for Qt API lovers instead.


I don't quite understand what you're trying to say with adulation club
for Qt API lovers. Could you explain this, please? Am I supposed to feel
insulted or offended?

Not sure what to say to this neither.

Let’s remember that a large part of Qt’s success has been due to its API. Making programming easy and fun has been at the core of what we’re doing and it has to stay that way, or we’re really loosing the core of what made and makes Qt successful.

Many of our users strongly feel (and IMO rightfully so) that STL is a difficult API that’s maybe very powerful for the things it does, but at the same time hard to use and where it’s very easy to get things wrong. Qt solved a lot of that pain.

Yes, our classes might not be quite as performant in all cases, but they do get the job done. And they do help our users to write code they feel comfortable maintaining, something that is in most cases much more important to them than another few percent of performance.

Cheers,
Lars



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190606/d8520e89/attachment.html>