De CodeWarrior, Xcode y Macs con Intel

*Actualización*: Greg cuenta en su blog cómo se enteró de la repercusión que estaba teniendo su descripción de su tiempo en Metrowerks y Apple, y se refiere a esta traducción como el enlace más interesante a su página —otros enlaces tuvieron menos suerte ;-)—. ¡Gracias, Greg!

A través de una red un tanto revuelta de enlaces, he encontrado esta página en la que Greg Bolsinga, un ex-ingeniero de Metrowerks, y actualmente empleado de Apple, cuenta algunas historias interesantes sobre ambas empresas. En realidad, su objetivo siempre había sido trabajar para Apple, pero pensaba que trabajar para Metrowerks era el segundo trabajo más parecido a trabajar en Apple. Consiguió entrar en Metrowerks en 1996, y se incorporó al equipo de compiladores Java.

El artículo es bastante largo, y aunque he incorporado la mayor parte del mismo en la traducción, he dejado algunos pasajes de menor interés, y he añadido [entre corchetes] notas para que se entiendan mejor algunos de los conceptos y siglas que se mencionan.

CodeWarrior y Palm OS:

En aquella época, estaba cerca el lanzamiento de CodeWarrior para Palm. Al parecer, alguien de Palm le dijo a Metrowerks que estaban utilizando el compilador 68K para Mac OS de Metrowerks, y que después realizaban un post-proceso del resultado […] para crear aplicaciones Palm OS. Se preguntaban si Metrowerks estaría interesada en vender esas herramientas. De ese requerimiento surgió la idea del Post-Linker. […] Así que, por lo que yo sé, fue Palm la que vino a Metrowerks con la idea de usar sus herramientas, y no al revés.

Acerca de Copland:

Trabajé para Metrowerks desde 1996 hasta el 2000. Nunca vi un ordenador con Copland en la oficina. El único ingeniero que trabajaba con Copland era un ingeniero _virtual_ (ya que no vivía en Austin). Había conseguido echar a andar el depurador de CodeWarrior (que en aquella época era una aplicación aparte del IDE) sobre Copland. Según recuerdo, el IDE funcionaba sin más (¿quizá en emulación?). El ingeniero solía bromear con que el depurador Copland de Metrowerks fue la única aplicación de terceros jamás creada para Copland. Lo que yo pensaba es que Metrowerks estaba esperando a ver si eso de Copland despegaba. El trabajo diario del equipo Mac de Metrowerks no se veía afectado por Copland; estaban enfocados en la versión de Mac OS que se entregaba en ese momento.

Metrowerks deja de lado Mac OS X, y apuesta por Carbon:

Vi NeXTstep en un viejo PC de la oficina de Metrowerks en el momento en que se anunció la compra de NeXT por Apple. Recuerdo que a uno de los ingenieros del IDE le gustó la pinta de FileMerge, y la copió para CodeWarrior. Según lo recuerdo, aún estaba bastante verde. Realmente no se sabía qué iban a hacer Apple o Metrowerks de este desarrollo. Creo que la dirección de Metrowerks le estaba intentando vender Latitude [una tecnología que permitía reproducir la API del Mac OS en Unix] a Apple, o a los clientes Apple de Metrowerks, como solución que permitía disponer de la Mac OS Toolbox en Rhapsody. Pero de esto no salió nada, especialmente cuando se anunció Carbon [el subconjunto de la Mac Toolbox que Apple reescribió para ser compatible con Mac OS X].

Las cosas entonces estuvieron muy tranquilas en Metrowerks respecto a Rhapsody. Según Rhapsody evolucionaba, y se soportaban PEF y CFM [formatos de codificación de archivos ejecutables] en Mac OS X, Metrowerks pareció pensar que esos eran los formatos que Apple iba a soportar, y Metrowerks creyó que Mach-O se iba a quedar como formato anticuado. Metrowerks apostó en lo que Apple le dijo a todo el mundo acerca de Carbon; que con un poco de esfuerzo de recodificación, tu aplicación funcionaría bien en Mac OS X. Metrowerks esperaba que a ellos también les funcionase esa estrategia. Creo que Apple esperaba más esfuerzo por parte de Metrowerks, pero Metrowerks se distrayó bastante una vez que se lanzó Mac OS X, por razones que explicaré a continuación.

