Nah. Not hard. Different. People have a natural inclination to resist the new. My guess is that a competent programmer with OO experience should be comfortable with Objective-C within a week or two of study.
Why Objective-C is Hard
61–70 of 156 posts
Re: Why Objective-C is Hard
#62Earlier 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…
You do get used to it. Because it's a superset of C, Objective-C has all the syntactic noise of C and some of its own. Ruby is certainly more compact, though with its Perl influence, you can write very cryptic Ruby code. You do pay a price in Objective-C in order to have C directly and immediately available.
FWIW, extracting nested expressions into local variables helps a lot with nested method calls.
Re: Why Objective-C is Hard
#63Not looking for trouble here but writing an iPhone app should be no more difficult than creating a Keynote presentation, imho. If Apple is the leader in document development (Keynote, etc), why can't they do the same with writing apps. Look at what they've done with the complexities of video editing. Where is the consumer grade development app for iPhone?
Re: Why Objective-C is Hard
#64I 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…
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?
Because Objective-C targets everyday desktop apps and mobile apps. In that space, manual memory management still wins the day.
For example, in Windows and Linux DESKTOP those kind of apps are ALSO made in C++ or C.
Java and C# are for the web server and the CORPORATE desktop (in-house apps).
Not many major end user apps outside the enterprise are made with either. Not any famous, widely used ones, anyway. Azureus, maybe, and a few dozen more.
Re: Why Objective-C is Hard
#65Anything 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.
To me the hardest thing is the seemingly arbitrary CG functions in Quartz2D and why they're so interspersed throughout the code. If I'm writing within the UIKit most of the time, and then have to make my own UIView for some custom drawing, I have a hell of a time remembering how, and always have to reference my earlier code, which I usually find on StackOverflow or somewhere else.
Example, let's draw a line and an ellipse in drawRect:
CGContextRef ctx = UIGraphicsGetCurrentContext(); //CGMove the point somewhere? //CGLineTo something //CGDrawEllipseInRect or something //stroke or fill? CGFillSomething maybe? //do i need to end the context?
Maybe it's a mental block on my part, but I can _never_ remember how to do this and always have to look it up, probably because it's not part of the standard UIKit and not used on daily basis. I guess I would just like to see the Quartz stuff conform more to UIKit naming conventions (but because it's based in C, I understand why it's not)
Re: Why Objective-C is Hard
#66Earlier 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…
Key-value accessors aren't exactly the shining moment of verbose method names (It's even been leaked that 10.8 has dict[key] sugar), but for methods with more parameters, it's much nicer than positional. e.g.:
connection:didReceiveResponse: addObserverForName:object:queue:usingBlock: drawAtPoint:forWidth:withFont:minFontSize:actualFontSize:lineBreakMode:baselineAdjustment:
Re: Why Objective-C is Hard
#67People fret over language syntax too much. In most sane languages including Objective-C you simply forget about the syntax after a few months. What’s much more important is the conceptual complexity: the number of language features and the way they fit together. A second important thing is the standard library. Objective-C is a pleasant language by both these metrics, since there are just a few language constructs ab…
I couldn't agree more. Everything is "hard" on the first couple of times, but the only recommendation I say to people is to stop worrying about the language, and go create stuff, get into that mindset of creating something, even if it's just a simple app. that will allow us to research and ask things around, and that's when you learn and progress. Nobody achieves anything by bitching around how hard this and that is.
You're right - I should have called it "Why Objective-C is Hard to Learn"; all of the issues I enumerate are surmountable with enough experience and experimentation.
Re: Why Objective-C is Hard
#68Forget the fact that we're not even talking about methods, really, we're talking about messages (a distinction I'm not going to make) and you refer to selectors like the one above as performAction:withTwoParameters:. Most people don't care anymore. Well, those people have fairly low expectations of themselves then. People say this bullshit about the supposedly strange Obj-C syntax, whereas the part that it's not C is…
withTwoParameters is actually part of the method signature. It's not a keyword identifier. So
[object performAction: param1 withTwoParameters: param2]
object.performActionwithTwoParameters(param1, param2)Re: Why Objective-C is Hard
#69Earlier quoted context omitted.
Dispatch queues have made most of my concurrency woes go away; same thing with ARC for memory leaks.
A word of caution with ARC -- you still have to release certain things manually, for example CGImageRefs with CFRelease if you're doing any sort of image manipulation.
Those aren't Objective-C objects, but I get your point. ARC does not relieve you of thinking about memory, it just makes it easier.
Re: Why Objective-C is Hard
#70Forget the fact that we're not even talking about methods, really, we're talking about messages (a distinction I'm not going to make) and you refer to selectors like the one above as performAction:withTwoParameters:. Most people don't care anymore. Well, those people have fairly low expectations of themselves then. People say this bullshit about the supposedly strange Obj-C syntax, whereas the part that it's not C is…
withTwoParameters is actually part of the method signature. It's not a keyword identifier. So [object performAction: param1 withTwoParameters: param2] is roughly equivalent to object.performActionwithTwoParameters(param1, param2)
withTwoParameters is actually part of the method signature. It's not a keyword identifier.
Sure, but it's not like that distinction is really important for the programmer. For most intends and purposes, he can just think of those as keyword identifiers
--or, better, as a kind of keyword identifiers that also have to be present whenever referring to the method.
Not that big of a deal.