5 ms·

He's missing a crucial piece of evidence. Apple has done a lot of work to make sure that Swift and Objective-C can coexist in same project. You can call Swift c

He's missing a crucial piece of evidence. Apple has done a lot of work to make sure that Swift and Objective-C can coexist in same project. You can call Swift code from Objective-C and Objective-C code from Swift with little fuss. This is completely unlike Microsoft's C++/.NET situation. If you look at the source code of the Swift standard library, "toll free" bridging code is everywhere. It even affects the language design of both Swift and Objective-C. Yes there are still inefficiencies, but they are small. Apple has done everything humanly possible to make this interface efficient, seamless and sustainable. So I think the plan is very clear: Don't force people (including Apple itself) to rewrite old code. Make it possible and desirable to add new features to old Objective-C projects in Swift. Maybe let Objective-C die of old age at some point in the very distant future. There is a ton of evidence that they are in this dual mode for the long haul. I think the one flaw in their strategy is that people who like Swift will start to hate the antiquated object oriented design of Cocoa and some lower level OS services. My prediction is that more and more of Cocoa will be wrapped with idiomatic Swift code that Objective-C devs will not want to adopt. At that point, there will effectively be two competing system APIs. The pressure to make a clean break with Cocoa will grow because some un-idiomatic parts of Cocoa will be hard to wrap and people will call for a modern replacement for Cocoa long before Objective-C is gone. So I think, most of the friction in this transition will arise on the library side, not with the languages themselves.

glhaynes 10y ago
I'm least clear about whether a clean break with Cocoa will be needed. Perhaps most parts of Cocoa that don't match well with Swift will just be given more natural-feeling replacements? Obviously this can be complicated by dependencies, though.
- Someone 10y ago
  That would almost certainly lead to a break with Cocoa. Those, for Swift programmers, more natural-feeling replacements will be harder to call from Objective-C than an API designed for Objective-C would be. The only way to make neither side unhappy about it would be to provide two 100% equivalent interfaces, one for Cocoa and one for Carbon. That is unfeasible, so there will be differences. Even if they manage to write functionally and preformance-wise identical interfaces, not shipping them at the exact same time still would make the other side feel discriminated against. I expect the first Swift-only library to appear on iOS because, on that platform, Apple can know exactly how much new code uses which language. That makes timing the transition easier. I also expect people to write glue code to call it from Objective-C, but that will be a rear-guard action. A few years after that, I expect Apple to drop Cocoa. Deep below Swift, all the core stuff such as strings will still use the same code, but that will be hidden behind a Swift interface. After all, this is Apple, a company that isn't afraid to drop backwards compatibility. This is what happened with Carbon and Cocoa, too (how many years did that take?) It won't happen overnight, though. Swift first needs to gain a few features (dynamism, more reflection, a frozen ABI, to mention a few), and the tooling must mature. I think the first feature breaking interoperability with Objective-C may be a borrow checker, as that is something they have expressed interest in.
