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

81–90 of 156 posts

Re: Why Objective-C is Hard

#81

Post by scrod »

>However, they're also adding to the language in ways that makes the code expressed in Objective-C simpler:

>Synthesizing properties

>Dot-syntax for accessing getters/setters

>Garbage Collection

>Blocks (closures)

>Automatic Reference Counting

>Weak references

Sorry, but none of these things make the language any simpler — they all add yet another style of doing things that only raises the bar and the learning curve for new developers when reading existing code, in precisely the same way that C++ and Perl have done. And this is true even of garbage collection (which, by the way, is deprecated in 10.8), because it needs to coexist with other frameworks and code that might not be garbage-collected, and more importantly because all heap-allocated C buffers consequently require their own low-level wrappers (e.g., NSAllocateCollectable, objc_memmove_collectable, etc.).

Re: Why Objective-C is Hard

#82

Post by btn »

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 design philosophy behind much of Objective-C is described in Brad Cox's book "Object-oriented programming: an evolutionary approach" [1]. Unfortunately, I don't have a copy handy to give you a quote.

[1] http://books.google.co.nz/books?id=U8AgAQAAIAAJ

Re: Why Objective-C is Hard

#83

Post by eropple »

Cushman wrote: post #31
jcizzle wrote: post #15

Earlier quoted context omitted.

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.

I've done exactly as you say, and I still find Objective-C Perlesque in its obnoxiousness. I also manage to achieve that not-terribly-hard feat on a pretty regular basis with Java: intellisense (hi, IntelliJ!) and IDE-provided Javadocs do the same thing, too, and someone who isn't going to write good Javadocs isn't going to name things well.

Re: Why Objective-C is Hard

#84

Post by AznHisoka »

Before I took the jump to learn Objective C and iPhone development, I dreaded the huge learning curve needed. Now that I'm on the other side, I LOVE the fact it intimidates people :)

Re: Why Objective-C is Hard

#85

Post by AznHisoka »

aaronblohowiak wrote: post #69
mirkules wrote: post #53

Earlier quoted context omitted.

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.

ARC to me is scary... I got over the huge learning curve, and the nuances of autoreleasing, and retaining, and it seems like now I gotta unlearn all of that??? And not to mention some third party libraries/source code don't support ARC. To me, I'm gonna hold off using ARC as long as possible.

Re: Why Objective-C is Hard

#86

Post by potatolicious »

objclxt wrote: post #39
phatbyte wrote: post #10

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

This is hardly consistent even in Apple's world. I recently went through your exact exercise myself, except instead of tabbars in Android, it's Core Data storage in iOS.

The vaunted Core Data + iCloud integration is woefully underdocumented (actually, it's practically undocumented), with the main resource being a mega-thread on Apple's dev forums, where every few pages someone from Apple will chime in with ever more confusing suggestions, and yet never updated sample code nor docs.

I really don't think "shitty documentation" is a uniquely Android thing, nor is it something iOS has resolved.

Re: Why Objective-C is Hard

#87

Post by 0x09 »

donmcc wrote: post #73
scott_s wrote: post #26

Earlier quoted context omitted.

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.

True, "verbose" isn't really the correct term, "explicit" better describes Objective-C. Here's an example where I think Objective-C's explicitness is helpful. The Windows API CreateWindow() function call in C: HWND hwnd = CreateWindow("MainWClass", "Sample", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, (HWND) NULL, (HMENU) NULL, hinstance, (LPVOID) NULL); And here's a long method c…

> I couldn't quickly find a Cocoa method call with eleven parameters

Allow me to introduce you to NSBitmapImageRep, which holds the dubious honor of being initialized by the longest public selector in all of Cocoa. Here's a contrived example:

  NSBitmapImageRep *rep = [[NSBitmapImageRep alloc] initWithBitmapDataPlanes:data
                                               pixelsWide:640     pixelsHigh:480
                                            bitsPerSample:8  samplesPerPixel:3
                                                 hasAlpha:NO        isPlanar:YES
                    colorSpaceName:@"NSCalibratedRGBColorSpace" bitmapFormat:NULL
                                              bytesPerRow:0     bitsPerPixel:0];
edit: formatting

Re: Why Objective-C is Hard

#88

Post by mirkules »

AznHisoka wrote: post #85
aaronblohowiak wrote: post #69

Earlier quoted context omitted.

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.

ARC to me is scary... I got over the huge learning curve, and the nuances of autoreleasing, and retaining, and it seems like now I gotta unlearn all of that??? And not to mention some third party libraries/source code don't support ARC. To me, I'm gonna hold off using ARC as long as possible.

Well, you don't have to "unlearn" it. It's actually a good thing you went through the "pain" of learning it pre-ARC because if you understand how reference counting actually works, you will be able to make better and more informed decisions on the management of your objects in 5.0+ with ARC (e.g. when to use strong vs. weak properties). There's nothing magical about it, and Ray Wanderlich has a fantastic ARC tutorial that helped me greatly: http://www.raywenderlich.com/5677/beginning-arc-in-ios-5-par...

Holding off on ARC is only advantageous if you need to support iOS versions before 5.0, but ARC is the future of iOS.

Re: Why Objective-C is Hard

#89

Post by mirkules »

batista wrote: post #72
mirkules wrote: post #53

Earlier quoted context omitted.

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.

Well, same goes for every non memory managed object in any language. Like, SWT objects in Java. Or file descriptors. Or DB connections.

Indeed, as Aaron above mentioned, ARC doesn't absolve the programmer of the responsibility of proper memory management, it's just less overhead to have to worry about.

Re: Why Objective-C is Hard

#90

Post by _delirium »

batista wrote: post #64
siavosh wrote: 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…

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

There's also Minecraft, one of the best-selling videogames of 2011. :)
Post reply on HN