Cppfront, Carbon, and Qt
-
@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.
-
@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 ;-)
-
@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?
-
@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.
-
@Chris-Kawa said in Cppfront, Carbon, and Qt:
I don't avoid anything. I just don't see any merit.
I meant not to give an accusation, only a suggestion of how your position may look from the other side, given the way it was presented.
Yet, one observation remains without controversy. C++ is tedious.
Another bold statement without backing.
I think it is not widely controversial, but yes, I understand, not universal.
Even in the earliest days, the syntax for abstract methods was at least a source of amusement.
Fixing build errors in nested templates is hardly among the more joyful experiences a developer can imagine
Why do you nest templates then?
The types are determined by the application objectives. Applications are diverse in their requirements, and the language ought to be a tool more than a burden for as many cases as possible.
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'm fine with the pace the language is changing.
Personally I don't believe in "one size fits all" solutions.
I think the point is being lost, that historically, in order to create a build target fully compatible with one generated by a C++ compiler, it would be necessary to write source in the C++ grammar. The constraint has proved limiting in many cases, and an alternative grammar, not bound to a new build system in its own right, but neither bound to any legacy syntax, would be welcomed by many. The objective might be to converge on a consensus for a definition of such an alternative grammar.
I think memory management is a red herring. It appears to be an interest of the author, as discussed previously at length, but is not embedded in the concept of the alternative grammar.
Rather, there is value is a different grammar compatible with the same build targets. It is the reason Kotlin is being used in places where the choice would have previously been Java, to create applications or libraries targeted for the JVM.
I think the concept of a "second" C++ grammar is compelling, though only a second. Having a third, fourth, fifth, and so on, all competing against each other, would defeat the purpose, of a community of developers readily able to contribute to each others' projects.
-
@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".)
