Learn them both at the same time. Pick two small projects. For project 1, implement it in Python, then implement it in C. For project 2, implement it in C, then re-implement it in Python. Repeat for the next two projects.
It will feel slow at first, but you will learn more quickly overall.
In theory yes, if you have an impartial third-party monopoly, but in practice it's still might-makes-right, where might = money, lawyers, political connections, ethnicity, etc. It's probably still better, but it's less transparently obvious what's going than with my club vs. yours.
Eh, I don't disagree, I was just trying to distinguish between property existing and objects existing. But maybe force defines existence all the way down.
Well, maybe it's more accurate to say that it's impossible to consent because no consent is required to take someone's picture in public. People generally exercise control by choosing not to be in public. You could say that having your picture taken is part of the terms of service of using public space. When you agree to something, you also agree to all of the consequences. Just because they are implicit doesn't make them invalid.
Don't get me wrong, I don't particularly like having my picture taken without my explicit consent. In the end, consent is all rather arbitrary because it's not like you can choose not to live in human society on Earth.
Python has its share of cruft and idiosyncrasies. I find some of the syntax irritating, e.g. boolean logic, argument handling, hidden / private / magic symbols, and those pesky half-open intervals that routinely lead to off-by-one errors.
More or less, assuming you can predict it. But there's a penalty for misprediction. So it boils down to whether using % frequently (either as a native instruction or as a sequence of instructions) is more or less expensive than predicting a branch frequently, given a certain misprediction rate.
On their own, % and / are way slower than +, -, *, <<, >>. Cycle counts depend on your architecture, you can look them up. That mod is so slow and should be avoided is a kind of folklore based in truth - kind of like function calls being slow - but like everything time-sensitive the mistake lies in not profiling before (manual) optimization.
There's an example on SO, I got similar results just now when I replicated it:
It doesn't matter on my machine whether the divisor is 10 or 42 (as in the example), the branching is way faster. Now, maybe if the branching were not in a loop and hence not so easily predicted, it wouldn't make a difference. But if this code is not being used in a loop, optimization may be premature anyway (as indicated in my original comment).
Probably f() has something to do inside the main game loop and gets called on a bunch of objects every frame. I haven't looked at the code enough to know if that's a bottleneck.
It doesn't have to be intended. It's just that every time you write or speak you communicate group membership. For example, there are further implications about group membership when you correct my interpretation of forking. Another example: unless it's a typo, your grammar ("I have heard") indicates that English is not your first language.
The other primary purpose of language is communicating group membership. For example, it's reasonable to guess that you belong to the "uses version control" group by your use of the word "forking" in a non-VC context above.
In my experience the public face of Japanese society is very polite, but that's distinct from what can be said with the language, and what people say with the language in private face contexts. It also varies to some degree by class, but you could say the same thing about English.
Also, loanwords like fakku are a legitimate part of the language. The katakana script is used almost exclusively for them and many sentences have them, spoken and written.