[cschep]

"Objective-C sucks" is just silly. If you know and like C#, of course you'll like developing for WP7 more. Weird that he talks about null references in Objective-C but you can send all kinds of messages to nil and you'll be fine. Not so in C#/Java.

[S_A_P]

I actually was just wishing c# had as terse of a null check syntax as ObjC. I love the fact that I can type

if(!object)

  [[Do something]about it]

vs

if(object == null)

  DoSomething.Aboutit

I know its a small thing, but my typenames are usually lengthy so in practice C# statements can get character heavy.

[nlogn]

This is actually really easy to do in c#:

  public static bool operator true(Class c)
  {
      return c != null;
  }

  public static bool operator false(Class c)
  {
      return c == null;
  }

To avoid redoing this for each class you can just derive from a base class that implements these.

[S_A_P]

well I know that it is possible, I was thinking of trying to write a similar type function with an extension method, but I just like how its included out of the box in ObjC. Really I think for a general purpose language C# is more flexible and while leveraging .NET you have more tools available to develop rapidly.

Part of me feels that Im not "really programming" when I write managed code though. I like writing C and ObjC because I feel like Im actually flipping switches on the CPU. It is silly I know(and all in my head), but being lower level seems to excite me more.

In reality I think its all about the right tool for the job, and choice is good.

[ektimo]

I meant it doesn't complain when sending a message to a nil object though this is probably not what you intended and makes tracking down bugs harder... or maybe I just have C++ mindset.

[alextgordon]

I think when many people hear about ObjC's nil semantics, they use it as a pretext for dropping all their null checks. This is a mistake, and you're right, it will make debugging exceptionally difficult when nils start falling through five levels of functions and propagated through ivars.

The trick is to use null checks almost like you're writing C++, but drop them when they are unnecessary and inelegant. Convince yourself that a null check is unnecessary before removing it. This way you're reducing the chance of bugs and making them easier to pinpoint.

For example, you can do:

    if ([someArray count])

rather than

    if (someArray && [someArray count])

On the other hand, you may be asking for trouble if you do

    [[someArray lastObject] dance];

without checking [someArray lastObject] for nil, since if someArray is empty, then nothing will dance and you won't know about it.

tl;dr: Messaging nil is not idiot-proof but it makes code read better.

[ryanpetrich]

The worst offender is the comparison methods:

    NSString *myString = nil;
    if ([myString compare:@"something"] == NSOrderedSame) {
        ...
    }