9 ms·
The Objective-C Runtime and Swift Dynamism
- btreesOfSpring 9y agoI'm getting the loading error, "An error occurred in the application and your page could not be served. If you are the application owner, check your logs for details." Not sure if there is a mirror, a write-up, or another example anyone might be able to pass along. edit: this google cache version is working[0]. [0] https://webcache.googleusercontent.com/search?q=cache:gXiqzW0OV04J:https://academy.realm.io/posts/mobilization-roy-marmelstein-objective-c-runtime-swift-dynamic+&cd=1&hl=en&ct=clnk&gl=us&lr=lang_de%7Clang_en https://webcache.googleusercontent.com/search?q=cache:gXiqzW...
- tambourine_man 9y agoYou can watch the talk with google cache. It’s from 2016. Basically, Swift dynamism is coming, hopefully safer than ObjC
- fbgugli 9y agoI hope apple does not kill swift with sillynes. M$ did very good job on 90's on that. I really would not like all apps again.. Is this 3rd time??
- dep_b 9y agoI still like Objective-C even if it isn't my go-to language anymore. It's quite elegant compared to it's peers from the 80's, it's a very small language yet you can achieve everything with it, even if it means dipping into C(++) for the parts that need to be really performant. But on the other hand seeing a different programming language when there's some optimization going on and having another programming language for business logic is a great thing too. How many times don't we see bugs, errors or security issues stemming from the fact that business logic gets implemented in C?
- nerdponx 9y agoWhat is cross-platform development like? Also, what about Objective-C prevents business logic bugs?
- dep_b 9y ago> What is cross-platform development like? Sorry, never tried that. > Also, what about Objective-C prevents business logic bugs? Generically speaking C makes it easy to interact with the computer memory but harder to abstract things while OO languages have it reverse. C has GOTO, Objective-C not. Objective-C has objects that easily can encapsulate different aspects of your logic. Objective-C is very verbose and readable while most C API's aren't. Obviously Swift is even better in that regard as it has better types and checks but it doesn't allow you to seamlessly use C.
- bogomipz 9y ago>"Before we start, Objective-C is a runtime-oriented language, which means that all of the links between your methods and variables and classes are deferred to the last moment possible to when your app is actually running, ..." I had not heard the term "runtime-oriented language" before. Is this really just another term for "supports reflection"? If not what would be other examples of "runtime-oriented" languages?
- chc 9y agoI think it means "dynamic," in the sense that when you call a method, the object's class is looked up and the class's method list is looked up and the methods' implementations are looked up and the class is even given a chance to handle the lookup itself. It doesn't just support reflection, it reflects pervasively. This basically corresponds to what we usually mean when we say a "dynamic language."
- alkonaut 9y agoIs that lookup done all the time (for each invocation of the same method):? Or is it done at a single point in time, like a JIT, but after that the method is “fixed”? With the possibility to intercept/replace code at runtime (at any time, not just at a resolve/jit stage) it must be very hard for the runtime to optimize calls (i.e make direct calls instead of indirect via method pointer lookup)? I’m not familiar with how this works in any runtime (V8, Hotspot, ...) so I’m curious which runtimes actually pay one extra method pointer lookup forever and which don’t. I’m guessing the answer for nearly all of them is “it depends”.
- jonhess 9y agoThe lookup happens on each invocation. It’s alway indirect, and the implementation of a method can be changed at runtime. Method calls aren’t optimized to be direct invocations.
- 0x0 9y agoThere's some good info on that here: "Dissecting objc_msgSend on ARM64" https://www.mikeash.com/pyblog/friday-qa-2017-06-30-dissecting-objc_msgsend-on-arm64.html https://www.mikeash.com/pyblog/friday-qa-2017-06-30-dissecti... "Let's Build objc_msgSend" https://www.mikeash.com/pyblog/friday-qa-2012-11-16-lets-build-objc_msgsend.html https://www.mikeash.com/pyblog/friday-qa-2012-11-16-lets-bui... There's also the "Illustrated history of objc_msgSend", although it appears a bit dated, it has some nice commentary on the evolution of this very performance-critical part of the objective-c runtime: http://sealiesoftware.com/msg/index.html http://sealiesoftware.com/msg/index.html
- thewayfarer 9y agoThis is particularly relevant right now. The swift-evolution mailing list is currently discussing adding a "dynamic member lookup" protocol to Swift to enhance interop with dynamic languages like Python, Ruby, and Perl. You can see the proposal here[0]. [0] https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438 https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae...
- skue 9y ago> Before we start, Objective-C is a runtime-oriented language, which means that all of the links between your methods and variables and classes are deferred to the last moment possible to when your app is actually running, and this gives you great flexibility because you can change those links. The alternative, where Swift is most of the time, is compiletime-oriented languages. So in Swift everything is a bit more harder bound, and you get more safety, but it’s less flexible. > This is what this debate was all about. Not just safety, but also performance. Swift offers significant performance gains when you don’t need the dynamism. Swift lets you opt into dynamic features (as he later explains), and you can seemlessly interact with Objective C on Mac platforms. But you don’t have to pay the penalty for dynamism in the vast majority of your code that doesn’t use these features. Edited: I also pointed out some additional mistakes in the post, but removed that because this comment got too long.
- mpweiher 9y ago> Not just safety, but also performance. Swift offers significant performance gains This is a common misconception. It is not true. Swift is slower than Objective-C, typically significantly so.
- skue 9y agoWhen arguing against a “common misconception,” one typically provides a source. You seem to be saying that Apple’s claims are not only wrong, but ObjC is somehow faster despite having to do more work. Swift has no runtime method table lookups, no extra objc_msgSend calls, better ability to analyze and inline code, no retain/release dance for code with value semantics, etc. Every benchmark I’ve seen shows Swift faster for these reasons.
- panic 9y agoDo you have experience writing Swift or Obj-C programs? My experience is that Obj-C has predictable performance which is often "good enough", whereas Swift is either too slow (without optimizations) or takes a very long time to compile (with optimizations enabled). As a concrete example, I took a Swift program I had lying around (8 files, 2854 lines total), compiled it without optimizations, and stress-tested it a bit. Here's what the "bottom-up" profile looks like: https://i.imgur.com/ohlKQgx.png https://i.imgur.com/ohlKQgx.png -- tons of time wasted in Swift runtime overhead. Compiling with optimizations removes most of the overhead, but a clean build of this (relatively small) program took almost 5 minutes with optimizations enabled.
- IMcD23 9y agoIt's important to note that this talk is from 2016. Since then, Swift 4 has been released, that added KVO and key paths to the language.