3 ms·

In contrast, I don't buy that dichotomy. The Objective-C runtime is runtime-heavy, generates a slew of runtime-interpretable data, and yet is compiled "natively

In contrast, I don't buy that dichotomy. The Objective-C runtime is runtime-heavy, generates a slew of runtime-interpretable data, and yet is compiled "natively" insofar as the body of functions-nee-methods is native. Instance variable access from native code is done through indirection with metadata maintained on their type and offset, dispatch is done through indirection from native code using class metadata, instantiation is done through indirection using the global registration of class metadata. The problem has consistently been in the non-forward-looking design of that structured data, not in the fact that they generate method bodies as native machine code.

comex 14y ago
Since I've been tired the last few days, here's a late reply: Direct pointer offsetting of fragile base classes and statically generated copy/destroy code for blocks in lieu of type information would be fairly unthinkable in a managed language, whose bytecode probably wouldn't be low level enough to even express those designs; it would still have been a good idea to think ahead and use indirection for ivars and include full type information in blocks, but managed language designers never really had the chance to make such mistakes in the first place. For other Objective-C changes, like garbage collection, the changes to code generation would have been unreasonable to make "in advance", but it's hard to imagine an analogous change in a managed language that would require an ABI break. Though Objective-C could have done better, it's a bit unfair to compare it to something like the JVM.