But they are all equivalence relations (i.e., reflexive, symmetric, and transitive).
Oy, this is a long conversation. The most important part: I do not think that there is any inherent/genetic/insuperable reason for any race to have trouble programming. The reason this question comes up at all is the very strong empirical fact that in the US, at least, computer programmers are virtually all white and Asian males. Nobody likes this! Which makes it all the harder to explain. Also, although computer science is a particularly extreme case, white and Asian males dominate many fields. Professors are largely white and Asian males, although there has been some progress on this in recent years. Even in some non-technical fields there are racial and sexual disparities. (But it should be noted that women have been outperforming men in school for a while, other than in CS.)
It's also clear that in some ways these problems are the result of social conditions. Women and minorities are paid less for the same work. Minorities are more likely to be sent to prison for the same offense. (To save typing, hereafter by "minority" I mean non-Asian. And yes, I recognize that "Asian" is an overbroad category, and the US experience of Koreans and Vietnamese are quite different.) And starting around age 10, girls are taught they're destined for non-technical fields.
The question for our group (BJC and Snap!) is how we can improve the situation in computer science. There has been a lot of progress in the last decade, largely due to the vision of Jan Cuny, a Program Officer at the National Science Foundation, who got the College Board to create the new AP CS Principles exam and provided funding for curriculum development and teacher preparation efforts. In schools that have adopted CS Principles, we do get close to 50% girls signing up for the class; minority enrollment isn't quite where it should be (measured against each school's minority population), but is making progress. But we are not, so far, retaining female and minority students through the CS curriculum.
Some programs have been trying to use computer applications that appeal directly to underrepresented groups. One well-known example uses recursive fractals to represent cornrows and related hair-weaving techniques. But there's a limit to how far that approach can be taken, and in any case, being as I am a white male with a preference for mathematical abstraction over real stuff, I don't have much to contribute in that direction.
But we can also try to eliminate things that pose unnecessary obstacles for any beginner. Especially if the beginner has felt marginalized all through school and has low self-confidence as a result, small obstacles may not feel small.
That's why a blocks language is useful in high school. For the Scratch target age range, just knowing what the words mean and how to spell them is an obstacle, and a drag-and-drop programming interface is obviously beneficial. By high school, some kids are totally ready for a text-based programming language, which includes having the skill of touch-typing as well as a good vocabulary, but others aren't. The ones who aren't have typically had poor elementary schools and parents who couldn't afford to spend a lot of time reading to them in the first few years of life. And so they are disproportionately minority.
The research on the effect on learning of = for assignment isn't open and shut, but there's some evidence that it gets in the way of learning, and there's certainly no evidence in favor of it. But it seems clear to me that the fact that it's wrong can't make it any easier to learn. As for integers and reals, as I said, if you want to say that 3.0 isn't a fixed-point number, that at least wouldn't be wrong. But it would still be an obstacle to learning. There's no reason for beginning programmers to have to worry about different flavors of number.
Tl;dr: Things that are hard for beginners are extra hard for beginners who also feel left out at school in the first place.
