3 ms·

> It's certainly slower. That's the least of problems, since nowadays we have smart runtime systems that dynamically optimize running programs. It's not elegan

> It's certainly slower. That's the least of problems, since nowadays we have smart runtime systems that dynamically optimize running programs. It's not elegant, but it works. A more fundamental problem is that this approach to programming leads to brittle code, and when it breaks, it doesn't warn you until it's too late.

comex 10y ago
Actually, I feel a bit silly and maybe confused, as the 'setProperty' I mentioned at the end of my last post is... just reflection. Which Swift already has, in the form of Mirror. The only reason the Objective-C runtime is needed for that example is that Mirror apparently only allows you to get the values of properties, not set them, but that just sounds like an implementation limitation that could easily be lifted - clearly built-in reflection is considered within the scope of Swift.[1] So it's a bit odd for Brent Simmons to put this in a list of things he's "nervous" won't be possible in the future, and not even mention reflection. Most of the other things in the list seem like they really aren't possible without Objective-C or, in its stead, new Swift features. (They could still be done with macros!) I guess reflection fits into the general category of dynamism even if it is essentially an existing Swift feature. In any case, to respond to your point: Objective-C does not have a JIT, and since there are a lot of advantages to a pure ahead-of-time compilation model (see the mailing list post linked elsewhere in this thread), as a language mainly focused on static compilation, Swift is unlikely to get one in the future just to deal with hypothetical dynamic features. Anyway, even in the relatively small set of languages that are both highly dynamic (going beyond simple reflection) and well-optimized - there's JavaScript, and LuaJIT I guess? and maybe some less common ones, there's PyPy but I don't call that well-optimized - if you actually use the dynamic features it's easy to fall off the JIT happy path and make your whole function unoptimizable. See [2]. But that's getting off topic. [1] In making that thinko I showed my lack of Swift experience: in Rust reflection is done with macros. [2] https://github.com/petkaantonov/bluebird/wiki/Optimization-killers https://github.com/petkaantonov/bluebird/wiki/Optimization-k...
- jonhohle 10y ago
  A JIT for what? Both Swift and Objective-C are AOT. Objective-C offers runtime dispatch into native code, no different than calling a function pointer in C (just with a more convenient method of looking them up at runtime).

comex 10y ago

Actually, I feel a bit silly and maybe confused, as the 'setProperty' I mentioned at the end of my last post is... just reflection. Which Swift already has, in the form of Mirror. The only reason the Objective-C runtime is needed for that example is that Mirror apparently only allows you to get the values of properties, not set them, but that just sounds like an implementation limitation that could easily be lifted - clearly built-in reflection is considered within the scope of Swift.[1] So it's a bit odd for Brent Simmons to put this in a list of things he's "nervous" won't be possible in the future, and not even mention reflection. Most of the other things in the list seem like they really aren't possible without Objective-C or, in its stead, new Swift features. (They could still be done with macros!) I guess reflection fits into the general category of dynamism even if it is essentially an existing Swift feature. In any case, to respond to your point: Objective-C does not have a JIT, and since there are a lot of advantages to a pure ahead-of-time compilation model (see the mailing list post linked elsewhere in this thread), as a language mainly focused on static compilation, Swift is unlikely to get one in the future just to deal with hypothetical dynamic features. Anyway, even in the relatively small set of languages that are both highly dynamic (going beyond simple reflection) and well-optimized - there's JavaScript, and LuaJIT I guess? and maybe some less common ones, there's PyPy but I don't call that well-optimized - if you actually use the dynamic features it's easy to fall off the JIT happy path and make your whole function unoptimizable. See [2]. But that's getting off topic. [1] In making that thinko I showed my lack of Swift experience: in Rust reflection is done with macros. [2] https://github.com/petkaantonov/bluebird/wiki/Optimization-killers https://github.com/petkaantonov/bluebird/wiki/Optimization-k...

jonhohle 10y ago
A JIT for what? Both Swift and Objective-C are AOT. Objective-C offers runtime dispatch into native code, no different than calling a function pointer in C (just with a more convenient method of looking them up at runtime).