Live data from Hacker News

Why Objective-C is Hard

ashfurrow.com

31–40 of 156 posts

Re: Why Objective-C is Hard

#31
post #15
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…

Seconded. The first time you write a fully working method using a library you've never used in one shot without looking anything up will make you love ObjC.

Re: Why Objective-C is Hard

#32
post #29

Earlier quoted context omitted.

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: whe…

>> who would be playing with the CALayer class without ever having touched the documentation?

How many hackers out there always read the entire manual before playing around? I'd wager most.

I agree that Objective-C is slightly schizophrenic about the dot-syntax, but I would argue that dot-syntax for getters and setters is easier for a newcomers to learn.

Re: Why Objective-C is Hard

#33
post #28

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…

Dispatch queues have made most of my concurrency woes go away; same thing with ARC for memory leaks.

Re: Why Objective-C is Hard

#34
post #29

Earlier quoted context omitted.

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: whe…

>> who would be playing with the CALayer class without ever having touched the documentation? How many hackers out there always read the entire manual before playing around? I'd wager most. I agree that Objective-C is slightly schizophrenic about the dot-syntax, but I would argue that dot-syntax for getters and setters is easier for a newcomers to learn.

I'm not saying one has to read the manual before playing around, but some things are simply not explorable with at least a little bit of introduction. You had to read somewhere that [NSObject alloc]init] was how to create a new object; you didn't just guess at it. Similarly, how far would someone get creating a CALayer, and adding it to a view without ever looking at the docs?

If someone is having a hard time learning Objective-C, maybe the real suggestion is to start by reading at least a bit of the manual.

Re: Why Objective-C is Hard

#35
post #19
post #11

Earlier quoted context omitted.

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

I've found after a while you get really used to the verbosity. I miss it when I return to other languages.

For instance, I look at the first example you posted and I know exactly what it does. It's very natural for me to read.

Re: Why Objective-C is Hard

#37
post #28

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…

[deleted]

Re: Why Objective-C is Hard

#38
post #28

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…

To me, this is almost like asking, "Why, since it is 2012, is the Halting Problem, such a problem?" I don't know what 2012 has to do with functional programming languages, though ... seems like there was this language a long, long time ago, in a far away land ...

Re: Why Objective-C is Hard

#39

I don't think Objective-C is hard at all. If you understand OO or come from a OO language you can pick it up pretty fast, like in a day or two. Cocoa on the other hand requires much more learning curve. Also apple could improve their documentation. I'm currently working on a OSX app, and Objective-C has been a breeze, with the new ARC is even more easy to work with.

Really? If you compare Apple's documentation to Android's...they're worlds apart. Here's a good example: I'm an iOS developer, and have been since pretty much day 1 of the platform. I recently actually started playing around with the Android SDK, and environment.

I followed Google's supplied tutorial for creating a tabbar app, and asked one of the Android devs who works with me to come take a look at the finished result.

"Oh", he said, "that's deprecated now. We don't do tab bars like that any more. We use fragments instead". And sure enough, when I looked closely, Eclipse was telling me what I'd done was, in fact, deprecated and Google recommended a different approach.

Except I'd followed their main tutorial for Android, step by step. Compare this with Apple, who have consistently updated their documentation for each API release. How Google could possibly think it's a good idea to deprecate a major platform feature for fragments (a good thing) and not update one of the most popular tutorials on their site to reflect this (the 'Hello Views' tutorial) is beyond me.

Post reply on HN