Cppfront, Carbon, and Qt
-
@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
mainexample 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.
@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 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
mainexample 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.
@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 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...
@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 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?
@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 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.
@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 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.
@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 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.
@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.
-
@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.
@brainchild if you do research, try anything you like. But you develop products for a long term, @Chris-Kawa is right about sticking to long lasting programming languages.
-
@brainchild if you do research, try anything you like. But you develop products for a long term, @Chris-Kawa is right about sticking to long lasting programming languages.
@JoeCFD Perhaps you misread my meaning. I am not suggesting beginning a project at this moment written in Cppfront or Carbon. To my knowledge, doing so is not even possible, as neither is complete.
I believe C++ is problematic for most development occurring today. Code is slow to write and hard to maintain. I also believe such a view is quite widespread. The idea of a viable front end is compelling, though of course any success is yet to be proved.
D, Rust, and Go emerged from a desire to replace C++, but each is a new language in its own right, not one that integrates cleanly into a system already begun in C++.
To represent the concept, and its potential, I return to Vala and Kotlin. Most developers prefer the design of more recent languages, all else equal, and C++ is almost singular among programming languages for its verbosity and redundancy.
-
@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.
@Chris-Kawa said in Cppfront, Carbon, and Qt:
@brainchild 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.
Microsoft is notorious for reinventing the wheel, even if it makes one as a hexagon just to be different from a circular one. I think it is not helpful to make comparisons to projects developed by Microsoft.
-
@JoeCFD Perhaps you misread my meaning. I am not suggesting beginning a project at this moment written in Cppfront or Carbon. To my knowledge, doing so is not even possible, as neither is complete.
I believe C++ is problematic for most development occurring today. Code is slow to write and hard to maintain. I also believe such a view is quite widespread. The idea of a viable front end is compelling, though of course any success is yet to be proved.
D, Rust, and Go emerged from a desire to replace C++, but each is a new language in its own right, not one that integrates cleanly into a system already begun in C++.
To represent the concept, and its potential, I return to Vala and Kotlin. Most developers prefer the design of more recent languages, all else equal, and C++ is almost singular among programming languages for its verbosity and redundancy.
@brainchild These guys are veterans. Their ideas are accumulated from experiences. Not bad! Have you seen a big company tried to rewrite their code in another language? If you are a manager, better to be careful when you select programming language.
-
@JoeCFD Perhaps you misread my meaning. I am not suggesting beginning a project at this moment written in Cppfront or Carbon. To my knowledge, doing so is not even possible, as neither is complete.
I believe C++ is problematic for most development occurring today. Code is slow to write and hard to maintain. I also believe such a view is quite widespread. The idea of a viable front end is compelling, though of course any success is yet to be proved.
D, Rust, and Go emerged from a desire to replace C++, but each is a new language in its own right, not one that integrates cleanly into a system already begun in C++.
To represent the concept, and its potential, I return to Vala and Kotlin. Most developers prefer the design of more recent languages, all else equal, and C++ is almost singular among programming languages for its verbosity and redundancy.
@brainchild said:
Microsoft is notorious for reinventing the wheel
Sutter works at Microsoft and was part of a lot of those wheel reinventions.
I think it is not helpful to make comparisons to projects developed by Microsoft
Why not? Carbon is Google people, D is Meta people, Rust is Mozilla people... and cppfront is Herb, who is a Microsoft guy. Companies are not some abstract entities. They are made of people. The same people that create those languages.
Most developers prefer the design of more recent languages
That's kinda bold statement. Can you back it up?
C++ is almost singular among programming languages for its verbosity and redundancy
Yes and it is evolving to simplify. See modules or even a modern hello world:
import std; int main() { print("Hello world\n"); }That's not the same C++ you would write in '83. Got rid of preprocessor, include order problems, verbosity of streams, improved compile times etc. And those simplifications didn't require new language or new tools. Just hard work on existing.
-
@brainchild These guys are veterans. Their ideas are accumulated from experiences. Not bad! Have you seen a big company tried to rewrite their code in another language? If you are a manager, better to be careful when you select programming language.
@Chris-Kawa said in Cppfront, Carbon, and Qt:
Sutter works at Microsoft and was part of a lot of those wheel reinventions.
I think it is not helpful to make comparisons to projects developed by Microsoft
Why not? Carbon is Google people, D is Meta people, Rust is Mozilla people... and cppfront is Herb, who is a Microsoft guy. Companies are not some abstract entities. They are made of people. The same people that create those languages.'
Companies are made of people, and carry a further abstraction through history, culture, and convention that transcends any single person. If I worked at Microsoft, then surely I would work in a way different from how I would work at another company, or by myself, and surely any mistakes in my work, whether by my choice or another's, would be learning experiences.
Most developers prefer the design of more recent languages
That's kinda bold statement. Can you back it up?
Developers adopt newer languages because newer ones tend to resolve the problems of older ones, based on the experience that accumulated toward their creation.
C++ is almost singular among programming languages for its verbosity and redundancy
Yes and it is evolving to simplify.
Yes, but even so, the problematic characterizations remain overall largely the same. We still have a big mess with headers, class names prefixing function names in definitions, and the fake function definitions for templates placed in header files.
-
@Chris-Kawa said in Cppfront, Carbon, and Qt:
Sutter works at Microsoft and was part of a lot of those wheel reinventions.
I think it is not helpful to make comparisons to projects developed by Microsoft
Why not? Carbon is Google people, D is Meta people, Rust is Mozilla people... and cppfront is Herb, who is a Microsoft guy. Companies are not some abstract entities. They are made of people. The same people that create those languages.'
Companies are made of people, and carry a further abstraction through history, culture, and convention that transcends any single person. If I worked at Microsoft, then surely I would work in a way different from how I would work at another company, or by myself, and surely any mistakes in my work, whether by my choice or another's, would be learning experiences.
Most developers prefer the design of more recent languages
That's kinda bold statement. Can you back it up?
Developers adopt newer languages because newer ones tend to resolve the problems of older ones, based on the experience that accumulated toward their creation.
C++ is almost singular among programming languages for its verbosity and redundancy
Yes and it is evolving to simplify.
Yes, but even so, the problematic characterizations remain overall largely the same. We still have a big mess with headers, class names prefixing function names in definitions, and the fake function definitions for templates placed in header files.
@brainchild said:
Companies are made of people, and carry a further abstraction
So you're saying we should discard anything we can learn from mistakes of companies because there's no single name to pin them on? That's a weird attitude. I disagree. Big tech companies create big tech we all use every day. That's, by far, the largest pool of experiences to learn from.
Developers adopt newer languages because newer ones tend to resolve the problems of older ones
Not in my experience. The way I've seen it in my career people usually switch because their manager/lead went to a conference or read a LinkedIn post and got the bug. People that do actual work have to deal with the realities of life and the fallout for years - transition, compatibility, tooling woes, growing pains, evolution beyond basic "let's improve syntax" ideas, while those decision makers move on to the new shiny every few months when those problems become too much to handle.
We still have a big mess
Yes, we can't clean everything up in an instant. What's your point? Throw away 40 years of evolution because you don't like class name in front of a method or some other style bit? Seriously? What's next? New language because ; is not optional like in "modern" languages and it confuses Python programmers?
-
@brainchild said:
Companies are made of people, and carry a further abstraction
So you're saying we should discard anything we can learn from mistakes of companies because there's no single name to pin them on? That's a weird attitude. I disagree. Big tech companies create big tech we all use every day. That's, by far, the largest pool of experiences to learn from.
Developers adopt newer languages because newer ones tend to resolve the problems of older ones
Not in my experience. The way I've seen it in my career people usually switch because their manager/lead went to a conference or read a LinkedIn post and got the bug. People that do actual work have to deal with the realities of life and the fallout for years - transition, compatibility, tooling woes, growing pains, evolution beyond basic "let's improve syntax" ideas, while those decision makers move on to the new shiny every few months when those problems become too much to handle.
We still have a big mess
Yes, we can't clean everything up in an instant. What's your point? Throw away 40 years of evolution because you don't like class name in front of a method or some other style bit? Seriously? What's next? New language because ; is not optional like in "modern" languages and it confuses Python programmers?
@Chris-Kawa said in Cppfront, Carbon, and Qt:
Companies are made of people, and carry a further abstraction
So you're saying we should discard anything we can learn from mistakes of companies because there's no single name to pin them on? That's a weird attitude. I disagree. Big tech companies create big tech we all use every day. That's, by far, the largest pool of experiences to learn from.
Not even slightly.
I am saying each company has a culture that affects what is done inside of it, separate from the choices or preferences of any single member.
If I worked on a failed project for a company that had a certain culture, I might like the opportunity to try again, free from that culture, and also learning from the mistakes.
Developers adopt newer languages because newer ones tend to resolve the problems of older ones
Not in my experience. The way I've seen it in my career people usually switch because their manager/lead went to a conference or read a LinkedIn post and got the bug. People that do actual work have to deal with the realities of life and the fallout for years - transition, compatibility, tooling woes, growing pains, evolution beyond basic "let's improve syntax" ideas, while those decision makers move on to the new shiny every few months when those problems become too much to handle.
I understand. Some developers may use a language for reasons not one's own. Many developers prefer newer languages, however, for being more elegant and expressive.
We still have a big mess
Yes, we can't clean everything up in an instant. What's your point? Throw away 40 years of evolution because you don't like class name in front of a method or some other style bit? Seriously? What's next? New language because ; is not optional like in "modern" languages and it confuses Python programmers?
My point is we have a mess, and much of that mess is addressed by projects such as Cppfront. Such is largely the reason I personally might like to see it succeed. C++ itself may also address some of the mess in the future, if possible. In either case evolution would be occurring continuously, not discarded.
-
@Chris-Kawa said in Cppfront, Carbon, and Qt:
Companies are made of people, and carry a further abstraction
So you're saying we should discard anything we can learn from mistakes of companies because there's no single name to pin them on? That's a weird attitude. I disagree. Big tech companies create big tech we all use every day. That's, by far, the largest pool of experiences to learn from.
Not even slightly.
I am saying each company has a culture that affects what is done inside of it, separate from the choices or preferences of any single member.
If I worked on a failed project for a company that had a certain culture, I might like the opportunity to try again, free from that culture, and also learning from the mistakes.
Developers adopt newer languages because newer ones tend to resolve the problems of older ones
Not in my experience. The way I've seen it in my career people usually switch because their manager/lead went to a conference or read a LinkedIn post and got the bug. People that do actual work have to deal with the realities of life and the fallout for years - transition, compatibility, tooling woes, growing pains, evolution beyond basic "let's improve syntax" ideas, while those decision makers move on to the new shiny every few months when those problems become too much to handle.
I understand. Some developers may use a language for reasons not one's own. Many developers prefer newer languages, however, for being more elegant and expressive.
We still have a big mess
Yes, we can't clean everything up in an instant. What's your point? Throw away 40 years of evolution because you don't like class name in front of a method or some other style bit? Seriously? What's next? New language because ; is not optional like in "modern" languages and it confuses Python programmers?
My point is we have a mess, and much of that mess is addressed by projects such as Cppfront. Such is largely the reason I personally might like to see it succeed. C++ itself may also address some of the mess in the future, if possible. In either case evolution would be occurring continuously, not discarded.
@brainchild said in Cppfront, Carbon, and Qt:
Many developers prefer newer languages, however, for being more elegant and expressive.
Did you ever worked in a company which had real projects?
Your sentence may be true for hobby stuff or a very small percentage of companies.
How will you even add a new language in a 20-year old product? Do you really think you can convince the manager that switching to a new shiny programming language will solve all your problems with the old code? Where do you live??? -
@brainchild said in Cppfront, Carbon, and Qt:
Two projects recently have emerged
I like to also include Jakt in this list. Not familiar with it myself, but interesting due to the people that are working on it.
@Chris-Kawa said in Cppfront, Carbon, and Qt:
As a pure syntax nitpick, how is auto main() -> int(Carbon) or main: () -> int =(cppfront) an improvement over int main()???
You picked the by far simplest example and the difference is just splitting hairs. Where it becomes more interesting is when (if) this idea of being able to read from left to right always can be applied to much more tricky syntax. (no, not going to repeat the examples here, DYOR).
@Chris-Kawa said in Cppfront, Carbon, and Qt:
Is owned by a single person. Has that ever turned out good?
To be fair, he has Microsoft behind him.
Anyway, Chris may disagree and try to convince people to not innovate. That is his right.
Ironically this topic of C++ transpiled languages got attention the other day because or severe problems in the industry. Problems that at least in part are due to the problems most of those projects are trying to solve. So, I don't care that Chris dislikes one guy and his repo. Or even dislikes Microsoft as a whole. As long as the research is done in the open and the code is available in an appropriate license, then we all benefit.
In the end the industry will use such a transpiled language or it won't. And more choice is good, competition of ideas is good, because then the chance is, usage is going to be more based on merit than on reputation.
To give my 2 cents on the initial question. I think its too early days to consider how this affects Qt or Qt using developers.
ps. first and probably last message on this thread, seems this is a hot topic ;-)
-
@brainchild said in Cppfront, Carbon, and Qt:
Two projects recently have emerged
I like to also include Jakt in this list. Not familiar with it myself, but interesting due to the people that are working on it.
@Chris-Kawa said in Cppfront, Carbon, and Qt:
As a pure syntax nitpick, how is auto main() -> int(Carbon) or main: () -> int =(cppfront) an improvement over int main()???
You picked the by far simplest example and the difference is just splitting hairs. Where it becomes more interesting is when (if) this idea of being able to read from left to right always can be applied to much more tricky syntax. (no, not going to repeat the examples here, DYOR).
@Chris-Kawa said in Cppfront, Carbon, and Qt:
Is owned by a single person. Has that ever turned out good?
To be fair, he has Microsoft behind him.
Anyway, Chris may disagree and try to convince people to not innovate. That is his right.
Ironically this topic of C++ transpiled languages got attention the other day because or severe problems in the industry. Problems that at least in part are due to the problems most of those projects are trying to solve. So, I don't care that Chris dislikes one guy and his repo. Or even dislikes Microsoft as a whole. As long as the research is done in the open and the code is available in an appropriate license, then we all benefit.
In the end the industry will use such a transpiled language or it won't. And more choice is good, competition of ideas is good, because then the chance is, usage is going to be more based on merit than on reputation.
To give my 2 cents on the initial question. I think its too early days to consider how this affects Qt or Qt using developers.
ps. first and probably last message on this thread, seems this is a hot topic ;-)
@TomZ said:
Chris may disagree and try to convince people to not innovate
That's just harmful exaggeration, please don't assume such things. Innovate away, by all means. I'm not against progress. I just don't believe that's it and I don't particularly look forward to cleaning up after this mess (by which I mean work in those hybrid workspaces if they do emerge), but have at it, I'll live.
So, I don't care that Chris dislikes one guy and his repo
I think you did grew to care a little bit, and I appreciate it :) I don't dislike the guy. Like I said in the other thread - he's a great presenter, community builder, facilitates a lot of work that is being done in the C++ space and does a lot of good work educating via blogs and whatnot. I just don't like the direction he's been trying to push C++ for the longest time, or the multitude attempts at replacing it with what I consider destructive processes and lesser options. I think it's misguided, fragmenting and harmful long term. Sure it's cool to play around with, like any tech is to me, but I just don't appreciate all that cheerleading that is currently happening around it. It's just a very limited toy, hyped up to high heavens, not a solution to all problems of C++, like some deem it to be.
I'm not chaining myself to a tree or anything like that. Do whatever you want. You asked about opinions in that other thread so I answered. OP asked the same here so I responded. If you don't want to see me talking about it that's fine. I'm a bit annoyed and tired of the topic anyway, so I probably will shut up if it reappears.
-
@TomZ said:
Chris may disagree and try to convince people to not innovate
That's just harmful exaggeration, please don't assume such things. Innovate away, by all means. I'm not against progress. I just don't believe that's it and I don't particularly look forward to cleaning up after this mess (by which I mean work in those hybrid workspaces if they do emerge), but have at it, I'll live.
So, I don't care that Chris dislikes one guy and his repo
I think you did grew to care a little bit, and I appreciate it :) I don't dislike the guy. Like I said in the other thread - he's a great presenter, community builder, facilitates a lot of work that is being done in the C++ space and does a lot of good work educating via blogs and whatnot. I just don't like the direction he's been trying to push C++ for the longest time, or the multitude attempts at replacing it with what I consider destructive processes and lesser options. I think it's misguided, fragmenting and harmful long term. Sure it's cool to play around with, like any tech is to me, but I just don't appreciate all that cheerleading that is currently happening around it. It's just a very limited toy, hyped up to high heavens, not a solution to all problems of C++, like some deem it to be.
I'm not chaining myself to a tree or anything like that. Do whatever you want. You asked about opinions in that other thread so I answered. OP asked the same here so I responded. If you don't want to see me talking about it that's fine. I'm a bit annoyed and tired of the topic anyway, so I probably will shut up if it reappears.
@Chris-Kawa said in Cppfront, Carbon, and Qt:
@TomZ said:
Chris may disagree and try to convince people to not innovate
That's just harmful exaggeration, please don't assume such things. Innovate away, by all means. I'm not against progress.
The characterization may seem to you as inaccurate, but from the other side, it has seemed at times you have sought to throw down any objection simply to avoid conceding any merit to newer approaches.
At one point it has come across that new languages tend to be adopted simply because managers overestimate their promise and impose them on developers. At another point, that the whole world must forever carry the burden of every old project firmly established in a particular language.
It has been hard to pull out any central theme, other than a bid to preserve the status quo.
Yet, one observation remains without controversy. C++ is tedious.
On one hand, it has accumulated decades of experience over the problem of merging constructs such as classes and generics with near-perfect run time optimization and type safety. On the hand, it has left developers with a level of verbosity that leaves them expending more effort fighting tools than taking advantage of the various kinds of higher-order constructs. Fixing build errors in nested templates is hardly among the more joyful experiences a developer can imagine.
The question I put to you is whether you more strongly object to the principle of building a compatible grammar, from scratch, in a modern context, or whether you more strongly seek to find problems in every particular attempt to do so.
Put another way, if you were asked to consider how to design an entirely new grammar, compatible with the old at each stage of use, but otherwise unburdened by legacy, would you think it possible to create one substantially more appealing than the current, enough so that developers might benefit from using it? If so, perhaps energies are more wisely spent advising existing efforts, instead of objecting to them, more usefully directed toward unifying the community, instead of complaining over fragmentation.
For my part, I return to the original thought experiment that prompted my question. Suppose someone wished to write a completely new application, using Qt, but felt deterred by the verbosity of C++, after recent experience writing in newer, lighter, and freer languages. Would a viable approach, if one were readily available, be of using a solution similar to Cppfront? Could one solution become a mainstream approach for resolving dilemmas of such kind?
-
@Chris-Kawa said in Cppfront, Carbon, and Qt:
@TomZ said:
Chris may disagree and try to convince people to not innovate
That's just harmful exaggeration, please don't assume such things. Innovate away, by all means. I'm not against progress.
The characterization may seem to you as inaccurate, but from the other side, it has seemed at times you have sought to throw down any objection simply to avoid conceding any merit to newer approaches.
At one point it has come across that new languages tend to be adopted simply because managers overestimate their promise and impose them on developers. At another point, that the whole world must forever carry the burden of every old project firmly established in a particular language.
It has been hard to pull out any central theme, other than a bid to preserve the status quo.
Yet, one observation remains without controversy. C++ is tedious.
On one hand, it has accumulated decades of experience over the problem of merging constructs such as classes and generics with near-perfect run time optimization and type safety. On the hand, it has left developers with a level of verbosity that leaves them expending more effort fighting tools than taking advantage of the various kinds of higher-order constructs. Fixing build errors in nested templates is hardly among the more joyful experiences a developer can imagine.
The question I put to you is whether you more strongly object to the principle of building a compatible grammar, from scratch, in a modern context, or whether you more strongly seek to find problems in every particular attempt to do so.
Put another way, if you were asked to consider how to design an entirely new grammar, compatible with the old at each stage of use, but otherwise unburdened by legacy, would you think it possible to create one substantially more appealing than the current, enough so that developers might benefit from using it? If so, perhaps energies are more wisely spent advising existing efforts, instead of objecting to them, more usefully directed toward unifying the community, instead of complaining over fragmentation.
For my part, I return to the original thought experiment that prompted my question. Suppose someone wished to write a completely new application, using Qt, but felt deterred by the verbosity of C++, after recent experience writing in newer, lighter, and freer languages. Would a viable approach, if one were readily available, be of using a solution similar to Cppfront? Could one solution become a mainstream approach for resolving dilemmas of such kind?
@brainchild You keep exaggerating like I'm some comic book villain. It's kinda funny but you know... doesn't help ;)
simply to avoid conceding any merit to newer approaches.
I don't avoid anything. I just don't see any merit. What do you want me to say? Something nice about it to sound more toned? Sure - the freedom is nice. It's creative fun to invent stuff with no baggage. I had a course in school where we invented our own languages. Fun.
It has been hard to pull out any central theme, other than a bid to preserve the status quo.
Just so you know - the feeling about central theme is mutual :) I might seem all over the place because I see problems with that approach all over it. I don't know how to be brief about it, I do admit that.
Yet, one observation remains without controversy. C++ is tedious.
Another bold statement without backing. You find it tedious. That we can agree on. I find it sporadically slightly annoying, yet acceptable for the benefits it brings me. Others will have their opinions. I suggest you don't appropriate them without consultation.
it has left developers with a level of verbosity that leaves them expending more effort fighting tools than taking advantage of the various kinds of higher-order constructs
Again - that's not universal. You might have that experience. You may know others that do too. It's not everyone. Others will have varying experiences. I for one spend a lot more time designing and implementing software than fighting tools. Speaking of tools - I'd like more of those, not more syntax to deal with.
Fixing build errors in nested templates is hardly among the more joyful experiences a developer can imagine
Why do you nest templates then? Just don't do it. I know old hackers that barely ever write templates beyond generic containers. They are happy, their code is simple and understandable. Heck, almost entire Qt is like that and it's fine. Why do difficult stuff and complain that it's difficult? Use when they help. Don't when they get in the way.
The question I put to you is whether you more strongly object to any attempt to build a compatible grammar, from scratch, in a modern context, or whether you more strongly seek to find problems in every particular attempt to do so.
Can I take door number three or are those two molds you created for me my only choice?
Put another way, if you were asked to consider how to define an entirely new grammar, compatible with the old at each stage of use, but otherwise unburdened by any legacy, would you think it possible to create one considerably more appealing than the current, enough so that developers might benefit from using it?
Oh, I think it's entirely possible to create better grammar and it's not really that hard. I just think grammar is maybe 1% of the problem and solving that 1% by reinventing everything creates a ton of, far more serious, problems that only add to the existing ones. Grammar is detail. We need big picture thinking. What is grammar going to fix if current day programmer is asking "how do i make button go click"? You think slightly better syntax is gonna make them suddenly write perfect nested generics and wonderful safe code? Hah, dream on.
feeling repulsed by the verbosity of C++ (...) Would a viable approach, in principle, be of using a solution similar to Cppfront?
I'd say a better approach would be to change career. Why on Earth are you doing something that repulses you as your job? That's not healthy. Not joking here, seriously. Go with the lighter languages that you like. Everybody wins and lives happily.
I don't like garbage collected languages for example, so I don't work with them. I don't try to "evolve" Java into something I prefer. I don't like watching sport so I don't do it. I'm not gonna try to reinvent soccer for everyone because I don't find it attractive.
I don't mind C++. It has flaws, sure. Some are fixable, some not. Evolution is happening, some simply can't due to legacy concerns. I'm fine with the pace the language is changing.Could one solution become a mainstream approach for resolving dilemmas of such kind?
Personally I don't believe in "one size fits all" solutions. Notice how people happily point out how different C++ is from other languages and yet they try to apply the same principles to evolving it. It's not Kotlin, It's not F#. It's not TypeScript. It is a different language. It has different concerns, problems and different way forward. It has 4 decades of legacy code, often with massive tech debt. It has enormous ecosystem of tooling and infrastructure. Standing the syntax on its head is not a solution. It's fuel to the fire.
