Slashdot Mirror
Steve Jobs thinks Objective C is Perfect?
josht writes "Nitesh Dhanjani has posted an e-mail thread between Steve Jobs and himself. Dhanjani argues "I'd like to see Apple developers gain more choice. With every iteration of OSX, there seems to be so much effort put into innovation of desktop components, but the development environment is age old." I agree with Dhanjani. What has Apple done recently to wow the developers, and make it fun to code Cocoa components? I've looked into the Objective C and Xcode environment but compared to Microsoft's .NET solutions, it doesn't impress me at all. I think Apple can do a lot better. Steve Jobs disagrees. What do the readers think about Objective C and Xcode?"
Anyone claiming a language lacking proper namespace support is "perfect" is nothing short of delusional.
He's already taken down the emails in question, apparently having had second thoughts about the appropriateness of posting private emails.
Sure, Xcode could do with a little bit of work to add features missing, but I truely find Cocoa a dream to work with. One year ago I only developed for the web, then I bought a Mac and was introduced to Cocoa by a friend. I havent looked back since, and have produced several 'scratch the itch' applications that otherwise wouldnt have been made.
The development environment is hardly static. Key-value-observing and bindings, Core Data; we get more toys for every system version and they are working on adding garbage collection to Objective C.
Network mirror still has the original blog post up.
Be a real patriot: Question authority. Think for yourself. Formulate your own conclusions.
Actually, Safari is largely written in C++ (the KDE rendering engine), and iTunes isn't an Obj-C app at all.
For some better examples, there's Xcode itself, Aperture, iPhoto, Quartz Composer, iChat, Address Book, and so on.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
You're splitting hairs, here. Safari is factored into an App and a couple of frameworks. The bulk of Safari is webcore.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Memory management in Obj-C is really simple, and making issue of it is an extreme exaggeration. You merely have to follow the rule of "if you allocate it, you're responsible for it", and make sure to either send it [obj autorelease] upon allocation or [obj release] in the [parent dealloc] routine. It really is that simple. Maybe that's too much to ask of the sissy programmers coming out of school these days.
cat
I code various C#/.NET things at work, and code Cocoa stuff at home for fun. I'm well-versed in both environments.
- The environments are apples and oranges (no pun intended). The languages, the workflow, everything is much different.
- Moving away from ObjC would require some significant reworkings of Cocoa, as its workflow is based on the "ObjC way". Take a look at the mess that is the Cocoa/Java bridge, or Cocoa#.
- Objective C is WAY more descriptive than other languages (take a look at how you pass arguments in functions, for example).
- Objective C is easy to learn. Yeah, it's a lot different than the usual paradigms, but when you learn it, you'll enjoy its simplicity.
Things I hate about Cocoa:
- It's not managed code. Why should application developers in this day and age have to worry about memory management? (autorelease doesnt count)
- Having to keep two different programming paradigms in my head. I never even learned C#, I learned Java and jumped right into C#, because they were so similar.
- Practically no one else in the world uses Objective C, so it's not a very valuable (salary-wise) skill to have.
- The X-Code/Interface Builder dance is quite clunky. It was cool back in the day, but Microsoft has a much better system developed.
- VS.NET 2005 > Xcode
"Is life so dear, or peace so sweet, as to be purchased at the price of chains and slavery?" - Patrick Henry
You can accomplish the same things with inheritance
No, you can't.
If you add methods to a class with an Obj-C category, all instances of that class gain those methods. This is not the same thing as inheritance, where only instances of the subclass have the new capabilities.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
The next generation Objective C and Xcode already exist: Smalltalk and Smalltalk programming environments.
Smalltalk is a language with Objective C's object model, but runtime safety, garbage collection, and reflection. Objective C was an attempt to create a very low overhead version of Smalltalk that would interoperate more easily with C code, but most of the technical reasons for making the compromises that were made in the design of Objective C are gone.
The only thing that would need to be done would be to extend Smalltalk with a notion of "native" or "unsafe" methods; that has been done multiple times before, and it can be done either by permitting C code to be embedded in Smalltalk (reversing the Smalltalk/C situation from Objective C) or by defining a Smalltalk subset that's close to the machine (as Squeak has done).
Dude you're nuts. Have you even *looked* at gcc's objective C support and the runtime or are you just pulling this out of your ass? Obj-C messages are highly optimized and incur about 2x-3x the overhead of C function calls.
Objective-C / Cocoa has it's warts, speed is not one of them.
As slow as javascript my ass. I doubt you've ever coded in obj-c. Please study a bit before you spread this kind of FUD.
Well, Copeland and OpenDoc are pre-Jobs Apple, so go yell at Amelio or Sculley about those two.
On the rest of it, Apple never made a blanket "use Carbon", or "use Cocoa" claim. They said, consistently, to use Carbon if you have a lot of legacy toolbox code, and to use Cocoa if you were starting a project from scratch or were bringing things over from NextStep. OpenStep is just the old name for Cocoa and Rhapsody is just the old name for OS X, so you're kinda overstating your point just to make it look more schizophrenic than it really was.
Metrowerks was in it for the money just as much as anyone else; they weren't "there" for anybody but themselves (and later, their shareholders). Once Metrowerks released a Windows version, they stopped giving the Mac priority and the tools stagnated. Apple inherited a perfectly good IDE from NeXT and Metrowerks gave no indication that they were chomping at the bit to upgrade their tools in a urry so that developers could be ready when OS X came out. Metrowerks wanted to play it cautious and didn't want to gamble on Apple's transition to OS X, so what else was Apple to do? I've met relatively few people except a few cranky old Toolbox guys who didn't want to make the transition to OS X, who aren't happy with Apple Developer support compared with what it was historically. The Inside Macintosh books used to cost an arm and a leg and weren't available in soft editions, MPW was a nightmare, as you stated, and the only other way to create applications was to buy third party IDE.
Life has been pretty good (not perfect, but pretty good) since Apple bought NeXT. It's been tumultous at times, but has steadily been heading in the right direction, and as a matter of fact, developers have not been leaving the platform in droves; there has been a well-documented and steady increase in the number of developers using OS X as their primary platform.
I'd hardly say they're "suffering".
The interface can exist as separate code, though. All the stuff that IB serialises is available through the Cocoa API (check out the docs on NSView and NSControl, for example), and can be instantiated directly with programming statements if you wish. Using IB to keep the UI code separate from the stuff that interacts with it is however a better way to work, as it allows modifications to be to made the UI without having to recompile the application (separation of concerns).
MS recognise the above, and will themselves be following a similar route in the future with XAML, which is set to replace WinForms as the UI-building methodology of choice once Vista is launched (XAML will be one of the Vista technologies back-ported to XP). WinForms is thus in life-support mode at the moment: they will fix bugs, but not add more features to it because it is considered to be a deprecated technology.
NB: I've adopted a mixed-mode approach to Mac programming that seems to work very well from a productivity viewpoint. I do a lot of the main stuff in AppleScript or F-Script, and "drop down" to Objective-C for performance-critical stuff, custom Cocoa sub-classes, Darwin-related tasks, and other things that AppleScript or F-Script either isn't good at, or does too slowly. One could of course do this equally well using (for example) Python with the PyObjC bridge, and I believe that there is something similar for Ruby (don't quote me on that, though!), so the scripting languages I use are just one of the options available to Mac developers. And XCode happily manages all the different language files from a single project, ensuring that Obj-C code is compiled before running the interpreted stuff, managing CVS repositories, and generally making the experience pretty holistic.
I'm not going to change your sheets again, Mr. Hastings.