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.
>Go try to wrestle a caveman for his fur pelt and see if he considers it to be a protected object.
But if I show up with a better club then all his stuff is now mine. A third party enforcing certain resource allocations with overwhelming force is different to everyone defending their own stuff.
Government is the difference between property rights and might-makes-right.
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.
But if I show up with a better club then all his stuff is now mine.
Bingo. Ownership exists without government - ownership exists to the extent others respect the claim.
Government is the difference between property rights and might-makes-right.
Governments are legitimate because of their might. Why do you think the basic social contract between authorities and the governed is "obedience for protection"?
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.
I agree that people make themselves vulnerable to someone taking their picture by going outside, but I strongly disagree that people consent to having their picture taken.
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.
Why do you say it's faster? It's guaranteed to fail branch prediction one out of ten times. My guess is that'd be a lot slower than using the integer modulo operator, which is not an expensive operation.
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.
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.