No supe nada de la compra por parte de Motorola hasta que se anunció. Después algunos empleados dijeron que habían escuchado rumores. Se nos dijo que las cosas no cambiarían mucho. Se decía que Motorola estaba interesada en Metrowerks porque querían poder proporcionar una plataforma software completa a sus clientes. Con las herramientas de Metrowerks, tendrían mucho más que compiladores de referencia, y podrían entregar tanto herramientas integradas como bibliotecas de funciones. Otra meta de la compra era que Motorola pudiera poner todas sus operaciones software bajo el mismo paraguas. Al principio, la gente de software de Motorola se mudaron al edificio de Metrowerks. Después de irme, Metrowerks se moudó al Motorola Parmer en Austin.

Llegada a Apple, y apertura de miras:

Cuando llegué a Apple mediante habilidad y suerte en Marzo de 2000, me abrieron los ojos. Prácticamente todo lo nuevo estaba basado en Mach-O [otro formato de compilación de aplicaciones, propio de NeXTstep y Mac OS X, y que da el mayor rendimiento], y las aplicaciones que no estaban en camino. Nada se compilaba con CodeWarrior en el equipo Mac OS X. Estaba claro que Apple no estaba pendiente del éxito de Metrowerks. No por rabia, sino por supervivencia. El Mac OS clásico no era un sistema operativo que pudiera llevar a Apple a lo largo de los próximos 20 años. Mac OS X, basado en los probados cimientos Unix, tenía que ser el vehículo en el que avanzase la compañía.

Primeras pistas de _Marklar_ (el proyecto interno que compilaba Mac OS X para Intel):

Cuando llegué a Apple, acabé haciendo bastante trabajo en el sistema de compilación Java de Mac OS X. Se trataba de una interesante mezcla de proyectos Project Builder y makefiles [la forma en que trabajan los compiladores Unix tradicionales]. Mientras lo depuraba, me di cuenta de que Java se estaba compilando tanto para Intel como para PowerPC. En 2000. Les pregunté a mis compañeros por qué, y me dijeron que se compilaba así por razones históricas. El equipo en el que yo estaba también trabajaba en el _runtime_ de Objective-C [la parte de Cocoa que permite programar mediante el envío de mensajes entre objetos], y recuerdo un e-mail de justo cuando yo llegué en el que uno de los ingenieros retiró el soporte PARisc y SunSPARC del _runtime_ Objective-C. No retiró el soporte Intel. Por cierto, el soporte de 64 bits para el G5 se añade al ejecutable de una forma prácticamente idéntica al soporte Intel. El formato de ejecutables binario Mach-O es tremendamente ampliable.

_Marklar_ confirmado, con resultados excelentes:

Unos pocos años más tarde subió mi categoría y tuve que firmar un acuerdo de no revelación (NDA) sobre las compilaciones Intel. Entonces supe que el Mac OS X para Intel no sólo se compilaba y enlazaba. ¡En realidad funcionaban, y bien rápido! Jamás había visto correr Java tan rápido en Mac OS X, en ningún hardware. Dado que usar Mac OS X en Intel resultaba tan placentero, intentaba hacer todo mi trabajo en Intel. Tuve éxito durante un tiempo, pero era difícil. Cada vez que usabas Mac OS X en una máquina Intel, tenías que cerrar la puerta y las persianas, porque no todo el mundo lo sabía. No era fácil aislarse de esa forma del resto del equipo.

Llegada del PowerPC 970, alias G5; más rápido que Intel en computación, pero no en la prueba combinada:

