Programming or Writing?

Mar 17, 2009 12:20

I've been conflicted lately. This is because I'm a writer, I've declared it, realized it, internalized it, and accepted it. (also I love to write). But at the same time there is something that I find enjoyable about programming. So much so that I've failed at every attempt to remove programing from my life. Kassi thinks I should just go with it, that I can be a writer and a programmer. But I still have some reservation about it.

I've started to learn Objective-C, the programming language for Macs and the iPhone. So far I really like it. The philosophy and syntax around it are quite different from anything I'm used to. In most Object Oriented Languages, You have very strict classes with inheritance and methods; properties for accessing those classes. And in most OOLs (Object Oriented Languages) you have something called generics so that you don't have to keep creating new classes because of a type difference. (Types are like numbers vs strings BTW.) If I have a list of integers (numbers) then I don't have to make a second list just so I can have a list of strings. In fact a lot of time and effort goes into this sort of thing. (There is also the fragile base class problem.) This is where Objective-C really shines.

Objective-C is C with SmallTalk features added. The biggest difference is how object methods are called. In C# (or C++ or Java or whatever) if you want to call a method you use the '.' dot operator (or '->' arrow operator in C++.) For Example, pretend 'Cat' is an object with a single method of 'Speak'. In C# you would write 'Cat.Speak();' to call the Speak method of the Cat object. In Objective-C however you don't call methods directly. You pass messages to objects. So in our example we would write '[Cat Speak]' in Objective-C. On the surface this looks like a small syntax change. Instead of a '.' operator you place the items in '[]' brackets with a space. But what these two items actually do is the key.

In C# the Cat method must have a Speak method or else it will throw an error. And that Speak method's signature must match exactly. (signature is the Return Type and all the parameters [in order] on the method.) In Objective-C on the other hand, the Cat object doesn't need to have a Speak method. If it doesn't, the call will simply return false. No errors will be thrown. (Warnings will be thrown since we did specify a type.)

"But Chris!", you say, "That's one of the strengths of C#!" (I don't know why you use so many exclamation marks, I can hear you, I promise.) And you're right, type checking is a strong feature of those languages. You could tell Objective-C to throw errors in these situations. But let me explain why this is such a good thing.

If you've ever programmed a larger application, then you will be familiar with the concept of boxing and/or generics. (I'm going to stick with C# examples.) Now let's say you write an application for a pet hospital. You need to keep a list of all the pets in the system. Let's also assume each type of pet has it's own class. (Cat, Dog, Snake, Hamster, Birds, Fish, pygmy goat, etc.) You have two choices: You could use boxing to add them all to an ArrayList of objects (because all classes inherit from object). Or you could use Generics to create a list for each type of Animal. Both of these methods are reasonable but have problems. They both require you to know the type of the object at compile time (or be able to get the type so you can cast it.) The reason is, not all of the animals will have the same methods. Not all of them can 'Speak' or 'Fly' so if you need to call those methods, you need to know the type at compile time or else an error will be thrown. Now there are creative ways to get around this problem. Which is why I said a lot of code and time is spent trying to get around this issue in the first paragraph.

But this really isn't a problem in Objective-C. You can store all the animals in a single list, and not worry about if they implement 'Speak' or 'Fly'. You can call the methods on ALL of the objects. Only the ones that actually implement the method will do something. All the time and energy to get around this problem in other languages is simply a non-issue in Objective-C. This isn't Objective-C's only strength, just one that I thought was most relevant to my daily programming.

There is one tremendous problem with Objective-C. The base classes (called Foundation) are Mac only. GNUStep tries to implement Foundation and some others on Windows and Linux but the downside is to great. Window users would have to install GNUStep (which isn't an easy process and involves MinGW) in order to use anything in Objective-C. Until Foundation can either be statically built into the application, or a simple (like a DLL) way to include it is developed, I'm afraid Objective-C is going to stay Mac only. Not only that, but in limited use on the Mac (you can use C++ on the Mac).

Apple pushes Objective-C but that just isn't enough in my opinion. Someone (preferably Apple) needs to make at least the core classes available for the three major operating systems (Windows, OSX, Linux). If there where to happen, then I think Objective-C could gain a lot of traction. Over time it could gain more support than C# or Java, or maybe even C++. But for now that is just my fantasy. I can use Objective-C for iPhone development and OSX development. That will have to be enough for now. I'll just stick to C# for my windows development.

programming

Previous post Next post
Up