Method signatures are often ridiculously long (see NSBitmapRep's initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel: method)
That's rather the point. It make code easier to read and understand when you can see, in the method invocation itself, what all of the parameters are for.
Parameter names in method calls are
Again, rather the point. Otherwise your above example would endue as initWithBitmapData(p,w,h,b,s,a,p,c,f,r,b).
The above combine to make even the most basic operations tedious. Want to trim leading/trailing whitespace off a string? Enjoy [someString stringByTrimmingCharactersInSet:[NSCharacterSet whitespaceCharacterSet]]
Autocomplete makes this rather irrelevant, no? Especially the much improved autocomplete in Xcode4+.
Immutable arrays, dictionaries, sets, strings. I get it, it can be useful for performance to know something is immutable (maybe, I'm not that convinced). But the common use case is most certainly mutable, so
That you don't actually understand this point is pretty telling. Performance isn't the only reason to make arrays and such immutable by default. It also makes such structures safer to pass around, especially to outside code, without having to worry about the data getting modified unexpectedly.
Memory management (up until recently) was neither fully manual nor fully automatic and ownership was based on naming conventions
Ownership is always based on naming conventions, or else there would be no predictability and the language would be unusable.
Being a superset of C, they couldn't provide an object-oriented array class using the normal array syntax, so instead you have tedium like [myArray objectAtIndex:2]
"Fixed" in enhancements coming with Xcode 4.4.
Ditto for strings. Also, you have to prefix string constants with '@'.
Oh no, a single extra character!
Similarly, you can't put "plain" objects into arrays, e.g. [myArray addObject:5] won't work, but [myArray addObject:[NSNumber numberWithInt:5]] will.
Perhaps you one valid complaint, rendered nearly irrelevant by enhancements again coming in Xcode4.4.
And of course you can't just create an array with ['a', 'b', 'c'] but instead have to do [NSArray arrayWithObjects:@"a", @"b", @"c", nil].
Oh hey, same thing.
Backwards conventions like [NSDictionary dictionaryWithObjectsAndKeys:@"value0", @"key0", @"value1", @"key1", nil];
And again, a solved issue.
If I'm going to pay the dev cycle price of a compiled language, it should catch stuff like non-existent selectors at compile time instead of blowing up at runtime
It does. Unless you turned off those warnings. I always build with -Wall -Wextra -Wno-unused-parameter
Stack traces from delayed selector calls have zero contextual information
They have the same information as that selector normally does.
The single inheritance model and a strict class hierarchy discourages writing reusable code. For example, if I have an app that runs on iPad and iPhone and they share a common screen (from the user's perspective although the layout/design might be significantly different), it's a real task to write a common parent class holds the common code.
You're doing it wrong. Reusing code is trivial as long as you've cleanly separated it using the MVC paradigm most common in Objective-C.
Many violations of don't-repeat-yourself: if you want to have an object with properties like Foo.title, then the code is roughly:
@interface Foo { NSString *title; }
@property (nonatomic, retain) NSString *title; @end
@implementation Foo @synthesize title -(void)dealloc { [title release]; [super dealloc]; }
Oh hey, another solved issue. Some of it has been for a few years now. You don't need a backing ivar on iOS or 64-bit OS X and never have. With the enhancements coming in Xcode4.4, you don't even need synthesize. With ARC, you don't need dealloc.
Similarly, there's no way to have a truly dynamic object with a clean syntax, e.g. in Python/ruby/js/and a host of others you could have a quick little object you use to pass state around, kind of like a struct that has its members added on the fly, e.g.: x = new Object() ; x.name = 'dave' ; x.age = 3. There is literally no way to do that in ObjC - the best you can do is create mutable dictionary and use its verbose syntax.
These are a bad idea in those languages too. Hey, lets have an object that can store anything under any name at any time, with no restrictions. Brilliant!
We could have a whole extra thread about the toolchain (Interface Builder is an abomination, Xcode often pegs multiple CPUs when it's just sitting there, if you kill the simulator instead of stopping the app via Xcode then you often have to reboot your host machine before you can run the simulator again) but I digress.
We could indeed. IB is still leaps and bounds ahead of any other GUI tools and your last point is just completely wrong. Xcode does have its problems though.
Variables don't; constants aren't.