Objective-C (Cocoa Foundation):

[editedTweet replaceOccurrencesOfString:@"foo" withString:@"bar" options:0 range:NSMakeRange(0, [editedTweet length] - 1)];

Ruby (Core):

editedTweet.gsub(/foo/, 'bar')

The two do the same thing. Actually, the first is slightly more efficient as it doesn’t rely on regular expressions, but ignoring that, they accomplish the same thing.

In both cases, we have a variable named editedTweet. It’s an NSMutableString * in ObjC, and a String in Ruby. (Ruby has no distinction between mutable and immutable objects anywhere, if I’m not mistaken; everything’s implied to be mutable.)

In both cases, we wish to go through the entire string. In ObjC, we do this by specifying a range that goes through the entire string (by starting at index 0 and ending at the last possible index, generated by asking for the string’s length), and in Ruby, we do this with the g in gsub, standing for “global”.

Finally, we wish to replace something in the string (which is why, in ObjC’s case, we specifically need a mutable string, as it’s going to be changed). Here’s where ObjC goes all berserkly detailed, with its replaceOccurrencesOfString:withString:options:range method. By sharp contrast, Ruby calls the comparable method gsub, for “globally substitute”.

So, which is “better”? Neither. I think both styles have their strengths and weaknesses.

The ObjC code could hardly be any clearer on what it does: “send the following to editedTweet: replace occurrences of string ‘foo’ with string ‘b’, using the options 0 (none), and throughout the entire range”. In comparison, to someone unfamiliar with what “gsub” is short for, the Ruby code is quite meaningless. “gsub” happens to be a common function on many languages, but if it weren’t, this would be very unclear.

On the other hand, the Ruby code is naturally a lot faster to type, and you build some good muscle memory for when you need this kind of function often, which you very well might. Sure, there’s autocomplete in just about any reasonable text editor or full-fledged IDE, but autocomplete is never quite as fast as typing just a few short characters, assuming you know exactly what those characters are going to be.

And either method also has its own sorts of flexibility that each other lacks. The ObjC one has various “options”, such as case-insensitive searching, and of course the ability to set a more specific “range”. Ruby, however, offers a complete regular expression implementation here, which of course also lets you do case-insensitiveness, and lots of other nifty things you could never do in the ObjC method, and which you’d need a wholly different method for.

With 10.5 Leopard, it seems we’ll be able to mix and match Ruby and Objective-C code in Cocoa, though to what extent is still unclear to me. If it’s true that you can just place a piece of Ruby code inside an otherwise ObjC file, that would completely do away with the above problem; you could simply choose whichever language is more suitable, while in one and the same block of code. Could it be?