<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On Jun 10, 2005, at Fri, Jun 10, 10:44 01 AM, David Steuber wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Lucida Grande" size="3" style="font: 12.0px Lucida Grande">I seem to recall that it was also observed that new features in Tiger also exist as Carbon apps (Spotlight) and that Carbon doesn't seem to be going away any time soon.<SPAN class="Apple-converted-space"> </SPAN>Instead, it keeps getting new APIs.</FONT></P></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Once again, Carbon has always been advertised as a *transitional* technology. The keynote made clear that porting a Carbon app to ix86 is going to be significantly more difficult than porting a Cocoa app especially if that Carbon app is being maintained under CodeWarrior as so many legacy Carbon apps are. My personal belief is that Carbon will simply be swallowed by Cocoa - you'll end up with a Cocoa Xcode project that directly uses any Carbon functionality that hasn't yet been wrapped in Cocoa classes.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>When Apple strongly suggests that developers do a thing one has to realize that Apple is playing with a full hand and we are not. They can and do have other reasons which they may choose not to make public for doing what they do. So when I see Apple moving as much as possible to Cocoa I see this a sign that doing otherwise is swimming against the tide. Once again, Apple does not have infinite resources. If they have to choose in a pinch whether to make going forward easier for Cocoa or easier for Carbon which do you think they'd choose? Oh, that's right, they already had to make such a choice for the intel move, and clearly, they've been organizing this transition around Cocoa and Xcode for years. Carbon legacy apps got the short end of the stick here, partly because Carbon is inherently more difficult to port to intel than Cocoa, and partly because many Carbon legacy apps have been developed and maintained using CodeWarrior.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>As an aside one might consider the influence of CodeWarrior being purchased by Motorola. Apple and Motorola have had some bad history so this might go some way toward explaining why Apple kept CodeWarrior out of the loop here.</DIV><BR><BLOCKQUOTE type="cite"> <P style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Lucida Grande; min-height: 15.0px"><BR></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Lucida Grande" size="3" style="font: 12.0px Lucida Grande">Xcode also continues to keep Carbon open as a target and apps are allowed to use both Cocoa and Carbon APIs.</FONT></P></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>And I believe that Apple is hoping that developers will write mostly Cocoa apps using a bit of Carbon for that functionality not yet wrapped in Cocoa classes. Ultimately Carbon will be just another C library used from Cocoa.</DIV><BR><BLOCKQUOTE type="cite"> <P style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Lucida Grande; min-height: 15.0px"><BR></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Lucida Grande" size="3" style="font: 12.0px Lucida Grande">If Metroworks can't do Cocoa, then that is indeed a strike against it.<SPAN class="Apple-converted-space"> </SPAN>A rather hard strike indeed.<SPAN class="Apple-converted-space"> </SPAN>I was thinking more about Apple pushing Xcode over, say, Lispworks or any other possible development environment (like OpenMCL).</FONT></P></BLOCKQUOTE><BR></DIV><DIV>Again, Apple had no choice here. To do otherwise would have been to inform a number of companies that they were likely moving to intel. How long do you think that would stay secret? Apple has the tools in place now because they needed them internally to do 5 years worth of OS and Apple application builds. Other language implementors will have to play catch up because Apple was not in a position to tell them they would need to move to intel one day. I know I would not have bought the dual g5 tower on my desk if I had known Apple was moving to intel down the road. I wouldn't have bought the 17" PowerBook I own. Now multiply this by millions of customers and realize that Apple would have gone under in much the same way as Osborne did back in the '80s if they put the fortunes of LispWorks or MCL ahead of their own.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>To bring this back to openmcl, Gary made the right choice years ago when he decided to heed Apple's advice and focus on Cocoa not Carbon for Mac OS X. Unfortunately Apple were not in a position to tell Gary to start developing an IA32 back end 5 years ago even though Apple themselves already had one working for every build of Mac OS X. Hopefully Apple will be in a position soon to let Gary and others know if and when a transition to X86-64 is coming which would allow him to skip the transitional step of IA32. Until that time I think that Gary is wise to wait and focus immediate efforts on how nicely openmcl plays with Rosetta's dynamic translation.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>regards</DIV><DIV>Ralph</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BR><DIV> <DIV>Raffael Cavallaro, Ph.D.</DIV> <DIV><A href="mailto:raffaelcavallaro@mac.com">raffaelcavallaro@mac.com</A></DIV> </DIV><BR></BODY></HTML>