[Development] Views

[Simon Hausmann]

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'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.
>
> 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.


> 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?



Simon