¿Carbon? ¿Cocoa?

En muchas ocasiones habrás oido hablar de estas APIs de programación, pero no comprendes muy bien de que va esta historia.

Stanley Roche nos trae un interesante artículo donde podremos comprender exactamente cuales son las bases de la programación en Mac y Mac OS X, así como dar luz sobre algunos mitos “maqueros” que corren de correo en correo y lista en lista.

¿Cuál es la diferencia entre Carbon y Cocoa?

Desde la aparición de Mac OS X las notas de prensa y noticias relativas a nuevas versiones de programas siempre hacen hincapié en que funcionan de forma nativa en el nuevo sistema operativo. Algunos de estos anuncios mencionan claramente que la aplicación está basada en Cocoa (cacao en español) y otras en Carbon (carbón o carbono). Los desarrolladores bien informados sin embargo no mencionan ninguno de los dos ya que saben perfectamente que el usuario medio de Mac o no sabe la diferencia entre uno y otro o simplemente no le importa.

Apple estuvo en conversación con los desarrolladores sobre las ventajas de Cocoa y como resultado, muchos usuarios de Mac han empezado a pensar que las aplicaciones basadas en Cocoa son de alguna manera mejores e incluso superiores a las aplicaciones basadas en Carbon. La verdad es que la elección de una API de programación tiene mucha trascendencia para el desarrollador pero más bien poca e incluso ninguna para el usuario final. Este articulo explica en que consiste exactamente Cocoa y Carbon, en que se diferencian y que impacto tienen tanto para el desarrollador como para el usuario final.

Las capas de MacOSX</center

Un poco de historia…

Cuando Mac OS fue introducido allá en 1984 era una joya tecnológica fruto de la programación más avanzada. Los sistemas operativos que vinieron en los años siguientes empezaron a implementar características tales como la protección de memoria y la multitarea preemptiva las cuales se han ido convirtiendo en algo imprescindible para el usuario de hoy. Apple no incluyó tales características en Mac OS simplemente porque entonces los microprocesadores no proporcionaban la potencia de proceso suficiente. Añadir características como la protección de memoria y la multitarea preemptiva a Mac OS era una tarea muy larga y compleja porque habían de ser implementadas a nivel del núcleo del sistema operativo. Apple lo intento varias veces pero nunca funcionó. Finalmente Apple decidió que comprar un sistema operativo moderno y hacerlo funcionar en el Mac era lo más razonable. Primero consideraron comprar BeOS de Be Inc., pero finalmente se decantaron por NEXTSTEP de NeXT Inc., la compañía que Steve Jobs fundó cuando dejó Apple. Esto de paso hizo que Steve Jobs volviera a Apple pero esta es otra historia.

NEXTSTEP proporcionó a Apple el sistema operativo moderno que necesitaba pero con un interfaz de usuario radicalmente diferente al de Mac OS. Apple empezó a cambiar NEXTSTEP para hacerlo más parecido a Mac OS. El resultado de todo esto fue entonces Rhapsody. Rhapsody era un novedoso y moderno sistema operativo para Mac con el típico interfaz Macintosh. El siguiente paso fue adaptar las aplicaciones existentes como Microsoft Office y Adobe Photoshop y hacerlas disponibles para Rhapsody con que los usuarios tendrían una buena razón para actualizarse.

Desafortunadamente, sistemas operativos diferentes son como idiomas diferentes. Pueden llevar a cabo las mismas tareas pero de manera manera muy distinta. Hacer que una aplicación Mac OS funcione en Rhapsody significa cambiar todo el código que comunica con el sistema a un nuevo lenguaje que Rhapsody entienda. Para empeorar aún más las cosas, las aplicaciones Mac están escritas en lenguajes como Pascal, C y C++ cuando el único lenguaje que puede comunicar con Rhapsody es Objective-C (y otros lenguajes desarrollados por NeXT). Los desarrolladores Mac que querían comercializar sus aplicaciones para el nuevo sistema operativo no sólo tenían que enfrentarse al aprendizaje de un lenguaje totalmente nuevo sino que también tenían que re-escribir sus programas desde cero. El problema es que las aplicaciones suelen estar hechas de miles e incluso millones de líneas de código. No es sorprendente que los desarrolladores no respaldaran la idea en absoluto por lo cual Apple tuvo que trabajar algo más con Rhapsody y proporcionar un mecanismo para facilitar el trabajo a los desarrolladores.

¿Qué es una API?

Las aplicaciones comunican con el sistema operativo gracias a unas interfaces llamadas en inglés “Application Programming Interfaces” o APIs abreviado. Estas interfaces o APIs hacen que la aplicación pueda hacer que el sistema operativo haga algo tan simple como un beep en el altavoz o algo más complejo como arrastrar y soltar un objeto. Por ejemplo para generar un beep la aplicación llamaría la función SysBeep(). En Rhapsody esta función se llama NSBeep.

¿Qué es exactamente Cocoa?

