6 ms·

The author says "Objective-C and Swift cannot continue to coexist indefinitely." but their only supporting argument is that a multi-lingual platform is bad beca

The author says "Objective-C and Swift cannot continue to coexist indefinitely." but their only supporting argument is that a multi-lingual platform is bad because nobody will know what language to choose. This is the same charge that has been leveled against Microsoft since they don't use .NET to produce every single piece of Microsoft software. Has that somehow stopped .NET from continuing to grow? No, it has not. Off-topic: Learned a new word reading this. Lacuna ~ an unfilled space or interval; a gap. Thanks!

paulddraper 10y ago
Or JVM... Java, Groovy, Scala, Closure Will they exist "indefinitely"? Well, all language have a lifetime, but these will/have coexisted for decades.
- icpmacdo 10y ago
  Quick spelling correction I think you mean Clojure. You got me searching for a new programming language that has a namespace conflict with a programming concept :) .
  - johnny22 10y ago
    it's also a way to minify js https://developers.google.com/closure/compiler/ https://developers.google.com/closure/compiler/
  - paulddraper 10y ago
    Autocorrect....
  - vorg 10y ago
    And "Apache Groovy" since it joined the ASF 2 years ago.
- astrodust 10y ago
  Perl and Python. Ruby and Rust. It's almost as if people have more tools than they know what to do with!
- fusiongyro 10y ago
  Not exactly the same thing since Oracle isn't maintaining any of those outside Java.
edw 10y ago
It was also the name of the mind-erasing company in Eternal Sunshine of the Spotless mind. That is a much better way to learn that particular word than this content-free meth-binge of an essay.
- brennen 10y ago
  "meth-binge"? I feel like it's possible you have not known very many people on actual meth.
  - edw 10y ago
    Yes, I have known more alcoholics, heroin addicts, coke freaks, and all-around pill-poppers. I wonder if you think, my perhaps inapt essay-as-a-meth-binge-objectified metaphor aside, whether the essay was worth the length, because I am of the opinion that it was full of baseless speculation in a mode approaching paranoia.
    - brennen 10y ago
      Eh, I'm not really the target audience, being neither a (this decade) user of Apple's platforms nor a developer for same. Still, I thought it was interesting enough to justify the read. I'm interested in how problems like this play out in the broader sense, and (some) modes approaching paranoia have shown themselves to have predictive utility in recent decades.
    - xor1 10y ago
      Go take a look at the stims subreddit if you want to read an actual meth binge.
