[Development] Question about Qt's future

[André Pönitz]

On Mon, Apr 21, 2014 at 10:53:01AM +0200, Kevin Krammer wrote:
> The language "barrier" between C++ and QML makes it easier to see where UI 
> ends and program logic begins, leading to better abstraction between core 
> application and its interface.

The compulsory QML/JS - C++ language cut generates otherwise uneeded work
on the user side as well as significant tooling (refactoring, debugging,
profiling...) problems. In a typical Qt Quick application the cut usually
goes straight through the middle of the Controler part of a classical
Model-View-Controler setup, i.e. sits in a pretty bad (and expensive...)
location. It's a sink of resources.

Sure, in theory, with a lot of discipline, project policy, and some luck in
prediction making, it would be possible to e.g. do only View related things
in QML/JS and align the language cut with the View-(Controler and Model)
cut, but in practice any crossing of the divide takes some effort and so
it's often "easier" to simply do some of the Controler work on the QML/JS
side (read "make the bindings a bit more complex"). On the other hand there
are (at least for non-toy applications) Controler bits that need to live on
the C++ side for performance reasons. So parts of the controler do end up
in QML/JS, others in C++, putting the language cut in an awkward place.

Having M/V/C boundaries not properly "worked out in code" while developing
a long lived application is not necessarily bad, as long as one keeps the
idea in mind, and properly does the separation on an as-needed base as the
application grows and gains in functionality. If the project is
"unilingual" this usually just means introducing some interface and some
mechanical refactoring, often enough supported by "native" tooling for the
chosen languange.

Having an enforced language break in the system takes away this
flexibility, leaving essentially the options (a) to accept the need to
re-write parts of the system in the "other" language once the time comes,
or (b) to use a waterfall style development model, fix the V/M/C boundary
before coding starts (and ignore future uses that might need some 
wiggling). I presume we agree that neither sounds good.

Andre'