> (though it would have been better if single characters would have been used for McCarthy operators and double characters for the bit string operators)

(It probably is better on net, but) not as much as one might think, actually. It's a clear win in terms of Huffman coding, but there's also a general principle that small infix operators have higher precedence, and large ones lower precedence, like how multiplication in math notation uses "·", or more often nothing at all, while addition uses "+". (It also shows up in natural languages; consider "Tom and Dick and Harry as well as Alice and Bob".) It's (probably, usually) worth subverting for assignment, because "=" is used a lot, but I'm not sure if it's a good tradeoff for boolean operators, eg:

  if(x == 3 & y == 5) foo(); // look's a bit too much like it's saying
  if(x == (3&y) == 5) foo(); // ie (x==(3&y)) & ((3&y)==5), rather than
  if((x==3) & (y==5)) foo();

Though, like "=", the initial misleading hueristic might wear off with sufficient exposure, and you can usually fudge it by adding spaces around the low-precedence operator.

Your examples would have looked much better and without suggestions of wrong precedence if C would not have also replaced the Algol operators ":=" and "=" with "=" and "==".

In my opinion this is one of the greatest mistakes of C, and which unfortunately has been inherited by too many other languages. Even Dennis Ritchie has admitted that this might have not been a good idea.

> if C would not have also replaced the Algol operators ":=" and "=" with "=" and "==".

That wouldn't help "!=" and "<=", and "=" is used far too often (in typical code, hence the "(probably, usually)" above) to be multi-character.

That is due to the limitation of the source code to ASCII, which I consider obsolete.

"!=", "<=" and the like were single-character operators in Algol and in many other early programming languages. They have been replaced with 2-character operators only because IBM and most other important US computer manufacturers were not willing to support character sets with enough characters for covering the needs of mathematics and of other languages than English.

The target for the US character sets was only the text that may appear in commercial letters written in English. For any other uses, like programming languages, characters have been accepted only when they could occupy one of the few vacant places in the character map.

The dominance of the US-made computer hardware forced this ugly limitation upon the programming languages. So the programming languages had to use various commercial characters, e.g. !, @, #, $, %, instead of more appropriate traditional mathematical symbols.

Now, with Unicode and UTF-8, I consider the use of ASCII for source code as stupid.

In Unicode, also the ":=" of Algol exists as a single character.

Regardless of how operators are encoded, as single- or multiple-characters, a good text editor for source code allows one to change the correspondence between pressed keys and the inserted text.

Because assignment is used more frequently, even when using ASCII a text editor can be configured to insert ":=" when you press "=", and, for example, to insert "=" for ctrl-= and "!=" for alt-=, in order to minimize key presses.

Many early programming languages were even more limited than ASCII itself, for the sake of portability. In Algol itself the operators and keywords were defined as abstract representations, with multiple possible ways of serializing those to computer-encoded text.

Agree.

It seems like it would ne more accurate to say that each C role is has skipped other languages, and thus will likely skip Hare as well. The feelings of people in that role might not have anything to do with it.

It is hard to find anyplace where you may have C but not C++. Do people still use PICs? I think 32-bit ARM chips may be had for 3 cents nowadays. For a really memory-constrained target, you might choose to turn off exception support.

They do, but personally I would be pushing for Pascal in such cases.

https://www.mikroe.com/mikropascal

Pascal lacks destructors and templates. No dice.

True, although in the context of PIC programming hardly matters.

For me no dice is being unsafe by default.

Thankfully in the context of C++ I could always fix, what from my point of view, are bad defaults regarding bounds checking.

Pascal is unsafe by default: it allows null pointers, and stale pointers.

True, but it has a much safer story than C in everything else.

C++ was attractive to me in 1993, because it offered me the safety, and modern language features I was used from Turbo Pascal and then some.

They exist, even to detriment of modern C, C89 + language extensions of their favourite embedded compiler is all they care about.