> It's okay for functions to have unknown behavior that I have to learn about before using them, because I'm used to that, but it's not okay for types to have any kind of unknown behavior, because I'm used to C,
It is not an issue of behavior but of understanding.
In C++, a large number of things can be happening in a single line: an operator being called, a type conversion, a template instantiation, an overriden function in one of a dozen of classes, a constructor called in some part of the hierarchy, in some namespace... who knows. You have to be smart enough to figure out what is going on in each of these cases. As you code base grows, this makes it increasingly hard to understand what is going on.
By that logic, you shouldn't use any dynamic language, because someone could monkey-patch every function and you'd have no guarantee what exactly was being called.
Also, you forgot macros in your list of gripes, as they can stomp on literally ANYTHING indiscriminately, despite being declared far away from the actual invocation point.
+1 on dynamic languages, not a fan for this and many other reasons
Haskell seems to go a long way towards solving this problem in my humble opinion. Meaning it can have very dense code but as long as you follow the types it is often fairly straightforward to figure out what a piece of code does.
The worst part about all the things that can happen implicitly in C++ is that they can all have side effects! Oh fun. This is not just a pitfall of C++ either, Java/C# can have the same issue - one statement can trigger a whole plethora of side effects making a large brownfield development project one hell of a nightmare.
Haskell seems to go a long way towards solving this problem in my humble opinion. Meaning it can have very dense code but as long as you follow the types it is often fairly straightforward to figure out what a piece of code does.
As a Haskell fan, I have to say that there is a bag of hurt here as well: performance in the lazy evaluation regime. It can be very hard to predict/understand when thunks are evaluated and the effect it has on heap use.
I am still hoping for a strict, pure language with monads to go mainstream enough to use it.
The next Haskell will be strict - Simon Peyton Jones
#define FALSE 1 is not that uncommon in C because C in its infinite wisdom doesn't have true/false literals so people have to invent those by themselves.
Glib goes into great lengths to avoid namespace conflicts so it defines the GBoolean type and G_TRUE/G_FALSE. Whether that really is better than #define TRUE/FALSE, I don't know.
In C99 #include <stdbool.h> has the type bool and the constants true and false (even in the "freestanding" flavor). Of course this doesn't save you if you are dealing with old/non-conformant compilers and/or legacy codebases.
So then what are they supposed to do, require a library X which has already invented them, while your app is using library Y which already does the same thing as X?
It is true that the pre-processor can create a lot of confusion, however it is easy to generate a -E version of the file that shows all substitutions. It is not even close to the confusion created by templates, for example.
It is not an issue of behavior but of understanding.
In C++, a large number of things can be happening in a single line: an operator being called, a type conversion, a template instantiation, an overriden function in one of a dozen of classes, a constructor called in some part of the hierarchy, in some namespace... who knows. You have to be smart enough to figure out what is going on in each of these cases. As you code base grows, this makes it increasingly hard to understand what is going on.