Objective-C's tendency to long names (variables, selectors, classes) makes it more "self-documenting" than any language I've worked with. Besides, it's not that bad with autocomplete.
>> I'm not an Objective-C native, but every time I write Objective-C it feels like I'm writing a short story.
That's the whole point of it ;-). Remember you usually only have to write the code once, but you or someone else may have to read it many times.
I used to hate long variable and function names in the past, and I used to hate named parameters. Going on the assumption the time spent typing the code was somehow relevant, and also feeling a little more badass being able to write all this cryptic gibberish to 'control the computer'. In time, I've learned none of this matters and readability of your code is one of the most important quality metrics of any piece of software that needs to be maintained by multiple people and/or over a long timespan.
With Xcode it's just as bad as it looks. If you have multiple names with the same prefix you have to type it all or scroll in a list to select the correct item.
It even fails to complete types like NSString correctly when part of a method call. Not always of course, just when it gets confused, and then I have to delete and type again because the case is wrong.
Now if only that autocomplete would passively infer the current project prefix + (super)class name, so you wouldn't have to type it when it's "local"...
Right, if only it used C#! Then it could use nice short names like ListViewVirtualItemsSelectionRangeChangedEventHandler or DataGridViewColumnDividerDoubleClickEventArgs.
Oh god. That's an artifact of the idiotic VB-style, non-generic event handling "pattern". If event handlers used normal functions like everything else this just wouldn't be a problem (those types just wouldn't exist).
