Go Back   MacRumors Forums > Apple Systems and Services > Programming > Mac Programming

Reply
 
Thread Tools Search this Thread Display Modes
Old May 24, 2009, 04:31 AM   #1
zyzzogeton
macrumors member
 
Join Date: Oct 2008
Carbon vs. Cocoa

Is it worth learning Objective-c to use Cocoa? Cause Objective-c looks hard and not clean
zyzzogeton is offline   0 Reply With Quote
Old May 24, 2009, 04:49 AM   #2
gnasher729
macrumors G5
 
gnasher729's Avatar
 
Join Date: Nov 2005
Quote:
Originally Posted by zyzzogeton View Post
Is it worth learning Objective-c to use Cocoa? Cause Objective-c looks hard and not clean
If you want to write iPhone software, or Mac software that you can maintain in a few years, learning Objective-C is an absolute must. Assuming that you know C (and if you don't, you can go home anyway) , and assuming that you are willing to learn about object oriented programming (and if you don't, see above), Objective-C is a much smaller language than say C++, a lot easier to learn to use well, makes it a lot easier to write _readable_ code, and is very, very powerful.
gnasher729 is offline   0 Reply With Quote
Old May 24, 2009, 05:13 AM   #3
Catfish_Man
macrumors 68030
 
Catfish_Man's Avatar
 
Join Date: Sep 2001
Location: Portland, OR
Send a message via AIM to Catfish_Man
Objective-C/Cocoa is much easier than Carbon.
Catfish_Man is offline   0 Reply With Quote
Old May 24, 2009, 06:16 AM   #4
foidulus
macrumors 6502a
 
Join Date: Jan 2007
Essentially Carbon doesn't have a very bright future

While Apple hasn't explicitly come out and said it, they seem like they are trying to distance themselves as much as possible from Carbon and moving people towards objective-c. For example, they scratched 64 bit Carbon which basically means that if you want a native 64 bit GUI, you pretty much have to go Cocoa(You could go Java too, but then it wouldn't be native).
foidulus is offline   0 Reply With Quote
Old May 25, 2009, 07:16 PM   #5
firewood
macrumors 603
 
Join Date: Jul 2003
Location: Silicon Valley
Quote:
Originally Posted by zyzzogeton View Post
Is it worth learning Objective-c to use Cocoa? Cause Objective-c looks hard and not clean
Objective-C and Cocoa are much cleaner and more scalable than Carbon. Having written apps in both, I wouldn't call the Carbon API easy. While some things might be easier, others would be extremely difficult.

I would learn to use some plain C, as well as its superset, Objective-C.

imho.
__________________
Apple II+, Mac 128k->512ke, MacBook Air 11, iPhone 6
firewood is offline   0 Reply With Quote
Old May 25, 2009, 11:26 PM   #6
Chirone
macrumors 6502
 
Join Date: Mar 2009
Location: NZ
Quote:
Originally Posted by gnasher729 View Post
a lot easier to learn to use well, makes it a lot easier to write _readable_ code, and is very, very powerful.
you haven't seen the legacy code i'm dealing with

also at one point made xcode crash every time it tried to open a project, and i deduced it was due to a method name being overly long... if xcode didn't complete writing your method calls out automatically then i would say objective c is one of the slowest languages to write because you just gotta keep typing and typing and typing and getting nowhere because of the ridiculously long method names (albeit easy to read/understand)

i thought carbon was dropped altogether and so cs4 wasn't going to be released on mac, but then i must have been told wrong?

i love how when mac upgrades to the next version all your code is suddenly broken, and none of your special hardware works anymore. keeps things up-to-date and money going into apple's pockets
Chirone is offline   0 Reply With Quote
Old May 25, 2009, 11:52 PM   #7
lee1210
macrumors 68040
 
lee1210's Avatar
 
Join Date: Jan 2005
Location: Dallas, TX
Quote:
Originally Posted by Chirone View Post
you haven't seen the legacy code i'm dealing with

also at one point made xcode crash every time it tried to open a project, and i deduced it was due to a method name being overly long... if xcode didn't complete writing your method calls out automatically then i would say objective c is one of the slowest languages to write because you just gotta keep typing and typing and typing and getting nowhere because of the ridiculously long method names (albeit easy to read/understand)

