5 ms·

I'm largely in agreement with Gruber insofar as development environments are largely a matter of taste. On the other hand, I'm rather surprised that Gruber is

I'm largely in agreement with Gruber insofar as development environments are largely a matter of taste. On the other hand, I'm rather surprised that Gruber is looking to defend reference counting, especially in light of how well it went for legacy programming languages like VB Classic. John Siracusa is by far the more well-reasoned Apple advocate in terms of programming language design and his Copland 2010 articles are definitely worth checking out if you want to read a cogent argument as to why Cocoa is NOT the way of the future. http://arstechnica.com/apple/news/2010/06/copland-2010-revisited.ars http://arstechnica.com/apple/news/2010/06/copland-2010-revis...

wmobit 15y ago
Note the 'Automatic' qualifier on reference counting
pohl 15y ago
On the other hand, I'm rather surprised that Gruber is looking to defend reference counting I suspect that you're not up to speed on some things that were revealed at WWDC this year, because "reference counting" and "automated reference counting" are not the same things. The latter is in the spirit of the last few paragraphs by Linus Torvalds in his famous 2002 discussion of Garbage Collection, when he says Does it take more effort? Yes. The advantage of GC is that it is automatic. But CG apologists should just admit that it causes bad problems and often _encourages_ people to write code that performs badly. I really think it's the mindset that is the biggest problem. A GC system with explicitly visible reference counts (and immediate freeing) with language support to make it easier to get the refcounts right (things like automatically incrementing the refcounts when passing the object off to others) wouldn't necessarily be painful to use, and would clearly offer all the advantages of just doing it all by hand. http://news.ycombinator.com/item?id=2473932 http://news.ycombinator.com/item?id=2473932 ...except ARC is better than Linus was imagining in the above, because it manages to do it without the "explicitly visible" part. http://clang.llvm.org/docs/AutomaticReferenceCounting.html http://clang.llvm.org/docs/AutomaticReferenceCounting.html Since you're a Siracusa fan... http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.ars/11 http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.a...
- smikhanov 15y ago
  except ARC is better than Linus was imagining in the above, because it manages to do it without the "explicitly visible" part I haven't read the article you're linking, but how does ARC manage to keep this invisible? The usual trouble is supporting legacy code. Even with C++/Boost, where there's a variety of _ptr templates each promising either automatic deletion or automatic reference count decrement at an appropriate time, you can find yourself in a situation where there's a legacy C function accepting and returning, say, wchar_t*. You simply cannnot avoid doing malloc/free or retain/release in this situation.
  - pohl 15y ago
    ARC handles this by being something you can choose in a per-compilation-unit basis, and by providing functions/macros for working with these legacy libraries. You still have to say what to do at such boundaries.
quux 15y ago
I don't think he was defending reference counting as much as trying to explain that garbage collection is probably never going to work satisfactorily with an unmanaged language like Objective-C. Automatic Reference Counting is probably as good as we're going to get without a managed version of Objective-C.
- nknight 15y ago
  This distinction between "reference counting" and "garbage collection" is either an Apple or Gruber invention. I've never heard anyone try to distinguish cleanly between the two before. Use of (automatic) reference counting is not new (see, for obvious example, Python), and is certainly being used as a form of garbage collection. There are many forms/strategies of garbage collection, reference counting is one of them. Trying to argue that we're never going to have "garbage collection" on iOS is utterly bizarre -- it's being added in iOS 5! It's just taking a different form.
  - schrototo 15y ago
    Well, I think the generally agreed upon meaning of "garbage collection" is something along the lines of "automatic memory management at runtime" (garbage piles up and gets collected) while "automatic reference counting" is "automatic memory management at compile time" (there's nothing to collect since nothing's gonna build up). All those terms sometimes get used differently in different contexts sometimes, but I think that's what's usually meant by them.
    - nknight 15y ago
      You're describing the difference between deterministic and non-deterministic garbage collection, not between garbage collection and some other concept. Even non-deterministic tracing garbage collectors may make use of reference counting. Some interesting references: http://en.wikipedia.org/wiki/Garbage_collection_(computer_science) http://en.wikipedia.org/wiki/Garbage_collection_(computer_sc... http://www.research.ibm.com/people/d/dfb/papers/Bacon01Concurrent.pdf http://www.research.ibm.com/people/d/dfb/papers/Bacon01Concu... http://www.google.com/search?q=garbage%20collection%20reference%20counting http://www.google.com/search?q=garbage%20collection%20refere...
