Why Objective-C is Hard • Hacker News Board

Re: Why Objective-C is Hard

#121

Post by 2muchcoffeeman » Wed, Mar 07, 2012, 1:16 AM UTC

guelo wrote: post #96

batista wrote: post #64

Earlier quoted context omitted.

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…

Uhhh, Android?

Does Android count?

http://en.wikipedia.org/wiki/Dalvik_(software)

"Then they are converted from Java Virtual Machine-compatible .class files to Dalvik-compatible .dex (Dalvik Executable) files before installation on a device. The compact Dalvik Executable format is designed to be suitable for systems that are constrained in terms of memory and processor speed."

And don't games use the Android NDK?

Re: Why Objective-C is Hard

#122

Post by scott_s » Wed, Mar 07, 2012, 2:12 AM UTC

s73v3r wrote: post #117

scott_s wrote: post #76

Earlier quoted context omitted.

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

When you use the word "replace", to most people, that signals that you would be changing the current object in place, not returning a new object based on the given one. On the second line, you didn't mention at all what is passed in. For the last two, removing the NS prefix would work if Objective-C had some kind of namespacing support. Currently it doesn't, so the NS prefix is kinda needed.

New object versus mutating the current object depends on convention - in Python, there is a "replace" function on the native string type that returns a copy (http://docs.python.org/library/stdtypes.html#string-methods); in C++, std::string::replace mutates the string in place.

I'm not sure what you mean by not mentioning what is passed in. Keep in mind: I have never programmed in Objective-C. I am going on intuition alone.

No namespace support is a bummer - it means you're going to end up with long identifiers all over the place.

Re: Why Objective-C is Hard

#123

Post by dkarl » Wed, Mar 07, 2012, 2:14 AM UTC

pooriaazimi wrote: post #109

dkarl wrote: post #99

Earlier quoted context omitted.

I couldn't disagree more. Objective-C is a product of the 1980s, when it kind of made sense that your program would crash if you did this: [NSArray arrayWithObjects:@"Hello", @"World"]; Of course it crashes! You have to add a nil sentinel value to the end of your list of objects, silly. And of course it compiles with only a warning, just like when you leave out the @ that makes the difference between a C string liter…

Thankfully, the NSArray and NSDictionaru madness has been addressed: http://cocoaheads.tumblr.com/post/17757846453/objective-c-li...

That looks really cool, but it doesn't work in Xcode 4.3, unfortunately. I found a bit more information here: http://blog.ablepear.com/2012/02/something-wonderful-new-obj...

Apparently it's a feature in Xcode 4.4 in the beta release of the Mountain Lion SDK. There's no developer preview for Lion, though. Fingers crossed that Xcode 4.4 will be released for Lion and not just for Mountain Lion....

Re: Why Objective-C is Hard

#124

Post by scott_s » Wed, Mar 07, 2012, 2:16 AM UTC

dkarl wrote: post #99

zoul wrote: post #42

People 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 disagree more. Objective-C is a product of the 1980s, when it kind of made sense that your program would crash if you did this: [NSArray arrayWithObjects:@"Hello", @"World"]; Of course it crashes! You have to add a nil sentinel value to the end of your list of objects, silly. And of course it compiles with only a warning, just like when you leave out the @ that makes the difference between a C string liter…

What in the parent post do you disagree with? It's probably obvious to you, but it's not obvious to me.

I understood his point to be mostly that syntax melts away after time, and you will just see the concepts. It seems that you are objecting to the notion that "Programming in Objective-C is easy," but I don't see that in his post.

Re: Why Objective-C is Hard

#125

Post by Deinumite » Wed, Mar 07, 2012, 2:33 AM UTC

glaurent wrote: post #80

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

Actually the C++ STL is known for being pretty small... that also depends on if you even count the C stuff that C++ includes.

Re: Why Objective-C is Hard

#126

Post by cageface » Wed, Mar 07, 2012, 2:50 AM UTC

glaurent wrote: post #80

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

The C++ standard library is actually quite small. Check Herb Sutter's keynote at Going Native 2012 for an entertaining visualization of its size compared to the Java or C# standard libraries: http://channel9.msdn.com/Events/GoingNative/GoingNative-2012...

Re: Why Objective-C is Hard

#127

Post by mdonahoe » Wed, Mar 07, 2012, 3:00 AM UTC

groovy2shoes wrote: post #119

jimbokun wrote: post #111

Earlier quoted context omitted.

Best I can tell, all of the problems you cite are fixed by MacRuby. It shows how surprising well Ruby semantics maps onto the message passing semantics of Objective C. They also found ways to wrap up the C stuff without making you manage your own memory. Not sure why Apple hasn't been more aggressive in pushing it for Cocoa development. Maybe because they don't trust it to perform well, yet, on iOS devices and don't…

> It shows how surprising well Ruby semantics maps onto the message passing semantics of Objective C. This is not surprising given that both Ruby and Objective-C xeroxed their object models from Smalltalk.

"xeroxed"

Clever, Mr. Kay

Re: Why Objective-C is Hard

#128

Post by cmelbye » Wed, Mar 07, 2012, 3:28 AM UTC

I personally love the syntax of Objective-C. I find it very readable. I wish I could use it more often.

Re: Why Objective-C is Hard

#129

Post by stream_fusion » Wed, Mar 07, 2012, 3:56 AM UTC

dkarl wrote: post #99

zoul wrote: post #42

People 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 disagree more. Objective-C is a product of the 1980s, when it kind of made sense that your program would crash if you did this: [NSArray arrayWithObjects:@"Hello", @"World"]; Of course it crashes! You have to add a nil sentinel value to the end of your list of objects, silly. And of course it compiles with only a warning, just like when you leave out the @ that makes the difference between a C string liter…

> You should typically not manage scarce resources such as file descriptors, network connections, and buffers or caches in a dealloc method. In particular, you should not design classes so that dealloc will be invoked when you think it will be invoked.

Do they propose an alternative mechanism to handling resources other than reference counting? As you state, RAII breaths life into c++, given how well it works for all types of resources.

It sounds like the above statement is possibly being made in anticipation of the introduction of garbage collection, which would make piggybacking resource destruction non-deterministic. Whereas, it could also be interpreted as a very strong reason to favor manual (maybe automatic) reference counting, and eschew GC entirely. I don't know objective-c very well, but I wonder if the use of GC has generated these arguments against it from within the OSX developer community.

Re: Why Objective-C is Hard

#130

Post by dkarl » Wed, Mar 07, 2012, 4:11 AM UTC

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…

Avoiding GC doesn't equate to "manual memory management." Objective-C uses reference counting, which is only manual in Objective-C for historical reasons, and they're trying to overcome that with ARC. I'm pretty sure most popular scripting languages use reference counting instead of garbage collection. C++ with pervasive use of shared pointers shouldn't be characterized as "manual" either.

Also, as of a few years ago, the only performance-related reason why the JVM wasn't a popular language for desktop GUI apps was startup time. (In the mobile space, it might be true that Java isn't fast enough on current hardware. My experience with Android hasn't been very inspiring, for sure.)

Keep in mind that desktop GUI frameworks take a HUGE amount of time and labor to create, and almost all of the excitement has been in web apps for the last decade. The status quo in GUI frameworks is heavily colored by history. All of the major GUI application frameworks are ancient and reflect the linguistic realities of the year 2000 much more than they reflect current technology.