Why Objective-C is Hard • Hacker News Board

Re: Why Objective-C is Hard

#131

Post by aufreak3 » Wed, Mar 07, 2012, 4:50 AM UTC

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…

It's good to remember Jeff Raskin's theorem "intuitive = familiar". If you come from the C++ world, Objective-C is going to look weird. If you come from the Smalltalk world, not all that weird.

Also, syntax is the worst place to start learning Objective-C imho 'cos there can be a lot of it to learn if you come from a non-smalltalk world. The best place I've found is to dive straight into the core runtime function objc_msgSend. Once you grok that, and see that you could write down the core runtime in a handful of C functions in an hour or so, everything else -- classes, categories, protocols, delayed invocation, remote invocation, proxies, posing, key-value coding -- finds a "natural" slot in your brain. As a bonus, as you get to the more "advanced" features unique to the system (relative to, say, C++) such as key-value coding, you see how the dynamism of the language plays to support all of that. (Disclaimer: Yes, this is how I got it, but I don't know whether it is generally good way to approach it, though I'd recommend it. Maybe I should write a tutorial on it.)

If you start by looking at the syntax and going "ugh", you'll be missing all the neat ideas in the system ... including, imo, the older memory management system that many complain about. I've, for example, used the "auto release pool" idea in C++ to relieve colleagues of the need to think about ownership and lifetime in relatively isolated corners of a system while considerably simplify api design and staying performant. If you're looking for "predictable performant garbage collection", this is a reasonable design candidate.

Re: Why Objective-C is Hard

#132

Post by SeanLuke » Wed, Mar 07, 2012, 5:33 AM UTC

batista wrote: post #70

SeanLuke wrote: post #68

Earlier quoted context omitted.

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.

> 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