Cocoa es el nombre que Apple dio a las APIs de Mac OS X, las cuales ya existían en Rhapsody. Las aplicaciones que fueron escritas originalmente para NEXTSTEP se hicieron en Objetive-C y utilizaban las APIs Cocoa para comunicarse con él. Algunas de las aplicaciones que vienen con Mac OS X (tal como Mail o Chess) se escribieron originalmente para NEXTSTEP así que utilizan las APIs Cocoa. Hay también aplicaciones de terceros que fueron escritas para NEXTSTEP que han sido actualizadas para ejecutarse en Mac OS X. Estas aplicaciones también utilizan las APIs Cocoa.

¿Qué es Carbon?

Cuando Rhapsody paso a llamarse Mac OS X, Apple introdujo una solución para convertir las aplicaciones Mac de entonces, llamadas Classic, en aplicaciones nativas de Mac OS X. Añadió entonces otro conjunto de APIs a Mac OS X las cuales utilizan en su mayoría los mismos nombres y parámetros que las que ya había y se usaban anteriormente en Classic. Esto significa que gran parte del código ya existente puede funcionar tal cual y sólo una pequeña parte necesita ser re-escrita o actualizada para poder correr de forma nativa sobre Mac OS X. Esto representa mucho trabajo pero no tanto como re-escribir aplicaciones desde el principio. Este conjunto de APIs se llama Carbon.

¿Es Cocoa mejor que Carbon?

¡En absoluto! Tanto las APIs Cocoa como las APIs Carbon llaman funciones del “Application Services” y del “Core Services” de Mac OS X. Contrariamente a lo que piensa mucha gente, las APIs Carbon no llaman a las APIs Cocoa. No supone ninguna diferencia entre llamar a las APIs Carbon o a las APIs Cocoa. Pero está claro que si se desea escribir una aplicación nueva en C o Java y solo interesa que funcione en Mac OS X entonces quizás interese aprender Cocoa ya que sus funciones están más integradas dentro de sus librerías OOP. Pero la gran mayoría de desarrolladores quieren aprovechar el código que han ido escribiendo en los últimos años, seguir utilizando C o C++, los cuales controlan mejor, entonces prefieren utilizar Carbon y no aprender Objective-C ahorrándose el tener que re-escribir todo desde el principio con Cocoa.

¿Pueden las aplicaciones Cocoa hacer más cosas que las aplicaciones Carbon?

¡Para nada! Tanto las APIs Cocoa como las APIs Carbon llaman y utilizan las mismas partes del sistema operativo Mac OS X. Sin embargo existe un pequeño grupo de funciones que Apple no ha puesto a disposición de Carbon simplemente porque no son necesarias para crear una aplicación nativa Carbon. También existe un grupo de funciones que Carbon puede utilizar en Mac OS X pero no Cocoa porque las aplicaciones Cocoa simplemente no las necesita. Apple esta trabajando en eliminar estas pequeñas diferencias.

¿Son las aplicaciones Cocoa más “nativas” que las aplicaciones Carbon?

¡Rotundamente no! Tanto las APIs Cocoa como las APIs Carbon llaman y utilizan las mismas partes del sistema operativo Mac OS X. Las aplicaciones Cocoa no son ni más ni menos nativas que las aplicaciones Carbon. Las APIs Carbon son más nuevas que las APIs Cocoa y como resultado puede que haya más problemas con ellas a corto plazo aunque Apple trabaja muy duro en eliminar toda diferencia.

¿Es Cocoa el futuro de Mac OS X? ¿Desaparecerá Carbon algún día?

Como mencionamos anteriormente, si no hizo ninguna inversión en las APIs Carbon o C++ y sólo le interesa escribir aplicaciones para Mac OS X, Cocoa junto con Objective-C puede ser la mejor elección. Crear una aplicación con Cocoa y Objective-C requiere menos código para llevar a cabo las mismas tareas que con C++ y las APIs Carbon. Los desarroladores de aplicaciones Mac ya existentes sin embargo continuaran con toda seguridad utilizando C/C++ junto con las APIs Carbon debido a la inversión ya realizada, la base de código fuente existente y la portabilidad a otros sistemas operativos. Las aplicaciones escritas en Objective-C y las APIs Cocoa no son portables y esto es un problema ya que la mayoría de desarrolladores quieren poder distribuir sus aplicaciones en más de un sistema operativo.

Apple continua mejorando tanto las APIs Cocoa como las APIs Carbon ya que sabe muy bien que las aplicaciones más importantes para Mac OS X (MS Office, Photoshop…) están escritas con estas últimas. Si Apple quiere que estas aplicaciones utilicen las últimas tecnologías tiene que ponerlas a su alcance gracias a Carbon. Añadir nuevas tecnologías a Carbon y a Cocoa supone exactamente la misma cantidad de trabajo.

Este texto está basado en el artículo original de Geoff Perlman de Real Software, Inc.

traducido y adaptado por Stanley Roche Busk de Max Programming, S.L.

exclusivamente para FAQ-MAC.