Welcoming? Successor language? #1961
Replies: 5 comments 18 replies
-
|
It seems like there are two high-level issues raised here -- there is a huge amount of text, so I'm not going to be able to respond point by point, but I'll try to address these two high level issues. However, I want to remind you to avoid using sarcasm to make your points on this forum. I understand that you feel strongly about these issues, but being sarcastic or snarky is not productive or effective and not something we do here. First, is a concern around whether the community is "welcoming" or not. =/ It's a hard balance to make a welcoming community, and impossible to be welcoming for everyone. Not every moderation action is perfect or without flaw. For example, we're still learning how to use GitHub most effectively -- hopefully in the future we can transfer issues to discussions rather than closing them. But we are trying to make sure our issues stay focused on specific changes and the discussion forums are used for more open-ended discussion. We're doing the best we can to keep that, as that is super important for others to feel welcome to participate and be productive. While the action was taken very quickly here, nothing was deleted or lost forever. You were able to move the discussion here which seems like a more appropriate forum. So while a little inefficient, this seems fine to me. Similarly, we try to have an FAQ to be helpful, but sometimes links don't work as well as we'd like or we have a typo. I don't think calling this "unwelcoming" is really helpful or moving the discussion forward. It both holds people to an unreasonable standard of not making simple mistakes, and ignores that there are tradeoffs here. We can't be perfectly welcoming to all people at all times. The second is that there are a number of design decisions and strategy decisions that you don't agree with. On the design decisions, @cjdb pointed at several pieces of information that informed these decisions. You may still not agree, these are complex decisions and it is very likely that reasonable people will disagree on them. But the important question is whether there is specific new information that needs to be considered. Otherwise, we've made the best technical judgement call we can given the information, and we should move forward with that. On the strategic side, we've chosen to articulate Carbon's strategy as a "successor" strategy -- but this is new terminology and we've tried to define it. Maybe that wording doesn't work for everyone, but picking wording and terminology like this is extremely hard. We've done the best we can, and just saying "don't use this term" doesn't help us. If there is some specific problem with this approach, combined with a constructive suggestion for another approach, I would focus on that. |
Beta Was this translation helpful? Give feedback.
-
The wording does not work because "successor" already has an established interpretation so you cannot use it to create new terminology. It usually means a second/third/fourth/… attempt by the original community at capturing some key language qualities in their next language effort, correcting shortcoming of their previous attempt. E.g. BETA was the successor for Simula, but is completely different, yet has similar modelling goals. There is no compatibility involved in being a successor. Java is semantically very very close to Simula, but it wasn't really a successor by intent or culture, despite being almost a replica. Neither was C++. |
Beta Was this translation helpful? Give feedback.
-
While this is your interpretation of "successor", others (including both myself and numerous reviewers who helped us craft the current phrasing) have different interpretations. I don't think there is a single established interpretation. The point of us clarifying what we mean with the term is to address the fact that there are different interpretations. I'm not aware of a useful term that wouldn't have this problem, and so wouldn't need this kind of clarification. |
Beta Was this translation helpful? Give feedback.
-
Well, this isn't really a big issue, but it was a rather clever marketing move to call it a "C++ successor", yet I am not the only one that also thought that it takes a lot of hubris to do so. :-) So, overall a good move on your part, you got the attention to kick-start your project (being slightly controversial makes for better headlines). For people growing up in a monarchy the power-element associated with "succession" is quite clear though. This is also a big factor in how languages are perceived. Kotlin was just another bland JVM language until the Android-aristocracy dethroned Java. Nobody would have given Swift another look if the Apple-aristocracy hadn't installed it as the new king. And so on… On the other hand Dart was intended to be the installed successor for JavaScript, but the Chrome-aristocracy chose not to, leaving Dart in limbo for a long time. TypeScript is not succeeding JavaScript though, it is more of a piggy-back/parasitic/symbiotic approach. TypeScript is a typed JavaScript dialect, Objective-C and C++ are C dialects… Carbon is different from these, in my view. It seems more like you try to go for a grass-root revolution by the people (users) shredding the conservative structures that govern C++. Which could be excellent if it was to happen, but also quite different dynamics from the ones you listed as "successor languages"? Carbon isn't being parasitic, but takes more of a conversion/transpiling approach. TLDR; forget about the "successor-language" rhetoric, it does not seem to be a good fit, embrace instead the fact that you are not doing another round of evolution of C++, but take lessons from it. |
Beta Was this translation helpful? Give feedback.
-
|
@chandlerc I wasn't trying to be sarcastic or snarky, but anyway ... |
Beta Was this translation helpful? Give feedback.
-
Please see "Why not Rust?" in the FAQ. |
Beta Was this translation helpful? Give feedback.
-
|
@jonmeow I saw it, but that's why I asked what are the benefits to the general programming community and specifically the C++ community. Other than Google and perhaps Microsoft, what other organizations have such large, complex C++ codebases and would like to move to something like Rust? I presume Google management, at some level, is agreeable to this project, but are there other corporate "sponsors"? |
Beta Was this translation helpful? Give feedback.
-
It's not directly implied just by the amount of adoptions, yes. But modern languages have their reasons why they choose this syntax over the C++ syntax (easier parsability, better readability,...) and because so many come to the same conclusion, I would indeed call C++ syntax outdated. |
Beta Was this translation helpful? Give feedback.
-
AFAIK, one of Dart Language designers' regret was to try too hard being |
Beta Was this translation helpful? Give feedback.
-
You probably think of Gilad Bracha who expressed that the semantics of Dart were bland, but his dynamic language Newspeak is a far cry from what Carbon is aiming for... |
Beta Was this translation helpful? Give feedback.
-
|
@chandlerc I think it would be helpful for any C++ developer to see each C++ keyword (as in https://en.cppreference.com/w/cpp/keyword) and other key concepts listed in one place, together with the current Carbon determination as to what wiil be done about it, e.g., kept as is, kept but modified (Go example: |
Beta Was this translation helpful? Give feedback.
-
|
I would agree on this but just in a later stage of development. Adding all differences to C++ now when basically the whole syntax could still change is just gonna be a nightmare to maintain. |
Beta Was this translation helpful? Give feedback.
-
|
@DevNoteHQ The docs/design is certainly a start. [A relational database or spreadsheet would keep it from being "a nightmare to maintain".] |
Beta Was this translation helpful? Give feedback.
-
|
(I've edited the comment above to remove sarcasm, which our code of conduct doesn't permit. My edit is marked with square brackets.) |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
Our code of conduct says to be welcoming, friendly, and patient, and in general, if someone asks you to stop, then stop. Many members of the community do not find sarcasm or snark as part of arguing for a technical position welcoming or friendly. You were asked to avoid this, and instead included it. Whether it was intended or not, this is continuing to post things that others find unwelcoming and have asked you to stop. Since it seems our community's approach isn't the one you want to follow, it probably isn't for you. FWIW, I greatly admire the Rust community and hope that Carbon will remain a similarly welcoming one. Given this discussion isn't productive and has veered off the original topic, hiding the off-topic comments and leaving the thread locked. |
Beta Was this translation helpful? Give feedback.
-
Please refer to issue #1948. I will copy my original and subsequent posts in case @cjdb decides to take further unwelcoming steps. First of all, I'd like to offer my opinion on what was unwelcome about the actions. If you run an open source project and emphasize that you want to create a welcoming community, and someone posts something in your issue tracker which you consider is not the "right" place to start a discussion, I think any community member, even the founder or leader, in order to be welcoming would make a comment letting the poster know that he/she should move the discussion to the "appropriate" other channel(s). Then, if the poster didn't act on the suggestion in a "reasonable" time (considering the global timezones involved, I think at least 24 hours would be reasonable), then perhaps closing the issue may be appropriate. I consider that closing the issue immediately as "not planned" is not welcoming. Locking the issue to further input by the poster and two other participants simply adds to the unwelcoming attitude. Saying "thanks for your input" is not sufficient/hypocritical when the obvious message is "go away!"
Some mostly random thoughts (after watching the announcement video, including Q&A, and browsing some issues):
Perhaps the community is welcoming, but have you considered that the syntax, albeit easier to parse, may not be welcoming to the thousands of C/C++ developers who are used to type name and would see let (or var) name: type as a retrogression to Pascal or BASIC? Even if you provide a tool to convert existing code, the new code will have to be written using the new syntax, so arguably that's an unwelcome change.
I'm afraid that claiming Carbon is a kind of "successor" language is stretching the analogies a bit. C++ of course kept 99% of the C syntax. If I'm not mistaken, Typescript did not introduce a radical new syntax for declaring entities, only type annotations. I'm not familiar with Kotlin, but it doesn't appear that different from Java.
The example in the README uses C++ #include's rather than the more modern module syntax. That is somewhat similar to the way initial Rust presentations would emphasize how "atrociously" C++ behaved with examples using raw pointers instead of unique or shared pointers (I realize most existing C++ code uses #include's, but it seems fairer to do a comparison using the newer syntax).
Last but certainly not least is the issue of error handling. I could not find a clear position but it seems that Carbon may not have try/catch. If so, is that seen as an improvement? How can Carbon then be a "successor" to C++?
Forgot to mention that there is already a "successor" language to C++ that, IIRC, has kept most of the C/C++ syntax intact (except for arrays). It's Walter Bright's D. It has modules and even design by contract features.
@cabmeurer: I can understand your thoughts on this, and would like to share some of mine. The details of chosen syntax you described as retrogression, I feel like is actually much more common for modern languages/design. With that in mind, I think the "thousands of C/C++ developers" that are use to type name are bound to be familiar enough with other languages like Kotlin, Go, Swift and many other languages that use the let (or var) name: type syntax.
I personally feel the mission for Carbon is to be a successor to C++, however whether or not you agree with that is a different thing. I have had several conversations with different devs, and some of their opinions are that rather than create a new language, that the efforts should be made to make another language the 'successor' (I've heard people say this about Rust, Go and even Swift) as of now, the language is experimental and time will tell.
As far as error handling, if we take a look at the docs, Roadmap it is stated that version 0.1 isn't slated to be released until the end of this year, and 1.0 isn't planned until 2024/2025. To quote the Roadmap:
"The design choices made to reach this point are expected to be experimental, and many of them may need revisiting before we reach 1.0, but the broad shape of the language should be clear at this point, and it should be possible to write non-trivial Carbon programs." So I would imagine something like try/catch would be reasonable to expect in the future.
It's one thing to know about let/var name: type-style syntax, it's quite another to be agreeable to code in it day in and day out. Rust, Go and Pascal's declaration syntax may be "modern", but I wouldn't want to use it on a daily basis.
"Successor" in what sense? C++ is a successor to C because you can take a large software base written in C, rename the .cs to .cpps (or whatever is your preferred C++ extension) and 99% of the files will compile (and you may get better warnings). I haven't actively looked at D recently but with what they called -BetterC you could compile a C file directly. Carbon at this moment is vaporware. At least Go, when it was announced outside of Google, had an implementation (perhaps written in C++, but nevertheless something "tangible") and although they didn't have generics and their build system went through multiple iterations after their first release, the overall syntax and language semantics were about 80% settled.
Plus one needs to consider that C++ will not remain static until 2024/2025 (that's why any comparisons ought to be against C++20 with modules and even what's been announced for C++23).
I'm sorry but your quote from the Roadmap doesn't inspire confidence.
@davidhunter22: In my personal opinion Carbon should drop any talk of "Successor to C++". As a long time C++ prgrammer I would love a better C++ but it seems very arrogant to claim to be that from the start, to the point where I am put of even trying the language. I would much prefer a more humble approach, for instance just focus on why if your a developer/company doing C++ why Carbon may be better than continuing to use C++ or switching to D or Rust and why migrating to it is easy.
Also I would stress the Visual Studio integration. The entire effort will always be a niche, like D, without this.
@cjdb: Thanks for your input! This is more of a discussion than an issue, so I'm going to close this. Please see Where should I ask questions about Carbon Language? from our FAQ.
I will address some points very briefly, but please use the appropriate channels instead of responding here.
The Carbon Language declaration syntax is to counter C++'s most vexing parse issue.
Kotlin has diverged from Java's syntax in some fairly significant ways, and a lot of those share similarity with the changes proposed in Carbon. You can see some of those in the Kotlin documentation.
Carbon is currently targeting C++17 as its entry-point for interop, so C++20 modules are unavailable. That isn't to say that C++20 and beyond won't receive interop support, but it's not a priority in the initial roadmap.
Carbon is still very much in design. A lack of exception handling in the specification doesn't necessarily mean that there won't be exceptions: it just means that no one has looked into them just yet.
Please see What alternatives did you consider? Why did they not work?. #1448 is our ticket to motivate someone writing an explicit section for why we don't think D works; you might like to subscribe to it so you get a notification once the FAQ is updated.
Beta Was this translation helpful? Give feedback.
All reactions