+1 martin
________________________________________ From: Development <development-boun...@qt-project.org> on behalf of Randall O'Reilly <randy.orei...@colorado.edu> Sent: Friday, December 04, 2015 8:35 AM To: Marc Mutz Cc: development@qt-project.org Subject: Re: [Development] RFC: more liberal 'auto' rules? 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.. 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 <marc.m...@kdab.com> 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 <marc.m...@kdab.com> | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt Experts > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
