>>12
Not at all. You can do this in C by making the "sum" a function pointer, point it at "builtin_sum", and then change it later if you wanted a different sum.
Are you an idiot? Are you making an argument based on the assumption that if you can do something in C then it can't be slow? Yes, you are and you are, it seems!
Sure you can do it in C and it would be slow, prevent all kinds of optimizations and so on. If you did it for every single function. And also used not a fixed set of named pointers, but a hashtable indexed by name, then it would be rapidly approaching
slow as fuck, forgive the pun.
Also you can do clever stuff with objects, replace GIL with mutexes etc. That's more or less what the Unladen Swallow dudes did: and imagine their amazement when they discovered that the interpreter itself -- the loop that fetches bytecode instructions and dispatches on them in a monstrous switch -- is not the only bottleneck or even the worst bottleneck, that if you just take the bytecode and compile the corresponding case blocks one after another you become like whopping 10% or 20% faster than
slow as fuck, yay! Even if you actually compile the bytecode to C and then compile C with maximum optimizations! C can be slow as fuck!
Speed has nothing to do with mutability of data; your argument is entirely stupid.
You are entirely stupid. Fucking idiot.