pvg 10y ago
It's an even sillier charge because the bulk of Apple's software relies on the Objective C runtime, including everything written in Swift. It's a multi-lingual platform where the new thing is (mostly) a language and one specifically designed to interoperate with the existing frameworks and runtime. The problem the article spends so much thought on feels like not much of a problem.
bangonkeyboard 10y ago
Microsoft actively maintains backward compatibility for Windows programs that are decades old. Apple reliably breaks waves of apps on a yearly schedule. You can't take one company's culture and apply it to a radically different one.
- coldtea 10y ago
  >Apple reliably breaks waves of apps on a yearly schedule. Not by suddenly stopping support for their previously sole language, so it's a moot point. At worse, they deprecate some APIs.
  - bangonkeyboard 10y ago
    The point is not moot as concerns the comparison I was responding to, and illustrates the attitude at Apple toward software and software developers, which is relevant to the topic at hand. If you are not using or targeting the latest version of Apple's releases, they do not care about you. If you do not correctly interpret the often implicit clues to their future directions, and sometimes even when you do, they will pull the rug out from under you with no compunctions. Except -- and this is really fun, thanks, Apple! -- I believe the current OSX build will no longer work as a screen saver on MacOS 10.6. It will work on 10.5, and 10.7+, though. That's because 10.6 was the one and only version of OSX in which ScreenSaverEngine required .saver bundles to use garbage collection, and the latest release of Xcode has dropped support for emitting GC-optional code entirely. So I can no longer compile a version that will run on 10.6. Also apparently the new app-store submission process requires that you set the minimum iOS version to 5.1.1 or newer if you want to include a 64-bit executable at all, despite the fact that the 32-bit executable runs just fine on iOS 3. Thanks again, Apple! Enforced obsolescence. Ain't it grand? [0] > At worse, they deprecate some APIs. That would be very surprising news to iOS developers at large, I'm sure. [0]: https://www.jwz.org/blog/2014/03/dali-clock-2-41/ https://www.jwz.org/blog/2014/03/dali-clock-2-41/
    - comex 10y ago
      Be careful - your post mixes two different types of compatibility. Compatibility between new software and old OSes is something Apple cares very little about, broadly speaking. In Apple's view, you should be on the latest OS, and if your hardware doesn't support that then you should get new hardware. This goes especially for iOS. For example, Xcode out of the box won't even let you target an iOS version older than 8.0 (late 2014), although you can target macOS down to 10.6 (2009). And Apple usually doesn't backport security updates to previous major versions of iOS, and only goes two versions back (two years) on macOS. So neither of the examples in your quote are too surprising. At the time the article was written, Apple didn't care about iOS 3 or macOS 10.6. If you want to support 'ancient' OS versions, that's your problem. On the other hand, Apple cares more about compatibility between old software and new OSes, though not nearly as much as, say, Microsoft. For example, the post mentions garbage collection. Objective-C garbage collection was never supported on iOS (2008) and was officially deprecated in 2012 with the release of ARC; Xcode stopped supporting it in 2014, but macOS continued to support existing binaries until Sierra (2016). Now, this is arguably a pretty aggressive deprecation schedule, but ObjC garbage collection had relatively little adoption throughout its life, and had a significant maintenance burden. (Among other things, in the past it was impossible to use ARC libraries in an GC app, meaning all of Apple's system frameworks had to use manual retain-release; AFAIK though this was later fixed, some time before support was removed.) In any case, Apple added a tool to Xcode that could automatically migrated most GC code to ARC. On the other hand, 32-bit binaries are still supported in macOS even though macOS has supported 64-bit CPUs since 10.4 (2005!) and required them since 10.7 (2011). I guess there was more adoption than GC, and Apple didn't want to break stuff. As usual, iOS is more aggressive: there are rumors support for 32-bit binaries on 64-bit devices will be removed in the next minor 10.x; iOS has supported 64-bit since 2013, though it currently still runs on 32-bit devices. Even so, that's >3 years for what in most cases is just a recompile. Deprecating Swift would be massively more disruptive than either of those, as migrating off it would require complete rewrites. The only analogy I can think of is Carbon, which Apple famously refused to port to 64-bit, requiring Adobe applications to have their UI layer rewritten for Cocoa. But Carbon was meant to be a transitional API since it was released with the very first version of OS X in 2001. It would be 6 years before the transition to 64-bit started, and as I said, 32-bit binaries are still supported today. The only possible reason Apple might be more aggressive with a hypothetical Swift deprecation is its relative newness and the resulting relative scarcity of existing code (but there's still a fair amount). But then, Swift has already been out for several years, and it's clearly not going to be deprecated anytime soon, given the current level of enthusiasm by Apple and others. If for some odd reason Apple decided to deprecate it, it wouldn't be for several more years, at which point there would be even more existing code.

paulddraper 10y ago

Or JVM... Java, Groovy, Scala, Closure Will they exist "indefinitely"? Well, all language have a lifetime, but these will/have coexisted for decades.

icpmacdo 10y ago
Quick spelling correction I think you mean Clojure. You got me searching for a new programming language that has a namespace conflict with a programming concept :) .
- johnny22 10y ago
  it's also a way to minify js https://developers.google.com/closure/compiler/ https://developers.google.com/closure/compiler/
- paulddraper 10y ago
  Autocorrect....
- vorg 10y ago
  And "Apache Groovy" since it joined the ASF 2 years ago.
astrodust 10y ago
Perl and Python. Ruby and Rust. It's almost as if people have more tools than they know what to do with!
fusiongyro 10y ago
Not exactly the same thing since Oracle isn't maintaining any of those outside Java.

edw 10y ago

It was also the name of the mind-erasing company in Eternal Sunshine of the Spotless mind. That is a much better way to learn that particular word than this content-free meth-binge of an essay.

brennen 10y ago
"meth-binge"? I feel like it's possible you have not known very many people on actual meth.
- edw 10y ago
  Yes, I have known more alcoholics, heroin addicts, coke freaks, and all-around pill-poppers. I wonder if you think, my perhaps inapt essay-as-a-meth-binge-objectified metaphor aside, whether the essay was worth the length, because I am of the opinion that it was full of baseless speculation in a mode approaching paranoia.
  - brennen 10y ago
    Eh, I'm not really the target audience, being neither a (this decade) user of Apple's platforms nor a developer for same. Still, I thought it was interesting enough to justify the read. I'm interested in how problems like this play out in the broader sense, and (some) modes approaching paranoia have shown themselves to have predictive utility in recent decades.
  - xor1 10y ago
    Go take a look at the stims subreddit if you want to read an actual meth binge.

pvg 10y ago

