5 ms·

I thought the GC point was kind of interesting seeing as Objective C does/did have Garbage Collection (if you're an OS X developer). It's been deprecated and AR

I thought the GC point was kind of interesting seeing as Objective C does/did have Garbage Collection (if you're an OS X developer). It's been deprecated and ARC is the replacement. There's been a bit of discussion about this in the past. Maybe if the first iPhone had come with the same hardware we're looking at today the story would be different but I tend to agree with the reasoning behind not supporting GC on iDevices. I feel like the hoops (some types of) Game developers have to jump through on Android even with todays hardware is validation of Apple's reasoning. http://www.cocoabuilder.com/archive/xcode/322876-why-arc-over-garbage-collection.html http://www.cocoabuilder.com/archive/xcode/322876-why-arc-ove... http://daringfireball.net/linked/2011/09/19/the-unfamiliar http://daringfireball.net/linked/2011/09/19/the-unfamiliar http://stackoverflow.com/questions/2484079/how-can-i-avoid-garbage-collection-delays-in-java-games-best-practices?rq=1 http://stackoverflow.com/questions/2484079/how-can-i-avoid-g...

pjmlp 13y ago
Apple failed to develop a stable GC for Objective-C, there were lots of issues when linking with libraries that did not make use of it. Plus the underlying C part, didn't allow for more than a plain conservative GC. ARC works by generating the retain/release calls the developers would write anyway with NeXTStep/Cocoa framework. So while it is a good solution for Objective-C, it isn't because it thrumps GC, but rather due to Apple's failure with a stable GC.
- sdegutis 13y ago
  I would argue a step further and say that it's because Apple chose the wrong solution for an OOP language with C-compatibility. They could have invented a language more like C# for NeXTSTEP, but they chose the route with easier C compatibility. Now they're paying the cost of taking that early shortcut.
  - comex 13y ago
    It goes both ways - they're still reaping the benefits of making it very easy to interface with low-level native code, too (plus sidestepping GC variability).
  - Touche 13y ago
    They still can. All of their competitors are constantly researching new languages but we never hear a peep of any of that from Apple. Presumably the design-driven culture prevents big projects like a new language from ever getting anywhere.
    - sdegutis 13y ago
      They're making pretty significant advances with Clang and LLVM and have pretty much caught up to GCC in performance and surpassed it in usability. So they're not doing nothing, for sure. But they're pouring all that effort into Objective-C, which will still has the inherent problem of C compatibility. Granted it's evolving (i.e @import), but it can only go so far without breaking compatibility completely like C# did.
      - Touche 13y ago
        I'm talking about language design. Clang and LLVM are not languages (well, not user-written languages).
        sdegutis 13y ago
        So then I think we're on the same page: Apple's putting their money into just tooling rather than language design plus tooling.
  - Moto7451 13y ago
    Given the development timeframe for NeXTSTEP, I don't think that a managed language would have been a likely choice. Remember, this is when your average barn burner workstation came with a 33MHz 386 Class CPU and 4-8MB of memory. The NeXT Computer came with a 25MHz '030 and 8MB of memory.
    - pjmlp 13y ago
      They could, as Xerox PARC machines were not as powerful and offered: - Lisp OS - Smalltalk OS - Mesa/Cedar (a GC enabled systems programming)
- mpweiher 13y ago
  The failure to develop a stable and performant GC is part of the reason. Another part is that such a GC is very difficult for C/Objective-C (one could say impossible or close enough to it as to not make a difference). However, that's not all of it. The iOS teams wouldn't touch the GC with a 10 foot pole, even had it worked, and with good reason. As the parent poster pointed out, GCs make performance and memory consumption unpredictable, especially on memory-constrained devices. And yes, phones are memory-constrained, despite the 1/2 - 1GB of memory, because you are also managing some potentially very large assets (retina class images, ...). Especially without virtual memory, where having an unexpected spike in memory consumption can get you killed, having unpredictable memory consumption is a non-starter...and the pain you have to go through on Android to avoid GC problems is significant (for example real-time OCR via the video camera overlaid onto the video stream). It's interesting that Android appears to be moving away from JIT to AOT with libart, I am very curious as to how that works out. My guess is that at least a subset of developers, those with stringent requirements, would also welcome more predictable memory management solution.
  - pjmlp 13y ago
    True, although WP doesn't not seem to have the performance issues of Android. WP7 was full .NET with JIT. WP8 is WinRT/.NET with AOT compilation. Both seem to perform much better than Android and on par with iOS. Although I do conceded that on WP8 there is a mix of reference counting(WinRT) and GC (.NET). Google was supposed to present more information about ART at FOSDEM, but they canceled the presentation on the last minute. So still no information what they plan there, besides AOSP source code. Xerox PARC systems already had GC enabled programming languages (Cedar/Lisp/Smalltalk) and they surely were less powerful than today's phones.

pjmlp 13y ago

Apple failed to develop a stable GC for Objective-C, there were lots of issues when linking with libraries that did not make use of it. Plus the underlying C part, didn't allow for more than a plain conservative GC. ARC works by generating the retain/release calls the developers would write anyway with NeXTStep/Cocoa framework. So while it is a good solution for Objective-C, it isn't because it thrumps GC, but rather due to Apple's failure with a stable GC.

sdegutis 13y ago
I would argue a step further and say that it's because Apple chose the wrong solution for an OOP language with C-compatibility. They could have invented a language more like C# for NeXTSTEP, but they chose the route with easier C compatibility. Now they're paying the cost of taking that early shortcut.
- comex 13y ago
  It goes both ways - they're still reaping the benefits of making it very easy to interface with low-level native code, too (plus sidestepping GC variability).
- Touche 13y ago
  They still can. All of their competitors are constantly researching new languages but we never hear a peep of any of that from Apple. Presumably the design-driven culture prevents big projects like a new language from ever getting anywhere.
  - sdegutis 13y ago
    They're making pretty significant advances with Clang and LLVM and have pretty much caught up to GCC in performance and surpassed it in usability. So they're not doing nothing, for sure. But they're pouring all that effort into Objective-C, which will still has the inherent problem of C compatibility. Granted it's evolving (i.e @import), but it can only go so far without breaking compatibility completely like C# did.
    - Touche 13y ago
      I'm talking about language design. Clang and LLVM are not languages (well, not user-written languages).
      - sdegutis 13y ago
        So then I think we're on the same page: Apple's putting their money into just tooling rather than language design plus tooling.
- Moto7451 13y ago
  Given the development timeframe for NeXTSTEP, I don't think that a managed language would have been a likely choice. Remember, this is when your average barn burner workstation came with a 33MHz 386 Class CPU and 4-8MB of memory. The NeXT Computer came with a 25MHz '030 and 8MB of memory.
  - pjmlp 13y ago
    They could, as Xerox PARC machines were not as powerful and offered: - Lisp OS - Smalltalk OS - Mesa/Cedar (a GC enabled systems programming)
mpweiher 13y ago
The failure to develop a stable and performant GC is part of the reason. Another part is that such a GC is very difficult for C/Objective-C (one could say impossible or close enough to it as to not make a difference). However, that's not all of it. The iOS teams wouldn't touch the GC with a 10 foot pole, even had it worked, and with good reason. As the parent poster pointed out, GCs make performance and memory consumption unpredictable, especially on memory-constrained devices. And yes, phones are memory-constrained, despite the 1/2 - 1GB of memory, because you are also managing some potentially very large assets (retina class images, ...). Especially without virtual memory, where having an unexpected spike in memory consumption can get you killed, having unpredictable memory consumption is a non-starter...and the pain you have to go through on Android to avoid GC problems is significant (for example real-time OCR via the video camera overlaid onto the video stream). It's interesting that Android appears to be moving away from JIT to AOT with libart, I am very curious as to how that works out. My guess is that at least a subset of developers, those with stringent requirements, would also welcome more predictable memory management solution.
- pjmlp 13y ago
  True, although WP doesn't not seem to have the performance issues of Android. WP7 was full .NET with JIT. WP8 is WinRT/.NET with AOT compilation. Both seem to perform much better than Android and on par with iOS. Although I do conceded that on WP8 there is a mix of reference counting(WinRT) and GC (.NET). Google was supposed to present more information about ART at FOSDEM, but they canceled the presentation on the last minute. So still no information what they plan there, besides AOSP source code. Xerox PARC systems already had GC enabled programming languages (Cedar/Lisp/Smalltalk) and they surely were less powerful than today's phones.