Cppfront, Carbon, and Qt

[brainchild]

C++ is an old and clunky language that has adopted many modern features but remains syntactically cumbersome. As the most obvious example, it follows C in requiring maintenance of header files separate from files defining functions. Class membership, part of C++ but not C, makes the syntax far more unwieldy, by requiring class name prefixes for each function definition. Template classes and functions introduce yet more confusion, because their implementations are given in headers.

Two projects recently have emerged for alleviating some of the development burden in C++, seeking to provide modern and elegant semantics, while retaining the programming same general constructs.

Cppfront attempts to expose the semantics of C++ through new syntax.

Carbon Language is rather fully new language, but one seeking to maintain broad interoperability with C++ projects.

Both projects are new and experimental, and will evolve considerably, if they survive.

Does anyone have thoughts, hopes, or reservations, about either project informing the future of development with Qt?

[JonB]

@brainchild
I thought you had already asked and exhausted just this question recently? Sure I saw a whole discussion on cppfront, wasn't that you?

I suspect you also know that Qt is not likely to move to cppfront or carbon ....

[brainchild]

@JonB I find it a bit rude of you to suggest made I particular comments, but not to bother to find a reference. Do you have one?

At any rate, it seems confusing to invoke the idea of Qt "moving" to one these languages, as the purpose of either largely is interoperability.

[JonB]

@brainchild said in Cppfront, Carbon, and Qt:

I find it a bit rude

Are you serious?? Most people would say "It wasn't me, but do you have the reference?".....

[Chris Kawa]

There was a bit of discussion here. I won't repeat myself, but I'm very skeptical about both of those things.

As for how they will influence Qt? To the same extent they will influence C++, so very little I think.
They focus on implicit memory management, no pointers, functional syntax (for some odd reason) etc. which doesn't match Qt's style too well. Maybe some 3rd party will make some toys or bindings etc., but otherwise I don't see Qt jumping head first into doing anything with those directly.

[JonB]

@brainchild
I have gone sought it out, since you regard it "rude" that I failed to do so.

The thread was https://forum.qt.io/topic/135257/old-hacker-low-tolerance, later on. It is true that it was not you, I misremembered, that's why I asked whether it was you. Sorry if you find my failure to recall correctly rude too.

[brainchild]

@Chris-Kawa Your characterizations about memory management and other run time features may be slightly accurate for Carbon, but in the case of Cppfront, many of your objections seem based on distaste for the interests of the author. Neither project has committed to memory management being central or required, and in the case of Cppfront, the objectives are stated to express a basic use case as an alternative syntax compatible with existing semantics.

[JKSH]

@brainchild said in Cppfront, Carbon, and Qt:

As the most obvious example, it follows C in requiring maintenance of header files separate from files defining functions. Class membership, part of C++ but not C, makes the syntax far more unwieldy

Not strictly.

It is perfectly valid in C++ to fully define all class methods in the header file, within the class declaration, without a separate *.cpp file. You just end up re-compiling things more often than necessary (and you might get dirty looks from your colleagues).

Does anyone have thoughts, hopes, or reservations, about either project informing the future of development with Qt?

I think it's good for people to try new things. That's how innovation and development occurs. At the same time, I don't have as strong an opinion as @Chris-Kawa regarding the merits of spending time on these particular projects.

I'm not quite sure what you mean by "informing the future of development with Qt" -- do you mean:

1. "(Cppfront or Carbon) influencing the future iterations of Qt"?
2. "((Cppfront or Carbon) and Qt) influencing future iterations of programming languages"?
3. Something else?

I don't think (1) will happen in the foreseeable future, since both projects are not ready for widespread deployment so it doesn't make sense for Qt to use/depend on them. I don't think (2) makes sense as a partnership either, since Qt and Cppfront/Carbon have very different purposes.

[brainchild]

@JKSH said in Cppfront, Carbon, and Qt:

I'm not quite sure what you mean by "informing the future of development with Qt"

My thoughts were no so particular, except more strongly associated with providing more options for those writing applications with Qt, rather than some explicit partnership or endorsement of one project for another.

I agree it strains the imagination to consider a course in the foreseeable future in which either project would affect the direction of Qt, but if one gains reasonable momentum, then the community as a whole might benefit from add-ons or utilities supplying any missing glue, to support integration better than might be available through each project independently.

It may be a rough analogy that the poor match between the limited semantics of the C language and the high-level abstractions of GLib and GObject led to the Vala language. Vala allows developers to utilize the support libraries through much cleaner and simpler programming. In principle, Qt developers might benefit from a language for writing applications more quickly and elegantly through a language not C++. The analogy is quite course, and I fear one that may anger some, but I think it still has some value.

[Chris Kawa]

@brainchild said in Cppfront, Carbon, and Qt:

Your characterizations about memory management and other run time features may be slightly accurate for Carbon

I believe there's just no reason for Carbon. We already have attempts at similar goals, like D or Rust. Why not help with those instead? It's just google guys being google guys and wanting their own. I predict it's gonna be a niche for couple of years and then it goes to the graveyard. Have fun with it while it lasts.

