Hi, I'm kinda new to programming (know a lil HTML, JavaScript, basic Java) and I'm looking for a language to learn to develop applications for Mac OS X. So far, I've narrowed my choices down to Java and Objective C. There are pros and cons for each. I want to learn Objective C primarily because that's what Cocoa is written in -- I'm planning to develop using Cocoa rather than Carbon. However, Objective C seems to be such an obscure language. Does anyone else even make an Objective C compiler besides Apple? This leads me to lean towards Java. It is supported by many vendors, it's portable, plus I already have some experience with it. The thing with Java is that it's very slow. I know it runs on top of a Java Virtual Machine so it won't be as fast as native code, but the performance hit is very noticeable. Does anyone know if this will improve? Also, I read about Apple's Java Bridge that lets you access the Cocoa API with Java, but is this a viable approach? Are there any advantages/disadvantages in doing this? Hopefully, someone with more programming experience can enlighten me. Thanks.
Java or Objective C?
- Thread starter Oliver
- Start date
(First, I'm biased: I'm a professional Java developer, so you just know what I'm gonna say 
<br>
I'd seriously look at Java. It's a lovely language to write for - it's clean and well-designed, and just <i>feels</i> right. There's a huge amount of useful stuff in the standard class libraries, and that's mostly well-designed too. There are loads of IDEs and other development tools out there, along with tutorials, books, libraries, even a blend of coffee...
<br>
Speed isn't the issue it was a couple of years ago. The first JVMs were just interpreters, and crawled; later ones had Just-In-Time (JIT) compilers which sped up the code but added a lot of overhead. But the latest one (the HotSpot VM that comes with the JDK1.3 in Mac OS X) is a <i>dynamic</i> compiler: it monitors the code <i>as it runs</i>, compiling code where it's worth it, and making optimisations based on what the code is actually doing - which is more than static C/C++/etc. compilers can usually do. HotSpot flies on Mac OS X - try it and see!
<br>
If you want Cocoa just for the Aqua UI, then you don't need it - the Swing GUI toolkit in the standard library has a pluggable look-and-feel (which means that the look-and-feel can be changed without changing a single line of code, even at runtime), and the default one on OS X (final) is Aqua! I was amazed when I fired up an app of mine and it appeared in glorious Aqua. (I don't know much about the Java Cocoa APIs. Even if they're good, you still lose portability, whereas with Swing you get Aqua <i>and</i> 100% portability!) (Admittedly, the initial Aqua L&F isn't perfect - I noticed a couple of redraw problems - but I'm sure it won't take long for them to get ironed out.)
<br>
And don't underestimate the benefits of portability. No porting worries, no recompiling, apps just <i>work</i>. I sent an app of mine to my mum's PC, and all she had to do was dobule-click on it and it ran. Perfectly. At work, we run stuff on NT or Unix interchangeably. Even my Psion's got Java! If you're sure that you're happy locking yourself into one platform, then fine. But if you ever want your software to get a wider audience, or might one day get a different platform yourself, Java is the obvious choice.
<br>
I'd seriously look at Java. It's a lovely language to write for - it's clean and well-designed, and just <i>feels</i> right. There's a huge amount of useful stuff in the standard class libraries, and that's mostly well-designed too. There are loads of IDEs and other development tools out there, along with tutorials, books, libraries, even a blend of coffee...
<br>
Speed isn't the issue it was a couple of years ago. The first JVMs were just interpreters, and crawled; later ones had Just-In-Time (JIT) compilers which sped up the code but added a lot of overhead. But the latest one (the HotSpot VM that comes with the JDK1.3 in Mac OS X) is a <i>dynamic</i> compiler: it monitors the code <i>as it runs</i>, compiling code where it's worth it, and making optimisations based on what the code is actually doing - which is more than static C/C++/etc. compilers can usually do. HotSpot flies on Mac OS X - try it and see!
<br>
If you want Cocoa just for the Aqua UI, then you don't need it - the Swing GUI toolkit in the standard library has a pluggable look-and-feel (which means that the look-and-feel can be changed without changing a single line of code, even at runtime), and the default one on OS X (final) is Aqua! I was amazed when I fired up an app of mine and it appeared in glorious Aqua. (I don't know much about the Java Cocoa APIs. Even if they're good, you still lose portability, whereas with Swing you get Aqua <i>and</i> 100% portability!) (Admittedly, the initial Aqua L&F isn't perfect - I noticed a couple of redraw problems - but I'm sure it won't take long for them to get ironed out.)
<br>
And don't underestimate the benefits of portability. No porting worries, no recompiling, apps just <i>work</i>. I sent an app of mine to my mum's PC, and all she had to do was dobule-click on it and it ran. Perfectly. At work, we run stuff on NT or Unix interchangeably. Even my Psion's got Java! If you're sure that you're happy locking yourself into one platform, then fine. But if you ever want your software to get a wider audience, or might one day get a different platform yourself, Java is the obvious choice.
strobe
Puny Member
I have to disagree 100% with "gidds"
1) Java is a very inflexible language compared to Objective-C. It has no forward invocation, no class extensions, no generic object types. I could never call it 'lovely'
2) bytecode execution is DOG SLOW! HotSpot 2.0 changes nothing. Java bytecode is still slow and always will be. You can think of HotSpot has a compiler which caches a lot, the initial penalty is still high. Try it and weep
3) Swing is NOT an API for the OS X platform. It's a Java platform API, like AWT. Swing apps do not behave like mac apps, they merely look like them. It's a facade and nothing more.
Swing is also a crummy API in it's own right. There is no interface abstraction. Cocoa is a lot easier to develop for.
If you want to write applications for OS X you'll want to use Cocoa, not Swing.
If you know C or Java it takes virtually no time to learn Objective-C. I learned it in one day.
1) Java is a very inflexible language compared to Objective-C. It has no forward invocation, no class extensions, no generic object types. I could never call it 'lovely'
2) bytecode execution is DOG SLOW! HotSpot 2.0 changes nothing. Java bytecode is still slow and always will be. You can think of HotSpot has a compiler which caches a lot, the initial penalty is still high. Try it and weep
3) Swing is NOT an API for the OS X platform. It's a Java platform API, like AWT. Swing apps do not behave like mac apps, they merely look like them. It's a facade and nothing more.
Swing is also a crummy API in it's own right. There is no interface abstraction. Cocoa is a lot easier to develop for.
If you want to write applications for OS X you'll want to use Cocoa, not Swing.
If you know C or Java it takes virtually no time to learn Objective-C. I learned it in one day.
Tom Kroening
Registered
I will have to agree that you should use Objective C. It might be a bit tricky to learn right off the bat, especially if you havn't ever used our good old friend the toolbox before - dont give up. There should be some good books coming out for it soon. It truely has the best interface builder i've ever seen. It does everything for you! Although java is supported, you'll be much happier with objective C. It basically works on the principle of [dog fetch:stick]; It is a VERY good idea to learn some C... although objective C different from C, you can still fall back on C for many things. If you have a few minutes go through the currency converter tutorial thats included in your developer folder... you dont need to know anything about programming to do it, and if you understand somethings while in the process, you'll be one step closer. Good luck!
Brian Somers
Registered
Both languages were designed with different goals in mind and both have different strengths and weaknesses. I have worked with both, and my preference is with Objective-C. The basic syntax is easy to pick up, but learning the libraries will be what takes the most time, which is true for both languages. The way I look at it, desktop apps should be done in Cocoa/Objective-C for the power and speed. Java is more suited to web-based apps and that is where WebObjects comes in. Apple is marketing WebObjects with Java, fyi. Also, if you talk to any NeXT/OPENSTEP oldtimers, you will find them for the most part to be rabidly pro-Objective-C (if you experiment, you will soon see why). I guess the best advice I have to offer is just try both languages and learn their strengths and weaknesses and see for yourselves where you can best use each one.
I'm saying contraversial, because this is bound to inflame some people.
I wrote a basic fibinacci recursive program in C to run on 9(in classic) in X, and I wrote a java version, and here's how long each of them took to run:
C on 9 : 12.3 seconds
C on X : 25.0 seconds
java on X : 16.4 seconds
I wrote 9 code in CodeWarrior 5, X code for the command line in Project Builder, and the java in Project Builder.
There's a lot of weirdness going on here, but the final point to be made is that logical and mathematical operations in java are plenty fast. In some cases (backed up by theory as well as this benchmark) it's actually faster than C.
Machine dual 450 (although only 1 processor ever got used in these tests as the apps were single processes) with 512M RAM.
Can anyone come up with a reason for C on X to be so much slower than C on 9?
I wrote a basic fibinacci recursive program in C to run on 9(in classic) in X, and I wrote a java version, and here's how long each of them took to run:
C on 9 : 12.3 seconds
C on X : 25.0 seconds
java on X : 16.4 seconds
I wrote 9 code in CodeWarrior 5, X code for the command line in Project Builder, and the java in Project Builder.
There's a lot of weirdness going on here, but the final point to be made is that logical and mathematical operations in java are plenty fast. In some cases (backed up by theory as well as this benchmark) it's actually faster than C.
Machine dual 450 (although only 1 processor ever got used in these tests as the apps were single processes) with 512M RAM.
Can anyone come up with a reason for C on X to be so much slower than C on 9?
This is hardly surprising, especially for recursive programs where tail recursion can be optimized away, but probably is not in case of gcc.
gcc is not a world champion in either compilation speed (relatively unimportant) or quality of optimization. It is adequate, at best (when optimization actually works, rather than generats wrong code leading to very interesting debugging problems).
gcc is not a world champion in either compilation speed (relatively unimportant) or quality of optimization. It is adequate, at best (when optimization actually works, rather than generats wrong code leading to very interesting debugging problems).
the fibinacci sequence is integer based, I'm not utilizing any math that would put itself at risk here. Accuracy to within the closest integer is usually pretty easy.
As for compilers, I agree that gcc sucks. I've had it go south on me and refuse to compile code that codewarrior had no trouble with. I've also had to take my code from gcc and bring it over to CW because Gcc's errors are horrible.
I like the presence of gcc for compiling stuff brought over from linux so oddities can be matched quirk for quirk, but in general I hate the gnu compiler.
But really, you think this speed difference can be attributed entirely to compiler optimization? Apple needs to plant another compiler in their Project Builder if this is the case!
As for compilers, I agree that gcc sucks. I've had it go south on me and refuse to compile code that codewarrior had no trouble with. I've also had to take my code from gcc and bring it over to CW because Gcc's errors are horrible.
I like the presence of gcc for compiling stuff brought over from linux so oddities can be matched quirk for quirk, but in general I hate the gnu compiler.
But really, you think this speed difference can be attributed entirely to compiler optimization? Apple needs to plant another compiler in their Project Builder if this is the case!
Sometimes, Strobe, you rub me the wrong way. But I have to agree with you 137.3% on gcc and gdb. I've tried, I beat my head, I ran away crying. I met them first on Solaris, and it made not want to code on Solaris. Now they thrive ubiquitously in the linux world. They may be free, but in my opinion, that's the only way they ever got anyone to use them.
After doing some more benchmarking, the fib(40) test seems to be fairly representative of overall performance, or at least in line with other benchmarks. Since the code I wrote doesn't really lend itself to any optimizing, and turning it on and off made negligeable difference, this reveals either a really poor compiler (gcc) or some serious runtime flaws. I'm leaning toward gcc just being a suck compiler.
After doing some more benchmarking, the fib(40) test seems to be fairly representative of overall performance, or at least in line with other benchmarks. Since the code I wrote doesn't really lend itself to any optimizing, and turning it on and off made negligeable difference, this reveals either a really poor compiler (gcc) or some serious runtime flaws. I'm leaning toward gcc just being a suck compiler.
Brian Somers
Registered
Back when I was taking Advanced C and C++ classes, I was using CodeWarrior on my PBG3 and working with a guy with a Unix background as a tutor. We found that CodeWarrior gave us a number of headaches, but that using gcc would often work better. Sometimes, it seemed to me that CodeWarrior didn't fully implement Std C/C++ considering why I couldn't get the code to work under VC++ half the time. Code written and compiled with gcc worked fine with VC++. However, Apple's customized version of gcc/Obj-C can still give headaches...I've heard some of the guys at work grouse about it and Apple's version of gdb. The version of gdb that comes with Solaris-hosted WebObjects is worth grousing about especially how it implements breakpoints and printons.
I do agree that gcc sucks. What's worse, it's acceptable for most tasks, so that the UNIX C compiler market has been very much destroyed. But, this does not have to be the only reason for lack of speed. One variable not addressed is the function call cost in Mach-O executables: I cannot guess at that one without actually comparing the generated assembly from CW/OS9 and gcc/OSX.
What would be interesting is comparing the recursive/non-recursive implementation of fibonacci series generator. If you don't mind posting (or e-mailing me) the code, I can re-write the generator in order to avoid excessive recursion.
This reminds me, recursion needs to map in the stack as it goes on (i.e. generates a lot of page faults initially), so the other interesting point would be to compare the initial recursion run with the next one (both in the same process, mind you), unless you are running a number of fib(40) loops within a benchmark.
Regards,
mladavacATsurfeuDOTat (the obvious replacements necessary)
What would be interesting is comparing the recursive/non-recursive implementation of fibonacci series generator. If you don't mind posting (or e-mailing me) the code, I can re-write the generator in order to avoid excessive recursion.
This reminds me, recursion needs to map in the stack as it goes on (i.e. generates a lot of page faults initially), so the other interesting point would be to compare the initial recursion run with the next one (both in the same process, mind you), unless you are running a number of fib(40) loops within a benchmark.
Regards,
mladavacATsurfeuDOTat (the obvious replacements necessary)