The way this argument is going is a very eloquent "he said, he said". I'd like to push it into a better discussion. Could you drop the rhetoric about "parroti

The way this argument is going is a very eloquent "he said, he said". I'd like to push it into a better discussion. Could you drop the rhetoric about "parroting the WWDC line" and "Apple stumbling about", the ad-hominem characterizations of developers who haven't implemented a GC, etc.? I'm going to require you to provide hard facts or examples to support your claims, and not present conclusions as arguments, and not muddy the waters. > The ObjC runtime is poorly designed in part due to the fact that it fails to cleanly and adequately represent the necsessary metadata to support new features, and thus requires repeated ABI breakage as Apple stumbles about trying to implement enhancements. The ABI was "changed" once. When I say it was "changed", I really mean that the new ABI was released for the first time on new architectures that did not previously have an ABI at all, and the old architectures' ABI did not change. Assuming that your objection to ABI "breakage" was compatibility-based in nature, this objection would be unfounded. You have also failed to make a claim that any particular feature is both useful and unimplementable, and also failed to support such a claim. Please make and support claims, not conclusions. > As for accepting Apple's assertions about GC at face value -- this is the same organization that proudly trumpeted their poor implementation of GC at WWDCs past, and migrated their entire set of Mac OS frameworks to support it. To be fair, garbage collection was released before iOS was released. Apple's position is today, and has always been, that garbage collection is infeasible on iOS. What has changed between 2006 and 2012 is that it now makes a lot of sense from both a developer mindshare point of view and an Apple engineer cost/benefit point of view to make Mac OS be as close to iOS as possible, because that's where the money is. There are very good reasons why (e.g. non-deterministic finalization) it is impossible to share code and illogical to share engineers between ARC and GC codebases. > GC at Apple died because of a poor implementation, political fallout from it, and lack of adequate investment in it. This contradiction is baseless (e.g. unsupported), so on that basis I am not compelled to respond. It also contradicts my discussions with engineers who were involved in the decision, so if you were to provide a basis, I have first-hand accounts with which to refute you. > Regardless of that, Apple should be capable of bringing more computer science firepower to this problem than Mono is. And here is the fundamental disconnect: you believe that currently-known GC algorithms are "good enough" for general use on iOS. I do not. Apple does not. Thinking it through logically, there are three possible root causes for this disagreement: 1. You and I could have a different conception of the hardware capabilities of iOS devices 2. You and I could have a different conception of the performance characteristics for currently-known GC algorithms 3. You and I could have a different threshold for user pain, so you might characterize a certain performance penalty as "acceptable" that I would characterize as "unacceptable." We've danced a little bit around #1 and #2, and we can talk some more about those. But I think the real issue might be #3. For example, the native screen refresh rate is 60fps. I would consider it unacceptable to skip five consecutive frames, and unacceptable to skip more than 15 frames as a sustained average over many seconds. Mono documents "major collections" to take a second, which fails both criteria. [1] I would also consider it unacceptable that, upon returning to the run loop (or equivalent common synchronization point), more than 15% of garbage bytes remain uncollected. There's just not that much memory to go around. At this point, I have laid out in very specific detail what I mean by "performs acceptably". Now, you can either A) tell me that my demands are insane, in which case we simply have a very different idea of what "responsive user interface" means, and there's really nothing more to be said to convince the other. Or, B) demonstrate that there exists some GC implementation which fulfills these requirements, and additionally demonstrate that it cannot be implemented with the current ObjC runtime. I think this is the the healthiest way forward for the discussion, because it leaves open the possibility that we may learn something. If instead we return to the things I listed in the first paragraph, I think we both have better uses of our time. [1] http://android.xamarin.com/index.php?title=Documentation/GC http://android.xamarin.com/index.php?title=Documentation/GC