3 ms·
Holy clickbait headline, Batman. Yes, Carbon has been replaced in the past but that involved a $400 million acquisition and 10 years of continual complaining,
by gilgoomesh 12y ago
Holy clickbait headline, Batman.
Yes, Carbon has been replaced in the past but that involved a $400 million acquisition and 10 years of continual complaining, kicking and screaming from established Carbon users who had no desire to change. I doubt it's an example of how future changes will occur.
Replacing entire application frameworks is hard. Super, super hard. It seems like it might be simple to start by replacing Foundation with Swift's standard library but actually, replacing Foundation would mean replacing every Cocoa framework since they all rely on it. And there's a gigantic amount of work in those frameworks; 25 years of development (all the way back to the early NeXT days).
I think this is why Swift includes such extensive support for Objective-C interoperation: Apple expect Swift will need to link against Objective-C APIs for a long, long time.
I think we're much more likely to see a major deprecation sweep through Cocoa in one or two years time (probably once Swift finally has all the features Apple have hinted are coming). Not deleting things, per se, but simply saying "these things look ugly or silly in Swift" so use these other things instead.
- e28eta 12y agoAnd what's the practical difference between death and deprecation? As the Swift standard library grows, and it becomes the widely preferred language for iOS and Mac development, isn't that a form of death?
- gilgoomesh 12y agoSimply: I don't think Apple are going to suddenly replace Foundation (or any other Cocoa framework) with a Swift only version. They'll just iterate the frameworks they currently have to make them a little more modern and a little more Swift friendly. Not that they could anyway: according to Chris Lattner, Swift is currently 1-2 years away from including a language "resilience model" that would allow safe linking to frameworks built with a different version of Swift. Until then, the Swift standard library needs to remain as small as possible because it is statically linked into every Swift app (it can't be shipped separately with the OS).
- matttthompson 12y agoI have no illusions about the amount of effort and investment necessary to change technology stacks. Carbon was only officially deprecated in OS X 10.8. To speak of the death of technology is only to acknowledge that it is mortal. My claim isn't that everything will be rewritten in Swift—far from it. Instead, the article is an exploration of what it would mean for Swift to evolve beyond the constraints of Objective-C & Cocoa interoperability, and how that may occur as Swift gains momentum.