Why look at collection classes? Well, after reading a bit about the language syntax and writing “Hello World”, I think the next thing you should learn about a language/framework is its Collections classes. Its one of the things that makes programming in a higher than C level language more powerful. Its also one of the most basic. You’ll find that the other parts of your chosen framework whether it is Cocoa, Eclipse, Rails, or whatever, uses these collection classes heavily.
Also, I’ve been writing code in these different languages, so I’m using this to help me get straight what the APIs are like for each collection class. Hopefully this will help you out if you’re transitioning from one language to another.
Let’s see what each language has to offer in terms of the 3 basics: OrderedCollection, Dictionary, and Set. Dictionary holds key/value pairs and Set holds unordered, unindexed, unique objects. I’m using the Smalltalk class names as the canonical names, since it is the GrandDaddy of all object-oriented languages.
|OrderedCollection||List – ArrayList||NSArray / NSMutableArray||Array||List||IList – List|
|Dictionary||Map – HashMap||NSDictionary / NSMutableDictionary||Hash||Dictionary||IDictionary – Dictionary|
|Set||Set – HashSet||NSSet / NSMutableSet||Set ||?||?|
Some brief thoughts on the language differences:
Objective-C / Cocoa, though more specifically the Foundation Kit, which is the non-UI related frameworks, offers immutable and mutable versions of each collection. This is unique and seems like a premature optimization at first. However, if you’ve ever read Josh Bloch’s Effective Java, you’ll realize that he recommends using immutable objects whenever possible, to reduce errors and ensure type-safety.
Also, all the Foundation Kit classes start with “NS”, which stands for NeXTStep. This is a workaround for not having namespaces as part of the language.
Java has a strict separation of interface and implementation. This is nice in one sense, but cumbersome in another. Its too bad you can’t just say new List() and have a factory that you configure in your application that tells you when to instantiate which implementation.
Also, Java has the largest and thus hardest to memorize collections API. There are multiple implementations of each interface. I included the ones that should be used by default for most cases. There are old versions of APIs (Vector and Hashtable) which tend to confuse veterans who used to use them and beginners alike. There are typesafe (Java 5/1.5 only) and non-typesafe versions (which involve casting.) Before Java 1.5, many programmers would just use typed arrays to get type safety. There’s also immutable versions of collections, but these are not protected via API, instead they throw UnsupportedOperationExceptions at run-time.
Java and C# have type-safe at compile-time collections. This is both good and bad, but in my opinion, it is rarely a problem in practice with the dynamically-typed languages. In general, C# seems to behave similarly to Java.
 UPDATE: Set available for Ruby as part of the Standard Library. Thanks to John Labovitz for pointing this out.