6 ms·

Not sure I see what's going on here (it's just a blog post linking to other blog posts?), but is this arguing that Apple should turn the safety of Swift back in

by chris_7 10y ago

Not sure I see what's going on here (it's just a blog post linking to other blog posts?), but is this arguing that Apple should turn the safety of Swift back into the unsafe mess of Objective-C? Horrifying stuff like swizzling, respondsToSelector tricks, etc.? That's what Swift is trying to get away from! Some of the classes in Apple's frameworks need to be overridden, some of them cannot be overridden, some of them don't both to call their overridden accessors - it's a mess! You can only discover this stuff by reading the documentation (if it's even there), when it ought to be enforced by a strict compiler.

refulgentis 10y ago
The Objective-C old guard has had a very hard time dealing with Swift. For a couple years now, every 3 months they have another blog post hand-wringing about what they used to do in Objective-C, how they can't in Swift, with the implicit warning this is worrisome and _needs_ to be reimplemented in Swift, or Swift isn't a serious contender long-term. Most of the of the community seems to have moved on, with the understanding that of course you can't reimplement performSelector/KVO/(insert dynamic, non-type safe feature that usually just bites you in the ass in the long run) from scratch, but we still have Objective-C that already implemented those features, and we will have it for years, if not decades, to come. Maybe Apple doesn't have to open source UIKit to prove their commitment to Swift (a short, albeit slightly unfair, summary of a blog post last week from another member of the old guard) There seems to be a general lack of imagination, and lack of understanding that Apple would never rewrite UIKit or other large, existing frameworks in Swift. But, once Swift is more stable in a year or two, maybe you start thinking about new frameworks being written in Swift, with Objective-C compatibility, instead of vice versa. Maybe you can't write Rails in Swift, but by god, why would you ever write Rails again? There's been two heavily up voted stories here in the past two weeks describing how awful it is to have a career dependent on a framework so dependent on dynamic untyped code. That matches exactly with my experience being pressed into service writing Rails code for a couple months - the development experience felt like the Stone Age compared to Swift, even if I could write a method ~20% faster.
- Razengan 10y ago
  I do hope Apple unveils a unified protocol-oriented framework for both MacOS and iOS. One that, when necessary, keeps Swift in mind before Objective-C.
  - refulgentis 10y ago
    Definitely - it would be awesome, but way ahead of schedule, if they're thinking about a true UXKit landing with ABI stability and "finished" generics in Swift 4.
    - Razengan 10y ago
      Well, considering that Swift was in development for 4? years or so before they announced it, it would make sense if they've already been working on a new API platform for a while. Something that pleasantly unites iOS+MacOS+Swift on the developer side, while letting those operating systems retain their differences and strengths on the user side.
- veidr 10y ago
  > That matches exactly with my experience being pressed into service writing Rails code for a couple months - the development experience felt like the Stone Age compared to Swift, even if I could write a method ~20% faster Me, too. At work, I am on two different projects at the moment: an SDK and application written in Swift, and a run-of-the-mill Rails app. Going back to the Rails app is frankly gut-wrenchingly bad. Every aspect of coding and debugging — and especially refactoring — is so much worse when doing it in ruby. The strength of Swift type system makes the tools so much better, and at least for me, it's easier to code in it and reason about it effectively (even if yes, you do type more letters). But, I want to point out: the same is not true of Objective-C. Even though it has a lot of dynamism under the covers, coding in Obj-C in Xcode is much closer to coding in Swift than Ruby. It's only in 'special cases' that you would really use an untyped object reference. So the compiler is able to catch a huge number of errors at compile time, the editor knows what type your variable is so autocomplete is intelligent, etc. I do like Swift better, but coding in Obj-C is much closer to Swift than Ruby in terms of the tooling experience, and in terms of how much dynamic untyped code there actually is in a program. Modern Obj-C is "mostly typed", and swizzling and weird object casting are seldomly done (usually only in a tricky situation, which is when you appreciate the ability).
deleted 10y ago
[deleted]
veidr 10y ago
It is a mess, but it's a mess that's well aligned with the state of Apple's application frameworks. When there is widespread discussion of a certain topic in the Mac/iOS programming community, Michael Tsai is well known for posting collections of links to important discussion of that topic, as he has done here. These are mostly grizzled Objectrive-C veterans writing. They have dealt with the messy legacy for years, but they also leverage the dynamism of Obj-C/Cocoa to solve a ton of real problems. Personally, I really like Swift. After 15 years of Objective-C programming, I probably won't do more than few more hours of it over the remainder of my life. But, I understand where these guys are coming from, and it's interesting to read about the problems they are having. This totally isn't a "language war", but if you look at it that way, it is one of the most fascinating ones. It's not just comparing and contrasting two programming languages arbitrarily, in theory; it's an energetic discussion among accomplished working programmers about real-world work in the only two languages that can feasibly be used for the platforms they are on. Super interesting.
mpweiher 10y ago
Did you actually read any of the linked articles? It seems not. Quotes: "many of these dynamic features are definitely hacks, with various issues" or "[Objective-C] is a bad design, as far as metasystems are concerned" or "The solution to bad metasystems is not to ban metasystems, it is to design better metasystems that allow these things in a more disciplined and more flexible way." or "The point is that these problems will need solving in a possible future world without the Objective-C runtime. These kinds of problems should be considered as that world is being designed. The answers don’t have to be the same answers as Objective-C — but they need to be good answers, better than (for instance) writing a script to generate some code."
dottrap 10y ago
What's going on here is Brent Simmons has been posting a series of blog articles expressing concern that very useful dynamic features used in Obj-C to great effect cannot be currently done in pure Swift. And many of the old guard that is knowledgable in how Obj-C+Cocoa is implemented and have built their own powerful things on top of it are also expressing their same concern that Swift has not addressed how these things are going to be done without Obj-C. http://inessential.com/2016/05/18/what_im_doing_with_these_articles http://inessential.com/2016/05/18/what_im_doing_with_these_a... There are key technologies in Cocoa like the Responder Chain, NSUndoManager, Key-Value-Coding/Key-Value-Observing/Cocoa Bindings, Core Data, that are made possible due to Objective-C's dynamic features which allows for easy coding and also impressive decoupling. The concern is that some developers actually need to develop things like this and Swift doesn't offer anything comparable. Additionally, as Swift enters new platforms where Obj-C doesn't exist, or if Apple kills off Obj-C support, there is no obvious replacement for those who want/need to build systems like Cocoa. For right now, Swift is a good consumer of Cocoa, but not something you could implement Cocoa with.
- chris_7 10y ago
  > Responder Chain Protocols, or even a superclass. > NSUndoManager Closures. Even Apple has moved away from target/selector for new APIs in favor of blocks. > Key-Value-Coding/Key-Value-Observing/Cocoa Bindings An equivalent is easily implementable in pure Swift, see ReactiveCocoa's PropertyType/MutablePropertyType, and I'm sure someone has packaged something similar as a µframework so that you don't need to add all of RAC. > Core Data This one is actually hard, as it relies on dynamic generation of implementations, instead of using that to solve a different problem, as is the case with KVO. I'm willing to toss Core Data overboard to gain the safety and productivity of Swift, but YMMV.
  - dottrap 10y ago
    It doesn't sound like you've read any of the articles. There are details and tradeoffs and limitations found by the people talking about them. And there is a massive knowledge vacuum because if there is a good solution, it's not something that is obvious and well discussed by Apple. Ignoring and dismissing them doesn't make them actually go away. Here's two on just the Responder chain: http://inessential.com/2016/05/17/responder_chain_followup http://inessential.com/2016/05/17/responder_chain_followup http://shapeof.com/archives/2016/5/dynamic_swift.html http://shapeof.com/archives/2016/5/dynamic_swift.html The bigger point (which is in that first Brent Simmons link) is that people have built all sorts of frameworks and tools over the past 20 years depending using of the dynamic features of Obj-C. Some are Apple's like all the above plus others like Interface Builder and XCTest, but other people have built their own things too that rely on the same concepts. How do these people move forward in a Swift world? None of these people are arguing that Swift is terrible and going back to Obj-C. They are trying to use Swift. They are only interested in solving the problems they have (and well). When Swift fails to solve a problem or is far worse than its predecessor, there is a problem. Not everybody can nonchalantly throw their stuff overboard like you are willing to do with Core Data.

by chris_7 10y ago

refulgentis 10y ago

The Objective-C old guard has had a very hard time dealing with Swift. For a couple years now, every 3 months they have another blog post hand-wringing about what they used to do in Objective-C, how they can't in Swift, with the implicit warning this is worrisome and _needs_ to be reimplemented in Swift, or Swift isn't a serious contender long-term. Most of the of the community seems to have moved on, with the understanding that of course you can't reimplement performSelector/KVO/(insert dynamic, non-type safe feature that usually just bites you in the ass in the long run) from scratch, but we still have Objective-C that already implemented those features, and we will have it for years, if not decades, to come. Maybe Apple doesn't have to open source UIKit to prove their commitment to Swift (a short, albeit slightly unfair, summary of a blog post last week from another member of the old guard) There seems to be a general lack of imagination, and lack of understanding that Apple would never rewrite UIKit or other large, existing frameworks in Swift. But, once Swift is more stable in a year or two, maybe you start thinking about new frameworks being written in Swift, with Objective-C compatibility, instead of vice versa. Maybe you can't write Rails in Swift, but by god, why would you ever write Rails again? There's been two heavily up voted stories here in the past two weeks describing how awful it is to have a career dependent on a framework so dependent on dynamic untyped code. That matches exactly with my experience being pressed into service writing Rails code for a couple months - the development experience felt like the Stone Age compared to Swift, even if I could write a method ~20% faster.

Razengan 10y ago
I do hope Apple unveils a unified protocol-oriented framework for both MacOS and iOS. One that, when necessary, keeps Swift in mind before Objective-C.
- refulgentis 10y ago
  Definitely - it would be awesome, but way ahead of schedule, if they're thinking about a true UXKit landing with ABI stability and "finished" generics in Swift 4.
  - Razengan 10y ago
    Well, considering that Swift was in development for 4? years or so before they announced it, it would make sense if they've already been working on a new API platform for a while. Something that pleasantly unites iOS+MacOS+Swift on the developer side, while letting those operating systems retain their differences and strengths on the user side.
veidr 10y ago
> That matches exactly with my experience being pressed into service writing Rails code for a couple months - the development experience felt like the Stone Age compared to Swift, even if I could write a method ~20% faster Me, too. At work, I am on two different projects at the moment: an SDK and application written in Swift, and a run-of-the-mill Rails app. Going back to the Rails app is frankly gut-wrenchingly bad. Every aspect of coding and debugging — and especially refactoring — is so much worse when doing it in ruby. The strength of Swift type system makes the tools so much better, and at least for me, it's easier to code in it and reason about it effectively (even if yes, you do type more letters). But, I want to point out: the same is not true of Objective-C. Even though it has a lot of dynamism under the covers, coding in Obj-C in Xcode is much closer to coding in Swift than Ruby. It's only in 'special cases' that you would really use an untyped object reference. So the compiler is able to catch a huge number of errors at compile time, the editor knows what type your variable is so autocomplete is intelligent, etc. I do like Swift better, but coding in Obj-C is much closer to Swift than Ruby in terms of the tooling experience, and in terms of how much dynamic untyped code there actually is in a program. Modern Obj-C is "mostly typed", and swizzling and weird object casting are seldomly done (usually only in a tricky situation, which is when you appreciate the ability).

deleted 10y ago

[deleted]

veidr 10y ago

It is a mess, but it's a mess that's well aligned with the state of Apple's application frameworks. When there is widespread discussion of a certain topic in the Mac/iOS programming community, Michael Tsai is well known for posting collections of links to important discussion of that topic, as he has done here. These are mostly grizzled Objectrive-C veterans writing. They have dealt with the messy legacy for years, but they also leverage the dynamism of Obj-C/Cocoa to solve a ton of real problems. Personally, I really like Swift. After 15 years of Objective-C programming, I probably won't do more than few more hours of it over the remainder of my life. But, I understand where these guys are coming from, and it's interesting to read about the problems they are having. This totally isn't a "language war", but if you look at it that way, it is one of the most fascinating ones. It's not just comparing and contrasting two programming languages arbitrarily, in theory; it's an energetic discussion among accomplished working programmers about real-world work in the only two languages that can feasibly be used for the platforms they are on. Super interesting.

mpweiher 10y ago

Did you actually read any of the linked articles? It seems not. Quotes: "many of these dynamic features are definitely hacks, with various issues" or "[Objective-C] is a bad design, as far as metasystems are concerned" or "The solution to bad metasystems is not to ban metasystems, it is to design better metasystems that allow these things in a more disciplined and more flexible way." or "The point is that these problems will need solving in a possible future world without the Objective-C runtime. These kinds of problems should be considered as that world is being designed. The answers don’t have to be the same answers as Objective-C — but they need to be good answers, better than (for instance) writing a script to generate some code."

dottrap 10y ago

What's going on here is Brent Simmons has been posting a series of blog articles expressing concern that very useful dynamic features used in Obj-C to great effect cannot be currently done in pure Swift. And many of the old guard that is knowledgable in how Obj-C+Cocoa is implemented and have built their own powerful things on top of it are also expressing their same concern that Swift has not addressed how these things are going to be done without Obj-C. http://inessential.com/2016/05/18/what_im_doing_with_these_articles http://inessential.com/2016/05/18/what_im_doing_with_these_a... There are key technologies in Cocoa like the Responder Chain, NSUndoManager, Key-Value-Coding/Key-Value-Observing/Cocoa Bindings, Core Data, that are made possible due to Objective-C's dynamic features which allows for easy coding and also impressive decoupling. The concern is that some developers actually need to develop things like this and Swift doesn't offer anything comparable. Additionally, as Swift enters new platforms where Obj-C doesn't exist, or if Apple kills off Obj-C support, there is no obvious replacement for those who want/need to build systems like Cocoa. For right now, Swift is a good consumer of Cocoa, but not something you could implement Cocoa with.

chris_7 10y ago
> Responder Chain Protocols, or even a superclass. > NSUndoManager Closures. Even Apple has moved away from target/selector for new APIs in favor of blocks. > Key-Value-Coding/Key-Value-Observing/Cocoa Bindings An equivalent is easily implementable in pure Swift, see ReactiveCocoa's PropertyType/MutablePropertyType, and I'm sure someone has packaged something similar as a µframework so that you don't need to add all of RAC. > Core Data This one is actually hard, as it relies on dynamic generation of implementations, instead of using that to solve a different problem, as is the case with KVO. I'm willing to toss Core Data overboard to gain the safety and productivity of Swift, but YMMV.
- dottrap 10y ago
  It doesn't sound like you've read any of the articles. There are details and tradeoffs and limitations found by the people talking about them. And there is a massive knowledge vacuum because if there is a good solution, it's not something that is obvious and well discussed by Apple. Ignoring and dismissing them doesn't make them actually go away. Here's two on just the Responder chain: http://inessential.com/2016/05/17/responder_chain_followup http://inessential.com/2016/05/17/responder_chain_followup http://shapeof.com/archives/2016/5/dynamic_swift.html http://shapeof.com/archives/2016/5/dynamic_swift.html The bigger point (which is in that first Brent Simmons link) is that people have built all sorts of frameworks and tools over the past 20 years depending using of the dynamic features of Obj-C. Some are Apple's like all the above plus others like Interface Builder and XCTest, but other people have built their own things too that rely on the same concepts. How do these people move forward in a Swift world? None of these people are arguing that Swift is terrible and going back to Obj-C. They are trying to use Swift. They are only interested in solving the problems they have (and well). When Swift fails to solve a problem or is far worse than its predecessor, there is a problem. Not everybody can nonchalantly throw their stuff overboard like you are willing to do with Core Data.