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

21–30 of 156 posts

Re: Why Objective-C is Hard

#21

Post by AshFurrow »

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…

I'm not saying that the information isn't available - I'm only saying that to someone new to the framework, it's hard to know what you don't know yet.

As a concrete example, you actually can do myLayer.frame = someRect. The results might not be what you expect, especially if the CALayer exists in a hierarchy already and if the anchor point isn't the centre of the layer, but how would you know that if you hadn't experimented already?

Re: Why Objective-C is Hard

#22

Post by igorgue »

You know what I really dislike about Objective-C is that is really inconsistent with properties and messages, at one point I said out loud: JUST PICK ONE! Coming from Python this is a big thing for me, I like when there's only one right way to do things.

P.S. My only experience with Objective-C is with the iOS SDK.

Re: Why Objective-C is Hard

#23

Post by glhaynes »

chc wrote: post #16
ejames wrote: post #6

Earlier quoted context omitted.

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 allowan…

Very well said. I think this also promotes a mindset of making methods that either mutate state or build and return an object. It's often very difficult to follow code that has lots of methods that do both.

Re: Why Objective-C is Hard

#24

Post by ahlatimer »

chc wrote: post #16
ejames wrote: post #6

Earlier quoted context omitted.

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 allowan…

The guidelines for Ruby are to add a bang (!) to any methods that mutate the object rather than returning a new one. That's not strictly followed, though, but for most of the commonly used standard library bits, you can be fairly certain that that is the case.

Re: Why Objective-C is Hard

#25

Post by jamesu »

Anything you do not understand is inherently hard.

The only thing i would say is uniquely hard about Objective C is getting your head around some of the APIs, but then again that can apply to any language.

Re: Why Objective-C is Hard

#26

Post by scott_s »

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 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.

Re: Why Objective-C is Hard

#27

Post by chc »

ahlatimer wrote: post #24
chc wrote: post #16

Earlier quoted context omitted.

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 allowan…

The guidelines for Ruby are to add a bang (!) to any methods that mutate the object rather than returning a new one. That's not strictly followed, though, but for most of the commonly used standard library bits, you can be fairly certain that that is the case.

In practice, even in the standard library, this isn't followed often enough to rely on. Here's a (possibly incomplete, since I'm writing this on the fly) list of bangless mutating methods just from Array:

  pop
  push
  shift
  unshift
As an even more extreme example, IO contains precisely one bang-method, despite the fact that probably 75% of IO's instance methods are destructive.

The general rule seems to be that if there's a mutating and non-mutating version of the same method, the mutating one will get a bang, but when there's a mutating method with no counterpart, it might get a bang but probably won't.

Re: Why Objective-C is Hard

#28

Post by siavosh »

I spend half my day in iOS development and the other half on a Java web stack. I love the RESULT of Obj-C+Cocoa Touch, you can achieve amazing user experience. But I'm reaching the point thinking: it's 2012, I'm an application developer, why am I spending half my time debugging memory leaks and concurrency issues? Java isn't much better either, why all this boiler plate, and still concurrency nightmares. I've done a handful of side projects with django and that's better, but I still think if I showed my teenage self what I'm programming in, he'd wonder if there was ever any real progress.

I guess what I'm saying is after all these years I want to work on a higher level, as a result I've started to play with Clojure and functional languages. Whether I'm idealizing functional/clojure life, I'll soon find out, but the appeal is very high to spend my time dealing with problem complexity, not language/framework ones.

Re: Why Objective-C is Hard

#29

Post by gdubs »

AshFurrow wrote: post #21
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…

I'm not saying that the information isn't available - I'm only saying that to someone new to the framework, it's hard to know what you don't know yet. As a concrete example, you actually can do myLayer.frame = someRect. The results might not be what you expect, especially if the CALayer exists in a hierarchy already and if the anchor point isn't the centre of the layer, but how would you know that if you hadn't exper…

Right, it won't cause a crash -- just unpredictable results. My point was more that dot syntax doesn't always equate to easier coding;

In this particular case though, who would be playing with the CALayer class without ever having touched the documentation? The overview of view geometry (frame, anchor point, bounds, position) is second only after the Core Animation introduction in the docs. And it's pretty clear: when you get a frame from a layer, it is an implicit function of the anchor point, position and bounds -- but the frame itself is not stored (when you set it).

So, if you're using dot syntax to store properties throughout your code, and then you use it on the frame property, a casual reading of the code might lead someone to think that you could retrieve that value later and have it be the same.

(Here's what Joe Conway says about the dot-notation syntax: http://weblog.bignerdranch.com/?p=83 )

Re: Why Objective-C is Hard

#30

Post by [deleted] »

stcredzero wrote: post #7

Unless you've played with other languages that support these features, like Ruby or Lisp, then this feels really weird. Don't worry! Lots of great things feel really weird the first time you try them, like broccoli or sexual intercourse. I find it really weird that there's no mention of Smalltalk, which is exactly where the weird syntax comes from. It's also where the notion of IntentionRevealingNames comes from, whi…

[deleted]
Post reply on HN