This 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].
I 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?
I'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.
> 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.
Tooling and maturity are reasons why not currently, maybe give it a couple of years ;)
Debuggers can not work properly, xcode indexing can beachball, compile times are quite a bit longer, there is API churn from version to version, a lack of ABI stability forcing you to bundle swift with your app increasing binary size and other bugs.
>"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?
The usual name for this is "late binding". It became popular because of Smalltalk, and it's a core principle of the "pure OOP" languages (like Self, Obj-C and Ruby) that Smalltalk inspired.
I 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."
Really just means a dynamic language just like smalltalk, LISP, python, Ruby etc. Like Objective-C all these allow you to add classes and method at runtime.
I think the author means "late binding" - the method lookup is done at invocation time rather than compile time. (There is caching, etc, to make it fast.)
[+] [-] thewayfarer|8 years ago|reply
[0] https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae...
[+] [-] dep_b|8 years ago|reply
How many times don't we see bugs, errors or security issues stemming from the fact that business logic gets implemented in C?
[+] [-] nerdponx|8 years ago|reply
Also, what about Objective-C prevents business logic bugs?
[+] [-] btreesOfSpring|8 years ago|reply
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:gXiqzW...
[+] [-] tambourine_man|8 years ago|reply
Basically, Swift dynamism is coming, hopefully safer than ObjC
[+] [-] skue|8 years ago|reply
> 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.
[+] [-] woolvalley|8 years ago|reply
Debuggers can not work properly, xcode indexing can beachball, compile times are quite a bit longer, there is API churn from version to version, a lack of ABI stability forcing you to bundle swift with your app increasing binary size and other bugs.
[+] [-] mpweiher|8 years ago|reply
This is a common misconception. It is not true. Swift is slower than Objective-C, typically significantly so.
[+] [-] bogomipz|8 years ago|reply
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?
[+] [-] panic|8 years ago|reply
[+] [-] chc|8 years ago|reply
[+] [-] jernfrost|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] dunham|8 years ago|reply
[+] [-] terhechte|8 years ago|reply
[+] [-] IMcD23|8 years ago|reply
[+] [-] fbgugli|8 years ago|reply
[deleted]
[+] [-] tzahola|8 years ago|reply
[+] [-] _sdegutis|8 years ago|reply