Pretend I'm a happy C++ developer in 2020
-
Am I still using Qt or did I had to move to a different toolkit because QML (or any other dynamic language where if-undefined-checking on every variable is the usual pattern in code) replaced everything?
A less tl;dr version:
I've seeked through the web for hours and for me the future of C++ coding with Qt is still uncertain. The roadmap, the topics here in the forums, blogs (at qtproject.org and on other websites) about it don't give a clear conclusion.Is writing a Qt-GUI in C++ code still supported in the future or goes everything to QML?
I don't feel like to use Qt this year to figure out at the end that I've to port everything to a different toolkit for the next year.The vagueness is frustrating because I've good memories about using Qt.
-
if you want to be future-proof and and use Qt without really depending on it, then just use the latest standard C++ for your core logic and the latest HTML5 for your UIs (you have websockets in Qt, so it's relatively easy). If you have to use UI stuff that goes beyond what HTML5 can deliver then it doesn't really make much difference what toolkit you'll be using, none of them comes with any real guarantees as to what features, and for how long, will be supported in future versions.
PS
you can build pretty powerful UIs in HTML, e.g. here: http://www.webtoolkit.eu/wt/examples/ -
[quote author="RoestVrijStaal" date="1424439283"]
...
I've seeked through the web for hours and for me the future of C++ coding with Qt is still uncertain.
...
Is writing a Qt-GUI in C++ code still supported in the future or goes everything to QML?
...
[/quote]Wow. First I heard of anything like this. I don't believe it.
Who knows what the future has in store. In the relatively short time frame of 5 years I cannot see Qt C++ disappearing. If QML becomes the thing to use then probably the project would be split if nothing else.
Don't forget about other related projects like KDE. I suspect they will not change over too quickly if this ever happens (a toolkit is one thing, an implementation based on a toolkit is something else).
Even if they stopped releasing Qt C++ today, it would still be around for many years until it became too dated to be useful.
I have no idea one way or the other but this is not something I am worried about at all. I was more concerned when Qt was bought by Nokia (maybe you were reading old articles?).
-
Interesting question that I think everyone would love to know the answer to.
But I have to ask the question of how many of your programs are still actually running and in use after 5 years, 10 years, 20 years?
I think for most programmers the number of programs that are really still being used is very small. I think program lifetime is often shorter than we think.
I wrote a program in Turbo Pascal 2.x back when it first came out. It was used to automate a fiber drawing line. It controlled heaters, take up reels, and used analog input to measure thickness and stress on the fiber. I think I delivered it to the customer in 1993.
In 2001 I got a call from the customer that they could no longer get the hardware that they had been running it on and the computer had failed so they bought a new computer. Unfortunately the program would not run even though the computer had been loaded with DOS (yes... DOS).
After a little dusting off of the cobwebs and research I found that some code I had that relied upon a timer interrupt no longer worked because the interrupt was different. A few line changes and it compiled and ran. The nice thing was TPC was a whopping 75k install. I had to download a DOS emulator to even run it.
That program still runs today although I would strongly say TP is dead and I would not recommend doing anything in it.
So that all being said, if you write something in Qt today and it is well written, runs well, then the chances are good your program would still work just fine in 2020. Just to be safe I'd make sure I had the development environment in a nice VM and saved off the entire thing so if whatever compiler you used was dead you could still fire up the VM and fix things.
How will C++/Qt change by 2020? Who knows. All I can say is when I wrote a C++ program back in 1995 almost everything I did was different from how I'm doing it now. Pointers were kind and you got comfortable with them. Now days it seems everything is PMPL, references and what have you. We now have containers. I had to write my own in 1995 as the ones provided by the compiler I used were crap. As far as Qt goes the framework is pretty awesome. I still stumble on new classes and things that I was about to write that are already done for me.
Anyway long winded reply. The short answer is if it works for you know, you can solve your problems now then sally forth and make it so. Spending too much time worrying about the future when you have no guarantees your code will even still be in use will give you fits.
-
[quote author="gyll" date="1424440201"]if you want to be future-proof and and use Qt without really depending on it, then just use the latest standard C++ for your core logic and the latest HTML5 for your UIs (you have websockets in Qt, so it's relatively easy). If you have to use UI stuff that goes beyond what HTML5 can deliver then it doesn't really make much difference what toolkit you'll be using, none of them comes with any real guarantees as to what features, and for how long, will be supported in future versions.
PS
you can build pretty powerful UIs in HTML, e.g. here: http://www.webtoolkit.eu/wt/examples/[/quote]
Obviosly using a different toolkit would help, but Wt makes me shudder. It's released as GPL (even less "developer's freedom"-friendly than the LGPL) and no out-of-the-box MinGW support.
Thanks, but no thanks.@Rondog & SysTech: Given that C++ started approx 3 decades ago and "survived" new languages (like Java and C#) it will be still exist. However 5 years isn't that long, so the Qt project lacks vision for the future and merely hops on hipster phenomenons?
-
[quote author="RoestVrijStaal" date="1425175269"]
@Rondog & SysTech: Given that C++ started approx 3 decades ago and "survived" new languages (like Java and C#) it will be still exist. However 5 years isn't that long, so the Qt project lacks vision for the future and merely hops on hipster phenomenons?
[/quote]Well that may be true. As far as hopping on the hipster phenoms I think it is safe to say that languages and frameworks that don't probably won't survive "the next big thing!" At least survive in the main stream.
My colleges and I have a work horse system written under Delphi 7 that has been running 24-7 in locations around the globe since 2004. While it works, gets the job done very well I might add, upper management is all about the next big thing so almost monthly we talk about updating this old horse and someone says, well the only way you can update it is if you can do unit tests and TDD.
Our QA department now completely runs the company. It doesn't matter that this old horse works far better and more reliable than the "new" horse recently written using all the new buzz methods. Everyone is on that bandwagon and since the version of Delphi that was used really didn't support dependency injection or unit testing out of the box it would be a big job to try and wedge it in plus most of the code was not written to support any kind of DI.
So the fact that we can't easily update it to a new Delphi and instantly support the current desired trend pretty much is killing the product. But it is not surprising that the roughly 4000 sites that use the old horse won't allow our company to kill it and replace it with the new horse.
This goes to my statement about how long your program expects to live. It is very difficult to forecast.
The only advice I have about this topic: Choice of language and framework, is that C++ as you say has been around for many years. So probably some variant of it will be around in 5 years.
As far as Qt who knows. I'd venture a guess it will be around. What will it look like, what will it do, I don't know. However...
You can get the source to Qt right now. Invest in a copy of VMWare, setup and create a VM with your desired OS, compiler, Qt, Qt source and get everything to build.
If you do this then in 5, 10 or perhaps even 15 years (assuming you can load your VM) you could load the exact environment used to product your software. I can't tell you the number of times over 25+ years of development that I wished I had VMWare and had the ability to clone my development environment into a VM. I'm still getting calls to this day about things I wrote in 1995. I can't even find the compiler I used.
-
I honestly don't share the worry about c++ future in Qt.
Yes, QML is the new thing, and it's very useful, especially in the mobile department, but the core components and classes will be backed up by C++ for the foreseeable future. Think about all dependencies the Qt has, if not anything else. I don't see projects like ICU, OpenSSL or others switching to QML.
Also, whenever a control over pure performance comes to play C++ still outshines everything out there, especially considering how dynamically the language evolves lately and how Qt embraces it (lambdas are brilliant example). QML is not something you could build a whole library on. C++ will be the better choice for that no matter what optimization tricks will get into QML, and, as such, I believe will stay for years to come.I also have to comment on the hipster aspect of Qt. While it's true that it tries to move with the flow (which is good IMHO) it's also true that the people responsible care deeply for the supported platforms and toolsets and don't jump easily to "the next shiny thing". It might not be easy to see that from the outside, but just a look at the development mailing list will give a lot more perspective about the mindset of Qt people. Every now and then someone jumps with a "new great idea" and it always goes through a long series of analysis and viability studies before getting to consideration stage. My feeling is that for the next couple of years anyone proposing to drop widgets from Qt will hit a wall immediately.
After a painful switch from Qt 3 to 4 the ease of porting is now near the top of core values of Qt, which can be seen in a lot smoother switch to Qt 5. There are big ideas for the future versions, but it's highly, highly unlikely anyone would ever suggest to abandon C++ part of Qt. It's built on it and it breaths it.
While it's true that the widgets module is not the flourishing part of Qt these das, it's also important to see that it is far from plans of abandonment, especially on desktops. New widgets and improvements are still coming. QOpenGLWidget to give an example.
I would sooner expect the c++ to come up with standard UI library, rather than Qt leaving widgets.
Of course this is software. Timeframes of 20 years are not something anyone can realistically try to tackle these days. Qt targets more down-to-earth time spans, something that can be anticipated and planned for, and c++ is definitely a strong part of it.
