On December 4, 2015 08:35:19 Randall O'Reilly <[email protected]> wrote:
> This debate between the std:: lib and wider C++ community vs. the Qt > traditions seems never-ending :) At the risk of perpetuating the inevitable > flame war, my perspective is well captured in this article: > http://simpleprogrammer.com/2012/12/01/why-c-is-not-back/ > > C++ is WAY too complex of a language, and other alternatives are rapidly > gaining users (particularly Python in the domain of scientific computing). > The STL and its sea of recursive templates has in particular been incredibly > daunting. C++11 helps, but the complexity remains.. > > Of course, there is no “right” answer in any of these language debates: only > different people optimizing different ends of many different fundamental > tradeoffs. > > C and C++ in general tend to attract people who favor optimization over > simplicity / usability of the language. Marc is clearly in that camp, > advocating many ways of optimizing performance.. With all the new language > options, presumably those that stick with C++ are even more apt to be > obsessed with performance.. > > But Qt is beloved by many (myself included) because it provides a *simple*, > elegant, well-designed, well-named API, that does a lot of stuff.. Not > because of its optimal performance or cutting-edge language features and > adherence to the C++ standard.. Hmm, do you really believe we cannot improve? If you compare signal and slots with resumable functions it looks quite complicated for many use cases. Look how complicated our network API is. It could be much easier with resumable functions. I don't say signal slots should go away but should be used in places their they have still an advantage. Ranges are quite nice too. With Qt we made C++ of the nineties much nicer but now C++ is incorporating many advanced features for concurrency and other areas from C#, Python and other interesting languages. The world is changing and we should adapt to this changing context. > I got “stuck” in C++ for historical reasons: it was the only viable option > for object-oriented programming in the 1990’s. Sure, I care about > optimization for my critical inner loops. But for everything else, I really > wish it was a lot simpler. And again, I value Qt for making it so in the > GUI, which consumes a huge amount of my code, and has minimal performance > demands, because it is a GUI and the human in the loop is almost always the > rate limiting factor. Of course we don’t want exponential slowdowns with > large numbers of Widgets etc, but I’ve never found that to be a problem in Qt. > > So anyway, this is just a vote to keep with the solid tradition of favoring > simplicity, clarity, usability, readability, etc, instead of just following > the std:: C++ crowd! Without Qt, I would have to suck it up and rewrite > everything in Go or Python or something.. :) > > - Randy > >> On Dec 4, 2015, at 12:49 AM, Marc Mutz <[email protected]> wrote: >> >> On Friday 04 December 2015 02:56:11 Thiago Macieira wrote: >>> On Thursday 03 December 2015 14:14:19 Thiago Macieira wrote: >>>> That depends on how big the remainder is. I argue that we're relevant >>>> enough that our own direction is big enough to be of relevance. >>> >>> That didn't come out right. Rephrasing: >>> >>> Qt has enough market share by itself that we can choose our own direction >>> and still be relevant. We are allowed to disagree with what others do. >> >> Yes, but only if we know *better*. >> >> I very much doubt that more than very few people in Qt development have the >> knowledge to objectively overrule the accepted C++ authorities. I myself >> have >> seen over and over again that how I thought a feature should be used was >> blown >> to smithereens by members of the committee, usually rightfully so. >> >> So the default should be to follow what the greater C++ community is doing, >> while *divergence* from that needs to be argued for. >> >> Everything else is approaching hubris, imo. >> >>> we don't use exceptions >> >> ...and look at the sorry state of error handling in Qt - every class does it >> differently... It's ok not to use exceptions, but not having a consistent >> error >> handling strategy doesn't put us into a position to throw that stone. >> >>> we don't use underscores >> >> ... except we do (grep "qt_"). And there's *nothing* wrong with that! >> >> Thanks, >> Marc >> >> -- >> Marc Mutz <[email protected]> | Senior Software Engineer >> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company >> Tel: +49-30-521325470 >> KDAB - The Qt Experts >> _______________________________________________ >> Development mailing list >> [email protected] >> http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development Sent from cellphone _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
