Well it depends how the developer chooses to do it. There are ways to use new features and still run on older versions of the OS. Major compiler changes can throw a major spanner in the works though....br- said:
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS Xcode 3.0
- Thread starter DavidLeblond
- Start date
- Sort by reaction score
Java and VB? Come on...Lollypop said:Said it before the keynote, and Ill say it now, Apple needs to kiss ass with the developers, and from the looks of it I dont really know if XCode 3 as apple is pitching it now will help with that. Yes it adds a few new and nifty things, but there is still a huge gap in comparison to visual studio.net and all the other IDE's. Personally I have writen programs in C, Java and VB, and I found the gap so big that I gave up trying to learn writing anything for the Mac...
On a side note.. I have a few good books on Xcode that im now selling!
Lollypop said:Said it before the keynote, and Ill say it now, Apple needs to kiss ass with the developers, and from the looks of it I dont really know if XCode 3 as apple is pitching it now will help with that. Yes it adds a few new and nifty things, but there is still a huge gap in comparison to visual studio.net and all the other IDE's. Personally I have writen programs in C, Java and VB, and I found the gap so big that I gave up trying to learn writing anything for the Mac...
On a side note.. I have a few good books on Xcode that im now selling!
If you can really code in pure Java, it's no problem to write for Mac OS X.
I havnt really coded in a while.. so ye, thats where my experience stops!kainjow said:Java and VB? Come on...
I usually use some sort of IDE, working with notepads gets a bit heavy when you have a dozen classes. What I personally found is that O-c has its own syntax and the you have the cocoa libraries, both very unknown to me, when I went to Java it was C like and the libraries were new. From a VB perspective its much easier to do more complex interfaces, sure interface builder does do a lot, but it kept on crashing for me.bousozoku said:
Bit besides the point, my only goal with attempting to write for OS X was because I could then say I could, dont really need anything right now for the mac...
I'm not getting my hopes up on garbage collection. IMHO both Java and .NET tried this and failed miserably. At least I haven't had that good an experience with it.
In what way was it a miserable failure? The performance? I'd argue that for many applications the overhead of GC would be acceptable on modern processors. 10 years ago, no, but today, yes. I'm hoping that Apple allows some kind of mixed mode where you can pick and choose which objects get managed manually or automatically so you can tune it for certain applications. Another nice thing would be to have some of the GC parameters adjustable, for instance how aggressive it is in tracking down dereferenced objects or how often it empties.DavidLeblond said:
HiRez said:
The problems I've had with Java is it just not DOING the garbage collection randomly, even when it passes the max heap. The problem I've had with .NET is when you use some COM objects, #1 it won't garbage collect #2 when you force it to garbage collect it trashes the HELL out of the COM objects that aren't SUPPOSE to be garbage collected. Now that may very well be crappy programming within the COM object but all I know is it sure pissed me off enough to leave a bad taste in my mouth whenever I hear the buzzword "garbage collection."
I've heard about GC, haven't used it as I don't know Java, but still that'd be awesome to have it integrated. Now I'm sure they'll do something like this: You can set specific options to either have GC turned on or turned off. There is no way they're making Leopard non-compatible with Tiger Apps (or prior OS versions of Apps). I'm positive Apple wouldn't leave us high and dry on that one.
Lollypop said:
Are you sure you have actually tried using XCode - your 'notepad' comments make it sound like you were using AppleScript editor!
And as for IB crashing - what kind of errors were you getting - I have never had it crash on me, I would be interested to know if that is exceptional - or par for the course.
ExoticFish said:
64-bit compiler.
I would hope that the Mac Pros have the same 64 bit support as the G5. On other machines it won't do you much good.
Lollypop said:...
I usually use some sort of IDE, working with notepads gets a bit heavy when you have a dozen classes. What I personally found is that O-c has its own syntax and the you have the cocoa libraries, both very unknown to me, when I went to Java it was C like and the libraries were new. From a VB perspective its much easier to do more complex interfaces, sure interface builder does do a lot, but it kept on crashing for me.
Bit besides the point, my only goal with attempting to write for OS X was because I could then say I could, dont really need anything right now for the mac...
Why don't you try Borland JBuilder for Mac OS X? It allows both a visual development paradigm and fill-in-the-blanks programming that VB developers love.
Personally, I haven't found any one Java environment to be completely useful. If JBuilder was more like C++Builder, I think they'd have a winner. Usually, I end up using NetBeans for visuals, then switching to jGrasp for coding.
ExoticFish said:
The information is on the previous page of this thread.
Odd, I've worked with C++, Smalltalk, Java, ObjPascal, C, Pascal, etc, etc, etc, and all the Borland and Microsoft and etc IDEs and I actually find XCode a more advanced than a lot of what's out there. To me it's just like Mail or iCal, really, really simple but I've never found it unable to do what I need -- usually faster and easier than in other IDEs. Not to mention the whole bindings, coredata, etc which IB and XCode facilitate.
My only major complaint is a lack of UML support, and in the language, the lack of garbage collection (thanks for fixing that one, Apple). I also am not particularly fond of CoreData but, it's about the best I can hope for considering how marginalized OODBs are.
But really, why are you even bringing up language -- what does the IDE have anything to do with the language? If you don't like ObjC it's probably because your limited OO background, not because of XCode. I mean, jeez, you can without touching the language manage to do quite a lot with CoreData and Cocoa Bindings.
It's usually a bad idea to buy a book on an IDE, the developer documentation is usually more than sufficient, spend your money on books that don't expire when a new version comes out. Those books just are reprints of developer documentation for the most part.
My only major complaint is a lack of UML support, and in the language, the lack of garbage collection (thanks for fixing that one, Apple). I also am not particularly fond of CoreData but, it's about the best I can hope for considering how marginalized OODBs are.
But really, why are you even bringing up language -- what does the IDE have anything to do with the language? If you don't like ObjC it's probably because your limited OO background, not because of XCode. I mean, jeez, you can without touching the language manage to do quite a lot with CoreData and Cocoa Bindings.
It's usually a bad idea to buy a book on an IDE, the developer documentation is usually more than sufficient, spend your money on books that don't expire when a new version comes out. Those books just are reprints of developer documentation for the most part.
Lollypop said:Said it before the keynote, and Ill say it now, Apple needs to kiss ass with the developers, and from the looks of it I dont really know if XCode 3 as apple is pitching it now will help with that. Yes it adds a few new and nifty things, but there is still a huge gap in comparison to visual studio.net and all the other IDE's. Personally I have writen programs in C, Java and VB, and I found the gap so big that I gave up trying to learn writing anything for the Mac...
On a side note.. I have a few good books on Xcode that im now selling!
It's not really a buzzword. It's been around a long, long time, without people throwing their arms up about performance.
COM is antithetical to most of these things [basic things like 'GC' that the OO community used to take for granted], so don't take your experience from there. Try any of the thousand languages that have no concept of manual memory management... as far as Java you have to complain not about the memory management faculty in the language but the VM's implementation of it...
COM is antithetical to most of these things [basic things like 'GC' that the OO community used to take for granted], so don't take your experience from there. Try any of the thousand languages that have no concept of manual memory management... as far as Java you have to complain not about the memory management faculty in the language but the VM's implementation of it...
DavidLeblond said:
It's not something you "use" it's something you don't use. It's like suddenly not having to think about object lifetime management. It keeps being touted as a new feature to use when it's more like removing an old headache you had to think about and deleting many lines of now-legacy code.
You can enable or disable GC based on leaked documentation from before Leopard was previewed -- but that's in terms of compiling. As far as backward-compatible apps that wont be possible. It's a Leopard specific capability, just like CoreData can't be used on OS X 10.3, GC can't be used in OS X 10.4... So if you write a spiffy new app on 10.5 and say "screw manually managing memory" and combile with the switch to turn GC on, your app will not run on 10.4. On the other hand of course any 10.4 app will run on 10.5 -- so there is forward compatability but not backward compatability. The way it should be, I think -- otherwise you limit Apple's ability to be agressive about new language/runtime/library features, and that's, deep down, what killed Microsoft's ability ot make any progress [worrying that brand new apps should be able to run on 3 year old OS versions].
At least that's my understanding based on the documentation of compiler switches that was accidentally released way back when.
You can enable or disable GC based on leaked documentation from before Leopard was previewed -- but that's in terms of compiling. As far as backward-compatible apps that wont be possible. It's a Leopard specific capability, just like CoreData can't be used on OS X 10.3, GC can't be used in OS X 10.4... So if you write a spiffy new app on 10.5 and say "screw manually managing memory" and combile with the switch to turn GC on, your app will not run on 10.4. On the other hand of course any 10.4 app will run on 10.5 -- so there is forward compatability but not backward compatability. The way it should be, I think -- otherwise you limit Apple's ability to be agressive about new language/runtime/library features, and that's, deep down, what killed Microsoft's ability ot make any progress [worrying that brand new apps should be able to run on 3 year old OS versions].
At least that's my understanding based on the documentation of compiler switches that was accidentally released way back when.
slooksterPSV said:
hurray! glad i caught it before i left work so i could suck it through the university bandwidth at 1300KB/s (slightly faster than my slow DSL connection at home)
br- said:
That is absolutely under control of the developer. Obviously you cannot use 10.5 features on a machine that runs 10.4 or 10.3. What a developer does: First, he chooses which is the earliest version that the application should run on (for example, 10.2.8). Then whenever a feature is used that isn't available in 10.2.8, the programmer has to check whether that feature is actually available on the machine that the program is running on. A lazy programmer could just set a switch that requires MacOS X 10.5 to run an application, but that means you lose many customers.
From Apple's website:
"Objective-C 2.0 - So compelling, Apple wrote Xcode 3.0 itself using it."
My layman's guess is Objective-C 2.0 runtime will only run on Leopard, so only the developers who have access to Leopard will be able to even run Xcode 3.0, which is why its distribution is select and secretive. It's not that applications developed on Xcode 3.0 will be Leopard-only compatible, but that Xcode 3.0 itself is Leopard-only compatible.
"Objective-C 2.0 - So compelling, Apple wrote Xcode 3.0 itself using it."
My layman's guess is Objective-C 2.0 runtime will only run on Leopard, so only the developers who have access to Leopard will be able to even run Xcode 3.0, which is why its distribution is select and secretive. It's not that applications developed on Xcode 3.0 will be Leopard-only compatible, but that Xcode 3.0 itself is Leopard-only compatible.
I would like to see Apple release something to compete with C# and the .NET framework. While Cocoa is still a good framework the Objective-C language is looking more and more dated every year as C# and frameworks like .NET are becoming more and more advanced. I just hope this will not lead to much faster small application development on Windows where traditionally Cocoa allowed this on the Mac against MFC.
ifjake said:
There is no reason why the Objective-C 2.0 runtime should only work on Leopard whatsoever. If that were the case, then development using it would be a complete non-starter for most developers, because not only XCode 3.0, but also any code written with it wouldn't run on most machines out there.
gnasher729 said:
You're right, of course, that it should run anywhere. The question is whether Objective-C 2.0 will be integrated properly into gcc on a global platform scale. It still seems odd to me that Apple has one version of gcc and the rest of the world seems to have another version.