i thought carbon was dropped altogether and so cs4 wasn't going to be released on mac, but then i must have been told wrong?

i love how when mac upgrades to the next version all your code is suddenly broken, and none of your special hardware works anymore. keeps things up-to-date and money going into apple's pockets
If the legacy code doesn't need alteration, it might be easier to just build the legacy code as a static library with GCC, then just link to it with XCode and call the methods needed in the new code.

I guess i'd say if you're using XCode, you don't keep typing and typing, you type [<object or class>, then esc and use code completion. This is the most compelling feature of any IDE in my opinion.

Re: CS4, it will be on mac, it will not be 64-bit. This is because apple decided carbon wasn't getting 64-bit support. Adobe's code needs to be dual-platform, so they've stuck to a lot of C/C++ as far as I understand it. Any Objective-C they wrote couldn't be used on Windows, and I guess the custom code they have for the interface for each platform is already enough for them to maintain. I'm sure Apple considers this a thorn in their side, because they want everything on Cocoa, and I'm sure adobe considers Apple a thorn in their side because they must support OS X but the API they use is no longer being extended dramatically to allow them to use the new whiz-bang features.

Re: OS updates... yes, they tend to break things. But code still works fine on the existing version, and I view the alternative as eternally being backward compatible, which i think stunts innovation. it is unfortunate for developers, but I think it's worth it for users to get big improvements.

-Lee
lee1210 is offline   0 Reply With Quote
Old May 26, 2009, 12:32 AM   #8
kainjow
Moderator emeritus
 
kainjow's Avatar
 
Join Date: Jun 2000
Quote:
Originally Posted by foidulus View Post
While Apple hasn't explicitly come out and said it, they seem like they are trying to distance themselves as much as possible from Carbon and moving people towards objective-c. For example, they scratched 64 bit Carbon which basically means that if you want a native 64 bit GUI, you pretty much have to go Cocoa(You could go Java too, but then it wouldn't be native).
Last WWDC when they announced that Carbon wouldn't be fully 64-bit, I think that was as good as any of an official statement on the issue. I was there at the session when they said it, but I don't remember the exact words. It was pretty clear though that Carbon shouldn't be used anymore for new development.
kainjow is offline   0 Reply With Quote
Old May 26, 2009, 01:57 AM   #9
Krevnik
macrumors 68020
 
Krevnik's Avatar
 
Join Date: Sep 2003
Quote:
Originally Posted by lee1210 View Post
Re: CS4, it will be on mac, it will not be 64-bit. This is because apple decided carbon wasn't getting 64-bit support. Adobe's code needs to be dual-platform, so they've stuck to a lot of C/C++ as far as I understand it. Any Objective-C they wrote couldn't be used on Windows, and I guess the custom code they have for the interface for each platform is already enough for them to maintain. I'm sure Apple considers this a thorn in their side, because they want everything on Cocoa, and I'm sure adobe considers Apple a thorn in their side because they must support OS X but the API they use is no longer being extended dramatically to allow them to use the new whiz-bang features.
Two things:

1) CS4 is out on the Mac now. I own a license.
2) Adobe did say that 64-bit on the Mac wasn't coming until CS5 or so. You can still write portable apps using a Obj-C UI (see Handbrake as a good example of a C library providing core functionality, with Obj-C driving the UI which talks to it). However, because Adobe has so much code in C/C++, porting the UI over would take time they didn't have for CS4. They were depending on Carbon going 64-bit so they could avoid having to port the UI to a new language on the Mac side of things.

Personally, Obj-C is just different. It looks hard/unclean because it is not what people think when they get into programming these days. They are so used to everything being based on C-syntax that they just don't know anything else.

I've been pleased with Obj-C/Cocoa as a development environment. Sure, the language will take a bit of time to get used to, but the framework is extremely useful, and quite powerful. It replaces a lot of the grunt work you normally have to do in C/C++ when building object models, and really takes the cake as a rapid development framework. I can prototype some apps in a couple hours, rather than days thanks to things like CoreData, Interface Builder and Bindings.
__________________
iMac 2013 27", 13" 2012 rMBP, iPad Air, iPhone 6
Krevnik is offline   0 Reply With Quote
Old May 26, 2009, 03:27 AM   #10
Chirone
macrumors 6502
 
