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

71–80 of 156 posts

Re: Why Objective-C is Hard

#71

Post by zxoq »

mahyarm wrote: post #58

I love the flexibility and breadth of things you can do with objective-c/c++. It's downsides mostly come from syntax, container class getting/setting is way too verbose, same with string operations. If there was a special syntax for just string and container classes, large swaths of my code would be smaller. UIKit view controller classes are also not flexible enough, and crap out in a lot of custom multithreaded oper…

Beta version of XCode has dict[@1] or dict[@"key"] for accessing members. Makes NSNumber and objectForKey old news. It's great. :)

Re: Why Objective-C is Hard

#72

Post by batista »

mirkules wrote: post #53
aaronblohowiak wrote: post #33

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

Well, same goes for every non memory managed object in any language.

Like, SWT objects in Java. Or file descriptors. Or DB connections.

Re: Why Objective-C is Hard

#73

Post by donmcc »

scott_s wrote: post #26
donmcc wrote: 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 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 call in Objective-C:

  NSString *filtered = [unfiltered stringByReplacingOccurrencesOfString:@"verbose"
                                   withString:@"explicit"
                                      options:NSCaseInsensitiveSearch
                                        range:NSMakeRange(0, [unfiltered length])];
Admittedly not equivalent examples, but I couldn't quickly find a Cocoa method call with eleven parameters. My argument is that if you're not intimately familiar with these two calls, CreateWindow() is pretty cryptic. You only get the most general sense of what it's doing without consulting a reference. Objective-C's strange method naming scheme (taken from Smalltalk) makes complex method calls much easier to understand in situ.

Re: Why Objective-C is Hard

#74

Post by 286c8cb04bda »

dpifke wrote: post #52
objclxt wrote: post #39

Earlier quoted context omitted.

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…

Why does a comment about Apple's documentation need to turn into a holy war versus Android? The parent said that Apple "could improve" their documentation, not that it was worse than Google/Microsoft/IBM/whomever.

> The parent said that Apple "could improve" their documentation, not that it was worse than Google/Microsoft/IBM/whomever.

Do you have any examples of big libraries where "they could improve the documentation" is untrue? I can't think of any offhand.

(This is not snark. I'm honestly interested if you do.)

APIs are perpetually under-documented, in my experience, so the parent comment's observation is essentially an empty statement.

Re: Why Objective-C is Hard

#75

Post by meow »

batista wrote: post #60

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

"Or the beast with 1000 features C# has become"

It's many things to many people. To beginners, its a friendly cub to play with. To enterprise coders its the beast of burden to carry things. To newbie web developers/existing c++ programmers its familiar face on a new road. It won't devour you unless you have a death wish.

Re: Why Objective-C is Hard

#76

Post by scott_s »

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 agree the second example is more understandable, but I think most of that benefit comes from named parameters (a language feature), not the naming convention itself. That is, were the naming up to me, I would prefer:

  NSString *filtered = [unfiltered replace:@"verbose"
                                   with:@"explicit"
                                   options:CaseInsensitive
                                   range:Range(0, [unfiltered length])];
Of course, I'm making assumptions about what those parameters mean. But I find this much more clear, assuming the intentions are what I think they are.

Re: Why Objective-C is Hard

#78

Post by btilly »

batista wrote: post #60

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

For one, CLR was designed from the start to support multiple languages, and Java didn't have any major language targeting the VM until like 2004-5.

I can't agree with this. Jython and Rhino started in 1997. JRuby started in 2001. Those are all ports of fairly major languages, and all saw significant use before 2004.

Re: Why Objective-C is Hard

#79

Post by RandallBrown »

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…

and visual studio... It has a WPF frontend anyway. I'm sure it drops into native code pretty quickly.

Evernote actually did a great post about switching from C#/WPF back to a C++ app and how it actually let them move faster. Pretty interesting read. http://blog.evernote.com/2010/10/26/evernote-4-for-windows-i...

Re: Why Objective-C is Hard

#80

Post by glaurent »

I know Objective C, C++, Java and have basic knowledge of C#. Of all these I'd rate Objective C as the easiest to learn and to handle. It's much more forgiving and easy on the programmer, and the syntax is trivial.

You seem to make a big case of the message passing syntax, but your example is very poorly chosen. Rather than 'performAction:withTwoParameters:' it should be 'performActionWithFirstParameter:andWithSecondParameter:' as are most Cocoa methods. Named parameters may seem verbose but they are much more readable than 'performAction(param1, param2)'.

If Objective C is a "large" language, I wonder what you'd call C++ or C#. Huge ? Humongous ? If you think Cocoa is large and complex, the C++ Standard Library or the Java library will make you weep.

Post reply on HN