>>3
Languages may be prone to be slow or fast when implemented, but they don't have such properties - implementations do.
No. If a language mandates that it should be possible to write
some_module.sum = new_and_improved_sum and it would take effect on every expression in that module that used the builtin function sum, then all and every implementation of this language would be
slow as fuck.
If a language allows writing
int.__add__ = new_and_improved_add and it is supposed to affect every integer in the program, then all and every implementation of this language would be
slow as fuck. (Python2.x doesn't allow exactly this, but you get the meaning I hope)
If a language allows adding an arbitrary object that supports certain interface to a list of integers and requires all functions like sum to not choke on it, then all and every implementation of this language would be
slow as fuck.
If a language allows doing all of the above from the multiple threads, then all and every implementation of this language would be
slow as fuck concurrently.
People writing an evaluator can haggle a bit, of course. They can JIT-compile the code and recompile all dependent code when you change something. Which would be slow as fuck then, but hey, it's your fault now. And of course there would be a lot of time wasted on bookkeeping and no extension module calls, but OK. They can add a tracing JIT to deal with things like arrays of integers where your tight loop usually goes through the same functions again and again. That of course would involve a lot of time wasted on bookkeeping again: maintaining statistics to detect when we've entered such a loop, compiling it, checking that the types are still right on each iteration et cetera. And forget about most kinds of compiler optimization, there's no time to do it in runtime. They can go as far as creating specialized arrays of unboxed ints whenever it seems that this is what is needed and then check every time and convert it back if you add something that is not an int (in case you are wondering: LuaJIT does something similar to mitigate the lack of arrays as such in Lua).
I like that you mentioned the Unladen Swallow, it's quite typical in this respect: some bright guys are confronted with the slowness-as-fuck problem and think "We know, we will remove GIL (also use JIT, tracing JIT, tagged pointers and whatever else has been invented in the last 50 years of trying to solve the problem that have never had any reason to exist in the first place)", now they have as much problems as they want. If they are young and arrogant they'll think that aloud, if they are really bright then they would not be totally embarrassed several years later when they manage to make their implementation merely slow (provided that the programmer doesn't use any dynamic features, any complex features, and had not forgot to sacrifice a black cock to the Goat with Thousand Young no more than a week ago), because hey, that's still a tremendous improvement and also a pinnacle of technological achievement (achieved when solving the problem that should not have existed, but I repeat myself)!
So no, some languages do have an objective property of being slow, or, more precisely, not allowing for the possibility of fast implementation, or at least making such implementation significantly harder to create.