[Interest] What you don't like about Qt

[Roland Hughes]

On 09/23/2016 06:18 AM, Konstantin Tokarev wrote:
>
> 23.09.2016, 13:50, "Roland Hughes" <roland at logikalsolutions.com>:
> [snip]
>> What I don't like right now about Qt is the 3-legged arthritic dog
>> running in deep snow called QML. It was a bastardized concept when first
>> conceived and it hasn't gotten any better.
> I think it isn't OK to attack a work of other people for its mere existence.
> QML has large user audience which likes it and makes beautiful applications
> with it, and at the same time nobody is planning to kill Widgets anymore.
Every project needs to have its warts identified so they can be removed. 
QML has become a serious wart and it appears Digia is on the path to 
killing or orphaning the C++ stuff when they develop things for QML first.
>
>> Nokia started that concept
>> which explains why they are non-existent in the phone market today.
> Nonsense
Believe it or not, it is true. QML didn't pan out for them. Microsoft 
realized just how weak Nokia had become and consumed them to push 
Windows phone which had about the same success as Zune. The side effect 
was kicking Qt out the door to Digia.

https://en.wikipedia.org/wiki/Zune

Windows based "smart" phones are virtually non-existent in sales. The 
only thing keeping Nokia afloat is legacy flip. Sorry, could not quickly 
find a post using 2015 numbers like this post using 2014.

https://techcrunch.com/2015/03/03/led-by-iphone-6-apple-passed-samsung-in-q4-smartphone-sales-1-9b-mobiles-sold-overall-in-2014/

I did find one with a difficult to interpret graph spanning 2010-Q32015 
which shows the dramatic Nokia market loss.
https://www.statista.com/statistics/263355/global-mobile-device-sales-by-vendor-since-1st-quarter-2008/

And this one which kind of spells out what bad decision on top of bad 
decision on top of bad decision has resulted in.
http://www.theverge.com/2015/7/8/8913365/microsoft-lumia-windows-phones-strategy-2015

>
>> The desperate grab for licensing revenue has them trying to make Qt all
>> things to all people serving multiple masters. It will fail as
>> everything which came before failed. You have to focus on one or two
>> things and do them well. Remember how Java was going to cure cancer and
>> end world hunger being used within every embedded device on the planet?
>> The VM got so bloated trying to be all things to all people it can't
>> even FIT on the embedded targets which were its original target. Don't
>> tell me about how well it works on a Pi with 1-2Gig of RAM. It was
>> originally targeted at single CPU (not multi-core) embedded processors
>> with under 512Meg of RAM. Before you quibble there are millions of those
>> things shipping in products every year. Not long ago I worked on such a
>> device. It will ship 5-7 million in the next 3 years because it is the
>> replacement/upgrade for multiple devices, one of which has an installed
>> base of 10+ million globally.
> There are many devices having under 80M of RAM available for applications,
> and, thanks to Qt, it's possible to develop apps for them as well ;)
Yes, with C++. Not a bloated scripting tool. Just take a look at how 
badly QML runs on the Raspberry Pi with a quad core and Gig of RAM.
http://www.logikalsolutions.com/wordpress/information-technology/raspberry-qt-part-12-qml-blows-big-stinky-chunks/

>
> [snip]
>> Over the past 5 months I have seen at least 3 C++ OpenGL reqs in my
>> inbox for every C++ Qt req. Most of these are coming from sites which
>> used to send out C++ Qt reqs. The situation has gotten so bad people are
>> once again started to work with polyForth.
>>
>> http://raspberryalphaomega.org.uk/2013/02/03/memory-map-thoughts-for-a-bare-metal-system/
>>
>> I haven't seen polyForth since the 80s but it's coming back.
> Wow, that's spectacular!
>
Well, shocking at least. The Forth dictionary made it almost impossible 
to change jobs. The "core" or "standard" dictionary was very tiny back 
in the day. Every shop developed their own dictionary that most worked 
with. We had a similar problem with COBOL in the 80s. Shops had built up 
massive copy-libs for everything in the name of code re-use. Sadly, it 
made new-to-the-shop COBOL developers nearly useless to the shop for 
months and in some cases years because they had to spend so much time 
learning what was where.

The C++ version of Qt was the first product to actually try to solve 
this problem in a cross platform manner. Java failed miserably at it, 
basically making the COBOL copy-lib problem a global 
Java-class-from-where problem. With C++ Qt it was all under a single IDE 
with a single set of interactive documentation. This trimmed spin up 
learning curves from months to just a few days when bringing developers 
onto projects.

With QML you end up having an incredibly slow running application and 
returning to the "months" time frame spinning developers up on a project.