Brendan (btrotter.delete@this.gmail.com) on July 12, 2021 8:52 pm wrote:
> For C, you know "a = b + c;" is definitely addition involving some kind of numbers without looking at any
> variable's declaration, and that it's definitely not likely to be a performance problem (note: the introduction
> of complex numbers made this statement "slightly less true", but only slightly). ​For C++, even if you know
> one variable is a plain "int" it still might format your hard drive (or concatenate, or search a list, or
> take your cache out behind the back shed and slap it around for 2 hours, or ...). Alternatives to overloading
> (e.g. "a = b.add(c);") provide an unmistakable warning that natural assumptions may not apply.
>

As I've said, contextual dependence is not only about the operators. Identifiers often suffer more. In particular, do not forget the infamous tradition of macro abuse, which is definitely worse in C than C++. C has no rules to prevent the crazy things (like #define a __format_your_hard_drive(a)); C++ does not either, but if it is a name in the standard library, it is the users' responsibility to avoid the clash. As Murphy's law, one will often meet worse ambiguity on identifiers caused by others' code without warranty. And I don't meet bad overloaded operators for years; it should be certainly not frequent than bad macro names in reality. Note besides attackers, only a novice will abuse the former, but even experts can be bitten by the latter by mistake (like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97362).

One more thing, the methodology to assume the static types of some entities as the premise to reasoning the meaning of the code is usually wrong. Explicit type annotation is a kind of complement of program semantics, rather than a base. It does not matter much in general whether some objects can be int or whatever integers; the important thing in such context is you know some object is an integer-like one support conventionally arithmetic "+" so every pieces of the code in this context can naturally have clear meaning without ambiguity (thus better readability). Whether the object is really an "int", "unsigned" or whatever, does not differ in this very syntactic context around "+" (since all these type support sane "+"). You have to differentiate concrete types only when you have some other reasons beyond the expectation of "+".

Operator overloading, in general, is relatively easy to reason in this style: just assume the overload operators sane by default. Anyway, overloaded operators are just equivalent to some functions in the context; will you suspect any functions do harmful things? To find a misbehaved rogue overloaded operator is also not that hard as long as the mismatch of expected behavior is easy to reproduce, because to find which overload is not difficult. OTOH, to locally reason the meaning of a macro is essentially hard (in the way to find the effective definition) since C/C++ macros has no hygiene/lexical scoping support. Failing to reason the meaning of the macros can have worse consequences because C/C++ macro replacements can do things far more evil than altering the semantic of an punctuation.

> Originally I went from electronics to assembly to C. When I learnt C++ in the 1990s my brain was in "decide
> what you want the CPU to do, then try to express what the CPU should do in whichever language you're using"
> mode. Higher level languages don't help you express "what the CPU should do" any more than C does, so I mostly
> just learnt to hate C++ due to all the extra stuff that had no value to me at the time. C++ has evolved since
> but the fundamental reason I didn't like it the first time persist (and first impressions are hard to break).
> Basically; it probably isn't hard to learn smart pointers, it's just hard to find the enthusiasm to try.
>
That's a typical wrong way to learn any high-level programming languages. Even the design of C is not compatible to this practice. C has already many, many things beyond the behavior exposed by the explicit machine code it translated to (e.g. undefined behavior upon the misused unsequenced evaluations); it is unwise to reason the meaning of C programs by manually translation the C code to some concrete machine code before you really want to dig into the chaos of the implementation-specific details. On the contrary, C itself relies on the fact you will accept things more than this, as "believing the programs". In particular, implementations of C can assume there is no undefined behavior, which implies as a C user, it is your responsibility to rule it out. The design of C essentially expects you smarter than the compiler and CPU before translation the code! C++ does more or less the same here.

