which programming language is best?

[petr6534]

I am an intermediate c++ programmer and want to start to develop games and applications for mac OSX. Which language is the best to learn- Carbon, Cocoa, or is there another language that is better?

[Skorche]

Carbon is a C/C++ API, and Cocoa is an API for Obj-C. I'd recommend going the cocoa route, it's far easier to learn. Carbon pretty much just around for porting C/C++ programs and for those who did Mac programming in the pre-OSX days.

[Taxxodium]

And let's not forget you can integrate Carbon in a Cocoa application. So yes, I second going for Cocoa.

[Nick]

I don't think I really use either Carbon or Cocoa. Technically I use Cocoa for SDL but other than that I'm just using C++. I would recommend Cocoa however as there are some very useful functions to use when reading/writing files as well as other things. The downside to Cocoa is the inability to be easily ported.

[sealfin]

Or you could just keep your C++ knowledge and use a combination of SDL (http://www.libsdl.org/) and OpenGL, and that way target any platform which supports those (Mac OS X, Linux, Windows, and lots of more obscure others...)

[codemattic]

Cocoa/Obj-C if you plan on writing Mac applications

If you plan on writing a game - C/C++ for the low-level graphic routines and either C/C++ or scripting language like Python/Ruby/Javascript for the game logic.

If you are writing a game - look at all the free/open libraries available to you. If you are making a 3d game look at Dim3. If you are making a 2d arcade game look at SDL. Look at cross-platform libraries for your image and audio needs.

good luck!

[DoG]

ObjC and Cocoa is definitely the way to go for regular user interface programming, and Carbon is the API of choice to access the OS from C/C++. There is no general best way to go, always get the right tool for the job.

[skyhawk]

I use the diagonalization principle, and for each of their arguments, I take the opposite of what they say, I form a programming language you should use based on that. Since no such programming language exist, you should either:
a) not program
b) program in whatever you damn well please cause I know that most of the time, whatever we say in regards to what a person should program rarely ever changes what they eventually program in.

[Vertizor]

Everyone has posted some really good advice thus far. All I'll say is:

I'm in the same boat as you, C/C++ is my primary language for over 5 years (4 of it professionally). When I started learning Cocoa, it took me a lot longer to get use to that style of coding than it did to actually learn the concepts, syntax, and Cocoa API. Often I would try to do things that weren't legal in objective-c, or just not how it's suppose to be done.

I then went to learn Carbon for a while. I felt a little more comfortable there because it's at least a language I'm more familiar with. But my stumbling block was the fact that I've been a Windows programmer for so many years, the most notable difference was the way message and event handling was done.

So whatever your background is, if you can let go of old habits it'll be easier. I've done Windows programming, PalmOS, Linux, BeOS. But MacOSX is an entirely new beast to me.

[Vertizor]

One more thing:

Specifically with game development, I often hear that using the C language is better because there's less overhead. The "overhead" is in regard to object-oriented languages and data structures. Using smaller, tigher, "struct" data types rather than entire classes may yeild more performance than making everything a class. On the other hand, it does limit you feature-wise, of what you can do in code. If you have a good handle on inheritance and code reuse, C++ might be very useful and almost if not as fast a C code.

There's been a lot of talk about which is better performance-wise: Carbon on Cocoa. I use to hang out in other Mac forums and I notice that there's a lot of misconceptions out there. Many Mac users still don't understand that Carbon has been updated for OSX and the Mach-O executable format. Long story short, the binaries are equally fast. But the more you rely on the API and framework, that's where I believe the differences start to be more clear. For example: I wouldn't consider using too many Cocoa classes that encapsulate data types. Like if I wanted to convert a string of text into a float or an int, the C runtime has functions for that type of operation which I'd gladly use over the NSString object to do the conversion.

With Carbon, I'm a little annoyed when it comes to strings. There's a difference between a Carbon string and a C string, and they're not always compatible. So that involves a string conversion routine before the 2 can be interchanged, and that costs time and memory.

[ThemsAllTook]

With Carbon, I'm a little annoyed when it comes to strings. There's a difference between a Carbon string and a C string, and they're not always compatible. So that involves a string conversion routine before the 2 can be interchanged, and that costs time and memory.

I'm curious what you mean when you say "Carbon string". There's CFStringRef, Str63, Str255, HFSUniStr255, char * (which I assume is what you mean by C string), UniChar *, and probably a few others I'm forgetting...

Alex Diener

[Vertizor]

I believe it's the CFStringRef vs. char* that I'm complaining about. Most Carbon functions that take a string argument, such as creating a window and setting its title text, take a CFStringRef. I just remember it being kinda tedious having to convert a char* into a CFStringRef then pass that to the function.

[blobbo]

start with java. truly, it's very easy to learn, and the concepts are easily applied to objective c or c++. learn c after java, though - then you'll be able to deal with memory management (very important).

[skyhawk]

start with java.
just ask him to be stupid why don't you.... seriously, java is absolutely the WORSE thing you could start someone with. I would suggest basic or assembly over java ANY day.

[blobbo]

skyhawk: Java is an excellent choice for learning how to program. It's very intuitive, and the library is large and strong. I found it very easy to learn - certainly easier than any other language I ever tried to learn on prior to it. Just speaking from experience.

[sealfin]

start with java. truly, it's very easy to learn, and the concepts are easily applied to objective c or c++. learn c after java, though[snip]

Seems people are posting without reading the first post in the thread ;) the poster stated they already know C++...

The threads poorly titled, this is more a misunderstanding about languages and APIs than "pimp your language" ;)