donmcc 15y ago
I think Gruber would elaborate by mentioning that garbage collection has a real and measurable cost in terms of performance and Apple would rather have a development environment that allows devs to produce the smoothest UI performance over one like Java or C# that is novice friendly but harder to get the highest level of performance out of. Personally I really enjoy working in Objective-C and Cocoa/Cocoa Touch. I think they both hit sweet spots in language/framework design and give you just enough high level abstractions to make developing easier without getting in the way. But then again, I program in C for fun :-)
davedx 15y ago
You're surprised that Gruber is defending Apple?
msbarnett 15y ago
ARC is reference counting in only the most literal sense; the compiler assumes all responsibility for managing reference increments/decrements and ensuring things are destroyed as soon as they are no longer referenced. It's garbage collection without any of the nasty downsides. And Siracusa has been trotting out his pet theory about Objective-C/Cocoa being a dead end for years now. All of the articles he's written on the subject have made it clear that a) he has essentially no experience with the subject he is trying to discuss, and b) he's really, really bad at predicting the future of Apple's development landscape. Since his first article calling Objective-C/Cocoa a dying platform, we've witnessed the introduction of an entirely new platform based on them (iOS), an enormous surge in usage and demand for Objective-C talent, and massive overhauls in the language (Objective-C 2.0) and memory model (first a conservative garbage collector, and now ARC). Siracusa has been out to lunch on the subject for years.
- chc 15y ago
  It's also garbage collection without many of the upsides — for example, normal garbage collection supports concurrency better than reference counting does, and circular references trip up ARC but not a proper garbage collector.
  - strmpnk 15y ago
    I don't see how the concurrency claim makes any sense. Many concurrency primitives revolve around counts (for example, a semaphore). Likewise, GC may be able to deal with messy situations (ones that I'd advise you avoid anyway), but brings problems too like non-deterministic lifetimes. ARC isn't a silver bullet but I think it gets pretty close to how people use GC in day to day software.
    - chc 15y ago
      With reference counting, each strong assignment has to alter at least one object's reference count in a thread-safe manner. With garbage collection, you can just assign — a fast, atomic operation. Also, one of those "messy situations" that you'd advise us to avoid is the nigh-ubiquitous Cocoa controller-delegate pattern. That's a circular reference. With ARC, you have to explicitly break it. It's not a big darn in general, but it's a definite weakness of retain counting. My point is that it's a massive hyperbole to call ARC "garbage collection without any of the nasty downsides."

wmobit 15y ago

Note the 'Automatic' qualifier on reference counting

pohl 15y ago

On the other hand, I'm rather surprised that Gruber is looking to defend reference counting I suspect that you're not up to speed on some things that were revealed at WWDC this year, because "reference counting" and "automated reference counting" are not the same things. The latter is in the spirit of the last few paragraphs by Linus Torvalds in his famous 2002 discussion of Garbage Collection, when he says Does it take more effort? Yes. The advantage of GC is that it is automatic. But CG apologists should just admit that it causes bad problems and often _encourages_ people to write code that performs badly. I really think it's the mindset that is the biggest problem. A GC system with explicitly visible reference counts (and immediate freeing) with language support to make it easier to get the refcounts right (things like automatically incrementing the refcounts when passing the object off to others) wouldn't necessarily be painful to use, and would clearly offer all the advantages of just doing it all by hand. http://news.ycombinator.com/item?id=2473932 http://news.ycombinator.com/item?id=2473932 ...except ARC is better than Linus was imagining in the above, because it manages to do it without the "explicitly visible" part. http://clang.llvm.org/docs/AutomaticReferenceCounting.html http://clang.llvm.org/docs/AutomaticReferenceCounting.html Since you're a Siracusa fan... http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.ars/11 http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.a...

smikhanov 15y ago
except ARC is better than Linus was imagining in the above, because it manages to do it without the "explicitly visible" part I haven't read the article you're linking, but how does ARC manage to keep this invisible? The usual trouble is supporting legacy code. Even with C++/Boost, where there's a variety of _ptr templates each promising either automatic deletion or automatic reference count decrement at an appropriate time, you can find yourself in a situation where there's a legacy C function accepting and returning, say, wchar_t*. You simply cannnot avoid doing malloc/free or retain/release in this situation.
- pohl 15y ago
  ARC handles this by being something you can choose in a per-compilation-unit basis, and by providing functions/macros for working with these legacy libraries. You still have to say what to do at such boundaries.

