Comment by berzniz | Hacker News Reader

Comment by berzniz | Hacker News Reader

I actually like the way nil is treated. I'm not a big fan of writing code with guards all the time like this:

// As in C#/Java if (obj != null) { obj.doSomething(); }

At least in javascript it's easier with the && operator:

str && str.doSomething();

In Obj-C you can just:

[str doSomething]; // If you really care if it happened or not, then introduce a check for nil

Once you get used to the idea that nil doesn't break your code, you start writing your methods accordingly.

For me, a lot of the stuff you write about (ARC, Blocks, literals) are the great improvements to the language.

Before ARC you had C/C++ like control of the memory and you could do some crazy stuff like an object holding on to itself and then committing suicide (pretty useful actually). With ARC you only have to care about retain cycles and declaring weak/strong pointers. It's an awesome feature for a non-GC environment.

Blocks are truly the biggest change in Obj-C and made the code much easier to develop. Any async task is now easy to deal with. Alongside GCD, multi-threading is made simple.

What I'm really trying to say is that from the first iPhone OS to iOS7, we've seen some major improvements to the language. If it continues at the same pace, you'll might like it more in your next year's review.

nil is a safety/convenience trade-off -- it can be dang convenient, but it's just begging for hard-to-spot bugs to appear in your code. To use your example:

> [str doSomething]; // If you really care if it happened or not, then introduce a check for nil

Usually I actually care if the code I wrote did something! Writing nil checks everywhere would be non-idomatic and really annoying. (Something like Haskell gives you the best of both worlds, arguably.)

I agree the language has gotten much better. I've worked on two ObjC iPhone projects, one before ARC and blocks, and one after. The impact of blocks, especially, is incredible. So, so, so much nicer. (Also object literals are a nice recent addition.)

That said, the criticisms voiced in this article, which I agree with and think are real problems, are unlikely to go away -- they're just too closely tied up in the core of what objc is. (You're never going to have a nil that throws or a type-safe containers in objc, I'll predict right now.)

I do overall like the language. Especially for GUI code, which tends to have lots of stuff doing relatively straight-forward things, the

   [soSomethingWithaThing:thing otherThing:otherThing frob:someFrob]

style of method naming, while verbose, is awesome -- the code is extremely easy to read, and it's well-neigh-impossible to get bugs by mixing up the method order. (Compare this to e.g. python, where you have neither type system nor naming to tell you if you mess up parameter order.)

There are some annoying circumstances where you still have to check for nil, so it's not exactly consistent. For example:

1. Adding nil to an array triggers an exception.

2. Trying to set a dictionary key/value pair with nil for either value triggers and exception. It'd be more consistent with other parts of the code base if setting a nil value unset that particular key.

3. Calling a block storage variable that's nil will crash.

It'd be nice if these all were no-ops too.

It is consistent though.

Sending a message to nothing gets your nothing. Adding nothing to something that expects something causes an exception.

I suppose it depends on what you consider consistent (i.e., all nil operations should be no-ops or just message-sending operations), but that only covers 1 and 2. Trying to invoke a nil block still crashes.

That's because blocks aren't completely objective-c objects. They can act like them in some cases, but underneath they are still C based. That's why you pass NULL instead of nil to specify an empty block.

All of Objective-C is C based in the end. Blocks are completely Objective-C objects. Attempting to call a NULL block crashes not because blocks aren't Objective-C objects, but because block invocation is not a message send.

Note that accessing an instance variable of a nil Objective-C object pointer will also crash, e.g.:

    obj->_ivar;

That's obviously not because Objective-C objects aren't Objective-C objects. The crash when calling a nil block is the same thing.

>At least in javascript it's easier with the && operator: str && str.doSomething()

Mixing a Boolean check and a potentially side effecting function in the same line of code is a neat hack, but it seems like it would make code harder to maintain. Also, what about handling the non existence of str?

Reply on news.ycombinator.com