[blobbo]

Excuse me - I misread the first post. My mistake.

[marlfxx]

If you have no mac programming experience, I'd say it's a tossup. With Carbon you can stick entirely to C++; however, the C interface (and the sheer size of it) can be confusing. With Cocoa, you must learn Objective-C, but the design is OO. The choice could depend on what you want to program. Because I program in OpenGL, I like using a cross-platform interface like SDL or GLFW rather than a mac-specific one.

[Vanamir]

Java is becoming the language of choice for instruction at college. It is a clean cross platform development environment where many of the tedious aspects of C/C++ are non-existent. This allows a student to focus on the science aspects of programming like classical algorithm analysis and data structures. It is not, however, well suited to game development at the moment. At least not serious game development.

[Sohta]

I am actually going to disagree with this. ( coming from someone who truly loathes JAVA, this is a bit surprising ). JAVA is not suited for high-polygon, high-details games, that's for sure. But, considering the machines we are working with nowadays, the language overhead is pretty negligeable for, say, a poker game.

A good way to illustrate my point is to point to the zillion JAVA web-based games out there.

Remember, A game is not defined only by their graphics ( wich are, IMHO, the only serious bottleneck at the moment ) EDIT: Whoa, reading myself, this almost sounds like a flamebait, I do think that there are other bottlenecks ( collision detection most notably ), but to a much lesser extent than graphics.

[Skorche]

Really? I'm loving java. I certainly don't think it's the end-all programming language, but it certainly makes sense to use it to replace most uses of C++. That said, I haven't been using outside of class for anything yet, but it seems like a very solid language.

[phydeaux]

Really? I'm loving java. I certainly don't think it's the end-all programming language, but it certainly makes sense to use it to replace most uses of C++. That said, I haven't been using outside of class for anything yet, but it seems like a very solid language.

The problem with Java has never really been the language itself (though the language itself gets annoying in the amount of characters you have to type to do all the typecasting) but the APIs that come with it. This is less of a problem now than it was a few years ago, but they're still not that nice. For example, if you look at a lot of older java games, the way you blit sprites to the screen is a complete mess, and you couldn't really access buffers you created by loading images directly, making a lot of things much harder than they needed to be.

Also, this is probably also somewhat better than it used to be, but despite claiming to be cross-platform, the Java runtime libraries on different OSs are only somewhat compatible for a lot of these graphical and sound APIs, making it so something that runs on Windows might flash or do something weird on the Mac. This was also a nightmare to deal with- I assume Java3d is probably a lot more consistent across systems, but if it's anything like the compatibility in the past, it's probably terrible.

These API problems are the main reason nobody uses Java for large game development, and if you're trying to do anything with bitmap graphics I would not recommend it.

[JustinFic]

I personally went for a combination of OpenGL and SDL. Both easy to learn and you can get results fast. Now that I'm making games with them I'm getting a better feel for what I'll need to learn next.

There is no silver bullet API that will solve all your problems. They all have their limitations. Start with the one that seems to do the most for you-- in my case it was SDL. Eventually, you'll be using a combination of them.

But whatever you choose, I suggest also learning OpenGL. You can use it with Carbon, Cocoa, and SDL, and it's easy to pick up.

EDIT: There's no reason not to learn Java- it should only take you a few days if you already know C++. But as far as using it- it's a different tool for a different job. It's useful for plenty of things, but for game development C/C++/ObjC + Carbon/Cocoa/SDL/OpenGL is generally a better set of tools.

[Skorche]

I really like the language in general, but I have noticed that libraries for multimedia seem to be really touch and go. On the other hand, I wasn't really planning on doing to much multimedia programming in java, because it seems like such a poor language for it.

[Vanamir]

I did mention that Java was not suited for serious game development. I am sure there are countless non-intensive games out there put to market quickly by the beneficial aspects of Java development. You are unlikely, however, to get a job at Game Studio without C/C++ Experience and a solid understanding of Computer Science. Projects are too big now to be hacked together. Some real distributed development techniques need to be employed. Just my two cents.

[anonuser]

TIme to throw my 2 cents in

there is a macro in the Carbon library that will return you a CFString
so dealing with them isn't that much of a hassel.

CFSTR()
use that and worry not.


and the language issue depends entirely on what you're going for. Cocoa makes things a bit easier in my opinion.
But Carbon is still pretty easy once you get the hang of it. I am by no means a master of carbon but I'm learning and it's not that difficult once you get on board.

Cocoa makes things go really fast, again at least with my experinces so it is a time saver.

But both API's can do (almost) the same things.

[Vertizor]

But Carbon is still pretty easy once you get the hang of it. I am by no means a master of carbon but I'm learning and it's not that difficult once you get on board.
I agree, at first when I was looking at the Carbon API initially, I balked at the way the event handling model was setup (I was already brainwashed into Win32 and MFC). Then when I really go into using it my impression of it changed, I thought it was pretty cool the way message handlers were attached to events.

[PowerMacX]

Java's "multiplatform" claims are in my experience very misleading. I've found many problems with inconsistent/drifting GUIs and performance (especially on Mac).
For me, C (or C++) is the "multiplatform assembler". It get's you as close to the hardware as you can be without locking yourself to a specific proccesor. My personal choice is SDL+OpenGL+C++. My current uDG entry, Okugai, is about 10000 lines long, and when I wanted to test it on a PC, porting it took me about half an hour.
For mac specific stuff (standard widows and widgets) I prefer Cocoa, but usually find myself making parts in Carbon because it gives you more control than the Cocoa wrappers (thats what most of them are) do.