4 ms·

I still use manual reference counting :) In John Oliver’s voice : “Fuck you Apple, fuck you.”

by checker659 9y ago

rimliu 9y ago
This kind of bragging sound just like "I don't read books".
- checker659 9y ago
  Does it? My bad.
- mpweiher 9y ago
  To you, maybe. But that says more about you than the OP. The tangible benefits of ARC are at best marginal, and there are downsides, which some can reasonably find more significant, and thus ARC not worthwhile. First off, "manual" reference counting is misnamed. It is at the very least "semi-automatic" and highly automatable. So how does a property declaration look with "MRC" vs. ARC? @property (nonatomic,strong) NSString *str; vs. @property (nonatomic,strong) NSString *str; Can you tell which is which? So how about use? someObject.str = @"Hello World!"; vs. someObject.str = @"Hello World!"; Can you tell which is which? In use, ARC and MRC are mostly indistinguishable, as long as you use accessors/properties for all instance variable access. You do that, right? Right? OK, so there is automatic dealloc. That's a nice convenience, but actually not intrinsically tied to ARC. How do I know? I implemented automatic dealloc for a project once. Didn't use it much after because the small effort spent on dealloc just didn't seem worth it, especially as you also had other boilerplate to implement, the coders, isEqual and hash. The one biggie was weak, which was previously handled via non-retained references, so no automatic nilling. This could actually be a pain from time to time, but really not that huge a deal and it was also never really intrinsic to ARC, as shown by Apple recently adding weak for non-ARC code. So those are/were the upsides. Not really that much. Among the downsides is a performance penalty that could be both significant and somewhat unpredictable, on the order of 50%-100% slower in realistic scenarios (in extreme cases it can be an order of magnitude or more). You could also get unexpected crashes because of retain/releases added in unexpected places. We had a crash in a method that did nothing but return 0; http://blog.metaobject.com/2014/06/compiler-writers-gone-wild-arc-madness.html http://blog.metaobject.com/2014/06/compiler-writers-gone-wil... However, for me the biggest pain point was the semantic changes in ARCed-C: what used to be warnings about an unknown message are now hard compile errors, and that seriously cramps Objective-C's style as a quick-turnaround exploratory language. And yes, I have worked with/built both significant ARC and non-ARC codebases. What's really troubling about these things (GC, ARC, Swift) is the rabid fanboyism. When GC came out, you were complete idiot and a luddite if you didn't embrace it and all its numerous warts (which were beautiful) wholeheartedly, and buy into all the BS. Then when GC was dropped and replaced by ARC: same thing. Did anyone say GC? We meant beautiful shiny ARC, you ignorant luddite. And it quickly became an incontrovertible truth that ARC was faster than "MRC", despite the fact that this wasn't so. And when people asked about it, mentioning they had measured significant slowdowns, they were quickly attacked and everything questioned, because everybody "knew" the "truth". Until a nice gentleman from Apple chimed in an confirmed. Oops. So please ratchet down the fanboy setting. Technologies have upsides and downsides. Reasonable people can differ on how they weigh the upsides and the downsides. And of course we are seeing the same, just magnified by an extraordinary amount, with Swift.
  - iainmerrick 9y ago
    What's really troubling about these things (GC, ARC, Swift) is the rabid fanboyism. When GC came out, you were complete idiot and a luddite if you didn't embrace it I don’t know how to check this, but that isn’t how I remember it at all. There was a brief flurry of interest when Apple added GC, but it never caught on. If it had been popular, Apple would have kept it. Then when ARC arrived, it was genuinely popular, and that’s why it was a lasting success. By automating the exact same retain/release/autorelease protocol that people were already doing by hand, it fit much more neatly into existing Obj-C best practices. I do partly agree with you, that Swift seems to have some problems that haven’t yet been fully resolved, but Apple are still going full steam ahead with it. It feels more like GC, but Apple are treating it like ARC.
    - saagarjha 9y ago
      > Apple are treating it like ARC That's because Swift uses ARC instead of traditional tracing garbage collection.
      - iainmerrick 9y ago
        No, that’s completely separate. What I mean is, ignore the specific technologies: Apple is treating Swift like an ideal incremental improvement (like ARC was) whereas it’s really a major change in direction that may or may not prove to be a good idea (like GC was).
    - mpweiher 9y ago
      > [GC not catching on] Well, GC was much harder to adopt, as it wasn't incremental. Either your code was GC or not. All of it. > If it had been popular, Apple would have kept it. Weeelll...I think the bigger problem with GC was that it didn't work; they never could get all the bugs out. Including the performance issues, but more significantly potentially huge leaks. Well, technically that's also performance. I also very much liked the idea of ARC, it looked exactly like what I had lobbied for, and it certainly was much better than GC, if more limited (cycles). And then I tried it and noticed (a) for my idiomatic and highly automated use of MRC, the benefits were between minimal and zero and (b) the drawbacks, particularly the stricter compiler errors, were a major PITA, and unnecessarily so. This becomes noticeable when you write TDD code in an exploratory fashion, because with the errors you have to keep 3 sites in your code up-to-date. That becomes old really fast, but I guess most people don't really do TDD (their loss!), so it's not something that's a major pain point in the community. Incidentally, someone once mailed me that they had switched some code back from ARC to MRC (partly due to what I'd written), and contrary to their expectations and previous assumptions could confirm that the difference was, in fact, negligible. > [Swift like ARC when it's more like GC] That's a good observation. Of course, Swift is a much more dramatic change than even GC ever was, and interestingly the community seems to be much more radical/rabid than Apple. For example, in the community it seems de-rigeur that you must use immutable structs whenever possible, whereas Apple's Swift book gives a few conditions where you might consider structs and then says you should use classes for everything else.