It's an even sillier charge because the bulk of Apple's software relies on the Objective C runtime, including everything written in Swift. It's a multi-lingual platform where the new thing is (mostly) a language and one specifically designed to interoperate with the existing frameworks and runtime. The problem the article spends so much thought on feels like not much of a problem.

bangonkeyboard 10y ago

Microsoft actively maintains backward compatibility for Windows programs that are decades old. Apple reliably breaks waves of apps on a yearly schedule. You can't take one company's culture and apply it to a radically different one.

coldtea 10y ago
>Apple reliably breaks waves of apps on a yearly schedule. Not by suddenly stopping support for their previously sole language, so it's a moot point. At worse, they deprecate some APIs.
- bangonkeyboard 10y ago
  The point is not moot as concerns the comparison I was responding to, and illustrates the attitude at Apple toward software and software developers, which is relevant to the topic at hand. If you are not using or targeting the latest version of Apple's releases, they do not care about you. If you do not correctly interpret the often implicit clues to their future directions, and sometimes even when you do, they will pull the rug out from under you with no compunctions. Except -- and this is really fun, thanks, Apple! -- I believe the current OSX build will no longer work as a screen saver on MacOS 10.6. It will work on 10.5, and 10.7+, though. That's because 10.6 was the one and only version of OSX in which ScreenSaverEngine required .saver bundles to use garbage collection, and the latest release of Xcode has dropped support for emitting GC-optional code entirely. So I can no longer compile a version that will run on 10.6. Also apparently the new app-store submission process requires that you set the minimum iOS version to 5.1.1 or newer if you want to include a 64-bit executable at all, despite the fact that the 32-bit executable runs just fine on iOS 3. Thanks again, Apple! Enforced obsolescence. Ain't it grand? [0] > At worse, they deprecate some APIs. That would be very surprising news to iOS developers at large, I'm sure. [0]: https://www.jwz.org/blog/2014/03/dali-clock-2-41/ https://www.jwz.org/blog/2014/03/dali-clock-2-41/
  - comex 10y ago
    Be careful - your post mixes two different types of compatibility. Compatibility between new software and old OSes is something Apple cares very little about, broadly speaking. In Apple's view, you should be on the latest OS, and if your hardware doesn't support that then you should get new hardware. This goes especially for iOS. For example, Xcode out of the box won't even let you target an iOS version older than 8.0 (late 2014), although you can target macOS down to 10.6 (2009). And Apple usually doesn't backport security updates to previous major versions of iOS, and only goes two versions back (two years) on macOS. So neither of the examples in your quote are too surprising. At the time the article was written, Apple didn't care about iOS 3 or macOS 10.6. If you want to support 'ancient' OS versions, that's your problem. On the other hand, Apple cares more about compatibility between old software and new OSes, though not nearly as much as, say, Microsoft. For example, the post mentions garbage collection. Objective-C garbage collection was never supported on iOS (2008) and was officially deprecated in 2012 with the release of ARC; Xcode stopped supporting it in 2014, but macOS continued to support existing binaries until Sierra (2016). Now, this is arguably a pretty aggressive deprecation schedule, but ObjC garbage collection had relatively little adoption throughout its life, and had a significant maintenance burden. (Among other things, in the past it was impossible to use ARC libraries in an GC app, meaning all of Apple's system frameworks had to use manual retain-release; AFAIK though this was later fixed, some time before support was removed.) In any case, Apple added a tool to Xcode that could automatically migrated most GC code to ARC. On the other hand, 32-bit binaries are still supported in macOS even though macOS has supported 64-bit CPUs since 10.4 (2005!) and required them since 10.7 (2011). I guess there was more adoption than GC, and Apple didn't want to break stuff. As usual, iOS is more aggressive: there are rumors support for 32-bit binaries on 64-bit devices will be removed in the next minor 10.x; iOS has supported 64-bit since 2013, though it currently still runs on 32-bit devices. Even so, that's >3 years for what in most cases is just a recompile. Deprecating Swift would be massively more disruptive than either of those, as migrating off it would require complete rewrites. The only analogy I can think of is Carbon, which Apple famously refused to port to 64-bit, requiring Adobe applications to have their UI layer rewritten for Cocoa. But Carbon was meant to be a transitional API since it was released with the very first version of OS X in 2001. It would be 6 years before the transition to 64-bit started, and as I said, 32-bit binaries are still supported today. The only possible reason Apple might be more aggressive with a hypothetical Swift deprecation is its relative newness and the resulting relative scarcity of existing code (but there's still a fair amount). But then, Swift has already been out for several years, and it's clearly not going to be deprecated anytime soon, given the current level of enthusiasm by Apple and others. If for some odd reason Apple decided to deprecate it, it wouldn't be for several more years, at which point there would be even more existing code.