On Apr 15, 2017, at 7:23 AM, Shawn Rutledge <[email protected]> wrote: > > >> On 13 Apr 2017, at 14:02, Randall O'Reilly <[email protected]> >> 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.
The “let a 1000 flowers bloom” kind of interoperability definitely seems appealing for avoiding the seemingly impossible task of having a significant % developers agree on a single language, but then you end up with a tower of babble, which has problems of its own — a jumble of dependencies and everyone has to learn all these different languages to be able to fix things, etc. The single most significant problem with the current babble situation, which definitely drives so much of Qt’s design and debates, comes down to the limitations with the linker, and the consequent need for strict binary compatibility. This forces separation of .h and .cpp (write everything 2x) and then PIMPL on top of that (now write everything 4x!). And then which version of STL to include — none!? One of the major innovations in Go is that it avoids all of those problems. You only ever write things once, in one place (no .h vs. .cpp), and, like an interpreted language, the only distribution mechanism *is the source itself*. There is no such thing as binary compatibility. To make this viable, the Go compiler is insanely fast and so you can just rebuild *everything* from scratch extremely quickly. This is presumably why they didn’t use LLVM etc. Dependency hell is essentially eliminated. So, Go is indeed a pretty radical departure from the current standards. You CAN link to C but not directly to C++ — requires SWIG to call C++.. For people who have “drunk the kool-aid” of Go, it seems not “just another language” but really a complete reinvention of the whole process, trying to capture as many of the “best of” features of things like python AND C++, etc.. A real tradeoff however is that it is MUCH nicer to work with native Go toolkits instead of importing external ones.. hence my advocacy of Qt potentially investing some effort here. > One big obstacle I’ve been seeing for years is the shortage of C++ API for > the QtQuick scene graph, and the difficulty of separating the scene graph to > be independent of QML. If you want to have one language for your application > (which isn’t QML, Javascript or C++) then you need scene graph bindings to at > least be possible. And the usual reason we give is that we don’t have public > API so that we remain free to change it. > But it’s still an obstacle for making bindings. IMO we’ve got to get to the > point where at least the private APIs are complete enough and reasonable > enough to use, so you could maintain a scene graph binding for another > language alongside Qt, and iterate along with it. Or else rewrite the scene > graph, but that seems like needless work, doesn’t it? Yet another instance of the problem solved (or at least reduced) by Go! Everything is exposed. Nothing is hidden. API is all with interfaces that are designed to be clean and minimal — changing the impl doesn’t break anything so you don’t need to hide it, as long as people just use the proper interfaces (which are well documented etc). > You can search GitHub and find plenty of scene graphs, but how many of them > can do internationalized antialiased text using an atlas (not pre-rendering > whole words or lines with freetype), and how many of them do batching like > Qt’s? Yes indeed — the nascent efforts in Go have all run up against the above kinds of problems — again, Qt could really make a difference here! > 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. see above.. >> 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. Once you have a scenegraph, it would seem like just having 2D be a natural subset of 3D would be awesome — not everyone needs 3D probably but for those who do, having the full power of the “regular” widget gui at your disposal in 3D would be amazing. And maybe indeed people will develop all kinds of nice new things once 3D is just an easy extension on top of what they are already doing. In my case, we have big neural networks that really need 3D, and it would really be awesome having this kind of inter-operability. >> 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. +1 :) And to further address the above point about “why just rewrite stuff in another language” — indeed the ONLY time it really makes sense is if you are doing a major redesign anyway — that’s why it seems like this might be a particularly good time to make the leap to Go at the same time.. - Randy _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
