4 ms·

I know this from practice, having come in halfway through a project on iOS whose code was exquisitely, terrifyingly awful. I was fine on memory management; it w

I know this from practice, having come in halfway through a project on iOS whose code was exquisitely, terrifyingly awful. I was fine on memory management; it was hunting down previous memory management errors that took up most of my time. I ended up giving up and reimplementing certain classes because it was seriously simpler than debugging the existing code. I think the issue is that trivial examples—for example, the kind you have in a blog post or comment—will invariably look simple and easy. In a non-trivial application, "four basic rules" ends up being four more things that can create bugs.

vannevar 16y ago
And this brings up a point overlooked in the article: it isn't about the time it takes to do things right, it's also about the time it takes to track down the problem when you inevitably (you ARE human after all) make a mistake. To me, that's the real value of GC, because memory allocation errors are tedious and time consuming to debug. The author is confusing 'habitual' with 'easy', and the two concepts are very distinct. And even beyond that he undervalues the debug time saved with automated GC.