3 ms·

This seems more like a case against message passing. The reason iOS is smooth and fast is that a lot of the heavy lifting is done by optimized pure C code call

by gress 12y ago

This seems more like a case against message passing. The reason iOS is smooth and fast is that a lot of the heavy lifting is done by optimized pure C code called from objective-C. A major goal for Swift is to let people achieve that kind of performance without having to write the high performance stuff in C. C is replaced with swift's functional core. Switching all dispatch to message passing would destroy this benefit and push more development back into C. The case of the Latin Conjugation, and the IRC client are terrible reasons for using message passing. Both are trivially solved with data structures and closures. It seems that the author has little experience with functional programming, and just wants to stick with Objective-C. I'm not against message passing - I just think that Swift gets the balance right, and it would take a much stronger argument than this to justify message passing everywhere.

Buckleyisms 12y ago
I suppose it depends on what you intend to use Swift for. My argument is that Swift will be primarily used to write high-level apps. For these apps, message passing is almost never a bottleneck. Swift is not going to replace the optimized C and C++ code, especially for the really low-level stuff. But even if Apple does decide to rewrite all the Core* frameworks et. al. with Swift, there's still an argument that Swift should use message passing by default, and a way to opt in to vtable and direct dispatch for performance-critical code. For higher-level apps, message-passing is a lot less useful if it's opt-in. As for the IRC and Latin conjugation, yes, those problems can be solved in other ways, but those other ways involve more (mostly glue) code. Trading more code for execution speed is the wrong tradeoff when performance is good enough. You're correct I want to stick with Objective-C, but not that I have little experience with functional programming. I love functional programming. I love most of Swift. But for the specific problem domain of Mac and iOS apps, I love Objective-C. It makes working with GUIs much easier than anything else out there, and the ability to method swizzle Mac apps is great for third-party add ons.
- michaeljbishop 12y ago
  Amen! (Minus the sizzling)
- gress 12y ago
  I honestly think you're wrong about message passing not being a bottleneck. I think there are things that people simply avoid because they'd be slow in Objective-C, and C isn't powerful enough. I am personally looking forward to being able to write more complex algorithms concisely and with high performance. Also, you are completely ignoring the fact that CPU cycles aren't just about time - they are about energy. Increased performance means longer battery life, or more sophisticated apps that we can use all day. I don't see how you can be correct about the IRC example requiring more glue code. Surely at the very least you need a table matching commands to selectors. How would this be any different to a table mapping command to closures or functions in swift?

by gress 12y ago

Buckleyisms 12y ago

I suppose it depends on what you intend to use Swift for. My argument is that Swift will be primarily used to write high-level apps. For these apps, message passing is almost never a bottleneck. Swift is not going to replace the optimized C and C++ code, especially for the really low-level stuff. But even if Apple does decide to rewrite all the Core* frameworks et. al. with Swift, there's still an argument that Swift should use message passing by default, and a way to opt in to vtable and direct dispatch for performance-critical code. For higher-level apps, message-passing is a lot less useful if it's opt-in. As for the IRC and Latin conjugation, yes, those problems can be solved in other ways, but those other ways involve more (mostly glue) code. Trading more code for execution speed is the wrong tradeoff when performance is good enough. You're correct I want to stick with Objective-C, but not that I have little experience with functional programming. I love functional programming. I love most of Swift. But for the specific problem domain of Mac and iOS apps, I love Objective-C. It makes working with GUIs much easier than anything else out there, and the ability to method swizzle Mac apps is great for third-party add ons.

michaeljbishop 12y ago
Amen! (Minus the sizzling)
gress 12y ago
I honestly think you're wrong about message passing not being a bottleneck. I think there are things that people simply avoid because they'd be slow in Objective-C, and C isn't powerful enough. I am personally looking forward to being able to write more complex algorithms concisely and with high performance. Also, you are completely ignoring the fact that CPU cycles aren't just about time - they are about energy. Increased performance means longer battery life, or more sophisticated apps that we can use all day. I don't see how you can be correct about the IRC example requiring more glue code. Surely at the very least you need a table matching commands to selectors. How would this be any different to a table mapping command to closures or functions in swift?