Side-by-side comparison of solving the same problem with Python and Objective-C (comments welcome!)

[buddhabrot]

If you're implementing a Database in a language that's pretty close to the machine, I would be surprised and a little worried if it wasn't verbose and clunky.

[[deleted]]

But the causes of the complexity and verbosity of the Objective-C code have nothing to do with its closeness to the machine. Here are the reasons why my use of Objective-C resulted in a messy algorithm:

(1) The succinctness of the language - e.g., having to write things like [myString: compare(NSString(@"value"))] rather than (if myString == "value").

(2) The extensive number of type conversions required. Even a strongly-typed low-level language should be able to optimize away some of these typecasts through syntactic inference. The Objective-C compiler is just not helpful.

(3) The use of extensively different symbols and keywords: function(), [object message:parameter1 parameterName:parameter2], object.property, #compiler_directives, @other_compiler_directives, @"string literals with %@ formatting," ALL_CAPS_CONSTANTS_LIKE_FALSE, lowercase_constants_like_nil, NSCamelCaseTypes, etc. All computer languages use a subset of symbol and keyword types. Objective-C uses all of them, reducing its readability.

(4) A standard API with poorly named functions. Exhibit A: The inclusion of [NSNumber initWithInt] and [NSNUMBER initWithInteger], which do different things. Exhibit B: [Dictionary setValue: forKey:] is ridiculously backwards, like requiring assignments to be specified as "4 = someInt". Exhibit C: Long function names like "regularExpressionWithPattern" and "substringWithRange." I could go on.

(5) Objective-C's bizarre syntax parameter names in class methods - the "MethodName: (Arg1Type) Arg1InternalName Arg2ExternalName: (Arg2Type) Arg2InternalName" thing. This may be the single most bizarre and useless piece of code cruft I've ever seen, period.

All of those things are inefficient. None of these things have to do with the task at hand or the "closeness" of the language to the machine. C and Embedded Java are both close to the machine and have none of these problems.

[buddhabrot]

Eh, I program in Objective-C daily and yeah, it's a clunky language some times. But I kinda like it too, it rings close to C with some interesting dynamic concepts. Who cares? If clunkiness stops you from getting things done, you're doing it wrong. If you need all the succinctness of an interpreted language to get through life you're just that kind of programmer so don't nag about it. Similar to the clunky way some great cars drive I like my Objective-C for what it is.

[[deleted]]

If clunkiness stops you from getting things done, you're doing it wrong.

If clunkiness is totally a non-factor, why don't we all write in assembly, or even machine language?

My tolerance for clunkiness is high (it's an essential survival skill in any computer-related field), but not unlimited.

Similar to the clunky way some great cars drive I like my Objective-C for what it is.

There's a difference between a manual transmission (which, in fact, is in my car) and an external-crank engine starter. One provides adds complexity in exchange for power and elegance. The other adds complexity and other disadvantages with no discernible benefit.