Cppfront, Carbon, and Qt
-
@brainchild said:
I think the concept of a "second" C++ grammar is compelling, though only a second.
What measures will stop anyone from inventing third when the second stops being considered sufficiently modern? I don't want to deal with four, three or two in single code base. One already has problems, as you eagerly point out, so what's compelling about multiplying that? Are you maybe tricking yourself into thinking that this new one will be somehow perfect and final? Because it won't, that I can assure you of.
-
@Chris-Kawa said in Cppfront, Carbon, and Qt:
@brainchild said:
I think the concept of a "second" C++ grammar is compelling, though only a second.
What measures will stop anyone from inventing third when the second stops being considered sufficiently modern?
It is a collective choice, of the community. Plainly, anyone may at any time promote a personal project, but your objections are taking the form of a "slippery slope" or of "all or none".
There is an unmet need, in my view, that may be met by an alternative grammar. The ability for any project to meet that need would diminish if there would be many competitors but no clear leader. Therefore, it may be in the general interest to develop one, and only one, alternative grammar, through a broad consensus, sufficiently different from the current to solve the problems that have prompted its creation, but without fragmenting in every direction over trivial differences.
Internal fighting is a problem that may occur, at times. So is complacency or stagnancy.
I don't want to deal with four, three or two in single code base. One already has problems, as you eagerly point out, so what's compelling about multiplying that? Are you maybe tricking yourself into thinking that this new one will be somehow perfect? Because it won't, that I can assure you of.
Comments of such kind are those that make it seem as though your mindset is of stifling innovation or progress.
The idea is a single alternative, imperfect, yet still favorable for projects seeking more rapid development and more expressive code, compared to any possible through C++, while preserving complete compatibility.
By the way, it why have you inserted the phrase "in a single code base"? Would not each project choose one or the other?
-
@brainchild said:
Comments of such kind are those that make it seem as though your mindset is of stifling innovation or progress.
I don't know why you keep saying that and I wish you would stop. I'm all for evolving C++ and enjoy a lot of its evolution that already took place. I'm not keen on inventing new languages that dress themselves as C++ to gain traction. That is not being against progress. Reinvention is not the only way to make progress.
while preserving complete compatibility
The repo says it on the front page metaclasses, runtime reflection and arena based garbage collection are all planned features. This language starts as C++ syntax 2, because otherwise it would be completely unattractive, but has very little intention on staying that way and is not shy about it.
Would not each project choose one or the other?
No, because very few projects in real world are new. Most of code out there is legacy, sometimes decades old. There's absolutely no rewriting the world so hybrids are the only way to even attempt that.
-
@Chris-Kawa said in Cppfront, Carbon, and Qt:
I'm not keen on inventing new languages that dress themselves as C++ to gain traction. That is not being against progress. Reinvention is not the only way to make progress.
I think the purpose is very different, though. I gave a use case, several times, which I find helpful to consider. It is quite the same as writing a GTK application in Vala instead of C.
while preserving complete compatibility
The repo says it on the front page metaclasses, runtime reflection and arena based garbage collection are all planned features. This languages starts as C++ syntax 2, because otherwise it would be completely unattractive, but has very little intention on staying that way and is not shy about it.
It may be not quite accurate to infer that they are planned. Are you referring to the phrase "not yet implemented"? I believe there is ambiguity.
I think it is fair to object that an alternative grammar for C++ should be separated from a run time engine. I think much of the doubtfulness follows from the enthusiasm for the developer to integrate his own external interests, of augmenting applications with a run time system. However, I still ask you to consider the question of grammar itself.
Metaprogramming is a different matter, compared to run time processing. Frameworks such as Qt rely on preprocessors, in other words, build processes external to the standard tool chain. Perhaps it would be helpful to consider some syntax for addressing such limitations.
-
@brainchild said:
I believe there is ambiguity.
Hah, don't stop believing :) Meanwhile in the real world...
I think much of the doubtfulness follows from the enthusiasm for the developer to integrate his own external interests
Well it is his language under his sole control, so what else do you expect to happen? There's no committee or anyone stopping him from anything. It's his repo.
However, I still ask you to consider the question of grammar itself.
I'm not interested in rhetorical. I already said a better grammar is possible. So what? It means nothing. Solves nothing. Write a perfect grammar and then what? How would you apply it to legacy code? And if you don't, well, as I said - hybrids, which are worse than the original problem. I don't see plausible anyone rewriting boost, DirectX, zlib, Qt or openssl in syntax 2. Do you? Hybrids, hybrids everywhere (to quote a meme).
Frameworks such as Qt rely on preprocessors. (...) Perhaps it would be helpful to consider some syntax for addressing such limitations
It is already happening in the C++ language itself. No need for cppfront.
-
@Chris-Kawa said in Cppfront, Carbon, and Qt:
@brainchild said:
I believe there is ambiguity.
Hah, don't stop believing :) Meanwhile in the real world...
You can be cynical, if you want. Perhaps your doubts will be vindicated, but I am not seeing them as helpful or robust at this moment.
Well it is his language under his sole control, so what else do you expect to happen? There's no committee or anyone stopping him from anything. It's his repo.
I would not ask the whole community to adopt a language under the private control of an individual, but neither would I ask it to reject the possibility that a language eventually moved under a broader public governance may begin as an individual's project. It is common for an idea to be proved on a small and private scale, to gain traction, and then to be moved to public ownership.
At any rate, Python in some sense is controlled by one individual, who is often called, literally, its "benevolent dictator for life". It is not ideal, by my likes, but neither has it stopped Python from becoming a popular and credible language.
Solves nothing.
For the record, do you believe the same of Vala and Kotlin?
Write a perfect grammar and then what?
Again, no one invoked the term "perfect", except you.
How would you apply it to legacy code? And if you don't, well, as I said - hybrids, which are worse than the original problem.
I think the general case would be that a particular module, component, library, or application would tend to be written in one or the other, following an overall plan, with compatibility of compiled libraries as well as particular regions within the broader project.
Mixing languages is common in large projects... Python and C, C++ and QML, and so on.
You might imagine (to repeat myself yet again) a graphical application written in an alternative syntax of C++, but built on Qt, just as one might be written in Vale, meaning it would be built over GObject and Glib.
I don't see plausible anyone rewriting boost, DirectX, zlib or openssl in syntax 2. Do you?
No, obviously. Why do you mention it?
Frameworks such as Qt rely on preprocessors. (...) Perhaps it would be helpful to consider some syntax for addressing such limitations
It is already happening in the C++ language itself. No need for cppfront.
Great. Good to know. Obviously I don't have this knowledge, at the current moment.
-
@brainchild said:
For the record, do you believe the same of Vala and Kotlin?
I have cursory knowledge about these projects, landscape of their ecosystem or challenges they face compared to C++, so I'll refrain from forming an ad hoc opinion. From my brief experience with Java though it's a very different world, so I wouldn't consider making parallels helpful here.
Again, no one invoked the term "perfect", except you.
Sure, just extrapolating. Lets stick with "better".
I think the general case would be that a particular module, component, library, or application would tend to be written in one or the other
Yes, that's what I called hybrids. It's a substantial burden to maintain if you ever had the displeasure to.
Mixing languages is common in large projects
And almost universally a cause of friction, which we're trying to reduce.
-
@Chris-Kawa said in Cppfront, Carbon, and Qt:
@brainchild said:
For the record, do you believe the same of Vala and Kotlin?
From my brief experience with Java though it's a very different world, so I wouldn't consider making parallels helpful here.
I would be curious to know what you see as the points of difference, which make the comparison counterproductive.
Again, no one invoked the term "perfect", except you.
Sure, just extrapolating. Lets stick with "better".
Yes, but the change represents a tremendous shift in meaning. I could design a language better than C++ in an hour. To be clear, it would not be much different, but still at least slightly better. I am not bragging. Anyone could do the same. The difficulty would be making a language not only better, but sufficiently compelling to encourage long-term adoption.
I think the general case would be that a particular module, component, library, or application would tend to be written in one or the other
Yes, that's what I called hybrids. It's a substantial burden to maintain if you ever had the displeasure to.
Mixing languages is common in large projects
And almost universally a cause of friction, which we're trying to reduce.
Mixing languages in large projects, in the general case, is completely inevitable. Seriously, get with it. We are not discussing tools like
ls, or even the entire core utilities of Unix or Gnu.Many projects are so large that many involved in them barely know most of the others, only the few others working on the same component. Even projects under separate governance integrate one another, as you well know. Constraining each project to use only one language is no more absurd than constraining all projects globally to use only one language.
Almost any Android application currently maintained is made of components variously built on Java, Kotlin, C++, and C. The number of languages increases further when one considers SQL for database queries and Groovy for build scripts, all part of the same source tree. How many languages do you imagine are integrated into the source tree of Android itself?
It is ironic, but not unintentional, that the current discussion is hosted on a forum oriented around a project that has one of the richest ecosystems of language bindings of any I know. Do you laugh at developers of Python applications using Qt bindings?
-
@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++).
-