but in the case of Cppfront, many of your objections seem based on distaste for the interests of the author

I do think he's the trojan horse of C++, yes, but I also do try to look at it objectively. You can't separate the work from the man who does it, and looking at his past work I can't ignore the obvious fact that he is (yet again) trying to morph C++ into something I don't appreciate at all.

the objectives are stated to express a basic use case as an alternative syntax compatible with existing semantics

I guess it would be the first time the box said something different than what the product inside did then :)

People keep saying cppfront is not a replacement, it's an alternate syntax. I don't believe we need yet another syntax in C++. We already have too much of it and I don't want to deal with both, which is what would end up happening in real existing projects.

As a pure syntax nitpick, how is auto main() -> int(Carbon) or main: () -> int =(cppfront) an improvement over int main()???

[brainchild]

@Chris-Kawa said in Cppfront, Carbon, and Qt:

I believe there's just no reason for Carbon. We already have attempts at similar goals, like D or Rust.

The project objectives are rather different. D attempted to unify the whole gamut of object-oriented programming into a single base language. Rust constructs are quite different from those of C++, so calls across the two languages require complex mappings that are difficult to maintain and often unsafe.

A legitimate objection to Carbon may be a tendency to express an equivocation between being a new language versus being a new layer for C++. Perhaps such an observation is part of your objection. It may be that the lighter approach offered in Cppfront is helpful for replacing C++ in some contexts, while leaving Rust and other newer languages for development that is more separable from C++.

You can't separate the work from the man who does it, and looking at his past work I can't ignore the obvious fact that he is (yet again) trying to morph C++ into something I don't appreciate at all.

I think it is important to keep objections grounded. Perhaps someone has written software I may find useful, but also has adopted a broad range of lifestyle choices or political leanings I find objectionable. Should I avoid using the software? The name of the project reveals its purpose. It's just a front end. Anyone who likes writing C++ code would be free to continue doing so, but I would just as well never have another mind-numbing fight with a C++ build tool chain.

I guess it would be the first time the box said something different than what the product inside did then :)

People keep saying cppfront is not a replacement, it's an alternate syntax. I don't believe we need yet another syntax in C++. We already have too much of it and I don't want to deal with both, which is what would end up happening in real existing projects.

We have too much of what? Alternative syntax for C++? What are other examples of active projects?

What do you think Cppfront does, substantively, that is wrong?

As a pure syntax nitpick, how is auto main() -> int(Carbon) or main: () -> int =(cppfront) an improvement over int main()???

It is a newer style many prefer, but obviously not the reason why either project was conceived. Objecting to either project as such is like objecting to choosing an electric car because of some conventional car being available with different cup holders.

[Chris Kawa]

@brainchild said:

Perhaps someone has written software I may find useful, but also has adopted a broad range of lifestyle choices or political leanings I find objectionable. Should I avoid using the software?

I would. You don't have to.
I will avoid those projects. You don't have to.

The name of the project reveals its purpose.

The name of the product is a way to sell whatever the authors want. cppfront brings warm fuzzy association with cfront and C++ syntax 2 sounds closer to what you know than C++/CLI for example. You can be ok with the product, that's fine, but please don't give into the pure marketing that is so transparent it's not even funny.

but I would just as well never have another mind-numbing fight with a C++ build tool chain

How would cppfront make the toolchains better? It actually makes it worse because it adds to its length.

We have too much of what? Alternative syntax for C++? What are other examples of active projects?

I don't mean other projects. I mean within C++ itself. There's couple dozens ways to initialize a variable. We don't need another.

What do you think Cppfront does, substantively, that is wrong?

• Markets itself as an alternative. It's not. It's an add-on at best, which complicates systems, not simplifies.
• Is owned by a single person. Has that ever turned out good?
• Introduces pointless syntax changes just because, like the main example above.
• Introduces yet another step in the toolchain. Complicates already complicated ecosystem.
• Further fragments the already fragmented world of programming languages.
• Does not have any tooling backing associated with it or plan for it.
• Since realistically any existing project would hybrid this with C++ the different defaults, depending on which file you're in makes things harder, not simpler.
• I could go on, but I don't want to. I had this conversation many times already and I'm kinda tired of this topic to be honest.

Objecting to either project as such is like objecting to choosing an electric car because of some conventional car being available with different cup holders.

That's just completely random comparison that has nothing to do with the situation. Electric cars or other such technologies are necessary for sustainable future that doesn't rely on carbon (oh, the irony). These projects are not necessary or helpful. C++ can and does evolve. If you want a car analogy it's replacing a brand X for brand Y, because it has nicer headlights but smaller trunk.

[brainchild]

@Chris-Kawa said in Cppfront, Carbon, and Qt:

Perhaps someone has written software I may find useful, but also has adopted a broad range of lifestyle choices or political leanings I find objectionable. Should I avoid using the software?

I would. You don't have to.
I will avoid those projects. You don't have to.

