[Development] As Qt contemplates its future..
Shawn.Rutledge at qt.io
Sat Apr 15 00:23:01 CEST 2017
> On 13 Apr 2017, at 14:02, Randall O'Reilly <randy.oreilly at Colorado.EDU> wrote:
> With the recent language explosion, there are now languages to fit everyone’s biases and aesthetics.
This explosion is possible because of common language backends and VMs like the JVM, CLR or LLVM. (Hacking gcc to add a new language would’ve been much harder.) So, hopefully that means that you don’t have to champion Go itself as the language of the century and plan on rewriting all of Qt in Go, right? As long as you can generate LLVM-IR somehow from your favorite language at this juncture, you share a foundation with plenty of other languages, so maybe modules written in one could interoperate with modules written in another? Depends on the ABI though.
The Rust guys make the point that it’s necessary to rewrite lots of old stuff in Rust in order to have all the security that it can guarantee. But with Go, is there such a mandate? To me so far, Go seems incrementally better but not quite a revolution; fine to try for new projects but maybe not worth the effort of rewriting old code. And of course I’ve been around the block before with this idea that such-and-such needs to be rewritten in such-and-such new-hotness language. The next rewrite ends up more bloated and slow than the last… that seems to be the rule.
Next, why does Go not use LLVM by default? Why do QML and V4 not use it, for that matter? I was hoping we’d do it that way, but we didn’t. I think it would have saved some work, and gained some interoperability, and a lot of tooling possibilities.
> This also means that there is an endless potential for language wars, which I’m sure nobody wants to rehash on this list. My point is just that Go represents a particular set of choices that I think is very compatible with a certain (possibly large) segment of the Qt user-base — those who favor clarity, simplicity, readability, over e.g., extreme performance optimization or having every different kind of possible language feature at one’s disposal (aka “language bloat”). As C++ is seemingly in a constant state of reinvention lately, and is now massively bloated and unwieldy in some people’s estimation, it might be an opportune moment to consider a “reboot” — a fresh new framework unburdened by all that cruft. My sense is that Go has made some really excellent (and hard) choices that benefit from all the different language experiments and experience (and especially the limitations of C++), and that one major thing holding it back is lack of a decent GUI framework, so that Qt could really make a big difference there. Furthermore, Qt itself has a kind of bloat problem of its own, having evolved in major ways over the years (Widgets vs. QML, scenegraphs, and now 3D), so it could possibly benefit from a fresh start / reboot as well.
> Perhaps building from the ground-up on a core scenegraph framework that can support 2D *and* 3D,
and usually it would be pointed out that a 3D engine is terrible overkill for 2D UIs. But now we’re coming out with that third choice anyway, Qt 3D Studio. So maybe we’ll get there after all, and find out whether or not a 3D scene graph is practical for ordinary everyday UIs. Of course if there ends up being a good reason to have a true 3D UI in most everyday ordinary applications, then the 3D scene graph is not overkill I guess.
> with different back-end renderers (OpenGL ES etc), using e.g., SVG syntax to do the widget etc painting in a resolution-independent, style-based manner (no more high-dpi hassles — future proof resolution independence)..
What I want in addition to purely scalable graphics is to do all the rendering on the GPU: no more pre-chewing of all the vertices by the parent CPU before feeding it to the little baby GPU cores. It would be worth whatever upheaval is necessary to get there, IMO. And by the time we figure out how, maybe we won’t have to worry about limited back ends like OpenGL ES anymore.
More information about the Development