From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: X-Spam-Status: No, score=0.8 required=3.0 tests=BAYES_50,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Received: by 2002:ac8:5e14:0:b0:31f:4280:8d93 with SMTP id h20-20020ac85e14000000b0031f42808d93mr2582526qtx.36.1658856703042; Tue, 26 Jul 2022 10:31:43 -0700 (PDT) X-Received: by 2002:a81:911:0:b0:31f:4906:80a2 with SMTP id 17-20020a810911000000b0031f490680a2mr3372766ywj.351.1658856702681; Tue, 26 Jul 2022 10:31:42 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!border-1.nntp.ord.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 26 Jul 2022 10:31:42 -0700 (PDT) In-Reply-To: Injection-Info: google-groups.googlegroups.com; posting-host=195.171.120.250; posting-account=WsVe0AoAAABheGmBjlLgPWhgIw6kxcL6 NNTP-Posting-Host: 195.171.120.250 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Carbon From: John McCabe Injection-Date: Tue, 26 Jul 2022 17:31:43 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:64143 List-Id: On Sunday, 24 July 2022 at 10:41:00 UTC+1, Luke A. Guest wrote: > On 22/07/2022 22:13, Gautier write-only address wrote:=20 > > Next attempt to replace C/C++ without really replacing it: Carbon! > Saw this last week and immediately thought they'd failed on one of their= =20 > "design goals," i.e. to be "readable. > > You will notice, as usual, a few aspects borrowed from Ada - and one po= int inspired by Ada 83 (which was relaxed in a later Ada version) :-) > What did they take from Ada? Certainly not the approach to making life easier and less error-prone for d= evelopers. I've got involved in a couple of discussions on their forum, and I'm inclin= ed to think they just want C++ but taken out of the control of ISO/IEC WGs = steering committees. They're pretty much not considering changing any of the aspects of C++ that= make it such a heap of junk (IMO, of course), including, but not limited t= o: 1. arrays 2. enums 3. (both of the above when used together :-)) 4. symbols - overuse, duplication, inconsistency 5. implicit stuff 6. pretend strong typing 7. forcing developers to deal manually with numeric values that don't fit i= nto an n-byte range, where n is a whole number It really is shockingly soul-destroying watching all that. What's worse is = that, from what I've seen over the years, the new languages that have been = developed in a more 'relaxed' way than Ada (well, evolved, really, like Jav= a, Python etc) and have become relatively successful have taken a good 10 y= ears or so to get to that point, yet the discussions on the Carbon forum ar= e all about how to appeal to _current_ developers who're used to C++; not _= future_ developers who, ideally, would _never_ be used to C++!