Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Objective-C is Hard

ashfurrow.com

Post reply on HN
Print view View original

11–20 of 156 posts

Re: Why Objective-C is Hard

#11

Post by donmcc »

tmcw wrote: post #4

Pretty great article. Though I wish someone could point to the paper or whatever that explains the philosophy of Objective-C having insanely verbose method and parameter names. Like, readable is one thing, but they always end up like stringFromAppendingThingToThingToNumberYieldingThingThx and it becomes unimaginable to use Objective-C without XCode to autocomplete the other 40 characters.

The idea is that code is written once but read many times. Objective-C's verbose naming make you work a little more when writing it (though a good programmer's editor or IDE like Xcode or AppCode greatly eases this) but it pays off each time you need to read the code, especially code you're not familiar with.

With it's C-based syntax, Objective-C isn't as clean as Python or Ruby, but due to the explicit naming conventions, I think it's more readable than Java or JavaScript.

Re: Why Objective-C is Hard

#12

Post by jonhendry »

gdubs wrote: post #8

Syntactic sugar (dynamic getter and setters using @synthesize, @property, allowing for dot syntax accessors) is not new. Nor is Garbage Collection. Garbage Collection is not available on iOS, but has been for a long time on OS X [edit: and as noted below, is actually being deprecated in favor of ARC]. Objective-c 2.0 came out in 2006. Blocks, at this point, are not really new either. So, I think it's incorrect to say…

GC is deprecated as of 10.8, in favor of ARC.

Re: Why Objective-C is Hard

#13

Post by radiowave »

I think it's very largely a question of what you're used to. I don't know much about Objective C, but given my knowledge of Smalltalk, the use of keywords to identify arguments seems entirely natural.

But then I've never really understood why people think it's acceptable for languages to insist that you do this:

myfunction("First argument","Does this one really go second?","Is there even a third?")

Re: Why Objective-C is Hard

#14

Post by gdubs »

jonhendry wrote: post #12
gdubs wrote: post #8

Syntactic sugar (dynamic getter and setters using @synthesize, @property, allowing for dot syntax accessors) is not new. Nor is Garbage Collection. Garbage Collection is not available on iOS, but has been for a long time on OS X [edit: and as noted below, is actually being deprecated in favor of ARC]. Objective-c 2.0 came out in 2006. Blocks, at this point, are not really new either. So, I think it's incorrect to say…

GC is deprecated as of 10.8, in favor of ARC.

Just to be clear, I was referencing the point in the original article where it said that apple was 'adding Garbage Collection' to make the 'code expressed in Objective-C simpler'.

Re: Why Objective-C is Hard

#15

Post by jcizzle »

tmcw wrote: post #4

Pretty great article. Though I wish someone could point to the paper or whatever that explains the philosophy of Objective-C having insanely verbose method and parameter names. Like, readable is one thing, but they always end up like stringFromAppendingThingToThingToNumberYieldingThingThx and it becomes unimaginable to use Objective-C without XCode to autocomplete the other 40 characters.

Selectors always describe exactly what the method does and what it needs. For example, stringByAppendingStringWithFormat: says "You will get a new string, by appending a format string to the receiver." There is also the mutable counterpart, appendStringWithFormat:, which is shorter because it doesn't return a new string, instead, appending directly to the receiver.

Verbose selectors make Objective-C self-documenting at the cost of extra typing. But autocomplete solves this problem because you only ever have to type 2-5 characters to insert the method you want (once you are experienced enough to predict what autocomplete will spit out).

Objective-C naming conventions form predictable patterns. Inexperienced programmers gripe because they have yet to figure out these patterns, good programmers love Objective-C because they understand these patterns and can therefore predict the name of a method and its arguments and great programmers write their own classes that use these patterns.

Re: Why Objective-C is Hard

#16

Post by chc »

ejames wrote: post #6
tmcw wrote: post #4

Pretty great article. Though I wish someone could point to the paper or whatever that explains the philosophy of Objective-C having insanely verbose method and parameter names. Like, readable is one thing, but they always end up like stringFromAppendingThingToThingToNumberYieldingThingThx and it becomes unimaginable to use Objective-C without XCode to autocomplete the other 40 characters.

