I actually find it much harder to read as a result of it's verbosity. For example, just yesterday I ran into a bug with these 2 lines:

    if ([[data objectForKey:@"released"] isKindOfClass:[NSNull class]]) {
    if ([[data objectForKey:@"posterUrl"] isKindOfClass:[NSString class]]) {        

They weren't right next to each other, and at a glance, I misread to assume they were doing the same thing. There's too much shit in the way of the actual differences (NSNull vs. NSString in this case) that I have a bad tendency to gloss over the details. Coming from ruby, the closest syntactical equivalent:

    if (data['released'].class == NilClass) {
    if (data['posterUrl'].class == String) {

Is so much clearer to me when glancing through code. That doesn't even touch on how you'd actually write that sort of thing (data['released'].nil?) which is infinitely more concise than either example. I know this is a bit of a contrived example, and I certainly could find better ones. I just find the 120 character long method evocations to consistently blur the details for me, and this just happens to be the freshest instance.

To be fair, I've only been doing iOS stuff for about a month. Does this trend reverse after you've been writing obj-c for a while?

I've found after a while you get really used to the verbosity. I miss it when I return to other languages.

For instance, I look at the first example you posted and I know exactly what it does. It's very natural for me to read.

Is it really easier than `data['poster_url'].is_a? String`? I wouldn't call the Objective-C example unreadable, but it's certainly a lot more line noise for not a lot more meaning.

You do get used to it. Because it's a superset of C, Objective-C has all the syntactic noise of C and some of its own. Ruby is certainly more compact, though with its Perl influence, you can write very cryptic Ruby code. You do pay a price in Objective-C in order to have C directly and immediately available.

FWIW, extracting nested expressions into local variables helps a lot with nested method calls.

Key-value accessors aren't exactly the shining moment of verbose method names (It's even been leaked that 10.8 has dict[key] sugar), but for methods with more parameters, it's much nicer than positional. e.g.:

connection:didReceiveResponse: addObserverForName:object:queue:usingBlock: drawAtPoint:forWidth:withFont:minFontSize:actualFontSize:lineBreakMode:baselineAdjustment:

I've found it pays off at write time too. Having to say something about each parameter when naming a method really helps me to stop and think about what I'm doing every time I add to an object's interface. I'd like to think it ultimately leads to less bloat.

I don't agree with your reasoning, but part of that is my operating definition of "verbose" is "more words than needed." That is, if you're being verbose, then by definition you're using too many words, which is a stance I find difficult to defend.

Personally, once you have more than two humps in your camel case, my eyes have trouble scanning.

True, "verbose" isn't really the correct term, "explicit" better describes Objective-C. Here's an example where I think Objective-C's explicitness is helpful. The Windows API CreateWindow() function call in C:

  HWND hwnd = CreateWindow("MainWClass", "Sample",
                           WS_OVERLAPPEDWINDOW,
                           CW_USEDEFAULT, CW_USEDEFAULT,
                           CW_USEDEFAULT, CW_USEDEFAULT,
                           (HWND) NULL, (HMENU) NULL,
                           hinstance, (LPVOID) NULL);

And here's a long method call in Objective-C:

  NSString *filtered = [unfiltered stringByReplacingOccurrencesOfString:@"verbose"
                                   withString:@"explicit"
                                      options:NSCaseInsensitiveSearch
                                        range:NSMakeRange(0, [unfiltered length])];

Admittedly not equivalent examples, but I couldn't quickly find a Cocoa method call with eleven parameters. My argument is that if you're not intimately familiar with these two calls, CreateWindow() is pretty cryptic. You only get the most general sense of what it's doing without consulting a reference. Objective-C's strange method naming scheme (taken from Smalltalk) makes complex method calls much easier to understand in situ.

> I couldn't quickly find a Cocoa method call with eleven parameters

Allow me to introduce you to NSBitmapImageRep, which holds the dubious honor of being initialized by the longest public selector in all of Cocoa. Here's a contrived example:

  NSBitmapImageRep *rep = [[NSBitmapImageRep alloc] initWithBitmapDataPlanes:data
                                               pixelsWide:640     pixelsHigh:480
                                            bitsPerSample:8  samplesPerPixel:3
                                                 hasAlpha:NO        isPlanar:YES
                    colorSpaceName:@"NSCalibratedRGBColorSpace" bitmapFormat:NULL
                                              bytesPerRow:0     bitsPerPixel:0];

edit: formatting

Awesome! Thanks for the example. Painfully long but a lot easier to understand in situ than something like CreateWindow().

I agree the second example is more understandable, but I think most of that benefit comes from named parameters (a language feature), not the naming convention itself. That is, were the naming up to me, I would prefer:

  NSString *filtered = [unfiltered replace:@"verbose"
                                   with:@"explicit"
                                   options:CaseInsensitive
                                   range:Range(0, [unfiltered length])];

Of course, I'm making assumptions about what those parameters mean. But I find this much more clear, assuming the intentions are what I think they are.

In Objective-C, those aren't named parameters, like you might find in Python, or faked in Ruby or Groovy. They are called 'Keyword Messages'. In your example above, the method signature is replace:with:options:range:, compared to say a C++ style replaceWithOptionsRange. It's simply a way to interleave arguments in the message send itself, inherited from Smalltalk.

When you use the word "replace", to most people, that signals that you would be changing the current object in place, not returning a new object based on the given one.

On the second line, you didn't mention at all what is passed in.

For the last two, removing the NS prefix would work if Objective-C had some kind of namespacing support. Currently it doesn't, so the NS prefix is kinda needed.

New object versus mutating the current object depends on convention - in Python, there is a "replace" function on the native string type that returns a copy (http://docs.python.org/library/stdtypes.html#string-methods); in C++, std::string::replace mutates the string in place.

I'm not sure what you mean by not mentioning what is passed in. Keep in mind: I have never programmed in Objective-C. I am going on intuition alone.

No namespace support is a bummer - it means you're going to end up with long identifiers all over the place.