To learn things like smart pointers is no more difficult to rule out the undefined behavior. Both of them just need different techniques than the way to translation the code. However, they are still loosely coupled by the basic type system. Note that many of the undefined behavior comes from the misuses of raw pointer values. The purpose of smart pointers is to provide an alternative way to use these pointers in a restricted way which exposes more clear intents, so as a result, it can be reasoned about more easily, and less error-prone. Someone may feel it unnecessary, because he/she already have raw pointers; however, consider the fact that pointers are a big source of misuses and the intents are often not clear, abuse of pointers should be better avoided by using more specific facilities instead. As a user, the enthusiasm of using smart pointers (and other things to replace pointers in a fine-grained way, like iterators) may come from the sense of mastery: he/she can solve the abuse without relying on the author of the compiler or whoever else just by plain coding.

> The strange thing is I didn't have the same trouble with Python, Java or C#. I think denying the ability
> to do anything low level up front forces me to accept that they're a "bubble wrapped plastic world" before
> I get frustrated (especially if it's the right job for the tool); while C++ gives people the choice to be
> frustrated (because of high level features) or to be frustrated (because of low level features).
>
> Of course mostly what I'm doing here is reflecting cqwrteur's attitude
> towards Rust back at cqwrteur as an attitude towards C++.
>

This is the key point: high-level programming languages do not fit the "low level up front" way well. C, C++, rust, Java, C#, Python... are all the same in this category; they are all "bubble wrapped plastic world". (In C and C++, the plastic worlds are built by the assumptions implied in the abstract machines. This kind of plastic boundaries seems just thinner than others; but they are still "plastics", even more fragile. Breaking them still does not guarantee you can reliably reach the world outside in the way you've expected.) The low-level features in these languages, if any, are opted-in. If you learn (modern) C and C++ just like Python or Java, it will be less painful.

Of course, C is still lacking too many features to avoid the verbosity without extraordinary trickery, so it is not recommended to beginners, or even to most users today. In kernel programming, most contributors are not skillful enough to abuse the current base language (C plus GNU extensions plus the permission to use some reserved constructs specific to the implementation) to solve some general (but seems simple) problems (for example, consider the min/max macros in the Linux kernel source), so any other languages may be potentially better than C in such contexts. These languages all have different other problems, but taking the ability to opt-out global GC as a premise, the only candidates in practice are C++ and Rust. Some problems of Rust are shown here; this does not mean C++ has no problems, just not the same problems.

BTW, the "low level up front" way only fits to real low-level language with far less abstractions. LLVM assembly is an example fit in this way; however, there are still several constructs in LLVM assembly (merely) delicately reflecting the purpose of some high-level languages. I don't think you can easily find a purer real "low level" language useful in practice without depending on much machine details.

> > Professional empirical evidence (in the sense of programming language theory and authoring the language
> > specification) shows both C++ and Rust are the kind of most evil ones about both complexity of language
> > rules and learning curves for most users. There do exist a few worse, say, Haskell; but C++ and Rust are
> > already enough far from easy and simple for non-specialists.
> > And they will both become worse in the forseeable
> > future. I don't see the essential differences here, besides "disgned by commitee v. community".
>
> Alan Kay is teaching children to program Squeak in to be trying to convince programmers who already have 4+ years of University to spend
> an extra 2 years retraining (for new features and new languages) every 2 years. ;)

To teach programming is a very different domain than to do the programming language theory research or to design a programming language. Alan Kay is also an expert to some specific paradigms of programming, but that's almost all.

As you said, there are efforts to improve the effects both in teaching children and university graduates to program; however, I suspect they are most in vain. I don't believe there should be different ways adapt to different people to learn a general purpose language. Instead, I believe we have still not found sufficient root common properties of a programming language easy for average users (including both children and adults). Additionally, we do not have a systemic view of theory about programming language designing that reduces the difficulties to find the design naturally easing the way to teach and learn. Different programming language designers always repeat bad practices with little progress and others will find their works are insufficient for the real needs. This should also be a reason why we can't avoid trivial retraining in reality.

There are remaining works to improve existing languages. The one difficulty is that the concerned complexity is already exploded. There are few people can control the complexity of a practical programming language in all its lifetime. Authors of most popular languages have failed in this area. In particular, I don't believe both C++ and Rust have chances to fix the problem (even just in the aspect of documentation).

The experiment to introduce a new language in an aged large-scale codebase is interesting, but the result would probably not be attractive at all (as mozilla-central already did).