[Interest] Qt API annoyances: where to log/discuss?

Sun Nov 4 23:58:50 CET 2018

Il 02/11/18 19:28, Jason H ha scritto:
> 
> 
>>> The bitwise OR operator, descending multiple namespaces.
>>> It makes my point. That these very common functional programming paradigms (map, reduce, etc)  are (needlessly?) obtuse in C++.
>>
>> Sorry, what is the point? Is it hard to read, write, teach, learn,
>> understand, extend...? What is the baseline we're comparing it against?
> 
> D) All the above. I didn't understand it when I first read it and I would say I "know" C++ beyond the 50th percentile of people claiming to "know" C++. I'm sure others won't either. Can we get a vote on who understood exactly what that statement was the first time they read it? The baseline I'm comparing it against is Python or JavaScript.

Well, I'm sorry, but this isn't an argument, nor a quantifiable metric. 
Fear of the unknown beats comfort of the known every single time.

I could bring the counter argument that since I am a Unix programmer, I 
see a pipe operator, and I can understand what's going on (thing on the 
left being "piped" into the thing to the right) and it brings joy to my 
heart. Maybe I can't grasp its gory details, but I can envision how such 
a thing could be implemented, and I am confident that it can be realized 
without hidden costs nor subtle surprises.

But mine isn't an objective argument, either; we're just going back and 
forth on our own biases, prejudices, pre-existing cultures, flawed risk 
evaluations, and so on.

For a discussion about this, cf. Dan Sacks' keynote at CppCon:

> https://www.youtube.com/watch?v=D7Sd8A6_fYU

> The value proposition of Qt is that it simplifies a lot of things. If we're going to fall back on "std all the things" then Qt (pronounced "Cute", which I think has meaning here) loses a lot of value prop and I should just switch to C++-without-Qt or Python. 

Not necessarily "std". But Qt ought stop reinventing the wheel where 
such wheels are provided in an excellent way by other libraries out 
there (Boost, Abseil, GSL, to name a few).

There are at least two great ranges libraries available (Boost.Range, 
ranges-v3), one of which -- crossing fingers -- is being used as a basis 
to add ranges into C++2a, there is absolutely ZERO motivation for 
redoing the same kind of work into Qt.

If you're willing to contribute such work to Qt, by all means, go ahead; 
but expect the acceptance bar to be set extremely high.

> It is my observation that C++ is becoming a language to not write programs in, but to instruct compilers on how to build your program. (Maybe this is role QML is filling?) 

This is true but up to a certain extent. Zero cost abstractions, "don't 
pay for what you don't use", "no lower language than C++" and similar 
design philosophies, together with widespread adoption in certain 
industries, make Standard C++ evolve slower than other language. 
Sometimes these philosophies also make C++ programming more awkward than 
it should be -- giving you the feeling you're programming at a very low 
level.

Luckily things are evolving. Part of this evolution is what we call 
"Modern C++".

> If I have to dedicate hours per week to maintaining my C++latest skills (which is futile absent a useful case in my own code base) then that negatively impacts my perception of Qt. Which is frankly irrelevant anyway because my code needs to be readable **by other people**.

I don't think it's futile. But, anyhow, this is a known struggle in the 
C++ world. We don't have an answer yet, but we keep trying.

See also Kate Gregory's keynotes at MeetingC++ / CppCon:

> https://www.youtube.com/watch?v=tTexD26jIN4
> https://www.youtube.com/watch?v=n0Ak6xtVXno

> I don't know why C++ enthusiasts are so hostile to newcomers, effectively raising the barrier to entry. 

I'm sorry if you had such a negative experience; technical people may 
sound overly aggressive, but from my little corner of experience, the 
broad C++ community is very welcoming. Just try joining something like 
CppCon or MeetingC++ or ACCU.

> This plays out in non-abstract terms. C++ is the fastest declining language at TIOBE ( https://www.tiobe.com/tiobe-index/ ) over the past 10 years. There were no positive spikes around each C++0x release. This stuff is being added and it's not attracting users. Meanwhile Python is fastest increasing (at this time, it's Java, C, C++, Python, VB.NET) (I do think JavaScript is under-reported, as the web is not getting off JS anytime soon)

Which is why Qt for Python is a thing...

> Let's look at Python's map/filter/reduce ( http://book.pythontips.com/en/latest/map_filter.html )
> 
> items = [1, 2, 3, 4, 5]
> squared =map(lambda x: x**2, items)
> less_than_zero = filter(lambda x: x < 0, items)
> product = reduce((lambda x, y: x * y), items)
> 
> They are clear and readable.  What are the C++0x equivalents? (I'm really asking)

Let me play devil's advocate here, and pretend I'm a C++ developer who 
doesn't know Python. I can see the _intent_ of the above code, but I 
could also start asking questions that the code doesn't immediately show:

* What kind of data structure is used for "items"?

* Are map/filter/reduce evaluated eagerly or lazily?

* If eagerly, what kind of data structures are used for "squared", 
"less_than_zero", etc.?

* If lazily, what can I do with "items"? Can I destroy it? Can I fill it 
with new data? Will it affect the lazy computations?

* What is the complexity in time and space of these algorithms? How many 
applications of the predicate? At worst, how many memory allocations am 
I going to perform?

* What happens if I cannot allocate memory?

* Can I control how memory is allocated?

* Can I use them at compile-time to evaluate compile-time constants?

Of course, these are biased questions. A Python developer may just not 
care at all about the answers to those above questions. C++ developers 
may. And the C++ language provides ways to have these answers.

Or maybe they just don't care. (I've seen enough code that eliminates 
duplicates out of a QList by doing list = list.toSet().toList();) 
There's nothing in C++ preventing you from writing "bad" code, for some 
measure of "bad". But in C++ there are also means to write very 
efficient code. The struggle is to find a way give users tools that are, 
at the same time, correct, efficient, and easy to teach/learn, so that 
they become the natural choice.

To answer your question, anyhow, assuming you want eager applications, 
you can use ranges-v3, getting very very close to the Python equivalents:

> using namespace ranges::view;
> std::vector<int> items{1, 2, 3, 4, 5};
> std::vector<int> squared = transform(items, [](int i) { return i * i; });
> std::vector<int> less_than_zero = filter(items, [](int i) { return i * i; });

> Excellent doesn't mean anything if it isn't accessible.  Qt should invest for the benefit of its users because the C++ std methods are obtuse. If you have Qt class, you already know and have a lot lot of control about how the container works.

And we go back to the discussion about bias; in the view of an 
experienced Qt developer, "you already know" is a huge overstatement 
(just think of QList and how many people get it wrong).

Cheers,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20181104/58f7a083/attachment.bin>