Join Date: Mar 2009
Location: NZ
Quote:
Originally Posted by Krevnik View Post
Two things:

1) CS4 is out on the Mac now. I own a license.
that's what we said about cs4
well... we said it wasn't 64bit but yeah, it's been out for a long time already

Quote:
Originally Posted by Krevnik View Post
I've been pleased with Obj-C/Cocoa as a development environment. Sure, the language will take a bit of time to get used to, but the framework is extremely useful, and quite powerful. It replaces a lot of the grunt work you normally have to do in C/C++ when building object models, and really takes the cake as a rapid development framework. I can prototype some apps in a couple hours, rather than days thanks to things like CoreData, Interface Builder and Bindings.
i'm not a fan of interface builder. mainly because i can't see any code that it generates. the interface just magically works or doesn't (in most of my cases it doesn't )
core data and bindings are great concepts. a lot more streamlined than actually going in there and doing all those monotonous tasks yourself...
although i have managed to make core data's redo capabilities crash and i have absolutely no idea why.
imo there aren't enough examples for core data and it makes it a definate non-trivial task to begin a program from scratch
Chirone is offline   0 Reply With Quote
Old May 26, 2009, 04:27 AM   #11
Thomas Harte
macrumors 6502
 
Join Date: Nov 2005
Quote:
Originally Posted by Chirone View Post
i'm not a fan of interface builder. mainly because i can't see any code that it generates. the interface just magically works or doesn't (in most of my cases it doesn't )
That's because Interface Builder doesn't generate any code. You're too used to things like ye olde MFC which tried to hack rapid-application development onto pre-existing frameworks.

If in Interface Builder you wire up a particular control to message a particular method, all that goes into the NIB is the name of the method. Objective-C is fully reflective, which means that the methods and instance variables of any class can be queried and looked up by name at runtime. So the message goes straight through with no code inbetween. There's no message map or secret handling code there's no code at all. It's essentially a language feature.

To be honest, I think the thing that would help you most at this stage might be to read more about Objective-C, especially if it's your first fully reflective language.
Thomas Harte is offline   0 Reply With Quote
Old May 26, 2009, 05:00 AM   #12
Chirone
macrumors 6502
 
Join Date: Mar 2009
Location: NZ
well... it makes it slightly harder to program interface elements without IB when you want your code to generate UI elements since you don't know how things were done in the first place and the only quick reliable source is non-existent

kinda like with core data... like how trying to add to the to-many relationships by programaticaly making an entity when a property of another has changed
Chirone is offline   0 Reply With Quote
Old May 26, 2009, 05:26 AM   #13
Thomas Harte
macrumors 6502
 
