El problema de la implementación alternativa (Alternative Implementation Problem)

El problema de la implementación alternativa

El autor habla sobre el problema de las implementaciones alternativas que aparece repetidamente en el mundo del software. La experiencia del autor se centró principalmente en optimizar lenguajes de programación de tipado dinámico.

• El proyecto PyPy desarrolló un compilador JIT avanzado para Python, pero en la práctica casi no se usa. Como Python sigue cambiando al añadir nuevas funciones, a PyPy le resultó difícil mantenerse al día.
• LuaJIT es muy bien valorado, pero como el lenguaje Lua sigue añadiendo nuevas funciones, LuaJIT ha quedado varias versiones atrás.
• El JIT de TruffleRuby ofrecía el rendimiento más impresionante, pero su compatibilidad de funciones era insuficiente en comparación con CRuby, por lo que solo tuvo un despliegue limitado.

Lección: una implementación alternativa es una apuesta destinada al fracaso

• Si se crea una implementación alternativa, inevitablemente se depende de los cambios de la implementación oficial.
• La implementación oficial controla la dirección del proyecto, y la implementación alternativa no puede hacer más que seguirla.
• Tradicionalmente, al crear implementaciones JIT para lenguajes interpretados, agregar nuevas funciones al intérprete es mucho más rápido, por lo que la implementación oficial puede adelantarse al JIT.

YJIT: implementar un compilador JIT de Ruby dentro de CRuby

• YJIT es otro JIT de Ruby, pero eligió implementarse dentro del propio CRuby.
• Gracias a esto, YJIT pudo ser 100% compatible con todas las funciones de CRuby desde el principio.
• Ahora se ha convertido en el JIT oficial de Ruby y está desplegado en Shopify, Discourse, GitHub y otros.

Una lección desde una perspectiva más amplia

• El lenguaje Crystal, que se parece a lenguajes existentes pero no es compatible con ellos, también solo logró un éxito limitado.
• Algo que parece similar a un lenguaje existente pero no es compatible solo termina confundiendo a la gente.
• Al crear un nuevo lenguaje de programación, es mejor no intentar ser un subconjunto de un lenguaje existente y seguir su propio camino.
• Así podrá evolucionar a su propio ritmo y en su propia dirección, sin quedar atado al rendimiento, las funciones o las bibliotecas de otra implementación.

Opinión de GN⁺

• El “problema de la implementación alternativa” descrito en este artículo es algo que debe tenerse en cuenta no solo en los lenguajes de programación, sino también al crear todo tipo de sistemas de software y hardware.
• Si uno solo se enfoca en la estabilidad y la compatibilidad, innovar puede volverse difícil. Pero desde la perspectiva de los usuarios reales, la compatibilidad es un factor muy importante. Es clave equilibrar la nueva tecnología con una experiencia amigable para el usuario.
• Desde una perspectiva de largo plazo, al iniciar un proyecto nuevo conviene pensar bien con qué será compatible y en qué dirección evolucionará.
• Al crear un nuevo lenguaje de programación, hacer que solo se parezca en la sintaxis a uno existente no hace más que aumentar la confusión. Más bien, es deseable dejar clara su propia filosofía y dirección.
• Más que competir en el mercado, parece más probable tener éxito a largo plazo ofreciendo soluciones creativas y originales.

[GN⁺]

Comentarios de Hacker News

• Al desarrollar una nueva implementación alternativa, si termina teniendo una arquitectura distinta a la versión existente, lo que era fácil en la versión original puede volverse muy difícil en la nueva. Por ejemplo, si un software propietario carga/guarda por secciones, pero la nueva versión sube todo el documento a memoria, entonces podría ser necesario modificar toda la arquitectura de la nueva versión para soportar la función de agregar archivos adjuntos.
• Posicionarse como una alternativa a una implementación existente es una propuesta perdedora. Los proyectos que se promocionan como "Python + X" tienen dificultades para competir con la versión oficial. Pero si, como MicroPython, están diseñados para microcontrollers y no compiten con CPython sino con otros entornos de programación para microcontrollers, entonces pueden tener éxito.
• A pesar de las afirmaciones de compatibilidad, en la práctica muchas veces la compatibilidad es baja incluso con funciones antiguas del lenguaje, y esa es una razón por la que fallan las implementaciones alternativas. En Ruby y Python, un ejemplo es la falta de soporte para native C extensions.
• Según la experiencia de fundar una startup, en lugar de perseguir funciones básicas, habría sido mejor demostrar que la arquitectura podía soportar funciones empresariales y enfocarse en algo diferenciado.
• Los desarrolladores valoran más las funciones del lenguaje y la interoperabilidad que el JIT. Es más fácil crear tu propio proyecto paralelo que contribuir a un proyecto existente, pero hay que preguntarse para quién es realmente. Hay que cuidarse de no caer en la autocomplacencia.
• El código wrapper se desvía del estándar y tiene poca documentación, lo que genera dolor. Es mejor agregar solo las funciones estrictamente necesarias y usar los valores predeterminados.
• Es similar a los problemas que enfrentó TiDB por la compatibilidad con MySQL. En teoría es un protocolo abierto, pero en la práctica Chrome marca el rumbo.
• No hubo ninguna mención de Kotlin.