> He talks a little bit about Interface Builder, but not a word on the different technologies that power the thing.
The main driving force behind the InterfaceBuilder and the OpenStep API's is ObjectiveC's deferred method call linking. This language is what enables the juiciest part of the IB, the one people seldom talk about: the possibility to build object graphs by plugging objects into other objects' outlets, and to link any event of an object to any action method of any other object. You can even use the IB to make a graph of objects that contains no graphical widgets. The IB produces no code (as erroneuosly stated in the article), instead it produces an archive of interlinked objects; in fact, the IB introduced a new programming paradigm which was, alas, followed by noone. Maybe it's because writing the whole thing in C++ would be overkill, if at al possible.
Other masterpieces resulted from ObjectiveC's power are the Foundation (and its Distributed Objects) and EOF frameworks. You have to actually compare these to any other counterparts to see why noone comes close. Dynamic linking, categories, protocols, these things work miracles; it's a shame ObjectiveC is slowly fading into oblivion, now betrayed even by its once-time main supporters: the former NeXT software team, now working on Mac OS X. And yes, Java comes painfully close, but its C++ legacy perpetrates enough brain damage to cancel the benefits of the ObjectiveC influence.
Some say crackers steal DirecTV's signal; others say that it's everybody's right to use whichever way they like whatever DirecTV is unsolicitedly beaming to their backyard.
I tend to side with the latter, I think it's OK if you build your own device that processes any signals that trespass your property; but when you buy DirecTV's hardware and services, you are in fact making an implicit statement that you are interested in their service and willing to pay for it; if you later use the hardware they provided for getting their service under other terms (that is, for free), it means cheating on that implicit statement, so it's more like stealing.
Check the context: it's not about patents, it's trademarking domain names he's speaking about. After all, patents would be a little offtopic in ICANN meetings, wouldn't it?
Apparently, certain advanced features of the GUI will only be available to you if you use the Objective C interface which is seems to be a way that Jobs can keep his NeXT dream alive.
I'm sure they'd rather have everything ported over to Java, for lots of reasons. The real reason they can't do it is not some Jobs' wacky dream, it's simply not feasible. Both Java and yours and others beloved bloated C++ lack the power, simplicity and elegance that enabled the creation of the AppKit, Foundation and Enterprise Objects frameworks. I dare anyone to show me a comparable dev kit written in Java or C++; use these frameworks for a while, then try JDK: it will look like kids' toys.
I can't imagine it would be extremely easy to port and maintain Windows applications, most of which are written in C++ to it either. For developers who are just starting out, writing their software in Objective C makes it very difficult to port to Windows locking them into the OS.
FYI, Cocoa (Openstep) is a portable environment; its Windows incarnation is called WebObjects for NT. Any well-behaved Cocoa application will only have to be recompiled to run under WO/NT.
Now Objective C might be the greatest language since latin, but the simple fact of the matter is that in GUI arenas, C++ currently dominates.
So does Windows in the OS arena; why don't you stick to it?
A lot of the Java libraries are designed in the spirit of OpenStep and the Java imaging model is essentially PostScript.
Take a closer look. There are subtle advantages to Objective-C over Java that makes the Openstep API much more powerful and flexible than the JDK; this is also why Distributed Objects is much better than RMI: I don't see how you could write something like the NSProxy in Java. It's the forwardInvocation: method, the categories and run-time vs. compile-time type checking that make all the difference. For a masterpiece of ObjectiveC programming, check out the Enterprise Objects Foundation; take a look at the EOFault and give me an ideea of how to implement it in Java - I tried hard but my $0.2 brain won't just cut it.
Now it's quite weird why Sun hasn't implemented all the ObjectiveC goodies in Java, especially since they are coauthors of the Openstep spec. Then we would have a really powerful alternative to C++. But I digress; I think the GNUStep people need help in their quest to build a free alternative to Openstep/Cocoa. It would bring everybody the possibility to use some wonderful programming paradigms that unfortunately have been marginalized for more than 10 years. Ever since I stopped working with the Openstep tools (2 years ago), programming is not as stimulating as it used to be. Whereas I would usually enjoy discovering new stuff in the APIs and the tools, now I just keep cursing: I can't do this, I don't have that.
>And what about the applications?... >And anyone who thinks that they could just recompile their OS X app for the x86 version is deluded. Three years ago, we ported a complex database OPENSTEP application from NeXT to OPENSTEP for Windows; that's not just another processor, but a substantially different sw platform too. It took us three days to do it completely, and that's because we didn't closely follow the OPENSTEP guidelines (today's Cocoa); otherwise it would take mere hours. You have to develop under OPENSTEP or Cocoa before you understand why this is possible, unlike any other platform. Even device driver development is different (the IOKit is object oriented; you only have to make a subclass or use an existing open source driver as a template), so writing a MacOS X driver is not the same as writing a Linux driver.
This whole theory with "cannibalizing Apple hw sales" doesn't seem right to me. Well, maybe it would make a small fraction of those considering buying Apple hw change their minds, but I'm quite sure things would evolve differently in the long run. Releasing a low-priced x86 MacOS X would provide a chance to taste the system for those unwilling to buy a whole Apple system; I think many would become addicted, especially if the development tools are sold for a reasonable price (that would enlarge the apps pool too - every other development system looks crippled after using the NeXT dev tools and frameworks). Then many of the new addicts would buy Apple hw, coz that's the real thing ! I've been running NeXTSTEP/OPENSTEP on both NeXT and Intel hw, and while overall system performance/stability was close, installing the system and setting up peripherals on Intel hw was nowhere near the seamless, out-of-the-box-and-running feel of the NeXT hw.
Slashdot Mirror
The main driving force behind the InterfaceBuilder and the OpenStep API's is ObjectiveC's deferred method call linking. This language is what enables the juiciest part of the IB, the one people seldom talk about: the possibility to build object graphs by plugging objects into other objects' outlets, and to link any event of an object to any action method of any other object. You can even use the IB to make a graph of objects that contains no graphical widgets. The IB produces no code (as erroneuosly stated in the article), instead it produces an archive of interlinked objects; in fact, the IB introduced a new programming paradigm which was, alas, followed by noone. Maybe it's because writing the whole thing in C++ would be overkill, if at al possible.
Other masterpieces resulted from ObjectiveC's power are the Foundation (and its Distributed Objects) and EOF frameworks. You have to actually compare these to any other counterparts to see why noone comes close. Dynamic linking, categories, protocols, these things work miracles; it's a shame ObjectiveC is slowly fading into oblivion, now betrayed even by its once-time main supporters: the former NeXT software team, now working on Mac OS X. And yes, Java comes painfully close, but its C++ legacy perpetrates enough brain damage to cancel the benefits of the ObjectiveC influence.
Some say crackers steal DirecTV's signal; others say that it's everybody's right to use whichever way they like whatever DirecTV is unsolicitedly beaming to their backyard. I tend to side with the latter, I think it's OK if you build your own device that processes any signals that trespass your property; but when you buy DirecTV's hardware and services, you are in fact making an implicit statement that you are interested in their service and willing to pay for it; if you later use the hardware they provided for getting their service under other terms (that is, for free), it means cheating on that implicit statement, so it's more like stealing.
Check the context: it's not about patents, it's trademarking domain names he's speaking about. After all, patents would be a little offtopic in ICANN meetings, wouldn't it?
I'm sure they'd rather have everything ported over to Java, for lots of reasons. The real reason they can't do it is not some Jobs' wacky dream, it's simply not feasible. Both Java and yours and others beloved bloated C++ lack the power, simplicity and elegance that enabled the creation of the AppKit, Foundation and Enterprise Objects frameworks. I dare anyone to show me a comparable dev kit written in Java or C++; use these frameworks for a while, then try JDK: it will look like kids' toys.
I can't imagine it would be extremely easy to port and maintain Windows applications, most of which are written in C++ to it either. For developers who are just starting out, writing their software in Objective C makes it very difficult to port to Windows locking them into the OS.
FYI, Cocoa (Openstep) is a portable environment; its Windows incarnation is called WebObjects for NT. Any well-behaved Cocoa application will only have to be recompiled to run under WO/NT.
Now Objective C might be the greatest language since latin, but the simple fact of the matter is that in GUI arenas, C++ currently dominates.
So does Windows in the OS arena; why don't you stick to it?
Take a closer look. There are subtle advantages to Objective-C over Java that makes the Openstep API much more powerful and flexible than the JDK; this is also why Distributed Objects is much better than RMI: I don't see how you could write something like the NSProxy in Java. It's the forwardInvocation: method, the categories and run-time vs. compile-time type checking that make all the difference. For a masterpiece of ObjectiveC programming, check out the Enterprise Objects Foundation; take a look at the EOFault and give me an ideea of how to implement it in Java - I tried hard but my $0.2 brain won't just cut it.
Now it's quite weird why Sun hasn't implemented all the ObjectiveC goodies in Java, especially since they are coauthors of the Openstep spec. Then we would have a really powerful alternative to C++. But I digress; I think the GNUStep people need help in their quest to build a free alternative to Openstep/Cocoa. It would bring everybody the possibility to use some wonderful programming paradigms that unfortunately have been marginalized for more than 10 years. Ever since I stopped working with the Openstep tools (2 years ago), programming is not as stimulating as it used to be. Whereas I would usually enjoy discovering new stuff in the APIs and the tools, now I just keep cursing: I can't do this, I don't have that.>And what about the applications? ... >And anyone who thinks that they could just recompile their OS X app for the x86 version is deluded. Three years ago, we ported a complex database OPENSTEP application from NeXT to OPENSTEP for Windows; that's not just another processor, but a substantially different sw platform too. It took us three days to do it completely, and that's because we didn't closely follow the OPENSTEP guidelines (today's Cocoa); otherwise it would take mere hours. You have to develop under OPENSTEP or Cocoa before you understand why this is possible, unlike any other platform. Even device driver development is different (the IOKit is object oriented; you only have to make a subclass or use an existing open source driver as a template), so writing a MacOS X driver is not the same as writing a Linux driver.
This whole theory with "cannibalizing Apple hw sales" doesn't seem right to me. Well, maybe it would make a small fraction of those considering buying Apple hw change their minds, but I'm quite sure things would evolve differently in the long run. Releasing a low-priced x86 MacOS X would provide a chance to taste the system for those unwilling to buy a whole Apple system; I think many would become addicted, especially if the development tools are sold for a reasonable price (that would enlarge the apps pool too - every other development system looks crippled after using the NeXT dev tools and frameworks). Then many of the new addicts would buy Apple hw, coz that's the real thing ! I've been running NeXTSTEP/OPENSTEP on both NeXT and Intel hw, and while overall system performance/stability was close, installing the system and setting up peripherals on Intel hw was nowhere near the seamless, out-of-the-box-and-running feel of the NeXT hw.