Rick Schaut (Microsoft MacBU): “No basta con recompilar”

Siguiendo la línea marcada por el artículo de Scott Byer sobre las dificultades de Adobe a la hora de cambiar de herramientas para crear Binarios Universales, Rick Schaut ha publicado una entrada en su blog sobre el impacto del cambio en Mac Office y la MacBU.

El artículo de Rick se articula en torno a la respuesta a 4 preguntas, que según Rick corresponden a falsas concepciones:

# Si Steve dijo que bastaba con marcar una casilla y recompilar, ¿qué pasa?
# Apple lleva años aconsejando a los desarrolladores que se pasen a Xcode. Si hubiéseis seguido el consejo de Apple…
# Si hubiéseis migrado de Carbon a Cocoa, no tendríais ningún problema ahora
# Algunos ya lo han hecho, ¿por qué no vosotros?

Vamos a ver qué respuestas da Rick Schaut a cada una.

h3. Si Steve dijo que bastaba con marcar una casilla…

Pudimos ver en la “demo de la WWDC 2005”:http://www.entremaqueros.com/bitacoras/memoria/?p=191&page=3 que Theodore Gray, de Wolfram Research, creadores de Mathematica, tenía una versión de Mathematica 6 funcionando en Intel al cabo de un par de días de trabajo —la versión _preliminar_ estuvo disponible en un par de horas—. ¿Por qué Microsoft no dispone ya de versiones internas compilando para Intel?

La razón de Rick es que lo que se dice siempre en todas las guías de creación de Binarios Universales es que, si no está ya en Xcode, el proyecto debe pasar del entorno que sea a Xcode. Y ese paso, definitivamente, no es trivial. Según él, lo que dijo Steve no es que fuera trivial crear binarios universales, sino que las herramientas ya estaban disponibles y eran fáciles de usar, no un impedimento.

Por tanto, aún queda pendiente disponer de todo el código en formato Xcode.

h3. Apple lleva años aconsejando a los desarrolladores que se pasen a Xcode

Rick comenta que si bien es cierto que Apple ha ido haciendo cada vez más y más hincapié en Xcode, nunca dijo el porqué. Y migrar Mac Office a Xcode no es, en absoluto tarea trivial. Y el trabajo de portar Mac Office a Xcode hubiera significado menos tiempo para el desarrollo de nuevas características. Así que ahora, al menos, tienen una razón tangible —las máquinas Intel en la calle— para hacer ese trabajo _aburrido_.

h3. Si hubiéseis migrado de Carbon a Cocoa…

Sobre este, Rick comenta que no es más que ignorancia sobre lo que representan Carbon y Cocoa. Sin embargo, en un artículo que él mismo escribió acerca de las diferencias entre Carbon y Cocoa, reconoce que Cocoa hace más cosas por el programador que Carbon… y entre otras cosas, proporcionaría el cambio de ordenación de bytes, o _sexo_ de los datos.

Lo que también comenta ese artículo es que Cocoa está fuertemente ligado a Objective-C, y aunque se podría utilizar Objective-C++, se perderíán las ventajas. Y si se pasara todo a Objective-C, no se podría reutilizar el código de creación de documentos común entre las versiones Mac y Windows de Office. Así que Cocoa no es una opción… y de todas formas Cocoa implicaría Xcode, y esa es la parte realmente difícil…

h3. Algunos ya lo han hecho, ¿por qué no vosotros?

La respuesta de Rick es: por complejidad. La complejidad de un programa con centenares de archivos, clases, interfaces, crece de forma exponencial con el tamaño, y correspondientemente el tiempo de depuración. Compara directamente PowerPoint con BBEdit para decir que no es, de ningún modo lo mismo… Si bien no menciona que Keynote ya está disponible como binario universal. Claro que, de todas formas, Keynote fue creada con Cocoa y Xcode desde el principio, y seguramente tuvo versiones internas en binario universal.

También señala que el código generado por Xcode a través de gcc no es tan compacto como el generado por CodeWarrior, y que el sistema de símbolos para depuración tampoco es tan eficiente como los archivos xSYM de los productos de Metrowerks, y que ha llegado a haber un caso de aplicación —al parecer, no de Microsoft— que ha crecido tanto a la hora de compilar con gcc y símbolos de depuración que _sobrepasaba los límites del sistema de memoria virtual_. Incluso propone un test para comprobar la diferencia de tamaño entre un binario compilado sin símbolos de depuración y otro compilado con ellos.

h3. Conclusiones

Rick concluye diciendo dos cosas:

[…]Quiero dejar claros dos puntos. Primero, estoy de acuerdo de todo corazón con el punto principal de Scott: no puedo imaginar a ningún desarrollador que prefiriese un largo, dilatado proceso de cambio de código de un sistema de compilación a otro, a crear características que resuelvan problemas de la gente. Ya estamos haciendo tanto como podemos hacer.

[…]En segundo lugar, quiero dar las gracias al grupo de herramientas de desarrollo de Apple por el servicial trabajo que han estado haciendo para ayudarnos a hacer la transición. Soy reticente a dar nombres, pero ojalá pudiera. Me he encontrado con estas personas, y son realmente una gente destacable. Gracias, a todos. Vosotros sabéis quiénes sois.