Because of my ventures into the waters of Objective-C I’ve started to take another look at C. Why you ask? This is because Objective-C is just a thin layer on top of C, which means that anything that is written in C is also written for Objective-C.
So do people still use C? I haven’t used it in over 7 years and it was standardized in 1989 (that’s a very long time in computer years). As far as my personal experience goes, no, no one uses it anymore. But is that really the case? According to TIOBE (http://www.tiobe.com) C is the second most popular programming language in the world (C++ is third, C# is seventh.) Apparently, I’ve been hanging out with the wrong crowd.
So everyone is using C, so a simple Google search should return all sorts of cool libraries for me to play with right? I’m interested in game development, so what game libraries/frameworks/engines can I use? (If you’re wondering why I’m looking for libraries in C instead of Objective-C then see here) So I checked out 18 different open source game engines/libraries/frameworks. Only 5 of them where written in C (and a few where pretty dated). Eight of the 18 engines where written in C++, 3 in C#, 1 in Python, and 1 in Java. Most of the professional game engines I looked into where C++ with one notable exception, the ID Tech engine (Quake games) which is C. All this means that about 28% of game engines are in C while 45% of them are written in C++. It defiantly looks like C++ has the home field advantage.
What about something like databases? SQLite is written in C (I’ll post more about it later). MySql is a mix of C and C++, PostgreSQL is C, and Oracle is C and assembly. Here it looks like C is king. I don’t know if this is due to historical reasons (doubtful in SQLites case) or if there is just something about C that tends its-self easer to database development.
While C is popular and a lot of software is still written in it, it seems to come down to what you want to accomplish. Game development has a strong tint of C++. Luckily, if you only care about developing for OS X you can have the best of all worlds. Xcode lets you mix C and C++ with Objective-C.
Thursday, March 19, 2009
First Impressions with Objective-C
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.
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.
Writing about Code
Since it seems that I've been writing a lot about programming, I figured I should park it somewhere in a vain hope that others will find it interesting.
So welcome to iPretendToCode
So welcome to iPretendToCode
Subscribe to:
Posts (Atom)