EOF is selling Apples, WebObjects sells Pears

[Nat!]

This is a mail going to the EOF mailing list and webobjects at group.apple.com

Here is a followup to my previous mail titled WebObjects Affirmation Statement (my comments) from about 1 week ago. In this mail I will just expand a bit on the topics raised there:


EOF is selling Apples, WebObjects sells Pears


When a developer develops for WebObjects chances are, that he isn't even doing it on an Apple computer. He is probably developing on a NT machine. Of course Apple knows the numbers better than me, but judging from the WO mailing list and personal contact it seems that NT is the prevalent platform for WO development (its got better adaptor support for sure). That in itself is of course pretty negligable, because the number of Apple developers are insignificant compared to the number of Apple users worldwide. But the WO Developers product will most likely also not run on Apple computers. Instead it will probably run on NT machines, a Sun server or with WO 5.0 on a Linux box. Mac OS X Server was not adequate as a server platform, due to its instability and it remains to be seen, whether Mac OS X will capture a sizeable share of the server market.
Since usually a WO solution will be deployed on one server and one server only, consequential Apple machine sales as WO servers will probably not even equal that of developer machines.

Looking at EOF/Objective-C/Cocoa the situation is completely different. Any such application must be developed on an Apple (sell each developer an Apple computer). Even better each copy of a custom EOF solution sold to a customer translates almost directly into sales of Apple machines! If that custom EOF app is used in a larger company, that can mean the sale of 10, 50, 100 or even more Apple machines. If a company like Apple has its foot right in there with an application, more sales to that company are not unlikely...

That might sound good to Apple. Albeit they are shutting themselves off that market, by abandoning the Objective-C only branch of EOF. The market will not be developing large scale custom software in Java only, or an Objective-C/Java hybrid. The risks would be simply to great. 

And these are the risks, that probably would make any sane company shy away from undertaking such an endeavor on a large scale project (in not particular order):


o From a system design perspective an Objc-C/Java bridge is a needless introduction of brittleness. In general, the more complicated the setup (C-runtime, bridge, Java) the less stable the system, violating the KISS principle. More technically, debugging bridged code is by principle unpleasant, given the current tools its almost impossible. It's difficult to trace memory leaks across the bridge. And then bridged objects are obviously slower than non-bridged objects. 

o Java Foundation is going to be a different implementation than Objective-C implementation. No one is error free not even Apple. Now there is a very good chance, that two different implementations do slightly different things. Leading to really subtle and hard to find bugs. 

o Switching mindsets between Objective-C and Java, when coding business logic and application code, is sure not to improve programmer's productivity.

o Java Performance. In WO its usually not _that_ big a problem, because you can always throw more money (fatter, more numerous hardware) at it. In a desktop application, you have one machine, where that application has to perform, there is usually only a finite amount of money to throw at it ($200 for more RAM per machine f.e.).  

o Virtual Machine Bugs. If you get a problem with that virtual machine you were developing on and must switch to a different virtual machine, you have suddenly a whole new different untested environment. Your old problem may go away, new problems may appear . If your problem does not go away there either, you can start developing your own VM... Problems like this always seem to crop up after developing for 1-1/2 years on big project XYZ.

o Resource sharing between applications. Each Java application runs in its own virtual machine. There is no such thing as shared libraries in Java. Dividing your big application into many smaller apps is not such a good idea anymore, when every library is linked into your application.

o Code optimizing. If you ever get into a tight spot, where the things run too slowly, you at least have the chance in Objective-C to just use C or even assembler. That is a comforting thought. If you are on a ship, you'd feel insecure, if there are no swiming wests anywhere! If the algorithm in Java is as good as it gets, you are hitting a wall.

o Given Apple's inability to provide patches and fixes to customers quickly, it is an absolute life saver to be able to fix Apple's frameworks with posers and categories. This can be a company saver,  when you do not have access to the source and time constraints/bugs on hand. 

o Development penalty in using Java. Objective-C makes a lot of problems easier to solve, due to the greater flexibility of the language and the runtime system.


None of the points make it strictly impossible to develop large scale applications, it just doesn't make it attractive (enough) in a business sense and neither in a technical sense. There are other possibilites outside of EOF and outside of Apple, that just make more sense.


Apple will provide pure Objective-C/EOF to "existing customers" only and has signalled that new development of pure Objective-C EOF Apps should not be done. By this Apple is shutting itself off from part of the market completely, a market where they should have a high chance of suceeding due to their superior technology. 

Apple should reconsider and give the market a totally different signal. Apple should - in any way it sees fit - give all developers/customers access to EOF/Objective-C and make sure that future applications written against this framework will be also runnable on Apple machines and OSs in the foreseeable future. It would be a strong selling point, if Apple would guarantee its customers, that if Apple were to abandon EOF/Objective-C in the not foreseeable future, that the customers get the source code. This is actually pretty common in this business of large scale custom software, when proprietary code is used.

Thanks for reading
	Nat!