Join Date: Nov 2005
Quote:
Originally Posted by Chirone View Post
well... it makes it slightly harder to program interface elements without IB when you want your code to generate UI elements since you don't know how things were done in the first place and the only quick reliable source is non-existent
Obviously this is true; you can't use Interface Builder to generate example code to learn about programmatic generation of interface elements. However, that's not because Interface Builder generates the code and doesn't show it to you, it's because interface elements know how to generate themselves directly from [N/X]IB files, so that code is no more inspectable that for example how an NSTextField responds to a mouse click. I assume this stuff is all part and parcel of the NSCoder approach to saving and loading classes (which is near identical to Java's serialisation as I understand it).

In general it's all relatively easy stuff though. All controls subclass NSView, so initWithFrame: should always be available for creating a new control at a specified position. Supposing you have an existing NSView and you want to add an NSTextField to it, you could do:

NSTextField *newTextField = [[NSTextField alloc] initWithFrame:<whatever>];
[view addSubview:newTextField];

Specific text field properties can be set using NSTextField-specific methods (probably before you addSubview), and you can always use setDelegate: to set yourself as a delegate for whatever methods you're interested in.
Thomas Harte is offline   0 Reply With Quote
Old May 26, 2009, 11:12 AM   #14
Krevnik
macrumors 68020
 
Krevnik's Avatar
 
Join Date: Sep 2003
Quote:
Originally Posted by Chirone View Post
well... it makes it slightly harder to program interface elements without IB when you want your code to generate UI elements since you don't know how things were done in the first place and the only quick reliable source is non-existent
The number of times where I felt it was required to generate UI controls programatically? Once. All the methods you need are documented, but there may not be tutorials, per se.

The last time I wrote code to build UI on the Mac or Windows was for a custom control. Neither side is really at its best when you are programmatically building it anymore (minus a few NIB tricks so you can split up the UI into more manageable chunks, and load NIBs on-demand). There are just so many knobs and dials that it can get out of hand quick. Thankfully Apple provides sane defaults on their controls when you do need to alloc one up yourself.

Quote:
Originally Posted by Chirone View Post
kinda like with core data... like how trying to add to the to-many relationships by programaticaly making an entity when a property of another has changed
Sounds like you need to assign that entity to one of your classes that subclasses NSManagedObject, so you can intercept the setter and perform actions on it. This sort of stuff /is/ documented because that is exactly what it is there for, to let you extend the behavior.
__________________
iMac 2013 27", 13" 2012 rMBP, iPad Air, iPhone 6
Krevnik is offline   0 Reply With Quote
Old May 26, 2009, 06:50 PM   #15
Chirone
macrumors 6502
 
Join Date: Mar 2009
Location: NZ
Quote:
Originally Posted by Krevnik View Post
Sounds like you need to assign that entity to one of your classes that subclasses NSManagedObject, so you can intercept the setter and perform actions on it. This sort of stuff /is/ documented because that is exactly what it is there for, to let you extend the behavior.
i had done that, and it worked, except when i hit undo and redo it crashed. and if i hit undo, deleted the entity then made a new one it would also crash.
Chirone is offline   0 Reply With Quote
Old May 26, 2009, 07:04 PM   #16
Krevnik
macrumors 68020
 
Krevnik's Avatar
 
Join Date: Sep 2003
Quote:
Originally Posted by Chirone View Post
i had done that, and it worked, except when i hit undo and redo it crashed. and if i hit undo, deleted the entity then made a new one it would also crash.
Look at undo grouping (part of NSUndoManager), my guess with so little information at hand is that your edits were perceived as multiple edits, and stored separately on the undo stack. You would get your OM in a weird state if you had two linked changes, and were able to undo one at a time.

EDIT: I see the other thread now, and it sounds more like the entity may be getting created programmatically outside the context of a Managed Object Context. If that is happening, there is a lot to CoreData that flat out breaks, because all entities need to come from a managed object context.
__________________
iMac 2013 27", 13" 2012 rMBP, iPad Air, iPhone 6
Krevnik is offline   0 Reply With Quote
Old May 26, 2009, 07:06 PM   #17
Chirone
macrumors 6502
 
Join Date: Mar 2009
Location: NZ
Quote:
Originally Posted by Krevnik View Post
Look at undo grouping (part of NSUndoManager), my guess with so little information at hand is that your edits were perceived as multiple edits, and stored separately on the undo stack. You would get your OM in a weird state if you had two linked changes, and were able to undo one at a time.
yeah that's what i was thinking as i posted that last reply

sorry for hijacking this thread...
Chirone is offline   0 Reply With Quote

Reply
MacRumors Forums > Apple Systems and Services > Programming > Mac Programming

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Similar Threads
thread Thread Starter Forum Replies Last Post
Carbon Skin? Ncage1974 MacBook Pro 2 Feb 28, 2014 06:51 PM
Bodyguardz carbon fiber skin vs. Ghost Armor Carbon fiber skin estestyler26 iPhone Accessories 4 May 7, 2013 10:18 PM
Carbon Skin? Ncage1974 MacBook Air 7 Mar 12, 2013 01:41 AM
Help with my first Cocoa App eugiel Mac Programming 1 Sep 30, 2012 09:18 AM

Forum Jump

All times are GMT -5. The time now is 04:27 AM.

Mac Rumors | Mac | iPhone | iPhone Game Reviews | iPhone Apps

Mobile Version | Fixed | Fluid | Fluid HD
Copyright 2002-2013, MacRumors.com, LLC