C++ does not omit features because they were worried that programmers would misuse them. This is, afterall, a language with multiple inheritance, allows arbitrary casts and allows programmers to grab a pointer to any arbitrary piece of memory. Stroustrup has said in many places that, in the end, he trusts the programmer and is in favor of including useful features despite their danger.
Full reflection doesn't exist in C++, I assume, because of the runtime overhead costs. The amount of reflection that is present through Runttime Type Information (RTTI) does add overhead, so it's only compiled in when programmers use those features.
Further, I'm not a Ruby programmer, but from reading HN I know there's significant discussion in the Ruby community about monkey patching arbitrary classes. The consensus I've seen is that it, in general, it's a bad idea. This is the same kind of cultural proscriptive advice the author says is not present in the Ruby culture.
"The consensus I've seen is that it, in general, it's a bad idea. This is the same kind of cultural proscriptive advice the author says is not present in the Ruby culture."
From my corner of the Ruby universe there's not even consensus about using the term "monkey patching", or when to apply it. (I find the phrase more confusing than enlightening, as most of the time people are not making a distinction between a deliberate coding decision to re-open a class for a specific result, versus employing the technique to hack pre-existing code you cannot otherwise properly alter.)
About the closest thing I find to consensus is, "Don't be dopey when re-opening classes", especially if you are writing code for unknown end users. But I know of few people who frown on ever re-opening classes.
Don't mistake HN "consensus" with Ruby community consensus. I've been very loud on HN about how monkeypatching is a bad idea, but I am not a member of the Ruby community. (I got my burned-by-monkeypatching credentials from Javascript.)
I never was really in the market for Ruby since I know Python very well, but certainly Ruby's love affair with monkeypatching would be sufficient by itself to turn me away.
I'm having trouble seeing your point here. You seem to be saying "features present in my language of choice are right and proper, while features not present were omitted for good and sufficient reasons and were a Bad Idea to begin with."
Also, there's a real muddle in your third paragraph. Are you claiming that Ruby culture is comparably proscriptive to Java or C++ culture? If not, it's tu quoque and the original author's point stands. But if your intent is to refute the central premise of his argument, you should really say so.
I'm not necessarily saying the features omitted from C++ were omitted for "good and sufficient" reasons, and I certainly didn't say they were a bad idea. What I am saying is they were omitted for reasons other than the author states. (The reason I'm not saying they are good and sufficient is that starts a discussion about the design of C++, which I think is too far off topic.)
I can't speak with confidence about Ruby's culture. But the talk I've seen about not freely modifying arbitrary classes seems to run counter with the author's main point, since that is the sort of freedom he's talking about. That sort of proscription reminds me of warnings against global state in procedural programs, and shared state in parallel programs.
Full reflection doesn't exist in C++, I assume, because of the runtime overhead costs. The amount of reflection that is present through Runttime Type Information (RTTI) does add overhead, so it's only compiled in when programmers use those features.
Further, I'm not a Ruby programmer, but from reading HN I know there's significant discussion in the Ruby community about monkey patching arbitrary classes. The consensus I've seen is that it, in general, it's a bad idea. This is the same kind of cultural proscriptive advice the author says is not present in the Ruby culture.