Across the [technological] pond

toddha — Thu, 09 Oct 2008 23:50:00 GMT

I haven't been writing much here recently for a few reasons.

1. Seattle is *very* nice in the summer time. Why stay inside blogging when you can go to the Center for Wooden Boats in Lake Union, Pike Place market, or take a ferry to Bainbridge?

2. Got married. We got married back home in Kansas City which took a while to plan for, especially since we were doing it all long distance. Afterwards we went to San Francisco for a few days and took the Coast Starlight train back. It's a very pretty ride, but I recommend you get a sleeper car. It's hard to sleep in coach and you don't get all the dining benefits the sleeper car has.

3. Changed jobs. I'm working on the Mac client for Live Mesh. I found the perfect job; not only do I get to work on UI and client code, but I get to spend my day on Macs (and sometimes PCs). Sure, compared to what I'm used to, the APIs are all different, the language is different, the OS is different, but that's the fun of it.

Assumptions are the mother of all (part 2).

toddha — Thu, 26 Apr 2007 04:33:31 GMT

In my own time, I've been learning Objective-C for fun. I'm not sure why, perhaps I didn't feel I spent enough time in front of a computer. But I digress.

One of the interesting things I've learned is that the following code works.

Note that I assume we have a class named ArbitraryObject, and that it has a method that takes no parameters entitled foo.

Objective-C

ArbitraryObject * obj; obj = nil; [obj foo];

Interesting, this code doesn't crash. In comparison, the following languages all crash when you try to do the equivalent.

ArbitraryObject obj = null; obj.foo();

This is the easy one. We get a NullReferenceException thrown.

Java

ArbitraryObject obj = null; obj.foo();

This is another easy one. We get a NullPointerException thrown.

Python

obj = None obj.foo()

Since we don't have to type what obj is, we get an AttributeError talking about how the NoneType object doesn't have an attribute of foo. Not exactly the same as before, but close enough.

C++

ArbitraryObject * obj = 0; obj->foo();

Note that this isn't the entire code required to get the program to crash (and I'm not sure what spurred me to prove to myself that it wouldn't work). The MS VC++ compiler was optimizing my defects away in different ways. I had to add an instance variable to the ArbitraryObject class, assign it in the constructor, and have foo return the variable. Then in the calling code I printf'd it. But I'm ignoring this for simplicity.

But regardless, it's an access violation error.

What we've proved is that Objective-C works very differently from how other programming languages work. There are some pros and cons of this, depending on your perspective. It's just important to know how things work.

A couple notes :

I use nil, null, 0, and None interchangeably.
I'm assuming the compiler hasn't optimized your (possibly intentional) errors away.
I really have nothing against any programming language or technology, so please don't assume that I'm some [arbitrary technology/programming langauge] basher or fanboy (even though Objective-C is primarily an Apple language, and Apple is a competitor to Microsoft). This is just another example of where you might think things work one way, and work a different way completely.
I find this particular example fascinating.

Performance

Comparing Objective-C performance to C#, Java, and Python isn't really fair as they all have to be translated into machine language at runtime.

However the C++ comparison is fair. What I'm assuming is happening in Objective-C (without diving into PPC assembly) is that there's a check before each function call that says, "Hey, if this address is nil then jump over this block of code that sets up for and executes the function call." So assumedly you have a some extra instructions every time you make a function call. Not a big deal, especially these days where we have a bazillion clock cycles per second, but definitely something that you need to think about if you're trying to squeeze every cycle out of the processor.

Program Flow

This is the main root problems I would assume. I'm going to use C# to flesh out the code, but you can easily translate it to Objective-C. More on this after the code.

Let's go back to our example code and flesh it out a bit in order to prove a point.

public class ArrayWrapper { private static int [] array = new int[] { 1, 2, 3, 4 }; private static int index = 10; public static SetIndex(int index) { ArrayWrapper.index = index; } public int GetIndexedValue() { // note that this crashes if index is the default value return ArrayWrapper.array[ArrayWrapper.index]; } } public class ArbitraryObject { // we don't have to define an empty constructor, but will anyways! public ArbitraryObject() { } public void foo() { ArrayWrapper.SetIndex(2); }}

And now for the driver code function.

public void DriverFunction(ArbitraryObject obj) { obj.foo(); // here we have assumed that obj.foo() did it's job and set the // index of the ArrayWrapper to a valid value Console.WriteLine(ArrayWrapper.GetIndexedValue().ToString()); }

Ok, so this seems like a really stupid example, but it's point is to show that you're assuming that the ArbitraryObject class worked in order for the rest of the function to work.

Let's run some tests. These are based on whether or not obj.foo( ) worked. I'm not going to translate this to Objective-C, but you can easily see what happens.

C# Tests
Valid instance of Arbitrary Object : Wrote out "3" to the console.
Null reference : NullReference exception at line xxxx.

Objective-C Tests
Valid instance of Arbitrary Object : Wrote out "3" to the console.
Null reference : Out of bounds error.

Ok, so we still get an error in Objective-C. And it's relatively easy to debug what's happening. But if the user gets this, the app will have crashed. And they'll get upset. Arguably, they'd get upset in C# too.

But what if the default index was valid? Like 0? We wouldn't crash, but we'd get incorrect results. Which is a LOT harder to debug. But doesn't crash for the user. Maybe it affects the final results that they're looking it for. Maybe it doesn't.

My point to all this is that this introduces a lot of subtleties to debugging something that you have to think about when writing or debugging the code. I'm not saying that it's bad at all. Sometimes you don't care about if the line fails or not -- and you don't have to write a bunch of function calls prefixed with if (reference != null).

Another reason to not make assumptions about the way things work (especially in new programming languages). :)

ToddHa's WebLog : Objective-C

Across the [technological] pond

Assumptions are the mother of all (part 2).