[Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]

[André Pönitz]

On Mon, Apr 28, 2014 at 10:36:22PM +0800, Sze Howe Koh wrote:
> On 25 April 2014 18:18, Joerg Bornemann <joerg.bornemann at digia.com> wrote:
> > On 25-Apr-14 04:21, Sze Howe Koh wrote:
> >
> >> I consider QML and JavaScript to be different languages. JavaScript
> >> can be embedded into QML to extend QML's capabilities, just like how
> >> it can be embedded into HTML to extend HTML's capabilities.
> >
> >
> > Yep, I hear people keep repeating the mantra "QML is declarative. It's just
> > QML/JS that isn't." Does that buy us anything tooling-wise? No. Because,
> > even though this thought is true in essence, in practice you have to use the
> > JS part.
> >   People throw handwritten QML files full of clever hacks at Qt Creator's
> > QmlDesigner and wonder why it doesn't fully understand the magic, even
> > though everything is deemed "declarative" (== "toolable").
> 
> To check if I've understood you correctly: You've found that
> classifying QML as "declarative" distorts developers' expectations of
> the tools?

Not just for the tools, in general.

But yes. Being declarative has an established meaning in the field, most
notably the contrast to being imperative, or at least something close.
Referential transparency typically shows up in the vicinity, which then
could even translate to "cool" tooling like formal proving of correctness
and a plethora of optimization possibilities.

If a language is stressed as "declarative" in every second sentence, my
expectation would _of course_ be that at least _some_ of that is for real.

Not so with "the contents of .qml files". The inseperable tie to the
imperative parts voids all the potential "declarative" benefits, and only
leaves the disadvantages of the hybrid.

> Do you think it will help if we rebrand QML as a "markup language" or
> a "multi-paradigm language", instead of a "declarative language"?

That would at least be a more correct description of the current state, and
therefore help to overcome the communication problems.  I wouldn't consider
it final solution, though, since it still means that we get no declarative
benefit while still paying all the cost for the hybrid.

> Some user interface markup languages (e.g. XAML, MXML, HTML) allow
> imperative code to be embedded within declarative code.

"Allow" ... well, yes.

But for HTML it's at least possible (and in some circles recommended) to
not embed scripting, And XAML makes pretty explicit recommendation to not
use the feature:
http://msdn.microsoft.com/en-us/library/aa970568%28v=vs.110%29.aspx "You
should consider avoiding or limiting the use of inline code."

That's quite a contrast to the QML which relies rather heavily on inline
JavaScript in all demos, or even worse, touts it as as a benefit in the
documentation:
http://qt-project.org/doc/qt-5/qtquick-usecase-integratingjs.html
"JavaScript code can be easily integrated into QML to provide UI logic,
imperative control, or other benefits."

"Declarative is good, imperative is good, how good must a
combined declarative-imperative language be!" --- Erm, *WAT*?

[On a serious note, that's one more instance where "QML" clearly refers
to the "declarative outer layer" of a .qml file]

> > Within a .qml file, JavaScript is in no way an "optional extension" of some
> > "declarative QML language". QML and JavaScript are _inseparably_ tied
> > together in the QML/JS hybrid contents of a .qml file.
> >
> > A quick grep in qtdeclarative/examples/quick/demos e.g. finds the pattern
> > 'if (' in 30 out of 88 .qml files. All nine examples are affected. And
> > that's not "just an accident", as "pure declarative QML" features like
> > ScriptAction, or on{Triggered,Clicked,Loaded,...} handlers _require_
> > immediate use of JavaScript.
> 
> To clarify, I do agree with you that QML is extremely limited without
> JavaScript for its intended role in Qt Quick.

Good ;-)
 
> [...] My actual argument in favour for QML was that it lets us express our
> intent much more concisely than other languages.

Right, that was the argument. And you do have a point when it comes to
"character count in the sources" when comparing .qml with the Android XML.
But this does not necessarily mean it's less effort to create the more verbose
XML. There are XML editors to get the "boilerplate" parts of XML right
and one doesn't even have to see those when working on a document...