It's because Objective-C methods are named according to the nouns that they return rather than the verbs they perform. For example, "[input stringByAppendingThing:thing]" rather than "input.append(thing)". Methods are actions, not objects, so the most concise description for a method is usually a verb. Describing it as a noun instead requires adding prepositions and turning verbs to the gerund '-ing' form. I realized…

Eh, I think that's a little overbroad. The way it works is, methods whose purpose is returning something are named for what they return, while methods whose purpose is creating a side effect are named for what they do. So NSString has `stringByAppendingString:` because you're asking for a new string, while NSMutableString has `appendString:`, which is essentially the same as it would be in Ruby except with an allowance for Objective-C's static type system.

What really creates the impression that Objective-C speaks in terms of nouns is that Cocoa tends to promote immutable objects more than Ruby does (e.g. the only way to get an immutable string or array in Ruby is to freeze a mutable one, while you'll almost never get a mutable array in Cocoa unless you create one yourself), so you probably do spend more time asking your objects for other objects than you do in Ruby.

Although the verbosity can get overwhelming, I actually like this about Objective-C. In terser dynamic languages, I'm constantly having to confirm (either mentally or in the docs) which methods mutate and which return a new object. Cocoa's naming conventions mean I pretty much never have to do that.

Re: Why Objective-C is Hard

#17

Post by revorad »

tmcw wrote: post #4

Pretty great article. Though I wish someone could point to the paper or whatever that explains the philosophy of Objective-C having insanely verbose method and parameter names. Like, readable is one thing, but they always end up like stringFromAppendingThingToThingToNumberYieldingThingThx and it becomes unimaginable to use Objective-C without XCode to autocomplete the other 40 characters.

That's one of the things I'm finding most annoying about learning Obj-C. The weird thing is that these extra long names make the language less readable to me, because I have to mentally diff very similar looking long strings.

Re: Why Objective-C is Hard

#18

Post by bunderbunder »

donmcc wrote: post #11
tmcw wrote: post #4

Pretty great article. Though I wish someone could point to the paper or whatever that explains the philosophy of Objective-C having insanely verbose method and parameter names. Like, readable is one thing, but they always end up like stringFromAppendingThingToThingToNumberYieldingThingThx and it becomes unimaginable to use Objective-C without XCode to autocomplete the other 40 characters.

The idea is that code is written once but read many times. Objective-C's verbose naming make you work a little more when writing it (though a good programmer's editor or IDE like Xcode or AppCode greatly eases this) but it pays off each time you need to read the code, especially code you're not familiar with. With it's C-based syntax, Objective-C isn't as clean as Python or Ruby, but due to the explicit naming conven…

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.

Re: Why Objective-C is Hard

#19

Post by ctide »

donmcc wrote: post #11
tmcw wrote: post #4

Pretty great article. Though I wish someone could point to the paper or whatever that explains the philosophy of Objective-C having insanely verbose method and parameter names. Like, readable is one thing, but they always end up like stringFromAppendingThingToThingToNumberYieldingThingThx and it becomes unimaginable to use Objective-C without XCode to autocomplete the other 40 characters.

The idea is that code is written once but read many times. Objective-C's verbose naming make you work a little more when writing it (though a good programmer's editor or IDE like Xcode or AppCode greatly eases this) but it pays off each time you need to read the code, especially code you're not familiar with. With it's C-based syntax, Objective-C isn't as clean as Python or Ruby, but due to the explicit naming conven…

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?

Re: Why Objective-C is Hard

#20

Post by drhayes9 »

ejames wrote: post #6
tmcw wrote: post #4

Pretty great article. Though I wish someone could point to the paper or whatever that explains the philosophy of Objective-C having insanely verbose method and parameter names. Like, readable is one thing, but they always end up like stringFromAppendingThingToThingToNumberYieldingThingThx and it becomes unimaginable to use Objective-C without XCode to autocomplete the other 40 characters.

It's because Objective-C methods are named according to the nouns that they return rather than the verbs they perform. For example, "[input stringByAppendingThing:thing]" rather than "input.append(thing)". Methods are actions, not objects, so the most concise description for a method is usually a verb. Describing it as a noun instead requires adding prepositions and turning verbs to the gerund '-ing' form. I realized…

Have you read http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom... ?

Yegge basically completely agrees with you. Once I started thinking of OOP in these terms it helped me, as a programmer, a lot.

Post reply on HN