3 ms·

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 b

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.
- iainmerrick 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. And another thing! I assume this is referring to Java and Obj-C. There's an alternate-universe proposal where this could have worked: Apple did actually briefly flirt with adding a traditional GC to Obj-C. If that had been successful, they could have essentially imported the Java memory model into Obj-C. However, the GC wasn't popular and was supplanted by Automatic Reference Counting. I'm not sure if that's what anyone actually had in mind (I can't recall when the Java bridge and Obj-C GC started and stopped) but I think it would have been technically feasible. I'd guess the iPhone would be very different in that world, or at least delayed, because GC has higher memory requirements and collector pauses make it hard to maintain a smooth UI. But you can make something like an iPhone using mostly Java, as Google proved with Android (eventually!)

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.
iainmerrick 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. And another thing! I assume this is referring to Java and Obj-C. There's an alternate-universe proposal where this could have worked: Apple did actually briefly flirt with adding a traditional GC to Obj-C. If that had been successful, they could have essentially imported the Java memory model into Obj-C. However, the GC wasn't popular and was supplanted by Automatic Reference Counting. I'm not sure if that's what anyone actually had in mind (I can't recall when the Java bridge and Obj-C GC started and stopped) but I think it would have been technically feasible. I'd guess the iPhone would be very different in that world, or at least delayed, because GC has higher memory requirements and collector pauses make it hard to maintain a smooth UI. But you can make something like an iPhone using mostly Java, as Google proved with Android (eventually!)