I see a lot of debate going back and forth on which language to use to develop real-time 3D games, and the general consensus is that C or C++ are the only languages that can offer suitable performance for high-end, system-intensive 3D games. I see a lot of people saying C#, Java or Python are too slow, particularly because of garbage collection. How about Objective C? Does Objective C have automatic garbage collection? What besides Automatic Garbage Collection make a language 'too slow' or unsuited for 3D games?
This question is probably more of a 'thought experiment' since I doubt I'll ever develop a game that is so resource heavy that these questions need to be addressed, but being a programmer, I'm inexplicably obsessed with performance, so I'd still like to know just for my own jollies.
Objective-C 2.0 has garbage collection available on Mac OS X 10.5, but it is optional -- you can still compile Objective-C apps without garbage collection if you so choose. On other platforms (iPhone, Mac OS X pre-10.5, and anything else), there is no garbage collection, and you have to manually manage your memory.
Objective-C is a strict superset of C, so you can code plain C in Objective-C if you want. Hence, there's no reason not to use Objective-C for games that wouldn't also apply to using C. You can use the extra features Objective-C provides as much or as little as you want.
The only real slowdown with Objective-C itself would be the messaging mechanism—and even then, it's usually components of the Cocoa framework that would slow things down. Objective-C's message sending doesn't really hurt performance that much.
Anyways, for most games, the majority of the performance bottlenecks will come from graphics code: if you delegate graphics stuff to OpenGL, which is ridiculously fast, then there really should be no problem with using Objective-C for games. The only other place where I can see Objective-C or Cocoa providing bottlenecks would be for intensive physics code—and that should probably be written in pure C/C++ anyways. Everything else, though, shouldn't really matter that much.
To be honest, I'd wager that the majority of OS X games nowadays are written in Objective-C using the Cocoa frameworks, with the performance-sensitive code written in pure C/C++ (and with graphics code utilizing OpenGL).
I'm also interested in the topic and i found this
http://wiki.gnustep.org/index.php/3DKit
It looks quite dead but now with clang/llvm 2.9 many of the goodies of Objective-C 2 are available on linux and could be interesting to have 3D API.
Objective-C does not have automatic garbage collection. Java has various methods of garbage collection and some of them are designed to be compatible with games by occurring incrementally at regular intervals. I would be surprised if C# or anything else which also had garbage collection didn't have multiple methods to choose from, some of which are compatible with games.
The only thing off the top of my head that would might make a game unsuitable for 3D games would be if it were interpreted and particularly slow in its implementation. That's not a characteristic of anything you listed above.
P.S. To address your original question, I'm pretty sure anyone who has an iPod Touch or iPhone will be able to tell you that Objective-C is definitely up to 3D games :)
Related
I'm starting to build a real-time raytracer for iOS. I'm new to this raytracing thing, all I've done so far is write a rudimentary one in ObjC. It seems to me that a C-based raytracer is going to be faster than one written in ObjC, but the ObjC one will be far simpler, as object hierarchies come in very handy. Speed is very important, though, as I want it to be real-time, say 30 fps.
What's your opinion on whether the speed up of C be worth the extra complexity? I can forsee the C code taking much longer and causing me headaches with lots of bugs (although I'm not new to C), but going for more speed is seductive initially.
Are there any examples out there of raytracers written in C? My google search for such things is contaminated with lots of results for C++ and C#.
If you want fast ray tracing, you can pretty much forget about using either C or Objective C. You almost certainly want to use OpenCL. It's still not going to be enough to get you (even very close to) 30 fps, but it'll probably be at least twice as fast as anything running on the CPU (and 5-10 times faster wouldn't be any real surprise).
as zneak stated, c++ is the best combination for speed and polymorphism.
however, you can accomplish something close by reducing the objc calls (read: reduce the polymorphic interface to the minimum set required, then just putting the parts that need to be fast in plain c or c++).
objc message dispatch is quite fast, and you can typically remove much of the virtual/dynamic methods from your interfaces (assume every objc instance method is virtual). c code in objc methods is still c code... from there, determine where your bottlenecks are -- it doesn't hurt to profile before changing working code, either ;)
Writing a "realtime Raytracer" is without the use of Hand-Optimized Assembly (or the use of the "cheap" Intel compiler ;) , but this is not possible for this platform), impossible because you need the speed.
Further more you need a lot of Processing power but i guess even the OpenCL path is not powerful enought (this is in my opinion the case even for real Desktop machines, the reason for this is the lack of an real big cache on the Graphics Processor).
Have a look through http://ofps.oreilly.com/titles/9780596804824/ that is as close as you'll get.
It isn't ray tracing, I have written a ray tracer and it is a huge amount of work. GL uses a different technique for graphics, hence it will be unable for example to render the capacity of a diamond to capture light. that link contains sample code, you can download and run it. You will realise that even some of the moderately complex examples really chug on an actual device... we are talking < 1 fps.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am currently a c# developer(one year's working experience with bachelor degree in china), now there is another job opportunity as an objective c engineer and i am kind of interested in that position. but what bothers me is the future of objective c, is it a dying language living in the shadow of c++, java and c#? or it is a good language to stick to?
thanks.
On the Mac it's definitely alive and kicking. Also the IPhone. So if you like working on those environments and systems then go for it.
As far as everywhere else it hasn't really caught on much that I'm aware of. Not to say that it couldn't though. Lots of good languages catch on relatively late, like erlang for instance, so I wouldn't count Objective-C out.
Not to mention the value of learning a new language and stretching yourself.
So, if you are asking will this help further my career? then one answer is yes learning something new can be of benefit to a beginning programmer.
If you are asking will experience with Objective-C itself be marketable? then the answer is yes if you want to work in the World of Apple software.
Objective-C is widely used on Mac OS X and the iPhone OS, so it's not likely to go away anytime soon. It forms the basis of OS X. Most Apple and third-party apps are written in Objective-C, and Apple is even rewriting the OS X Finder in Objective-C, so it looks like it'll be sticking around for a while.
It's definitely not living in the shadow of C++, Java, and C#, especially on OS X. (I personally think Objective-C is a much better language than C++, Java, and C#, but that's just my opinion.) It has a different feel than those languages (due at least in part to its dynamic, rather than static, nature), but it's not really living in the shadow of them.
It's worth learning if you want to develop for the Mac or iPhone, but it isn't used widely outside of those platforms, so if you're not interested in that line of development, I suppose it's not worth it to learn.
As others have said, Objective-C is alive and well on Apple's platforms (namely, OS X and the iPhone).
Additionally, it sounds like Objective-C will show you a whole new different approach of doing OO work. Considering the strong typing of C++, Java, and C#, Objective-C is very different, as it's built on true dynamism. I personally find it a joy to work with, much moreso than Java or even C++. I particularly like how the delegate system works, as well as the borrowed Smalltalk syntax.
Plus, being a simple superset of C, it's really easy to learn Objective-C. It should only take a couple hours at most to get the syntax down, and from there, it's down to learning about the library (which has good documentation). When learning it, you should try to not get into patterns that you normally do with the other languages you listed, as you won't get the full benefit of its dynamic typing.
FWIW, Objective C is about the same age as C++ and both predate Java and C# by quite a few years. I honestly think that the C++ and Java communities could learn a lot from Objective C. IMHO, the NeXTSTEP API is much cleaner than the Java library. Really writing code in Objective C with the Foundation and AppKit (et.al.) gives you a good appreciation of MVC architectures and how cleanly they can be implemented.
Anyway, I think that it is quite worth the effort to learn a language like Objective C. If for no other reason than to gain a greater understanding of what shaped languages like Java.
It really depends on your career direction. As the other posters say, if you switch to Objective C I think you will learn a lot and probably have some fun (and some pain) along the way.
Because objective c is so much closer to C and to some extent C++, you will end up being more employable in not just objective c, but c, and C++.
C is mainly used for lower level programming such as for hardware devices. So if you have a special interest in hardware devices you could go Objective C -> apple kernel device drivers (which are c), and then any hardware programming job.
If you just want to make websites, and basic desktop apps for windows, stick with C#.
I don't think Objective-C will be dead in a long time, because it is at the core of Mac OS X. If Apple should come with more modern languages I am sure it would be a dynamic language built on the Objective-C runtime to allow easy reuse of existing software and components. That would mean one would probably continue to use Objective-C for performance critical parts. Just like python developers still write parts of their code in C.
And because Apple controls the language I think it is more likely with rapid improvements in the language to keep it relevant than say C++.
Objective-C might get used more on other platforms in the future. It was back in the OpenStep days. But when Apple bought NeXT they stopped making Cocoa and Objective-C available on other platforms. The compiler is still available everywhere but not the frameworks and runtime. The new CEO might be more open minded than Steve Jobs about making ObjC available elsewhere.
I'm looking for strategies and articles on making Carbon code 64-bit ready.
Carbon for 64-bit does not and will not exist. It's pretty much a dead end.
So in order to bring Carbon application and toolkits to 64-bit their GUI part will have to be re-written in Cocoa and Objective-C, right?
How can I minimize the effort I have to put into the transition? How can I minimize the amount of needed Objective-C code?
So in order to bring Carbon application and toolkits to 64-bit their GUI part will have to be re-written in Cocoa and Objective-C, right?
Yup.
How can I minimize the effort I have to put into the transition? How can I minimize the amount of needed Objective-C code?
Learn Cocoa. Read The Objective-C Programming Language and the Cocoa Fundamentals Guide. Become familiar with MVC, KVC, and Objective-C. Bookmark the Foundation and AppKit framework references. Learn to love Interface Builder, for it is your friend (moreso in Cocoa than it ever was in Carbon).
Get good at Cocoa. Read more Guides (if you're still on Leopard, use [1] instead). Write as many throwaway apps and even real apps as you can get away with in whatever time you have available. If you can, give them away under a BSD license, and write reusable source code and give that away, too. People will find bugs and some will tell you about them, and some will submit patches. Get to be able to write a complete app with a model layer, no more than two controllers, and at least one custom view or cell in a day.
Read the Carbon Porting Guide, then port your app.
I came from Carbon myself. It's completely different—you may as well start fresh, ignoring your previous Carbon experience, and maybe you won't make some of the early mistakes I did (like skipping the model layer).
As for your app, you probably have a lot of surgery to do, as Carbon did not force you to keep UI and logic separate like Cocoa does. Cocoa enforces MVC; if you don't adhere to it, you pay the price by reinventing wheels and making and correcting mistakes.
That makes Cocoa sound like more work, but it's not. Porting is hard (inevitably), but otherwise, Cocoa is quite the opposite: Writing (and reading!) a Cocoa app is much easier than writing (and reading) a Carbon app. Once the porting is over, you'll be glad you switched.
Oh, and many people will recommend one or both of Cocoa Programming for Mac OS X by Aaron Hillegass and Programming in Objective-C 2.0 by Stephen Kochan. I have the first book, and have read some of it, but that was after I had already learned Cocoa, so I can't earnestly recommend it; that said, it is not bad, and I don't think you'd do wrong to read it. I have not even seen the second book, so I won't say anything about its quality.
[1]: file:///Developer/Documentation/DocSets/com.apple.ADC_Reference_Library.CoreReference.docset/Contents/Resources/Documents/documentation/Cocoa/index-date0.html (Stack Overflow won't let me link file: URLs)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Do I really have to learn Objective-C to develop solid Mac Apps?
As Mac users tend to use only applications that have a nice (native) GUI, i don't think that Mono and GTK+ or any Java GUI (Swing) will fit their needs.
There are projects like Cocoa#, PyObjC and RubyCocoa, but are they ready for primetime?
So do I really have to learn Objective-C ?
I would prefer a dynamic language.
Objective-C is a dynamic language, as far as the Objective-C parts go. Here's a little summary article: http://www.macdevcenter.com/pub/a/mac/2003/04/28/objective-c.html
The syntax is scary at first, but it grows on you. I suggest biting the bullet and slogging through it.
If you want to work at a "real job" doing Mac programming with other people, you're going to need to know Objective-C (in my opinion, anyway).
I think the short answer is yes, you need to learn Objective-C.
The Python and Ruby "bridges" work, but it's not what Apple is pushing or using itself. A few years ago there was a Java bridge to Cocoa but that's now deprecated. Who knows what will happen to the non-ObjC languages?
In any case, Objective C is pretty dynamic. Not in the way that Ruby/Python are perhaps, but it's certainly not like C++.
Short answer: YES :)
Our first app was built in Python, using the PyObjC bridge. From experience I can tell you that to build an application with a bridge you need to learn:
The idiosyncrasies of the bridge
To read and write code in the bridge language (Python in my case)
To read code in Objective-C (All useful sample code is in Obj-C)
To write pseudo-code in Objective-C (if you ever want to ask questions on a mailing list or likewise)
Cocoa
Of all those things to learn, Cocoa is the biggy. It's where the really interesting stuff comes in and the thing you really need to wrap your brain around. After working on this PyObjC project, it's become pretty easy for me to code in Obj-C, even though I had no prior experience coding in C.
So my advice is: Focus on learning Cocoa, and use the language that's most suited as a tool to do that (Obj-C). If you ever find a particular reason to use a bridge, such as having a need for an ORM that can deal with networked SQL, etc. you can apply around 90% of what you learned writing your first Obj-C/Cocoa app(s) in the bridged project.
Finally: I don't really understand the resistance many people who're new to the platform have to learning Objective-C. Isn't it exciting and gratifying to learn new stuff and build the best possible things armed with this new knowledge?
You definitely need to learn Objective-C even if you choose to use one of the bridges. Apple has already shown by their treatment of Java that they're not really interested in providing huge amounts of support or backwards compatibility to the use of Cocoa through anything but Objective-C.
So use one of the bridges, if you like, but have a firm grasp of the Objective-C runtime and the bridges so that you can manage them yourself, if need be.
Do I really have to learn Objective-C to develop solid Mac Apps?
Currently, yes.
As Mac users tend to use only applications that have a nice (native) GUI, i don't think that Mono and GTK+ or any Java GUI (Swing) will fit their needs.
Correct.
There are projects like Cocoa#, PyObjC and RubyCocoa, but are they ready for primetime?
Cocoa#: I don't know, as I don't use C#.
PyObjC: Sort of, but Cocoa in Python is a bit of a hack, since Python isn't Smalltalky enough.
RubyCocoa: Maybe. I'm waiting for MacRuby to mature, though. See also:
Jens Alfke on MacRuby
Jesper on MacRuby
There are a small number of successful Cocoa apps written in bridged languages, so you don't necessarily need to use it that much, but you do need to learn it. People who try to learn to write Mac OS programs in bridged languages do themselves a huge disservice. The bridged languages are great tools, but they are the sort of things that allow someone with a knowledge of the bridged language and Objective C to become extra productive, not skip learning Objective C.
In order to use something like PyObjC or MacRuby effectively you need to really have a good understanding of how the native runtime works to deal with all the impedance mismatches that can occur between the bridged language and the Objective C runtime.
Short answer is yes, longer answer is "you can use Objective-C++." Either way you're going to have to learn at least some of Objective-C. Once you start digging into Cocoa (the framework for building Mac OS X apps), the Xcode tools, and the Apple Human Interface Design guidelines, you'll realize that Objective-C is the way to go.
Not only you have to know Objective-C (the easy part), you must be very comfortable with plain old C. That's in my opinion the biggest challenge for most people.
If you already know C, Objective-C is pretty easy to learn.
Ruby and Python are both viable for "real" Mac apps. ADC has a few articles on the topic. MacRuby looks like it will be replacing RubyCocoa.
I would still recommend learning Objective-C though. Most of the example code you find will be in Objective-C and the books tend to be Objective-C (though the Pragmatic Programmers have a RubyCocoa book in the works. Most Cocoa apps are written in Objective-C.
And Objective-C is dynamic. Take a closer look at it, it isn't nearly as intimidating as people think. It's Cocoa that tends to have the steeper learning (or unlearning) curve.
No you don't have to learn cocoa however it is worth looking at because it is an incredibly powerful api and very well documented, if you already know C then its very easy (honestly it is - i know it looks daunting syntactically).
The problem with the bridged approach on OS X is it seems to be very immature and only really designed for people who are prepared to read the documentation associated with the main cocoa api.
In all honesty if you know c you will pick up the basics of obj-c with a book, the one by Arron Hilligas (spelling?!?!) is superb.
If you try hard enough, you can go about producing software without using Objective-C that has the potential to be great except for the fact that at the end of the day it won't be very good. You will spend more time trying to harangue a language into doing something that it isn't the absolute best at. At WWDC I wore a shirt that said "Learn Objective-C or Retire" which didn't go over too well with some people who still held dearly onto the last threads of Pascal's life, but the point is altogether true - Objective C is where it's at on the Mac and to pretend otherwise is to do yourself a disservice.
Having said that, you should definitely not rule out the bridges on the platform for extending your application - Bill Bumgarner is quick to point out how much power the Twisted networking framework provides to Cocoa applications via the PyObjC bridge.
Not programming in a scripting language turns out to not be so bad when you're using XCode. The GDB integration is very good; I'm primarily a Perl guy, and I find the XCode debugger very nice and very easy to use.
The "fix" feature will really surprise you with how usable it is. Imagine finding a bug in your ObjC code, fixing it, and then telling the debugger to continue on. It actually works in a lot of cases.
Try ObjC. You may find you like it a lot better than you think you will.
"have to", well... technically, no.
Since most Mac app jobs are done thro ObjC (for a very good reason I might add), I wouldn't kid yourself and learn it.
Hell no. You can use a number of languages to make a nice GUI with. It just depends on what's the usual/easiest solution for the platform. In Mac OS X's case, Objective-C and AppKit are pretty easy to use choices. However, I use REALBasic sometimes, and that allows cross platform development (and, of course, a performance hit).
So really it depends on how much work you want to put into it. You should learn Objective-C if you want to really do serious Mac development. But you can get by without it....
No. While Apple is strongly pushing Cocoa, Carbon is still supported. It uses plain C instead. As for good-looking GUIs, just use Interface Builder.
However, I must say that Objective-C is a great language. It is really easy (it was my first language) and very powerful.
In general yes; but even if you (correctly IMHO) ruled out Mono, GTK and SWING because they don't fit well in the GUI, try Qt. it's REALLY respectful of Mac GUI standards (HIG: Human Interface Guidelines), and can be equally programmed on C++, Python and Java. the last version is cocoa-based and 64-bit capable.
the only thing missing from Qt that you'd get from Objective-C is those awful non-HIG-compliant modern Apple applications (yeah, Aperture and Final Cut, I'm looking at you!)
I've become very comfortable in the world of pointer-free, garbage-collected programming languages. Now I have to write a small Mac component. I've been learning Objective-C, but as I confront the possibility of dangling pointers and the need to manage retain counts, I feel disheartened.
I know that Objective-C now has garbage collection but this only works with Leopard. My component must work with Tiger, too.
I need to access some Cocoa libraries not available to Java, so that rules out my usual weapon of choice.
What are my alternatives? Especially with no explicit pointers and automatic garbage collection.
What do you mean by "component?" Do you mean a chunk of code or a library you are going to hand to other people to link into their apps? If so then it is not realistic to use any of the bridged languages at this time. While a lot of the bridges are very nice, they almost always have complications and issues that most app developers will not be willing to deal with to use a single component, especially if it involves bringing in a substantial runtime.
The bridges are most valuable to bridge other language libraries into your Objective C app. While you can write fairly complete apps using them, doing so often requires a better understanding of Objective C than simply writing an Objective C application, since you need to understand and cope with the language, object model, threading, and memory allocation impedance mismatches that occur.
This is also why many people argue that even if you are quite familiar with a language, trying to learn Cocoa using that language through a bridge is generally more difficult that learning it using Objective C.
Finally, much of the recent support for bridged languages was due to "BridgeSupport," a feature was added in Leopard. Even bridges that predate that have been migrating towards, sometimes in such a way that using the bridged language on Tiger and Leopard can have substantial differences. Also, there is currently no bridge support for iPhone, and most bridged languages will not work on it, if that is an issue.
Ultimately, if you are writing a library that is going to be linked into other apps, you need to run on Tiger and Leopard, and you need to access Cocoa only APIs I think you will find using any non-Objective C solution quite difficult.
You can try PyObjC to write Cocoa apps in python, or MacRuby if you are interested in Ruby.
You shouldn't be intimidated by Cocoa's retain/release reference counting. It's much, much easier in practice than GC fans would have you believe. The Cocoa memory management rules are dead simple, they only affect a tiny amount of your code, and even that code can be generated automagically.
Here's the trick. You encapsulate your MM code in accessor methods, and always use accessors. Xcode has built-in scripts to generate the appropriate accessors, or if you need more flexibility there are 3rd-part apps like Accessorizer.
This isn't an intrusive approach - you only need to worry about retaining an object if you're going to need to keep it for later use, and if you're going to do that you'll need an instance variable in which to keep it anyway. And, if you're using KVO and bindings, you'll need to use accessors to make sure the appropriate observer notifications are fired. Basically, if you're using good OOP and Cocoa practices, there's practically no additional thought or effort involved with memory management.
Most folks who have difficulty with Cocoa's "manual" memory management are doing so as a result of misusing it. The most common mistake is to scatter the relevant code all over the place. That means that a missing retain, extra release, etc will be difficult to find.
Try any of the Cocoa bridges listed in here http://www.cocoadev.com/index.pl?CocoaBridges
You can also try F-Script - a smalltalk dialect that is written specifically for MacOSX/Cocoa.
RubyCocoa is getting steadily more impressive, and I've seen lots of successful implementations using it. That is, of course, if Ruby's your cup of tea...
You can always use REALbasic (www.realsoftware.com). Real easy and fun to use, not free though. You can not make dylibs (or dll's) using it, but you can use dylibs and dll's in your code. And you can use cocoa libraries as well
Don't forget that you can use java as well, and i don't mean java-cocoa bridge, i mean actual java.
There's also a package from apple that provides you with access to a couple of osx features as well.
Also to comment on Shem's point, if your targeting osx 10.5 and above, you can take advantage of garbage collection.
If you want lisp syntax then Nu is a lisp implemented on top of Objective-C http://www.programming.nu/
Also, FreePascal can generate native Carbon Apps (in progress working for Coccoa)
Look at Python and wxPython (the wxWidgets in Python).
The wxWidgets have a very elegant App-Doc-View application design pattern that's very, very nice. It's not used enough, IMO. I haven't found any wxPython examples of this App-Doc-View example, so you have to use the C examples to reason out how it would work in Python.
I'd post examples, but I haven't got it all working yet, either.
.NET via Mono mono-project.com
See NObjective (http://code.google.com/p/objcmapper/) bridge to Cocoa. It provides more features than others with less overheads.
I'm looking into Mono too. Objective-C is a little too bizarre for me at this point. Too many years doing C/C++, Java, C#, Perl etc. I suppose. All these seem pretty easy to float between. Not so for Objective-C. Love my Mac but afraid it will take too much precious time to master the language.