quux 15y ago

I don't think he was defending reference counting as much as trying to explain that garbage collection is probably never going to work satisfactorily with an unmanaged language like Objective-C. Automatic Reference Counting is probably as good as we're going to get without a managed version of Objective-C.

nknight 15y ago
This distinction between "reference counting" and "garbage collection" is either an Apple or Gruber invention. I've never heard anyone try to distinguish cleanly between the two before. Use of (automatic) reference counting is not new (see, for obvious example, Python), and is certainly being used as a form of garbage collection. There are many forms/strategies of garbage collection, reference counting is one of them. Trying to argue that we're never going to have "garbage collection" on iOS is utterly bizarre -- it's being added in iOS 5! It's just taking a different form.
- schrototo 15y ago
  Well, I think the generally agreed upon meaning of "garbage collection" is something along the lines of "automatic memory management at runtime" (garbage piles up and gets collected) while "automatic reference counting" is "automatic memory management at compile time" (there's nothing to collect since nothing's gonna build up). All those terms sometimes get used differently in different contexts sometimes, but I think that's what's usually meant by them.
  - nknight 15y ago
    You're describing the difference between deterministic and non-deterministic garbage collection, not between garbage collection and some other concept. Even non-deterministic tracing garbage collectors may make use of reference counting. Some interesting references: http://en.wikipedia.org/wiki/Garbage_collection_(computer_science) http://en.wikipedia.org/wiki/Garbage_collection_(computer_sc... http://www.research.ibm.com/people/d/dfb/papers/Bacon01Concurrent.pdf http://www.research.ibm.com/people/d/dfb/papers/Bacon01Concu... http://www.google.com/search?q=garbage%20collection%20reference%20counting http://www.google.com/search?q=garbage%20collection%20refere...

donmcc 15y ago

I think Gruber would elaborate by mentioning that garbage collection has a real and measurable cost in terms of performance and Apple would rather have a development environment that allows devs to produce the smoothest UI performance over one like Java or C# that is novice friendly but harder to get the highest level of performance out of. Personally I really enjoy working in Objective-C and Cocoa/Cocoa Touch. I think they both hit sweet spots in language/framework design and give you just enough high level abstractions to make developing easier without getting in the way. But then again, I program in C for fun :-)

davedx 15y ago

You're surprised that Gruber is defending Apple?

msbarnett 15y ago

ARC is reference counting in only the most literal sense; the compiler assumes all responsibility for managing reference increments/decrements and ensuring things are destroyed as soon as they are no longer referenced. It's garbage collection without any of the nasty downsides. And Siracusa has been trotting out his pet theory about Objective-C/Cocoa being a dead end for years now. All of the articles he's written on the subject have made it clear that a) he has essentially no experience with the subject he is trying to discuss, and b) he's really, really bad at predicting the future of Apple's development landscape. Since his first article calling Objective-C/Cocoa a dying platform, we've witnessed the introduction of an entirely new platform based on them (iOS), an enormous surge in usage and demand for Objective-C talent, and massive overhauls in the language (Objective-C 2.0) and memory model (first a conservative garbage collector, and now ARC). Siracusa has been out to lunch on the subject for years.

chc 15y ago
It's also garbage collection without many of the upsides — for example, normal garbage collection supports concurrency better than reference counting does, and circular references trip up ARC but not a proper garbage collector.
- strmpnk 15y ago
  I don't see how the concurrency claim makes any sense. Many concurrency primitives revolve around counts (for example, a semaphore). Likewise, GC may be able to deal with messy situations (ones that I'd advise you avoid anyway), but brings problems too like non-deterministic lifetimes. ARC isn't a silver bullet but I think it gets pretty close to how people use GC in day to day software.
  - chc 15y ago
    With reference counting, each strong assignment has to alter at least one object's reference count in a thread-safe manner. With garbage collection, you can just assign — a fast, atomic operation. Also, one of those "messy situations" that you'd advise us to avoid is the nigh-ubiquitous Cocoa controller-delegate pattern. That's a circular reference. With ARC, you have to explicitly break it. It's not a big darn in general, but it's a definite weakness of retain counting. My point is that it's a massive hyperbole to call ARC "garbage collection without any of the nasty downsides."