>>66
I know what epistemology is. I know about every term used in the post means. Many people don't, however, and using such terms with almost no adequate context for that just creates
communication noise. Communication noise is both a consequence of bad communication skills, and of intentional blabbery in order to induce confusion, excitement and anger, disguised as intellectually profound reasoning. The point he possibly wished to express in the post is deeply buried behind an intentionally confusing verbosity -- even comparable to the "C++ complexity" he so much condemns, if you permit me an alias.
In other words: what he really intended is to cause public commotion and exasperation, and to impress the audience. Gain the argument through aesthetics. Or at least that's the way I judge it, since by no means I take the guy for a stupid man.
Apart that, I agree with some things you've said. The language induces some behavioral patterns on people, as much as human languages do that (that is called "Sapir-Whorf hypothesis"). However, do other OO languages induce "better" behavior and mental discipline than C++? Do they differ at all? C++ is not much different from other OO languages. As it is already clear from what I've been arguing, OO itself numbs people down to their bogs, but that's just my opinion.
I don't see such a need of foresight in C++, or, if I do, I don't see why it differs from other object-oriented languages. The need of such an ability -- to foresight what your needs will be, before even having any sketch of your layout --, assuming it exists, is bound to the object-oriented mentality itself, not the language. I'm not particularly fond of the OO mentality itself, but C++ can't be blamed for it. What I see is that everything in the object-orientation world
is difficult, but C++ doesn't contribute to make it harder. Design issues are bound to the paradigm, and the language -- by offering "too much" in any regard -- can't make it more difficult. For example, I don't consider whether a reference or a pointer will be used to be a design decision in itself, neither whether some symbol will be in some namespace or another (since the language allows you to do mostly anything you want to do in many dimensions), and so on. I consider that people who lose themselves in
these problems, and need some language constraints to keep them in track, have failed to grasp the greater design problem of their projects.
I will make an exception: weak-typed languages (Python comes to my mind), where you don't have to explicitly declare types and they may vary in the runtime, ward off a lot of problems you usually have in OO. Duck-typing allow you to boost enormously your code, writing future-compatible code without the need of even specifying what future code needs to do in order to communicate with your design: they just need to provide a compatible interface. But they do introduce another gigantic pack of problems which are automatically solved in strong-typed languages, and I suppose you are well aware of those problems. Well, C++ has simply opted for one of this problem/solution pairs.