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=-1.7 required=3.0 tests=BAYES_00,NICE_REPLY_A,
	REPLYTO_WITHOUT_TO_CC,T_SCC_BODY_TEXT_LINE autolearn=no
	autolearn_force=no version=3.4.6
Path: eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: "G.B." <bauhaus@notmyhomepage.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Carbon
Date: Sun, 28 Aug 2022 19:34:34 +0200
Organization: A noiseless patient Spider
Message-ID: <teg8va$m5ah$1@dont-email.me>
References: <f91d8f78-d92f-4200-a1bd-dce840bf0400n@googlegroups.com>
 <tbj438$1eab$1@gioia.aioe.org>
 <f88660da-350c-40df-ac70-a644e6f30661n@googlegroups.com>
 <tbqs0t$104n$1@gioia.aioe.org> <tbrsd7$2iq3d$1@dont-email.me>
 <993af397-b615-44e7-ae8d-ec706f9b6098n@googlegroups.com>
 <5f819cdd-e763-4a96-aed5-545d57edac23n@googlegroups.com>
 <a68c8311-6430-4956-9e82-eaed3a962114n@googlegroups.com>
 <877d2u21ps.fsf@nightsong.com>
 <bf592477-feba-418a-b1aa-17bbc81e7f76n@googlegroups.com>
 <8735di1y6a.fsf@nightsong.com> <teecue$dupe$1@dont-email.me>
 <87ler9ywye.fsf@nightsong.com> <tefalc$j9vn$1@dont-email.me>
Reply-To: nonlegitur@notmyhomepage.de
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 28 Aug 2022 17:34:35 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="bbb361a20df01664d9838ddb9b7f44aa";
	logging-data="726353"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+wIB1XXo903B/GkVo4w4roEn9ig2ugDxQ="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.13.0
Cancel-Lock: sha1:MSh+AQPEhzmJ9v3+cjMQxh3BBKU=
In-Reply-To: <tefalc$j9vn$1@dont-email.me>
Content-Language: en-US
Xref: reader01.eternal-september.org comp.lang.ada:64239
List-Id: <comp.lang.ada>

On 28.08.22 10:57, John McCabe wrote:

> Yet they're happy to adopt many of C++'s legacy syntactic/semantic issues,
> e.g. assignment produces a result that can be implicitly converted to a
> boolean and used in a conditional which, when considered at the same time
> as the use of "=" for assignment, and "==" for comparison, has caused
> numerous issues and head-scratching over the years.

Claims about "=" and "==" without substantial statistical and economical
evidence are just not going to cut it, I think. On the contrary, they
might reflect on the speaker and his favorite language. Also, what is the
general impact of "=" when comparing effects of other features that
supposedly have caused or prevented issues, like run-time bounds checking?

Has discussing these issues ever helped choosing languages, influencing
the choice in the direction that a programming engineer would?
If not, what is a good way of discussing language design?

I think there is a story by Hofstadter about the magic that symbols
can work on young people.

I submit the common length of "==" and "!=", and some languages' choice
of "=/=", perhaps all but APL lacking "≠". The latter also officially
uses "←" for assignment, not sequences of punctuation available through
iterated pressing of single buttons on the ASCII keyboard. ;-)

Also the convenience of being able to compare two objects for
being the same object, using "===" in some languages---out of the box!

procedure same_object (A : T; B in out T) is
begin
   what_do_i_put_here; --  ?
end same_object;