You won't agree with anyone on everything, but you can still build on each other's work, and respect it. In fact, I doubt anyone has a choice of using tools and ideas created by others with whom one's own interests are not in perfect alignment.

The name of the project reveals its purpose.

The name of the product is a way to sell whatever the authors want. cppfront brings warm fuzzy association with cfront and C++ syntax 2 sounds closer to what you know than C++/CLI for example. You can be ok with the product, that's fine, but please don't give into the pure marketing that is so transparent it's not even funny.

Sure, but I found no evidence of incongruity between the stated and actual objectives.

but I would just as well never have another mind-numbing fight with a C++ build tool chain

How would cppfront make the toolchains better? It actually makes it worse because it adds to its length.

C++ is hard to use. Thoughtless technical mistakes lead to obtuse error message. It is a problem for the language, experienced when the tool chain is invoked.

We have too much of what? Alternative syntax for C++? What are other examples of active projects?

I don't mean other projects. I mean within C++ itself. There's couple dozens ways to initialize a variable. We don't need another.

Right, there are problems with C++ syntax. Why would the observation lead you to object to an alternative?

What do you think Cppfront does, substantively, that is wrong?

• Markets itself as an alternative. It's not. It's an add-on at best, which complicates systems, not simplifies.
• Is owned by a single person. Has that ever turned out good?
• Introduces pointless syntax changes just because, like the main example above.
• Introduces yet another step in the toolchain. Complicates already complicated ecosystem.
• Further fragments the already fragmented world of programming languages.
• Does not have any tooling backing associated with it or plan for it.
• Since realistically any existing project would hybrid this with C++ the different defaults, depending on which file you're in makes things harder, not simpler.
• I could go on, but I don't want to. I had this conversation many times already and I'm kinda tired of this topic to be honest.

You're plainly just nitpicking. It is a small experiment currently owned by one person trying to prove a concept. Every objection you give has an alternative side.

That's just completely random comparison that has nothing to do with the situation. Electric cars or other such technologies are necessary for sustainable future that doesn't rely on carbon (oh, the irony). These projects are not necessary or helpful. C++ can and does evolve.

It is an analogy, of which you have missed the purpose. You may not think the concept of Cppfront adds value, but whether it does broadly is the question, not whether you like every nuance.

---

Vala has succeeded as a front end for GObject and GLib. Kotlin has succeeded as an alternative syntax for building Java classes. Whether Cppfront will succeed is an open question, but I fail to see a problem with the concept, especially in light of recent examples of comparable successes.

[Christian Ehrlicher]

@brainchild said in Cppfront, Carbon, and Qt:

It is a small experiment currently by one person trying to prove a concept. Every objection you give has an alternative side.

Does anyone have thoughts, hopes, or reservations, about either project informing the future of development with Qt?

So you really want to tell us that any serious development of this size will switch to a one-man show? Wow...

[Chris Kawa]

@brainchild I mean I could respond to everything you said, but, like I said, I'm kinda tired of being the old guy screaming at clouds, while there's a party around the new shiny thing.

I'm ok with those things existing. It's not the first time. It's definitely not the last. I see a lot of markers of repeated history that people on with the hype just seem to brush off.

How about this - lets just wait it out couple years. You'll have your fun with it, then awkwardly fall silent when it fizzles out, and I'll have my fun murmuring "I told you so" to the deaf computer screen. Sounds ok to me.

[brainchild]

@Christian-Ehrlicher said in Cppfront, Carbon, and Qt:

So you really want to tell us that any serious development of this size will switch to a one-man show? Wow...

I don't understand your comment.

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?

[Christian Ehrlicher]

@brainchild said in Cppfront, Carbon, and Qt:

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?

So how does Qt come into play here?

If you want to try it out - try to compile Qt with it or port it to this and if it's working out in 5 years or so then It may be a valid compiler (or whatever) for Qt.

[brainchild]

@Chris-Kawa I am not predicting success. I believe the future is open. The objections given so far have not seemed compelling. They have seemed to emphasize what the project is not, not what it is.

I am not aware of any project, ongoing or abandoned, quite like Cppfront, but would be happy to learn of any.

[Chris Kawa]

@brainchild Well, for an easy pick look no further than into Herb's past. Find anyone who has to maintain C++ C++/CLI C++/CX UWP hybrids to this day and ask how fun it is to deal with language evolutions that were too shiny to pass on. They were "just a little syntax sugar" too at the start. Just a little ^ here and there. And not even a single man projects. Had all the might and backing of Microsoft, Visual Studio tooling etc. Now they are husks on life support and burden to everyone who jumped on the hype train.

[brainchild]

@Christian-Ehrlicher said in Cppfront, Carbon, and Qt:

So how does Qt come into play here?

As I stated, Cppfront may help support cleaner and faster development of applications based on the Qt. My view is it might be valuable as an option, though it may never fully replace C++, even for entirely new projects.

Carbon may also offer similar benefits, though the project is different.

If either fails to gain interest, or if its development stalls, then it will be irrelevant for Qt.