(I'll use lisp conventions, it's what I'm used to)

What you're saying is for coders, saying

    (doit x y :withFloat 5 :key "string")

has no important distinctions with

    [foo doit:x:y withFloat:5 key:"string"]

But keywords have defaults if they're missing. And furthermore you can have them in any order. So to implement the equivalent of the Lisp method above, I'd have to implement all of the following methods in Objective-C

    doit::withFloat:key:
    doit::key:withFloat:
    doit::withFloat:
    doit::key:
    doit::

That's just for two keywords. What happens when you have ten?

Re: Why Objective-C is Hard

#133

Post by Argorak » Wed, Mar 07, 2012, 6:05 AM UTC

chc wrote: post #27

ahlatimer wrote: post #24

Earlier quoted context omitted.

The guidelines for Ruby are to add a bang (!) to any methods that mutate the object rather than returning a new one. That's not strictly followed, though, but for most of the commonly used standard library bits, you can be fairly certain that that is the case.

In practice, even in the standard library, this isn't followed often enough to rely on. Here's a (possibly incomplete, since I'm writing this on the fly) list of bangless mutating methods just from Array: pop push shift unshift As an even more extreme example, IO contains precisely one bang-method, despite the fact that probably 75% of IO's instance methods are destructive. The general rule seems to be that if there'…

The guideline is: if your method does something that the programmer should think twice about or shouldn't use without proper knowledge (e.g. didn't read the docs), use !. An incomplete case of usages:

  - There is a safer alternative (e.g. mutating vs. non-mutating or skipped validation)
  - It should only be called once in a process (e.g. Padrino.start!)
  - It is non-reversible (many statemachine libraries use action! as the way to invoke state transitions, which might not be reversible)

This doesn't mean that every method needs to be suffixed by ! if it does something destructive. `delete` in the context of an ORM is standard, so it doesn't have a bang. The whole point of `pop` is to manipulate the receiver: no point in warning about it. IO is always destructive, so ! doesn't make sense either.

Re: Why Objective-C is Hard

#134

Post by dkarl » Wed, Mar 07, 2012, 6:42 AM UTC

stream_fusion wrote: post #129

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…

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

That's an interesting hypothesis, but I can't find any source to confirm or contradict it offhand. The part I took the quotes from only mentions that the order of dealloc'ing objects in a collectable object tree is undefined, as is the thread on which dealloc is called. Both of those are easy to keep in mind while implementing dealloc, though. If a resource has to be freed from a particular thread, then dealloc can schedule it to be released on the right thread using GCD. The non-deterministic order of dealloc'ing would rarely be a problem for releasing resources. After all, if a resource is only used via a particular object, and that object is dealloc'ed, then clearly it's okay to release that resource! Perhaps there are complicated cases where resources have to be released in a particular order, but that's no reason to give up RAII for simple cases.

Re: Why Objective-C is Hard

#135

Post by signa11 » Wed, Mar 07, 2012, 8:15 AM UTC

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…

> People fret over language syntax too much. In most sane languages including Objective-C you simply forget about the syntax after a few months.

language syntax and it's consistency is (imho) the UI of the language. you get put off by ugly as often as you care to look at it...

Re: Why Objective-C is Hard

#136

Post by pjmlp » Wed, Mar 07, 2012, 9:20 AM UTC

I don't understand all these comments about Objective-C being hard.

Maybe it is because I am programming computers since the Z-80 days, or because like it is expected in my country I did a good earned CS degree.

If you think using a language like Objective-C is hard, maybe you should not be programming at all.

Re: Why Objective-C is Hard

#137

Post by batista » Wed, Mar 07, 2012, 9:22 AM UTC

dkarl wrote: post #130

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…

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…

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.

I don't think so. Besides startup time, Swing was always slow --an over-engineered mess. For some Java people it was always "fast enough in the latest version" (like for some Linux people it was always "the year Linux wins over the Desktop"), but even the best Swing UI had perceptible lags over a bog standard native. Heck, even SWT that's half-native has huge GC related lags in Eclipse.

Swing also had the uncanny valley effect, trying to mimic native UIs. And even when they tried to bypass the issue with custom l&f like Alloy et al, they couldn't, because the uncanny value is mostly due to how the controls BEHAVE and not with their style (that's why in, say, OS X, you can use apps styled like Aqua and others styled like Metal at the same time and you don't get the "uncanny valley" effect).

Re: Why Objective-C is Hard

#138

Post by julik » Wed, Mar 07, 2012, 9:28 AM UTC

Well, from my limited experience with Objective-C a few things made it hard.

The first is the traditional Cocoa pattern of a method that does useful things, which looks like this:

  - (void)beautifullyNamedMethodFor {
  	void* ugly_ptr_type; // and around 45 more
  	CFObscurePtrRef* .. = CFObscureObsoleteFunction(NULL, NULL,.....); // 56 arguments
  	// to the callback omitted for brevity
  	...*....(*foo)...->(*x++);
  	// and so one - with 45 lines of NULL ptrs passed as void* to CF calls
  	// juggled and incremented ad absurdum until your eyes bleed.
  }

So on the surface it's a beautiful Smalltalkish thing, while down below it's usually all hairy C, pointers and null-terminated strings and Core Foundation callbacks right out of MacOS 7 (especially if you want anything useful to be done that is not in Cocoa by default). This always seemed to me to be a deception in a way.

Another pet peeve of mine is the same agony of choice that is object variables (pointers versus values). When I want to return something or declare a variable, even when I am in the rose-tinted-glasses Cocoa world of beautifully-named methods, classes and keyword arguments I still have to put the dreaded death star in front of just the right things (and to remember NOT to put it in front of exactly proper other things).

So I guess for me the most problematic Objective-C part is the one that has to do with C (because it adds a level of complexities on top of C). The "Objective" part is actually very nice, once you get used to the call syntax and the brackets.

Re: Why Objective-C is Hard

#139

Post by unicron » Wed, Mar 07, 2012, 10:04 AM UTC

cageface wrote: post #114

unicron wrote: post #94

Earlier quoted context omitted.

I've put together a few things with Objective C over the years dating back to OSX 10.1 (yuck PB sucked then) to iOS. Most ended up being ported to Java or C#. The syntax IS absolutely horrible if you ask me as it results in crazily verbose ways of expressing stuff. Everything is "too meta" and there are very few first class parts of the language. It still FEELS like it's hacked together with C macros (which was what…

Also the lack of any decent threading abstraction - ick. What? Grand Central Dispatch is a lot easier to work with than most explicit threading mechanisms and with the new block support is a lot less verbose than the typical Java thread-based approach.

It's just a fancy thread pool/task queue with a fugly syntax extension not some magic unicorn that poops rainbows.

Java/C# don't need a language extension - the functionality exists outside the semantic boundary of the language. Another cludge in Objective-C.

C# (ThreadPool/async framework/Windows workflow) and Java (ExecutorService/lots of 3rd party frameworks) have had them for years with well-known communication, thread safe data structures, concurrency and locking semantics.

Most of the verbose mess you see in Java threads is because the person writing it doesn't know much.

Re: Why Objective-C is Hard

#140

Post by unicron » Wed, Mar 07, 2012, 10:16 AM UTC

pooriaazimi wrote: post #110

_delirium wrote: post #90

Earlier quoted context omitted.

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

Nothing, not even a Flash video makes my MacBook Pro hotter than 5 minutes of Minecraft...

That's because your MacBook Pro is poorly designed. I had the same problem with mine. One reason I sold it - impossible to sit with it on my lap.

Another example: http://www.youtube.com/watch?v=5AZzPZ0kjyk

I now had a ThinkPad X220 which is roughly the same CPU as the MacBook Pro and has twice the memory and it never even gets warm.