- protomyth 9y ago
  No, in a lot of circumstances the release / retain worked really well and is really understandable. It is more a point of view from folks who structured their programs in a certain way that made ARC rather unneeded. I look at it more like I know where the resources need to be or I have some very specific rules myself. It is more prevalent where you have some type of document life cycle or specific file interactions.

I still use manual reference counting :) In John Oliver’s voice : “Fuck you Apple, fuck you.”

rimliu 9y ago

This kind of bragging sound just like "I don't read books".

checker659 9y ago
Does it? My bad.
mpweiher 9y ago
To you, maybe. But that says more about you than the OP. The tangible benefits of ARC are at best marginal, and there are downsides, which some can reasonably find more significant, and thus ARC not worthwhile. First off, "manual" reference counting is misnamed. It is at the very least "semi-automatic" and highly automatable. So how does a property declaration look with "MRC" vs. ARC? @property (nonatomic,strong) NSString *str; vs. @property (nonatomic,strong) NSString *str; Can you tell which is which? So how about use? someObject.str = @"Hello World!"; vs. someObject.str = @"Hello World!"; Can you tell which is which? In use, ARC and MRC are mostly indistinguishable, as long as you use accessors/properties for all instance variable access. You do that, right? Right? OK, so there is automatic dealloc. That's a nice convenience, but actually not intrinsically tied to ARC. How do I know? I implemented automatic dealloc for a project once. Didn't use it much after because the small effort spent on dealloc just didn't seem worth it, especially as you also had other boilerplate to implement, the coders, isEqual and hash. The one biggie was weak, which was previously handled via non-retained references, so no automatic nilling. This could actually be a pain from time to time, but really not that huge a deal and it was also never really intrinsic to ARC, as shown by Apple recently adding weak for non-ARC code. So those are/were the upsides. Not really that much. Among the downsides is a performance penalty that could be both significant and somewhat unpredictable, on the order of 50%-100% slower in realistic scenarios (in extreme cases it can be an order of magnitude or more). You could also get unexpected crashes because of retain/releases added in unexpected places. We had a crash in a method that did nothing but return 0; http://blog.metaobject.com/2014/06/compiler-writers-gone-wild-arc-madness.html http://blog.metaobject.com/2014/06/compiler-writers-gone-wil... However, for me the biggest pain point was the semantic changes in ARCed-C: what used to be warnings about an unknown message are now hard compile errors, and that seriously cramps Objective-C's style as a quick-turnaround exploratory language. And yes, I have worked with/built both significant ARC and non-ARC codebases. What's really troubling about these things (GC, ARC, Swift) is the rabid fanboyism. When GC came out, you were complete idiot and a luddite if you didn't embrace it and all its numerous warts (which were beautiful) wholeheartedly, and buy into all the BS. Then when GC was dropped and replaced by ARC: same thing. Did anyone say GC? We meant beautiful shiny ARC, you ignorant luddite. And it quickly became an incontrovertible truth that ARC was faster than "MRC", despite the fact that this wasn't so. And when people asked about it, mentioning they had measured significant slowdowns, they were quickly attacked and everything questioned, because everybody "knew" the "truth". Until a nice gentleman from Apple chimed in an confirmed. Oops. So please ratchet down the fanboy setting. Technologies have upsides and downsides. Reasonable people can differ on how they weigh the upsides and the downsides. And of course we are seeing the same, just magnified by an extraordinary amount, with Swift.
- iainmerrick 9y ago
  What's really troubling about these things (GC, ARC, Swift) is the rabid fanboyism. When GC came out, you were complete idiot and a luddite if you didn't embrace it I don’t know how to check this, but that isn’t how I remember it at all. There was a brief flurry of interest when Apple added GC, but it never caught on. If it had been popular, Apple would have kept it. Then when ARC arrived, it was genuinely popular, and that’s why it was a lasting success. By automating the exact same retain/release/autorelease protocol that people were already doing by hand, it fit much more neatly into existing Obj-C best practices. I do partly agree with you, that Swift seems to have some problems that haven’t yet been fully resolved, but Apple are still going full steam ahead with it. It feels more like GC, but Apple are treating it like ARC.
  - saagarjha 9y ago
    > Apple are treating it like ARC That's because Swift uses ARC instead of traditional tracing garbage collection.
    - iainmerrick 9y ago
      No, that’s completely separate. What I mean is, ignore the specific technologies: Apple is treating Swift like an ideal incremental improvement (like ARC was) whereas it’s really a major change in direction that may or may not prove to be a good idea (like GC was).
  - mpweiher 9y ago
    > [GC not catching on] Well, GC was much harder to adopt, as it wasn't incremental. Either your code was GC or not. All of it. > If it had been popular, Apple would have kept it. Weeelll...I think the bigger problem with GC was that it didn't work; they never could get all the bugs out. Including the performance issues, but more significantly potentially huge leaks. Well, technically that's also performance. I also very much liked the idea of ARC, it looked exactly like what I had lobbied for, and it certainly was much better than GC, if more limited (cycles). And then I tried it and noticed (a) for my idiomatic and highly automated use of MRC, the benefits were between minimal and zero and (b) the drawbacks, particularly the stricter compiler errors, were a major PITA, and unnecessarily so. This becomes noticeable when you write TDD code in an exploratory fashion, because with the errors you have to keep 3 sites in your code up-to-date. That becomes old really fast, but I guess most people don't really do TDD (their loss!), so it's not something that's a major pain point in the community. Incidentally, someone once mailed me that they had switched some code back from ARC to MRC (partly due to what I'd written), and contrary to their expectations and previous assumptions could confirm that the difference was, in fact, negligible. > [Swift like ARC when it's more like GC] That's a good observation. Of course, Swift is a much more dramatic change than even GC ever was, and interestingly the community seems to be much more radical/rabid than Apple. For example, in the community it seems de-rigeur that you must use immutable structs whenever possible, whereas Apple's Swift book gives a few conditions where you might consider structs and then says you should use classes for everything else.
protomyth 9y ago
No, in a lot of circumstances the release / retain worked really well and is really understandable. It is more a point of view from folks who structured their programs in a certain way that made ARC rather unneeded. I look at it more like I know where the resources need to be or I have some very specific rules myself. It is more prevalent where you have some type of document life cycle or specific file interactions.