Qt5: Javascript vs C++?
-
Qt5: Javascript vs C++?
Hello everybody,
I would like to share with you some thoughts about Qt5 and the expectations I can feel about it.
Looking for information about the differences between Qt4 and Qt5, I found this article:
http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/And some few others remarking the great opportunities coming up with QML. I understand how important
is for Qt to become one of the most popular tools for gadgets and mobile devices, and I can realize how easy
is to develop an small application for smarthphones using QML and Javascript (I watched a lot of demos at Youtube
about it and they are stunning!).I can't ignore how useful this resource is even more when it is bringing in a lot of business for Qt developers, but, on the other hand, I am really worry about that subtle idea that I can feel in the air about the future of Qt: "QML+Javascript is the coolest new toy and C++ is the older/dying art". I want to be clear on this, I'm not saying that is a fact, but I can't help to smell it when I read the news and the comments of people when they talk about the coming Qt5 age.
I can understand how QML+Javascript can be a great resource for a lot of applications, and if we are talking about mobile devices, even more.
But, what about the complex applications focused on desktop environments with complex data structures and a large list of business rules, memory management algorithms, hardware interfaces, etc? Has the Qt4/C++ programming style a chance as we know it in the Qt5 route-map? I can read people really happy because they will be able to develop a lot of new applications for smartphones using QML+JavaScript, but what about the other "space of problems"? i.e. Can you port a complete ERP solution to QML+JavaScript?
I have to confess that I'm really worry about how some programmers get excited for the new stuff, jump on the new wave and start coding... and how few many stop for a moment, take a breath and ask to themselves: "Is this the right tool/resource for my requirements?"
It's like when you talk about node.js and the websockets-based architecture. A lot of people is choosing this kind of resources because they are really cool (and is true!), but... is it the right choice for your problem/project?
Maybe I'm just paranoid and misunderstanding the whole thing, but I would like to read comments and thoughts from other developers about the Qt5 scene and the approaches we can give to its tools if you will.
Thanks!
-
Greenspun's tenth rule of programming ( "http://c2.com/cgi/wiki?GreenspunsTenthRuleOfProgramming":http://c2.com/cgi/wiki?GreenspunsTenthRuleOfProgramming ) says:
"Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of CommonLisp."From my point of view Qt with QML+javascript gets "a better implementation of CommonLisp".
I wrote lots of stuff in lots of different programming languages and as soon as you develop something complex enough you end up having lots of high performance modules and "something to mix-match them on the flight" (macros, an interpreter, setup files for different configurations with their own "custom syntax and semantics", etc. etc.).QML+javascript is perfect for that; it allows to "script the GUI" and lots of other things without having to reinvent the wheel.
The only thing I think is still missing is the capability to "pre-optimize or compile to C++" QML and Javascript code to improve performance on embedded devices. -
QML is not considered good for desktop apps yet, so don't worry! QtWidgets remain available and functional in Qt5, and they are unlikely to ever go away. QtQuick gets much more attention, true, because it's really new, shiny and powerful.
To be honest, I used to share your uneasiness about Qt's direction, but it all vanished now - after I've tried QML and followed development discussions on Qt mailing lists. Qt in NOT becoming QML/JS framework, it's just another tool made available to developers, as a parallel player to console and widgets. Also, it offers powerful connection of QML and C++, so not all logic has to be in JS. For Qt5, QML is not the only thing that gets an update - a lot of internals of QtCore are seeing big changes (new regexp engine, new QUrl implementation, full QPA integration, and many more), as well as other modules.
@L.MCH - sort of optimisation will come with Qt5, where V8 is used as JS engine (and that means JIT will be used).
-
Regarding C++/QWidgets I'm still not too optimistic. According to "Qt Modules’ Maturity Levels":/wiki/Qt_Modules_Maturity_Level in the wiki, the "widget classes like QPushButton, QLineEdit, etc." are marked as done, meaning
bq. Let me remind you that Done is not Deprecated! Done really means “stability and zero regressions are the most important things, so we are not adding features and we are not working on improving performance, but it’s fine to use this code”.
[emphasis by me, v.]I cannot see a bright future for widget classes in that statement.
It reads to me: Ok, use it if you need, but don't expect too much and basically you might be on your own some time in the future, when we loose interest in it as it's not the hot new stuff, but the old crap... Let's cross fingers that I'm wrong.
-
There were numerous discussions on mailing lists regarding module statuses. The general consensus is that... descriptions of maturity levels are not the most fortunately chosen! In most cases, "Done" was given just to show that:
- a module is feature-rich and more or less bug-free
- there is no active maintainer under Open Governance
That's it. It does not mean "we will never going to do anything in this module, ever". What it means is "it's OK for now, but we don't have anyone to take it further". Time and time again, maintainers on MLs repeated: "if anyone with a good set of ideas, and nice record of positive contributions to the project steps up, we can change status from "Done" to "Active/Maintained"." (OK, this is not an actual quote, but sort of a summary of what was being said).
Even "Deprecated" modules are not doomed. In most cases (QtSvg, for example) it's just that module's quality is not good enough to mark it as "Done", but - again - if anyone willing to take the job volunteers, it may be brought back to life at any time.
I can post some links to relevant discussions, but that's probably a bit too much (usually, they were very, very long ;) ).
-
It just adds my impression that, communication wise, the move to Qt 5 is a plain disaster. What has been announced more or less officially is old or outdated (cf. blogs on various sites) or scares the old and abiding developers (in the sense of using Qt, not developing the libs itself). The summary on the discussion of "done" just adds to that overall impression: there is plain no interest in further development of C++ based widgets.
Back to communications again: I don't have time nor interest to follow the mailing lists, as have many other devlopers too. It's up to the Qt Project to setup sufficient communication channels, it's not the duty of the users to search for the bits and parts somewhere deep in the internets when a project changes processes, responsibilities and goals that much.
Back to widgets: Oh yes, someone can step up and take maintainership in that part. But who should take that enormous task? It's a very big module where you need excellent knowledge of the internals to be able to fill that position properly. I cannot see anyone outside the current Nokia/Troll crew for that.
In the end, I have the fear that widgets support in Qt 5 takes the same way as Qt3Support took in Qt 4: It's still there, but less than a second class citizen nowadays. Yes, I'm very pessimistic on that. And until the Qt Project takes efforts to prove the opposite, I continue to expect the worst. This way I won't be disappointed.
Again: this is a communication disaster, lasting from before last years' developers' summit up to now...
-
Sadly, you are 100% right here, Volker. I've even raised the subject of outdated documents on ML once, but there was not much response. Recently, some new wikis are arriving on qt-project.org, though, so hopefully it will get better. Also, amount of approvers and maintainers from outside Nokia is on the raise, as well as amount of commits - projects seems to be gaining steam.
I don't share the pessimism, but I might be proven to be very wrong here. We will see how it goes.
-
Absolutely agree with Volker! It will be really a shame if only QML with more high level languages gets a focus. Looks like focus have got a kiddie-coders for coding their shiny iThings... But what about real Tasks? Where is a lot(A LOT) code to be optimized and developed in Qt. IMHO ;)
-
While I agree with Volker I don't feel pessimist about Qt and I don't have doubts about C++ programming with Qt. C++ is a great language, one that has been used and will be for a lot of time. The way I understand QML is that it is a kind of very successful binding for Qt, but the core implementation remains C++ based. So, even if widgets are marked as done, I believe they will naturally evolve with the framework. Of course I could be wrong.
Now the real discussion seems to me if <commercial partner here> will lead the choice of the tools developers have to use. Do not forget that there are whole communities based on Qt efforts, like KDE, that even if are proposing QML approaches (e.g., Plasma Qhick), have their core still based on C++ and Qt. I think such communities should actively jump in in order to provide much more good reasons to choose one way or another or both. -
I don't talk about nuking away C++ entirely. That will be needed in the backend for QML/Quick applications too. It's just about the standard QWidgets, as we all know it for ages now. I just have the fear that they don't get that much love that they need to satisfy developers' needs (in the sense of developers using Qt).
QML is really cool stuff, no doubt. But it is far away from being ready for the Desktop. And it will take years for QML Desktop Components to be as mature as the traditional widgets are nowadays. In the meantime, we have to bridge the gap, and for most big projects this will be using the old style widgets.
Yes, the code base out in the wild using Qt widgets/C++ is huge. Really huge. But what's that worth if the hackers developing Qt don't have interest to do more than bugfixes that make automatic testing shut up and some more or less critical bug once in a while? Are we developers using Qt supposed to support us ourselves? Here, you have the source code, we're open government, you can submit a patch? That's a bit too easy and lazy of a way to go. And I don't want to talk about that patches being accepted in the end or not. That's a different story that can lead to big frustration too, but that's for a separate thread.
-
[quote author="Volker" date="1329132734"]I don't talk about nuking away C++ entirely. That will be needed in the backend for QML/Quick applications too. It's just about the standard QWidgets, as we all know it for ages now. I just have the fear that they don't get that much love that they need to satisfy developers' needs (in the sense of developers using Qt).
QML is really cool stuff, no doubt. But it is far away from being ready for the Desktop. And it will take years for QML Desktop Components to be as mature as the traditional widgets are nowadays. In the meantime, we have to bridge the gap, and for most big projects this will be using the old style widgets.
Yes, the code base out in the wild using Qt widgets/C++ is huge. Really huge. But what's that worth if the hackers developing Qt don't have interest to do more than bugfixes that make automatic testing shut up and some more or less critical bug once in a while? Are we developers using Qt supposed to support us ourselves? Here, you have the source code, we're open government, you can submit a patch? That's a bit too easy and lazy of a way to go. And I don't want to talk about that patches being accepted in the end or not. That's a different story that can lead to big frustration too, but that's for a separate thread.[/quote]
Yes, Volker has some good points set here! As much as I love developing using C++/Qt and QWidgets, I am very sceptical on the above points as well!
-
[quote author="Volker" date="1329132734"]Here, you have the source code, we're open government, you can submit a patch?[/quote]
I've tried to use one open-source dev tool/framework, and their attitude was exactly like you suggest. When I asked for a bug fix or a feature, to make that tool more compatible with Mac OS X, their response sounded more like "Would you shut up at last, please? You have the source code, do this yourself. Don't bother us. We are happy drinking bear and coding the stuff that we want to code. We don't care what you need."
I don't like bear, I like red wine. I don't like open source dev tools, I like reasonably priced commercial tools :-)
-
serkol: I hope you did not get such a response from a troll!
-
No, it was not from a TROLL, neither from a troll :-)
This was before I looked at Qt. I hang out in that tool's forum for a couple of months. It's not a specific response, but their general attitude. They always sounded bothered when someone asked for a bug fix or a feature in some area that was not interesting for them. And they always gave the same response - you have the source code, do this yourself. Sometimes their response was more polite, sometimes less, but always the same meaning.
-
Well, you do have the option to stop whining and get a commercial Qt contract from Digia, or pay any of the Qt support-offering companies to maintain the parts of Qt that are critical for you. I really wonder why you ask Nokia to invest in supporting technology they have less interest in. Nokia's stake is obviously in selling huge numbers of phones and perhaps other gadgets. That requires technolgies like QML, not widgets. Meantime, they are giving away a great toolkit that helps us all and provides many of us a decent income. I'm not complaining here.
Personally, I think that Digia will need to step up in the qt project. They are starting to, but I think they are the ones who should take up maintainership of Qt Widgets.
-
[quote author="Andre" date="1329163835"]Well, you do have the option to stop whining and get a commercial Qt contract from Digia
[/quote]This is exactly what I want to do, when/if they resolve the incompatibility with Mac App Store and Mac OS sandboxing, and if the price is reasonable. I haven't even asked them about the price yet, because they have promised to resolve the App Store and sandboxing issues, but they have not done this yet.
[quote author="Andre" date="1329163835"]stop whining[/quote]
I immediately recognize the language from that tool's user group. Are you involved into a open-source project by chance?
[quote author="Andre" date="1329163835"]I really wonder why you ask Nokia[/quote]
Who is talking about Nokia? I have shared my experience with some open-source project that is not related to Nokia. Did you read my post at all?
-
The 'you' was not meant personally. It was more aimed at Volker than you, to be honest. There is much talk of 'it is not the task of the users to do this', but who's responsibility is it exactly, and why?
Seriously. We have been given an awesome toolkit that we can use. And topics like this give the feeling that users still think that it is never enough. I understand that Nokia is focussing on the parts that are most interesting to their business. There are other stepping to the plate to take up part of the work (and I know, Volker actually is one of those, in the sense of the work he does here in the community; don't underestimate the importance of that role). But so far, it is not enough yet. Let's give it a chance to grow though. It is a big transition.
Digia may or may not be able and willing to meet your (serkol) requirements for you to take a licence. I also don't know what you think is a reasonable price. I don't think Digia's position is easy either: they are trying to sell a license on a product that offers little benefit now over using the open source version. At the same time, we as a community will in the long run need to have paying customers to allow for development in areas that the individual developers using Qt will not be able to maintain themselves (like Qt Widgets). That is quite a catch 22.
And yes, I am involved with an open source project. Years ago, I used to run one. And even in that time, I did have to deal with users demanding features and fixes, but not willing to contribute themselves. Nowadays I am involved - mostly on the community side - of a small project you might have heard of: Qt. I am not a Troll though, and I do in no way speak for the project.
-
I'm quite ok with the situation right now. For the commercial project there's a commercial license available from Digia. and long before from Trolltech and Nokia. From that point of view I can sit back and relax. Hopefully Digia will fill the gap that might come up.
From Nokia's point of view, the current direction of development makes pretty good sense. But I, as well as many other developers, having paid for a commercial license or not, have to care of my/our own business. The commitment to using Qt is an invest itself. You spend time on the code base, etc. The question if that was a good decision in the end or not is answered later and depends on wether the trust a developer has put into the framework and its "manufacturer" amongst other facts. That trust is not too big, if one recaps the past two to three years. One was always asking what benefit does see in acquiring Qt/Trolltech. Then they announced that it will be the platform for their future phones and that Nokia will stand committed to Qt. That was quite ok, developers calmed down. Then there was the 2011 Feb-11 announcement. We all remember how we felt at that sad day. Giving Qt out to the community was a logical step, of course. But it was nothing that brought back too much trust into the intents of Nokia. It's still unclear what their role will be in the future (what will be the next billion devices?) It's an down and up and down and up.
Then look back at the past Developer Days. There was much moaning about the strong focus on mobile development and less and less desktop topics. Again, it's ok that Nokia changes focus here. But it's ok for the developers that feel falling back to be not amused too, to say it politely.
Back to widgets: If there was a proper replacement for widgets now (or once Qt 5 is out in a few months), this all wouldn't be that big problem. But there is no prime time ready QML/Quick for the desktop and widgets are done. What will fill that gap? To a desktop developer this can look like a slap in the face.
Maybe my concerns are based on incomplete information and I'm wrong. Who knows? The only point I strongly stand for, is that it's a communication disaster.
There's one last thing to add[1]: The fact that we all discuss this here in that detail and with that much emotions is only based on the one and only truth: Qt is an awesome framework and everyone is concerned that this holds true for a long, long future, be it we that we're whining here, as well as all the developers involved creating Qt.
fn1. ok, I've copied that introduction from someone else :)
-
This is my take on the open source. I'm talking in general, not about Qt.
I don't have time or skills to contribute to open source projects. When I decide to use one, I think of myself as a customer, and I think of the project leaders as service providers. Unfortunately some open source leaders have different views.
Let's say I walk into a store and I see a lady offering free cheese samples. Let's say I take some cheese and I ask her very nicely for a cracker. What do you think I will hear back?
-
Stop wining, go and buy your cracker.
-
Don't you see that this cheese is free? Why don't you bring your own crackers and share them with others while you eat my cheese?
-
or I'm sorry, we don't have crackers right now. But you have a great point, cheese and crackers go well together! I will bring some crackers tomorrow!
Do you see the difference? Most commercial software leaders look at the user suggestions as a valuable feedback. Some open source leaders... you know...
I don't want to explore the commercial interests of open source leaders, and why they treat non-contributing users like wining beggers. I just need to be practical and make some decisions for myself. This is what I have decided:
When my needs are exactly the same as the open source project's direction, we are happy. When I have different needs, I don't expect anything, and I will not ask.
So, Volker, just calm down and don't expect anything from Qt, if it's not QML.
-
Communication disaster: do you want to contribute and write a press-release? No? Just calm down.
-
Widgets: do you want to contribute? No? Just calm down.
Peace.
Peace and happines to everyone. Happy Valentine!
-
-
[quote author="serkol" date="1329165999"]they have promised to resolve the App Store and sandboxing issues, but they have not done this yet.[/quote]
According to latest announcements, an update to Qt 4.8 (4.8.1) is set to be released in mid-march.