rtpg 10y ago
I think Python is a good example of how things can happen. Python's standard library includes a lot of pretty frustrating libraries, but offers a lot of low-level functionality. So people can easily write wrapper libraries with more "pythonic" usage. Think about requests vs. urllib (though technically requests' backend can be replaced). I can imagine that Apple could write Swift libraries that are more idiomatic to the language by just wrapping Cocoa stuff. I mean, React Native can exist, so why can't this?
- masklinn 10y ago
  > a lot of low-level functionality. So people can easily write wrapper libraries with more "pythonic" usage. Think about requests vs. urllib (though technically requests' backend can be replaced). To my knowledge, requests is implemented on top of urllib3 (a third-party library from which it gets most of its advanced feature), not the stdlib's urllib or urllib2.
  - rtpg 10y ago
    Ah, I stand corrected. It seems like urllib3 uses Python's socket library stuff though? I guess that part of the code isn't the trickiest part.
- fauigerzigerk 10y ago
  I agree that wrapping can and does work in most cases. But then there are times when it doesn't work without introducing a lot of complexity and/or inefficiency or without limiting design choices. How will the new concurrency/parallelism facilities they are planning for Swift work with libdispatch queues? Will they want to build on GCD or not? Will whatever they do work for Objective-C just as conveniently? That's an open question in my view. For an example why wrapping cannot work efficiently in all cases look no further than Python 2 vs Python 3 strings. They are conceptually too different. With enough "waste" of resources everything can be wrapped. I don't know how React Native works. But React.js uses a virtual DOM that effectively doubles memory usage. That's what gives them the freedom to use a completely different approach to updating the UI. I put "waste" in quotes because sometimes paying for a more productive and simpler system with higher resource consumption is the right thing to do. But in other cases it is not.
iainmerrick 10y ago
I agree with you, but just to play devil's advocate, don't forget that Apple spent a lot of time and effort on toll-free bridging between Objective-C and Java back in the day. Java was close to a first-class citizen on OS X and could even have eventually supplanted Obj-C (despite lacking some key features). Then Apple decided they didn't like Java any more, and running Java on OS X has been increasingly painful ever since. I don't mean Swift would be ditched, if an analogous situation arose; rather, Apple could very easily decide to axe Obj-C if they don't feel like supporting it any more. They don't care at all about sunk costs (correctly, in most cases).
- Kurtz79 10y ago
  The obvious difference is that Apple had absolutely no control on Java's evolution as a language, that is clearly not the case with Swift.
- fauigerzigerk 10y ago
  Toll-free bridging between a runtime that uses a tracing GC and one that doesn't share that exact same tracing GC is impossible. It's just a desperate stop gap. Of course Apple could theoretically ditch Swift or Objective-C or replace both something else. But there is zero indication of any such intention.
  - iainmerrick 10y ago
    Yeah, the point I was trying to make is just that Apple could easily decide to ditch Objective-C in the relatively near future. From our point of view as developers, there are good reasons not to, like maintaining backwards compatibility and keeping developers happy, but Apple generally seems to ignore those issues. Not that they actually want developers to be unhappy, they just expect and require them to fall in line. (Or they could ditch Swift too and go with something entirely new and crazy, but that seems too unlikely even for me) Edit to clarify: I think what they do care about is technical issues, and giving themselves the tools to make the slick products they want to make. And their technical strategy is generally pretty sound -- look at their balanced CPU+GPU designs on iOS, for example, both faster and more power-efficient than the ludicrous octo-cores and oversized screens you get on "flagship" Android devices. To me, making Swift and Objective-C interoperable was a smart decision to give themselves (and coincidentally their developers) a smooth migration path. They also think that reference-counting is better than tracing GC for the types of applications they care about (and I think they're correct). But nothing in that says they care about keeping Objective-C around indefinitely.
pjmlp 10y ago
> He's missing a crucial piece of evidence. Apple has done a lot of work to make sure that Swift and Objective-C can coexist in same project. You can call Swift code from Objective-C and Objective-C code from Swift with little fuss. This is completely unlike Microsoft's C++/.NET situation. How come?!? That is exactly what C++/CLI for .NET, and C++/CX for UWP applications are for.
- fauigerzigerk 10y ago
  .NET came with massive additional resource consumption, with its very own comprehensive system API and with an entirely different resource management paradigm. Adding it to an average C++ program back in 2000 would have been utter madness and I don't think it was ever what Microsoft intended as the standard use case for .NET. Also, C++/CLI is not the language in which most people want to write .NET software, nor is it C++. It introduces an entirely new pointer syntax just to deal with resources that don't work with RAII. Its very existence proves that there is a huge gap to bridge. You simply cannot smoothly and efficiently use a library written in a language that comes with a tracing GC from another language/runtime. That's why we have all those isolated library ecosystems for Java, JavaScript, .NET, etc. Microsoft already had exactly the right technology to build on back in 2000. COM was a simple idea that would have stood the test of time as the basis for multiple language runtimes that can share a library ecosystem efficiently. But they decided to ape Java and balkanize their OS APIs. Now they are busy undoing the catastrophic damage they did to Win32. It's a huge mess, nothing ever sticks, nothing is ever coherent enough to be blievable, trust in their APIs has been eroded so much it hardly exists at all any more.
  - pjmlp 10y ago
    > Adding it to an average C++ program back in 2000 would have been utter madness and I don't think it was ever what Microsoft intended as the standard use case for .NET. Yet that was exactly what I was doing in 2001. Using C++/CLI predecessor, Managed C++, to create .NET components that exposed a RPC library written in C, which was the backbone of all distributed software developed by employer at the time. All the remaining layers were written in VB.NET and C#, using those components. > You simply cannot smoothly and efficiently use a library written in a language that comes with a tracing GC from another language/runtime. Yes you can, otherwise I and many other Windows devs wouldn't be using C++/CLI and C++/CX on our applications. > Microsoft already had exactly the right technology to build on back in 2000. COM was a simple idea that would have stood the test of time as the basis for multiple language runtimes that can share a library ecosystem efficiently. They never thrown it away, .NET embraced COM, allowing its consumption and exposing .NET classes as COM objects. Since Windows XP, the majority of the new APIs are COM based not Win32. Also UWP is just the COM+ Runtime brought back to life, but using .NET metadata instead of COM type libraries. > . It's a huge mess, nothing ever sticks, nothing is ever coherent enough to be blievable, trust in their APIs has been eroded so much it hardly exists at all any more. I can provide similar examples for Oracle, IBM, Apple and Google if you wish.

glhaynes 10y ago

I'm least clear about whether a clean break with Cocoa will be needed. Perhaps most parts of Cocoa that don't match well with Swift will just be given more natural-feeling replacements? Obviously this can be complicated by dependencies, though.

Someone 10y ago
That would almost certainly lead to a break with Cocoa. Those, for Swift programmers, more natural-feeling replacements will be harder to call from Objective-C than an API designed for Objective-C would be. The only way to make neither side unhappy about it would be to provide two 100% equivalent interfaces, one for Cocoa and one for Carbon. That is unfeasible, so there will be differences. Even if they manage to write functionally and preformance-wise identical interfaces, not shipping them at the exact same time still would make the other side feel discriminated against. I expect the first Swift-only library to appear on iOS because, on that platform, Apple can know exactly how much new code uses which language. That makes timing the transition easier. I also expect people to write glue code to call it from Objective-C, but that will be a rear-guard action. A few years after that, I expect Apple to drop Cocoa. Deep below Swift, all the core stuff such as strings will still use the same code, but that will be hidden behind a Swift interface. After all, this is Apple, a company that isn't afraid to drop backwards compatibility. This is what happened with Carbon and Cocoa, too (how many years did that take?) It won't happen overnight, though. Swift first needs to gain a few features (dynamism, more reflection, a frozen ABI, to mention a few), and the tooling must mature. I think the first feature breaking interoperability with Objective-C may be a borrow checker, as that is something they have expressed interest in.

rtpg 10y ago

I think Python is a good example of how things can happen. Python's standard library includes a lot of pretty frustrating libraries, but offers a lot of low-level functionality. So people can easily write wrapper libraries with more "pythonic" usage. Think about requests vs. urllib (though technically requests' backend can be replaced). I can imagine that Apple could write Swift libraries that are more idiomatic to the language by just wrapping Cocoa stuff. I mean, React Native can exist, so why can't this?

masklinn 10y ago
> a lot of low-level functionality. So people can easily write wrapper libraries with more "pythonic" usage. Think about requests vs. urllib (though technically requests' backend can be replaced). To my knowledge, requests is implemented on top of urllib3 (a third-party library from which it gets most of its advanced feature), not the stdlib's urllib or urllib2.
- rtpg 10y ago
  Ah, I stand corrected. It seems like urllib3 uses Python's socket library stuff though? I guess that part of the code isn't the trickiest part.
fauigerzigerk 10y ago
I agree that wrapping can and does work in most cases. But then there are times when it doesn't work without introducing a lot of complexity and/or inefficiency or without limiting design choices. How will the new concurrency/parallelism facilities they are planning for Swift work with libdispatch queues? Will they want to build on GCD or not? Will whatever they do work for Objective-C just as conveniently? That's an open question in my view. For an example why wrapping cannot work efficiently in all cases look no further than Python 2 vs Python 3 strings. They are conceptually too different. With enough "waste" of resources everything can be wrapped. I don't know how React Native works. But React.js uses a virtual DOM that effectively doubles memory usage. That's what gives them the freedom to use a completely different approach to updating the UI. I put "waste" in quotes because sometimes paying for a more productive and simpler system with higher resource consumption is the right thing to do. But in other cases it is not.

iainmerrick 10y ago

I agree with you, but just to play devil's advocate, don't forget that Apple spent a lot of time and effort on toll-free bridging between Objective-C and Java back in the day. Java was close to a first-class citizen on OS X and could even have eventually supplanted Obj-C (despite lacking some key features). Then Apple decided they didn't like Java any more, and running Java on OS X has been increasingly painful ever since. I don't mean Swift would be ditched, if an analogous situation arose; rather, Apple could very easily decide to axe Obj-C if they don't feel like supporting it any more. They don't care at all about sunk costs (correctly, in most cases).

Kurtz79 10y ago
The obvious difference is that Apple had absolutely no control on Java's evolution as a language, that is clearly not the case with Swift.
fauigerzigerk 10y ago
Toll-free bridging between a runtime that uses a tracing GC and one that doesn't share that exact same tracing GC is impossible. It's just a desperate stop gap. Of course Apple could theoretically ditch Swift or Objective-C or replace both something else. But there is zero indication of any such intention.
- iainmerrick 10y ago
  Yeah, the point I was trying to make is just that Apple could easily decide to ditch Objective-C in the relatively near future. From our point of view as developers, there are good reasons not to, like maintaining backwards compatibility and keeping developers happy, but Apple generally seems to ignore those issues. Not that they actually want developers to be unhappy, they just expect and require them to fall in line. (Or they could ditch Swift too and go with something entirely new and crazy, but that seems too unlikely even for me) Edit to clarify: I think what they do care about is technical issues, and giving themselves the tools to make the slick products they want to make. And their technical strategy is generally pretty sound -- look at their balanced CPU+GPU designs on iOS, for example, both faster and more power-efficient than the ludicrous octo-cores and oversized screens you get on "flagship" Android devices. To me, making Swift and Objective-C interoperable was a smart decision to give themselves (and coincidentally their developers) a smooth migration path. They also think that reference-counting is better than tracing GC for the types of applications they care about (and I think they're correct). But nothing in that says they care about keeping Objective-C around indefinitely.

pjmlp 10y ago

> He's missing a crucial piece of evidence. Apple has done a lot of work to make sure that Swift and Objective-C can coexist in same project. You can call Swift code from Objective-C and Objective-C code from Swift with little fuss. This is completely unlike Microsoft's C++/.NET situation. How come?!? That is exactly what C++/CLI for .NET, and C++/CX for UWP applications are for.

fauigerzigerk 10y ago
.NET came with massive additional resource consumption, with its very own comprehensive system API and with an entirely different resource management paradigm. Adding it to an average C++ program back in 2000 would have been utter madness and I don't think it was ever what Microsoft intended as the standard use case for .NET. Also, C++/CLI is not the language in which most people want to write .NET software, nor is it C++. It introduces an entirely new pointer syntax just to deal with resources that don't work with RAII. Its very existence proves that there is a huge gap to bridge. You simply cannot smoothly and efficiently use a library written in a language that comes with a tracing GC from another language/runtime. That's why we have all those isolated library ecosystems for Java, JavaScript, .NET, etc. Microsoft already had exactly the right technology to build on back in 2000. COM was a simple idea that would have stood the test of time as the basis for multiple language runtimes that can share a library ecosystem efficiently. But they decided to ape Java and balkanize their OS APIs. Now they are busy undoing the catastrophic damage they did to Win32. It's a huge mess, nothing ever sticks, nothing is ever coherent enough to be blievable, trust in their APIs has been eroded so much it hardly exists at all any more.
- pjmlp 10y ago
  > Adding it to an average C++ program back in 2000 would have been utter madness and I don't think it was ever what Microsoft intended as the standard use case for .NET. Yet that was exactly what I was doing in 2001. Using C++/CLI predecessor, Managed C++, to create .NET components that exposed a RPC library written in C, which was the backbone of all distributed software developed by employer at the time. All the remaining layers were written in VB.NET and C#, using those components. > You simply cannot smoothly and efficiently use a library written in a language that comes with a tracing GC from another language/runtime. Yes you can, otherwise I and many other Windows devs wouldn't be using C++/CLI and C++/CX on our applications. > Microsoft already had exactly the right technology to build on back in 2000. COM was a simple idea that would have stood the test of time as the basis for multiple language runtimes that can share a library ecosystem efficiently. They never thrown it away, .NET embraced COM, allowing its consumption and exposing .NET classes as COM objects. Since Windows XP, the majority of the new APIs are COM based not Win32. Also UWP is just the COM+ Runtime brought back to life, but using .NET metadata instead of COM type libraries. > . It's a huge mess, nothing ever sticks, nothing is ever coherent enough to be blievable, trust in their APIs has been eroded so much it hardly exists at all any more. I can provide similar examples for Oracle, IBM, Apple and Google if you wish.