> [...]
> >> (Alternatively, one could argue that QML is a hybrid
> >> declarative-imperative language).
> >
> > Alternatively, one could argue that QML is a not-well-defined,
> > non-standard languange largely incompatible with established tools
> > and workflows,
> 
> That's what a trailblazer looks like, no? :-)

Nah... that's just the politically correctly compressed version of the
overdue yearly rant on the topic ;-}

> > with
> > developers not agreeing on fundamental aspects of its nature, costs and
> > benefits... But, hey, which fool would raise such a claim ;-}
> 
> These aren't properties of the language itself, but a symptom of the
> lack of rigorous definitions, and a lack of the "full picture" view of
> the technology. These can be addressed with some thought, without
> having to modify the language.

I think at least three modifications are inavoidable: For one, things that
could be written in a declarative way but which currently are only possible
using JavaScript, a declarative way should be added. Second, it should be
stressed in the documentation (including the examples), that using
inline imperative code is naughty. This can be supported by e.g. the QML
Designer refusing to operate on such files. People can still do that, but
would be on their own. And finally, and that's also acting as a proof that
the first two items actually have been done, the JavaScript dependency
should be _optional_.


> > So "someone" should sit down and come up with a single "official" definition
> > of the basics: What is QML, how does it relate to JS, what's the relation
> > to .qml files.
> 
> +1.
> 
> Deconstructing your list, here are the items of interest:
> 
> 1) A scripting language that pre-dates Qt 4.
> 2) A language, heavily influenced by CSS, that lets authors declare a
> hierarchy of objects and the attributes for each of those objects.
> 3) A language that is the composite of (1) and (2). Specifically, it
> uses (1) to express computational logic within the object attributes
> of (2).
> 4) A file format where each file encapsulates exactly one top-level
> object and its child objects (if any), expressed using (3).
> 
> (1) is JavaScript.
> (4) is called a "QML file" and has the ".qml" extension.
> 
> The label "QML" is sometimes been applied to (2), sometimes to (3). We
> need to decide which, and stick to it once and for all. Some options:
> 
> Option A:
> - Call (2) "QML"
> - Find a new name for (3) (QML-JS? QMS?)
> - Change the name and extension of (4) (".qmljs", ".qms", ...)
> 
> Option B:
> - Call (3) "QML"
> - Find a new name for (2)
> 
> 
> Any others models/options?

Maybe, but those two are indeed the main contenders as far as I can tell.
I also don't think it's worthwile to complicate the issue further by taking
more fringe interpretations into account.

> Previously, I called (2) "QML". But after considering how people use
> this language, and studying other markup languages, I've changed my
> mind and think that (3) should be called "QML". Option A is also far
> too invasive a change.

I am currently still in the (2) == "QML" and (3) == "QML/JS" camp, but I
have no vested interest here. Pretty much any fixed, consistent definition
is fine with me. Note that at least within the Qt Creator code base a lot
of the (2)-related items are indeed called "QmlJS*" (but it's mostly C++
code, can be refactored easily. SCNR ;-) )

> On a related note, do we have an official statement on what "QML"
> stands for? I've only found a blog comment saying "Qt Modeling
> Language". [3]

Wikipedia mentions "Qt Meta Language or Qt Modeling Language" and "It is a
JavaScript-based, declarative language".

Oh, well.

I am tempted to suggest to reload http://www.classnamer.com/ until it
contains Q, M, and L.

> > the "QML is whatever can be written in a .qml file" concept ("develop
> > your own applications using QML and Qt C++") but sometimes mentions
> > JavaScript seperately ("integrate QML code with JavaScript and C++.").
> 
> Agreed. There needs to be more thought given to terminologies used in
> QML [4]. It also feels like API reviews for QML are less rigorous than
> for C++, [5] but that topic is for another day.

Indeed, and indeed.

Andre'