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.
I develop with both objective-c and c# and while I like the c# syntax and gc better, Interface Builder is the most elegant way of user interface programming out there.
Fleur de Sel
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."
There's also a Python bridge for Obj-C. So for those that prefer a very different language, with its interpreter already distributed with the OS, Python's a great option. You get the native objects exposed by OS X available to Python.
And let's not forget OS X is built on top of BSD. So effectively anything which can be written for BSD can be written for OS X. There are, of course, limited GUI tools, but options are available. Qt libraries, for example, will display native GUI elements when possible.
Developers: We can use your help.
Actually, Safari is largely written in C++ (the KDE rendering engine)
Actually, Safari IS written in Objective-C. So is WebKit. WebCore on the other hand is written in Objective-C++ (KWQ), and yes, includes a significant amount of C++ code (KHTML).
I think this adequately demonstrates the flexibility of Objective-C: to be able to interoperate with C and C++ code on their terms, while C++ code can only interact with Objective-C the same way C can.
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
Just because they're "bytecodes" doesn't tell us whether they're interpreted or compiled.
True, however in this interview with Anders (Chief C# Language Architect), he states that "I think one of the key differences between our IL design and Java byte code specifically, is that we made the decision up-front to not have interpreters". A bit further down he says "When you make the decision up-front to favor execution of native code over interpretation, you are making a decision that strongly influences design of the IL".
Certainly you CAN interpret it, but it was designed to be JITed.
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).
So does C++: they're called virtual function tables.
true. However, this sort of dynamic dispatch is limited to objects which are members of a certain inheritance hierarchy. In Obj-C, when a message is sent to an object the determination of whether or not that receiver can respond to the message is determined at runtime. It doesn't matter that the receiver is a member of a particular class which inherits from some class which defined some virtual functions.
With virtual functions in C++ it's sort of a cross between compiletime and runtime: The receiving object must be a member of a certain class hierarchy with the virtual functions defined in a parent somewhere. If you try to pass a class pointer of the wrong class (meaning it's not part of an exclusive hierarchy) then you'll get a compile time error. In Obj-C on the otherhand, we don't care what the class pedigree of an object is as long as it can respond to the message being sent (or to put it another way, as long as it's interface matches the expectations of the user).
Perhaps it could also be said that virtual functions are C++'s hack to allow limited dynamic dispatch. But it's not as dynamic as what is possible in Obj-C (or other very dynamic OO languages like Smalltalk and Ruby).
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.
Python. There you go. Have fun! Oh, don't forget to install PyObjC or you may be disappointed.
Note: Apple didn't come up with it. Neither did MS. It's open source. Apple employees have a lot to do with PyObjC though, which is also open source.
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".
i hate m$ as much as the next /.'er, but you're wrong on both counts.
MS gives theirs away for free, too.
MSDN membership is comparable to the price of ADC, when you compare the same ADC and MSDN levels. (msdn level 1 costs $500, level 2 costs around $1500).
one really annoying thing about apple -- I can use the latest versions of microsoft visual c on my clunky old W2K installation just fine (no way in hell am i "upgrading" to xp!). however apple's latest xcode requires me to upgrade osx -- it won't install on osx 10.3.9. it will only install on osx 10.4, and i can't see any good reason for it. this means for apple, i have to shell out $130 just to be able to upgrade xcode.
I must strongly disagree. In no sense is the auto-release pool equivalent to garbage collection. For one, you still have to think hard about memory management in any complex application - for temporary objects that are just part of the internal works of a function, they work OK, but then stack allocation works better. For actually passing objects around inside a program they don't work at all and you must still manage refcounting and ensure there are no refcount cycles.
For those who have not encountered this particular construct (which is not unique to Cocoa), an NSAutoreleasePool basically keeps memory around until the main loop is reached. So you can allocate objects inside one and not worry about freeing them, as long as they don't have to survive beyond this particular event. It's a bit more involved than that : there are stacks of them, and you can create them and flush them manually outside the context of a GUI thread. But it's a bit of a cludge and not a substitute for full automatic memory management (though I would agree that a language which forces you to use GC for everything is not suitable for implementing desktop applications).
Unless you mean that in ObjC the possible methods for an object are not available at link time,
Correct.
in which case type safety is not available. I don't know enough about ObjC; perhaps you can explain it to me succinctly?
You are actually almost right. The way to put it should be that type safety is available but not required. Method type safety is a compile-time warning, not a compile-time error, because while a program which passes the type safety checks is guaranteed to function without type errors at runtime, a program which fails the type safety checks is not guaranteed to encounter type errors at runtime.
If this sounds "bad", consider it in context of what happens when a type safety violation does occur at runtime-- the object is given a chance to deal with the "method not found" error itself, in the form of a forwardInvocation: method call basically saying "hey, I tried to execute the method named 'blah' on you and it didn't work"; if that fails, an exception occurs. The penalty for a type error is not all that bad, especially compared to what happens in this point in C++ (you get a messy crash). Also consider that while compile-time type safety is not totally accurate, there is also run-time type safety available which is much more accurate. All objects accept a respondsToSelector: (methodSelector) method which basically ask, "do you accept this method?", and this method has the ability to determine side-effects of dynamic dispatch that the compiler could not.
These are somewhat advanced techniques within Objective C, and one should not be running programs which emit type safety warnings unless you really know what you're doing. However, when used correctly these things are quite powerful. Performing type safety checks at runtime instead of compile-time allow objective c libraries to leverage the Delegate pattern in a way most languages can only dream of; an objective c object can accept any other object as a delegate, and then simply say "do you accept this method? if so, run it. if not, never mind". In Java, the analogous construct would require a potentially very messy use of interfaces and probably a lot of blank methods to satisfy those interfaces. ForwardInvocation: allows even stranger and more interesting constructs, for example "proxy objects"-- Objective C offers a concept called "distributed objects" which are much like Java RMI, except that distributed objects lack any of the stub hassle and are in fact entirely transparent to any code interacting with the distributed object in question.
(Full disclosure: Absolutely everything I describe above as an advantage in Objective C can be fully implemented in Java by use of the reflection classes. However, people rarely take advantage of this, perhaps partly because the reflection classes are not very fun to use, and perhaps partly because the Java reflection functionality is quite slow.)
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
xnu isn't a microkernel.
If you use a category add a method to a class in ObjC when someone passes you a object of that class (or I assume a subclass) it has that method and you can use it. If you extend the class in Java and someone passes you an object of the original class you can't use the new method. E.g. even if Java's string class were not final, adding a "encode to UCS-2 and frobnicate any combining marks" method to a subclass wouldn't let you call that method on string people pass you.
In C++ the "way around" that is to use an overloaded non-member function. I don't recall being able to do anything like that in Java though.