Cppfront, Carbon, and Qt
-
@brainchild said:
Yes, but the change represents a tremendous shift in meaning
I guess I should've done this about 40 posts ago, but since we're at the stage of dissecting singular words I might have misused I'm gonna take the late wake up call and see myself out of this discussion.
Have a nice day and pleasant cppfront experience.
-
@Chris-Kawa said in Cppfront, Carbon, and Qt:
I guess I should've done this about 40 posts ago, but since we're at the stage of dissecting singular words I might have misused I'm gonna take the late wake up call and see myself out of this discussion.
Have a nice day and pleasant cppfront experience.
Fair enough.
If I have seemed to nitpick over words such as "perfect", it is because of the suggestion that seeking a "perfect" language is unhelpful because one would always be possible that is more perfect. In contrast, the reason for an alternative grammar would be to address immediate and common limitations that have yet to be addressed, if even they may be, through the main track of the language.
If you are curious, you might explore Kotlin and Vala. You might try to think about writing business logic in one of these languages, compared to doing so in Java and C, and to consider whether you might begin to be able to imagine an analogy with a nimbler syntax for C++.
-
@brainchild said in Cppfront, Carbon, and Qt:
Does anyone have thoughts, hopes, or reservations, about either project informing the future of development with Qt?
This discussion has examined the pros/cons etc. of cppfront etc. in detail. But that was not your original question, which I quote above.
To come back to that. For my 2 cents. I don't think that cppfront, or others, will "inform the future development of Qt". It has a 20 year old code base which I doubt TQtC is going to rewrite. When processing
Q_OBJECTclasses I doubt they are going to want to change tomocgenerating cppfront code, in case anybody wants to look at it. TQtC has barely changed examples over to Python/PySide after years of development, I doubt they will bother to rewrite them for cppfront. Will they bother to rewrite the Creator IDE to provide editing support for cppfront? When will gdb integrate with cppfront code to support a debugging experience? And so on.Maybe if there is widespread support for cppfront or whatever Qt will look at it. Till then I suspect not. If you really want your question answered you need to ask TQtC what they are planning to do in this regard, not this community.
-
@JonB said in Cppfront, Carbon, and Qt:
To come back to that. For my 2 cents. I don't think that cppfront, or others, will "inform the future development of Qt". It has a 20 year old code base which I doubt TQtC is going to rewrite.
Perhaps it has been my mistake to have chosen such general language, which is now being interpreted along a particular course.
I never sought to suggest the code base of Qt being rewritten, not even slightly.
(In fact, the language I actually employed was "inform the future of development with Qt".)
-
@brainchild
Then what did you ever have in mind withabout either project informing the future of development with Qt?
Anyway, Qt being such an existing long-time project/code base I just don't think they will. Not whether that is good or bad, just that it probably won't happen/doesn't have much synergy with Qt.
-
@JonB said in Cppfront, Carbon, and Qt:
Anyway, Qt being such an existing long-time project/code base I just don't think they will.
You don't think they will do what?
-
@brainchild
I don't think they (TQtC) will use cppfront or whatever to "inform the future of development with Qt".If cppfront becomes accepted/developed, and gets to the stage where you can just use it in practice on any project in place of lower-level native C++, and a variety of tools like we have now work with it, then maybe one will be able to use it in Creator. Till then I just doubt it will have any effect on TQtC or people developing with Qt. That's all.
-
@JonB said in Cppfront, Carbon, and Qt:
Till then I just doubt it will have any effect on TQtC or people developing with Qt. That's all.
I am trying to emphasize the difference between two cases, the Qt Project making changes to the tools, on one hand, versus developers who use the tools, on the other hand, having additional options for writing applications.
It is the latter case around which I intended to orient discussion.
-
@brainchild
Yes, I understand. And my 2 cents is that, no, cppfront or whatever will not "inform the future of development with Qt", even with the word "with".If cppfront affects future development of C++ projects in general that's fine and will have a knock-on consequence for any C++ project, Qt or not. But that is not a question about the relevance to Qt.
Most people who use Qt use Creator for their editing/compiling/debugging process. It doesn't matter whether cppfront is an improvement over C++ or not, it's just not of special interest to Qt developers till Creator does. And my guess is that if that comes at all it would only be in many years' time after widespread adoption of cppfront and all tooling. So personally I don't think Qt, or the development of programs using Qt, will be much interested in or affected by it until after it becomes the de facto standard. cppfront may or may not be worthy, and may or may not affect C++ coding, just it is not particularly relevant to Qt coding one way or the other. That's my 2 cents.
-
@JonB said in Cppfront, Carbon, and Qt:
Most people who use Qt use Creator for their editing/compiling/debugging process.
Most applications have business logic implemented through code written in C++, right?
-
What impact will they have on Qt? They will influence C++ to the same extent, I believe, so very little.
They emphasise implicit memory management, no pointers, functional syntax (for some strange reason), and other features that don't fit Qt's style. Perhaps a third party will create some toys or bindings, but I don't see Qt diving headfirst into doing anything with those directly. -
Wow, this was very long discussion and not very useful so far because it evolved into a kind of flamewar.
I like the cppfront idea. C++ has many problems. Mostly because it is complicated and it is memory unsafe. This certainly hurts its adoption for new applications. When a new project is planned, the stakeholders often gravitate towards other languages despite they offer worse performance than C++. When you are at a panel of decision makers and you advocate for C++, prepare for defending yourself very hard - how dare you vote for a memory unsafe language!? Successors like cppfront or Carbon or jakt aim to change this while keeping the backward compatibility and top notch performance and that is a very valid reason for their exsitence and development. Of course, none knows the future and it is quite possible they will not succeed. But it is worth trying.
Regarding Qt, it has serious problems of its own. Its adoption is certainly lagging behind expectations of QtC and the community. Now its stronghold remains only in the area of embedded UIs. And curiously aging QtWidgets are still a thing on desktop (unlike QML), even after those years. And new powerful competitors such as Flutter emerge and have so much momentum... The future will be hard for Qt, without doubts.
So contrary to many opinions here in the discussion above I think that Qt and C++ successors, be it cppfront, Carbon or jakt, can actually be a happy marriage. Of course it may take a few years from now to materialize and it may be not without initial friction and effort.
New a few thoughts regarding possible future of cppfront (but the same more or less holds for any C++ successor language) in relation to Qt:
-
The QtC will certainly NOT (!) rewrite Qt source code to cppfront. It will just not happen. The codebase will always remain in C++.
-
But clients' code calling to Qt can easily be written in cppfront. It can include Qt headers and link to them without any problem. It does not need any Qt bindings such as Python or Rust.
-
Yes, it will certainly complicate the build chain. There is need for translating of cppfront code to C++ code. This is an extra step and should probably be done before moc runs.
-
cppfront will need some mechanism to create C++ headers for the clients' code and put Qt macros such as
Q_OBJECTto the right places. Only then moc can grab them and do its work. -
But, given the simpler syntax of cppfront I can imagine someone writing an alternative moc which could work directly with cppfront files. Then moc and cppfront can run in parallel.
-
Of course I can imagine syntax highlighter and other tooling of cppfront built into IDEs like QtCreator. The syntax model is so much simpler than C++ so these tool should be simple to develop and should run very fast (compared to similar tool for C++).
-
-
Indeed, of all the new improvements/suggestions for C++ I think cppfront stands out (a.k.a. "a Typescript for C++")
Just watched Herb's C++ Now 2023 keynote on Youtube about it, looks good :-)
-
@vladimir-kraus just realized: since cppfront will have a reflection API, the duties of moc could most likely be handled by some code in a Qt-header at compile time...
-
I think my suggestion is that the current state of the project is a proof of concept. If it fails to gain interest, then it may never pass to another phase. However, if others are interested, then the scale of the project may expand. Is it not often the case, for many important projects, perhaps C++ itself, of beginning on a small and personal scale?
