On 09/23/2016 06:18 AM, Konstantin Tokarev wrote:
23.09.2016, 13:50, "Roland Hughes" <rol...@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.
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest