* Warren D Smith <warren.wds@gmail.com> [Apr 20. 2014 19:29]:
Re swap, there should be a <--> b built into language.
An operator "<-->", _seriously_?
It's a matter of syntax. Also it should be a hardware instruction too. Jorg Arndt by saying templates can fix this, is missing my point. My point is: syntax matters. SWAP(a,b) is simply poor syntax for such a common operation. Common stuff, should be short. Principle of the Huffman code.
I can certainly live with swap(a,b). Note C is not a high level language.
[...]
Re C deficiencies, another huge one is no array bounds checking. It should be provided as part of the language -- for example, A[n] would be bounds checked by default, but one could turn it off by, say A[[n]] or explicitly declaring A to be unchecked int A[77]; or some such. Or even a compiler overrule flag to turn off/on all boundschecking.
You keep suggesting things that would make life hellishly complicated. Use valgrind. Be happy thereafter. (more below)
A tremendous number of bugs have been caused by this one incredibly simple and easy to fix C language design error, plus this is probably the top reason underlying security flaws in everything today.
Want Java? Performance eek bytes bottom. (again, more below)
And re add-with-carry, not allowing multiprecision arithmetic, as a result you cannot write good cryptography in C alone. You need assembler. Virtually everything Joe User does today, involves crypto. So it's insane. And yes, add-with-carry does require some thought to see how to put it into an HLL, but the best choice was NOT "completely surrendering."
How clear was that (importance of cryptography) at the time C was created? For very low level things you tend to need assembler in every language at some point. Hardly any language is as good as C at pushing that point away from you! I have used about 20 machine instructions in about 15 _tiny_ assembler fragments in the last 20 years.
The proper approach is (of course!) to write programs that write programs.
--The proper approach is to make the language have enough power that I do not have to in many common cases. I'm not opposed to your idea per se.
The designers of C didn't think of every possible use 30 years in the future. They should really be ashamed.
--I think you were being sarcastic, but I completely agree with this. The bottom line is: they designed something without the future in mind and now we are paying for it. Huge. Security flaws that would not be there if C had included array bound check, are costing literally billions. This would have far far overpaid for the whole C development effort.
It is (almost) trivial to create array with bounds checks. But wait! Just use what is already there: std::vector. V.at(i) <--= bounds check V.[i] <--= no bounds check And that is _precisely_ what you asked for.
And if C had included various machine language stuff like in MMIX, then people would have used it, which means CPU designers would have put it in hardware.
How can a language reasonably include "machine language stuff"??? A (the?) point of C was to get CPU _independent_!
Instead since it was "not used" CPU designers were not going to supply it. Which meant it was silly to put in an HLL. Vicious circle.
And, by the way, there is a threshold in programming language criticism where "Write your own or cork it!" applies.
--ah. The trouble is, writing your own is (a) hard, and (b) virtually certain to be a wasted effort. Which is exactly the problem. Just look at all the wasted language ideas that are out there in languages essentially nobody uses.
I know 8^) To me it sounds that would you read up on C++, you'd find most of your demands are solved for the overwhelming majority of use case.
[...]
Best, jj