VisiónE

¡Reutiliza el código! ¡No lo tires!

Antecedentes

Como amante de los videojuegos vintage (antiguos), los emuladores diseñados para ejecutar las antiguas aplicaciones de esas maquinas decadentes vienen como anillo al dedo. ¡Es la oportunidad para disfrutar nuevamente de las diversiones de antaño! De más está decir que sirven para dejar testimonio de su antigua grandeza.

El programa en cuestión

Uno de mis sistemas favoritos fue el Sega Genesis, la consola más popular que produjo esa compañía. Fue el sistema que desbancó al NES de Nintendo. Y como tal, tiene multitud de seguidores. Siendo antiguo usuario de Windows, busque un emulador del sistema, encontrando varios. Pero el mejor sin duda fue el Gens. La primer versión que utilizé solo soportaba juegos propios del Genesis. Conforme el tiempo pasó, agregó soporte para el Sega-CD y el 32X. Ambos ampliaciones de dicha consola. ¡Era la gloria! ¡No existía emulador alguno que se le pudiera igualar! Alta compatibilidad, velocidad, y soportando cosas que otros ni por asomo conseguían. Su creador, Stéphane Dallongeville, decidió liberar el código como GPL, debido a su falta de tiempo por mantener el proyecto. Inmediatamente surgio un porte del mismo para Linux. Y entonces...

La decadencia

El porte para Linux, a pesar de conseguir recrear prácticamente todas las características del original, ha dejado que desear. Es lento por cuestiones incomprensibles. Y su desarrollo es lento... muy lento. Existen problemas fundamentales en la implementación que llevan meses sin ser resueltos. Para pronto: es inutilizable en términos prácticos. Sigue siendo uno de los mejores emuladores para Windows, después de Fusion, de Steve Snake. Y lo increíble, es que no hay un solo emulador decente para Genesis en Linux, a pesar de ser una máquina tan popular, existiendo buenos emuladores para otras bastante más raras, como el TurboGraphx 16.

Lo último

Hoy 20 de agosto de 2005, Stéphane anuncia que se reescribirá completamente el código de Gens, argumentando que es díficil de mantener. Yo simplemente no me lo creo. Parece más probable que el equipo desarrollador haya caído en lo que yo llamo "síndrome del código sucio". Cualquiera que haya escrito algo en su vida (me refiero a un programa), sabe que con el tiempo, conforme el programa crece, aumenta una sensación de "suciedad" en el código. Le crecen pelos y cosas. Al revisar antiguas secciones del código fuente, uno ve aparentes "parches", que no sabes ni porque están ahí, que no te gustan. Uno termina tratando al código como si fuera algo que se pudriera o se degradara con el tiempo. Y sientes un irrefrenable impulso por "limpiar" todo eso. Pero, a no ser que haya un error profundo de diseño, no veo una verdadera razón para hacer semejante cosa.

Como Joel Spolsky recalca, una de las razones por las que tenemos ese impulso radica en el hecho de que es mas difícil leer código que escribirlo. Y como bien señala, esos pelos y cosas están ahí por una razón: arreglan bugs. No hay ninguna razón para pensar que el código nuevo es mejor que el viejo. El viejo ha sido probado y usado. El nuevo no.

Bajo Windows, los problemas de Gens se reducen a un diseño de la interfaz no muy lograda. Bajo Linux, a la incorrecta implementación del SDL que sustituye aquí al DirectX. Pero en su interior, a pesar de no ser perfectos, ambos son una maravilla técnica. El núcleo del programa es eficiente y poderoso. ¿Por qué lo van a tirar a la basura? ¿De verdad creen que un programa construido por varias personas (el futuro Gens) tienen más probabilidades de tener más estética y coherencia interna que uno producido por una sola persona (el actual Gens)?

Esos "pelos y cosas" tomaron tiempo en crecer. El necesario para descubrir y corregir los inevitables problemas de los programas complejos. Reconstruir un código desde cero es tirar ese conocimiento a la basura.

Si realmente van a construir desde cero, auguro que el "nuevo", pero no necesariamente mejor Gens, tardará unos 4 años en compararse al actual, que es lo que ha tardado en llegar a donde está.

Concluyendo

Considero que la complejidad inherente a los programas hace inevitable la aparición de esos "pelos y cosas". Si tuvieramos la capacidad para "captar" un programa completo y todas sus funciones de una mirada estaría bien. Pero eso no sucede así. Supongo que es inevitable y que forma parte de otra clase de "orden". ¿No han escuchado que nuestro ADN está lleno de código "basura", "repetido", y no se cuantas cosas más? Tal vez lo que para nosotros es "bonito" resulta incompatible con la alta complejidad.