Supe del G5 antes de su lanzamiento. Una parte del _runtime_ Java compila al vuelto _bytecode_ Java [la forma en que los programas Java se compilan para que los diferentes _runtimes_ los ejecuten siempre de la misma forma] a código máquina [el conjunto de ceros y unos que forman las instrucciones tal y como las entiende directamente el microprocesador], así que los ingenieros del compilador Java siempre conocen los nuevos chips por adelantado. Con esto se pretende verificar que no se genera código erróneo para el nuevo chip, y también para añadir mejoras y optimizaciones a la generación de código para dicho chip. Pero en Apple se trabaja de forma que uno sólo sabe lo que necesita saber, así que como miembro del equipo AWT [Applet Windowing Toolkit, el conjunto de funciones que permitía crear gráficos en pantalla o en un navegador a las primeras aplicaciones Java], no tenía por qué saber nada de los nuevos chips. Pero al mismo tiempo está claro que cuando un compañero trabaja encerrado la mayor parte del tiempo, hay algo. Llegó el G5, y con su bus principal más rápido, era más rápido que la máquina Intel de mi oficina. Cuando se lo hice saber a un ingeniero del equipo Mac OS X sobre Intel, resultó que mi máquina ya era _vieja_, y no tenía demasiada RAM. Me aseguró que Mac OS X era aún más rápido en las máquinas Intel más modernas que en el G5. Yo sé crear una prueba de rendimiento que pruebe casi cualquier cosa que yo quiera probar. Así que en aquella época Apple dijo que el G5 era más rápido, y disponía de pruebas de rendimiento para defenderlo. Y era verdad, para esos tests. Pero en general, Mac OS X sobre Intel simplemente da la sensación de ser más rápido. Sé que la compilación completa de todo el sistema Java era mucho más rápida en Intel que en PowerPC. La compilación de grandes paquetes de software realmente llevan al límite el sistema de Entrada/Salida, así que en mi experiencia ése es el cuello de botella.

Errores de Metrowerks:

Metrowerks cometió varios errores. Creyeron que lo que Apple decía sobre compatibilidad se aplicaba por igual a todas las aplicaciones Mac OS. Como herramienta de desarrollo, deberían haber liderado las nuevas tecnologías Mac OS, en lugar de permanecer en lo que claramente quedaba ahora como modo compatibilidad. Además, nunca vieron Mac OS X como una plataforma Unix, a pesar de tener experiencia con su IDE y compiladores en plataformas Unix. Si querían seguir siendo competitivos, deberían haber permitido la ejecución del compilador gcc como opción del IDE. Además, deberían haber intentado que Apple soportase mejor los compiladores Metrowerks de línea de comandos desde Project Builder y Xcode. En cierta forma Xcode lo soportaba, ya que puede ejecutar cualquier herramienta de línea de comandos con facilidad. Sin embargo, las opciones de compilación no eran compatibles con gcc. Metrowerks tampoco intentó ninguna clase de interoperabilidad. Nunca crearon un importador de Project Builder o Xcode, ni un importador de Makefiles, lo cual es increíble, porque ya tenían el código de un importador simple de Makefiles. Tampoco permitieron compilación multihilo, de modo que no permitían que los desarrolladores aprovechasen las grandes máquinas multiprocesador de los últimos 10 años. Deberían haber tenido como meta que el compilador de línea de comandos de Metrowerks fuese capaz de compilar Darwin (de código abierto, y basado en Makefiles), para demostrar que eran competitivos, el código compilado era más rápido, y se compilaba en menos tiempo. Además, cuando se anunció el G5, Metrowerks nunca soportó su conjunto de instrucciones, ni la compilación de 64 bits. Creo que cualquiera de esas acciones habrían demostrado que estaban más comprometidos con Apple y sus clientes.

Conclusiones:

Mis mensajes a comp.sys.mac.programmer.codewarrior de los últimos años tenían como propósito que los desarrolladores Mac pensasen en el compilador gcc, y lo que proporciona. En general, compilar código con más de un compilador siempre es una buena idea. Hace tu código más robusto. También facilitará el pasar ese mismo código a otro compilador, lo que es una ventaja cuando se quiere o se necesita soportar plataformas adicionales. Tiende a limar los puntos ásperos de tu código, y del diseño de tu programa. Los usuarios de CodeWarrior que nunca echaron un vistazo a Project Builder / Xcode con gcc acaban de encontrarse con una carga adicional de trabajo en un espacio de tiempo más corto (claro, suponiendo que quieran portar su código a Mac OS X para Intel). También he sugerido siempre a los usuarios de csmp.codewarrior que probasen el formato Mach-O, porque es el formato preferido por Apple. Algunos sugieren que no hacen todo lo que Apple sugiere, porque históricamente Apple ha dejado tecnologías en la cuneta. No estoy seguro de entender esa línea de pensamiento, porque dado que estás desarrollando para Apple, deberías estar al día de alguna forma con lo que Apple esté haciendo. Si no lo haces, entonces tu código y tú podeis quedaros atrás. También postularía que el que Apple deje tecnologías en la cuenta sin ton ni son es cosa del pasado. Apple está bastante centrada desde que Mac OS X salió en 2001.

Creo que aquello con lo que todo el mundo debería quedarse de esta gran aventura que es la programación en Mac OS es el mantener buenas prácticas de ingeniería de software. Intenta compilar y enlazar tu código con diferentes compiladores. Nunca se sabe dónde va a acabar compilándose y ejecutándose tu código. No sabes si un compilador diferente encontrará problemas que tú no conocías. Separa las cosas extrañas, por ejemplo, el hacer algo específico de un sistema operativo en medio de código C o C++ estándar. De todo punto separa la interfaz de usuario del código de proceso. Lo más probable es que si tu código ya es multiplataforma, ya habrás hecho esto. Si utilizas un lenguaje que puede estar perdiendo tirón, o es absolutamente nuevo, deberías considerar portar partes de tu programa, según haga falta, al nuevo lenguaje del momento. Los enlaces entre funciones C son la lengua común de todas las ABIs [la forma concreta en que un trozo de programa se comunica con otro, una vez compilado] en Mac OS X, Unix, e incluso Windows (creo), así que un buen interfaz C a las diferentes partes de tu programa también sirve de ayuda. Una vez que existe un interfaz C, cualquier lenguaje debería ser capaz de llamar a la funcionalidad proporcionada, no importa desde qué lenguaje o _runtime_.

Finalmente, hay que considerar que realmente no hay una forma clara de ganar dinero vendiendo herramientas de desarrollo. Los vendedores de cada plataforma quieren ser capaces de dirigir el desarrollo hacia nuevas versiones y características. Ya que un suministrador de herramientas de desarrollo de terceras partes muy probablemente no tendrá ni el mismo ritmo de lanzamiento, ni las prioridades del desarrollador de la plataforma, es inevitable que surjan conflictos de prioridades y fechas de lanzamiento. Creo que todas y cada una de las grandes plataformas de software proporcionan su propio conjunto de herramientas. Esto permite a quien desarrolla una plataforma dirigir a terceros con menos esfuerzo. Creo que Metrowerks tuvo un momento, de 1994 hasta 1998, más o menos, en el que sacaron dinero a sus herramientas Mac OS. Es una pena que prácticamente hayan desaparecido de Mac OS, porque fue un viaje divertido y excitante. Ahora Apple ha sido capaz de dar un paso adelante, y entregar herramientas que proporcionan muchísimas funciones, y también pueden dirigir a Apple y a terceros desarrolladores a donde tenga que ir la plataforma Mac OS X.

Vía “Infinite Loop”:http://arstechnica.com/journals/apple.ars/2006/3/8/3095 < "Rogue Amoeba's Blog":http://www.rogueamoeba.com/utm/posts/Linked/mw-2006-03-07-19-00 < "DaringFireball de John Gruber":http://www.daringfireball.net/ < "John Siracusa por iChat":http://arstechnica.com/staff/fatbits.ars/