Objective C is also known as objc or objective-c, and is in my humble opinion wonderfully elegant. It is now the focal language Apple is pushing for new Mac OS X development; though in theory they consider Java to be about equivalent in their eyes, Java frequently lags in tools support and is treated as a second-class citizen by some OS X APIs.
Objective C was created by Brad Cox in 1983, but nothing really happened with it until 1986, when Brad and Andrew Novobilski released a book on it, and the good people at NeXT (who were all Smalltalk junkies), decided to use the language as the foundation of their flagship operating system. Following this turning point, virtually overnight, Objective C had completely failed to take the world by storm, a status it still holds today. Meanwhile-- partly because of the reluctance of those who controlled the language to loosen their direct copyright control of it (GCC wasn't able to get a proper objc implementation until 1992) and partially because of a variety of other reasons-- pretty much everyone not developing for (and on) NeXT machines was quickly scared away into the arms of the also emerging and less-purely-oo C++.
With time, realizing that more and more the cult following for NeXT products was being driven by developers who had become addicted to the highly RAD aspects of the NeXTStep API and used it to make customized programs for corporations, NeXT began porting their API to other operating systems as a very (financially) expensive runtime and collection of development tools, trying to package NeXT as a platform-independent industrial-strength Objective C development environment. This continued until they were bought by Apple.
Objective C the language is still fairly inextricably intertwined with the NeXTStep API, which has been renamed to Cocoa now that Apple owns NeXT. Objc makes NeXTStep/cocoa what it is, and NeXTStep/cocoa makes objc worth using. ObjC is not, of course, welded to its API the way that java is (except for three to five classes that are at this point basically part of the language)-- but, since wants to write a class library from scratch, ObjC development for anything other than a NeXTStep workalike is rare.
NeXTStep has two halves, the Foundation and the AppKit. The first is a practically-essential-they're-so-useful collection of base classes that basically amounts to some kind of StdLib, the things that NeXT believed should be a part of any ObjC runtime. The second is NeXT/Apple's specific implementation of a GUI API written on top of that Foundation-- and in my opinion, it's the best damn GUI API ever written. Not everything you would want to write in Objective C would involve the AppKit, but near as i can gather, other than that, these days, all Objective C development uses a form of the NeXTStep foundation.
At this point "some form of NeXTStep" would be either GNUStep (Which is a GPLed re-implementation of NeXTStep; they are still in progress, and their AppKit is said to be buggy, but their Foundation is solid enough to develop for), which runs on linux, windows, and many Unices; or Apple's Cocoa (Which is YellowBox (Which is NeXTStep renamed) renamed), and only runs on Mac OS X; or WebObjects, an Apple product which is something a little different, runs just about anywhere, and seems to actually kind of resemble something between Zope, J2EE, and the Everything Engine. Once Mac OS X makes its market presence really well felt and Cocoa begins to attract developers away from Carbon in significant numbers, and once GNUStep becomes developed enough that it becomes a viable development platform for linux and windows software (or if mac users' wildest dreams come true and apple releases Cocoa environments for linux/windows..).. well, lets just say things are going to get very very interesting.
To clear up Nicola's writeup above just a bit: the @implementation, which you usually see dumped alone in its own .m file, is usually accompanied by an @interface, which goes in an accompanying .h file. the @interface is exactly the same, except instead of implementing the method as Nicola does above, you simply place method prototypes. If you have the { variable list } attached to the @interface, you are allowed to omit it from the @implementation.
Between the two, if you are trying to link into an object library, Objective C only requires the @interface's .h file-- the @implementation's .m file does not need to be distributed, and you can just distribute compiled binaries for that the way you do with C++.
Following is a little metanode of everything that objective-c adds to the C language. Let me know if you find anything relevant which i do not list here. Read these, and you basically understand the language; however, these nodes really should NOT be used as material for learning the objective-c language. They are more meaningful as reference material for those who already grasp the language basically and need to clear things up to themselves.
If you want to learn the objective-c language, there is an excellent book-- so good that any attempt to emulate it on everything2 would be pointless-- available for free at http://devworld.apple.c om/techpubs/macosx/C ocoa/ObjectiveC/ObjC.pdf (minus spaces). I suggest you read it, even if you have no use for objective-c-- it is a very quick read, and understanding the way objects are dealt with in objective c may give you a better understanding of how to deal with them in other languages.
A couple more things: If you wish to learn the NeXTStep/GNUStep/Yellow Box/Cocoa API-- which you probably will have to in order to do anything in objective c-- there is good coverage of all classes at:
- http://devworld.apple.c om/techpubs/macosx/C ocoa/Reference/Foundatio n/ObjC_classic/FoundationT OC.html
- http://devworld.apple.c om/techpubs/macosx/C ocoa/Reference/Applicatio nKit/ObjC_classic/AppKitT OC.html
These could be noded, but i would consider this a bad idea-- they are comprehensive and long, and if the e2 version got out of date it would be hellish to update. (There are writeups on id/NSObject, however, and a writeup on NSString might be worthwhile as well.) Just read them offsite. If you wish to use the open, cross-platform GNUstep rather than the mac os x-tied cocoa, http://gnustep.org/resources/documentation.html will help you understand where the two APIs differ.
And finally, a couple more URLs you may find interesting:
- C++ compared to objective c: http://www.mactech.c om/articles/macte ch/Vol.13/13.03/Ca ndObjectiveCCompared/
- Java as compared to objective c: http://www.wosource.com/ObjCvsJava.html
- Smalltalk, Eiffel, and objective c contrasted: http://www.dekorte.com/O bjective-C/Documentation/2_C omparisons/Comparisons.html