Mantenga un lenguaje de programación compatible con versiones anteriores en lugar de solucionar sus fallas

Primero, algo de contexto (cosas que la mayoría de ustedes saben de todos modos):

Cada lenguaje de programación popular tiene una evolución clara, la mayoría de las veces marcada por su versión: tiene Java 5, 6, 7, etc., PHP 5.1, 5.2, 5.3, etc. Al lanzar una nueva versión, hay nuevas API disponibles, corrige errores, agrega nuevas características, nuevos marcos, etc. En definitiva: es bueno.

Pero, ¿qué pasa con los problemas del idioma (o la plataforma)? Si hay algo mal en un idioma, los desarrolladores lo evitan (si pueden) o aprenden a vivir con él.

Ahora, los desarrolladores de esos lenguajes reciben muchos comentarios de los programadores que los usan. Por lo tanto, tiene sentido que, a medida que pasa el tiempo (y los números de versión), los problemas en esos idiomas desaparecerán lenta pero seguramente. Bueno en realidad no. ¿Por qué? Compatibilidad con versiones anteriores, por eso. Pero ¿por qué es esto así? Lea a continuación para una situación más concreta.

La mejor manera de explicar mi pregunta es usar PHP como ejemplo:

PHP es amado y odiado por miles de personas. Todos los lenguajes tienen fallas, pero aparentemente PHP es especial. Mira esta publicación de blog . Tiene una lista muy larga de los llamados defectos en PHP. Ahora, no soy un desarrollador de PHP (todavía no), pero leí todo y estoy seguro de que una gran parte de esa lista son problemas reales. (No todo, ya que es potencialmente subjetivo).

Ahora, si yo fuera uno de los tipos que desarrolla activamente PHP, seguramente querría solucionar esos problemas, uno por uno. Sin embargo, si hago eso, el código que se basa en un comportamiento particular del lenguaje se romperá si se ejecuta en la nueva versión. Resumiendo en 2 palabras: compatibilidad con versiones anteriores.

Lo que no entiendo es: ¿por qué debería mantener PHP compatible con versiones anteriores? Si lanzo la versión 8 de PHP con todos esos problemas solucionados, ¿no puedo simplemente poner una gran advertencia diciendo: "No ejecute código antiguo en esta versión"?

Hay una cosa llamada deprecación. Lo tuvimos durante años y funciona. En el contexto de PHP: mire cómo en estos días la gente desalienta activamente el uso de las mysql_*funciones (y en su lugar recomienda mysqli_*y PDO) La desaprobación funciona. Podemos usarlo. Deberíamos usarlo. Si funciona para funciones, ¿por qué no debería funcionar para idiomas completos?

Digamos que yo (el desarrollador de PHP) hago esto:

• Inicie una nueva versión de PHP (digamos 8) con todos esos defectos corregidos
• Los nuevos proyectos comenzarán a usar esa versión, ya que es mucho mejor, más clara, más segura, etc.
• Sin embargo, para no abandonar versiones anteriores de PHP, sigo lanzando actualizaciones para solucionar problemas de seguridad, errores, etc. Esto tiene sentido por razones que no estoy enumerando aquí. Es una práctica común: observe, por ejemplo, cómo Oracle siguió actualizando la versión 5.1.x de MySQL, aunque se centró principalmente en la versión 5.5.x.
• Después de unos 3 o 4 años, dejo de actualizar las versiones antiguas de PHP y las dejo morir. Esto está bien, ya que en esos 3 o 4 años, la mayoría de los proyectos habrán cambiado a PHP 8 de todos modos.

Mi pregunta es: ¿Todos estos pasos tienen sentido? ¿Sería tan difícil de hacer? Si se puede hacer, ¿por qué no se hace?

Sí, la desventaja es que rompes la compatibilidad con versiones anteriores. ¿Pero no vale la pena pagar ese precio? Como ventaja, en 3 o 4 años tendrás un idioma con el 90% de sus problemas solucionados ... un idioma mucho más agradable para trabajar. Su nombre asegurará su popularidad.

EDITAR : OK, así que no me expresé correctamente cuando dije que en 3 o 4 años la gente se mudaría al hipotético PHP 8. Lo que quise decir fue: en 3 o 4 años, la gente usará PHP 8 si comienzan un nuevo proyecto.

Suena bien, pero rara vez funciona en la práctica; las personas son extremadamente reacias a cambiar el código de ejecución, e incluso para proyectos nuevos de campo verde son muy reacios a cambiar de un idioma / versión que ya conocen.

Cambiar el código existente en ejecución que "funciona bien" no es algo que ocupa un lugar destacado en la lista de prioridades de ningún proyecto. En lugar de aplicar un esfuerzo a las cosas que los gerentes pensaron que ya habían sido pagadas, solo para poder actualizar a una versión más reciente de un lenguaje o plataforma, decretarán que los desarrolladores deberían permanecer en la versión anterior "por ahora". Puede intentar atraer a sus usuarios con excelentes funciones que solo están disponibles en la nueva versión, pero es una apuesta en la que corre el riesgo de disminuir su base de usuarios sin un beneficio claro para el idioma; Las características modernas y geniales no se pueden comparar fácilmente con el precio de la base de instalación fragmentada en la opinión popular, y corre el riesgo de obtener una reputación de ser una "cinta de correr de actualización"

(Obviamente, la mayor parte de esto no se aplica a los proyectos escritos por aficionados solo por su propio placer. Sin embargo (aquí puede ser un flamebait ...) PHP es desproporcionadamente raramente elegido por los hackers porque es un placer escribir con ellos en primer lugar. )

Estás subestimando el impacto de la compatibilidad con versiones anteriores; su estimación de que todos los proyectos activos migrarían en 3 o 4 años es demasiado optimista.

Supongamos que soy un desarrollador de PHP. PHP tiene fallas, pero sé cómo solucionar esas fallas, esa es parte de la razón por la que me pagan como desarrollador de PHP. Ahora suponga que sale PHP 8 y ​​corrige esos defectos, pero no es compatible con versiones anteriores. Como resultado:

• Tengo que pasar tiempo actualizando mi código para PHP 8. Ese es el tiempo que podría pasar respondiendo a las solicitudes de los clientes, implementando nuevas funciones y manteniéndome al día con la competencia.
• Incluso después de hacer esto , hay una buena posibilidad de que me haya perdido algún caso de esquina o un problema de compatibilidad imprevisto, introduciendo errores en mi código.

Dado esto, existe un fuerte incentivo para nunca migrar a PHP 8, incluso si es "mejor, más claro, más seguro, etc." Se estima que todavía hay miles de millones de líneas de COBOL (!), Aunque obviamente hay tecnologías mucho mejores disponibles, el costo de una actualización, combinado con el riesgo de errores, simplemente no hace que valga la pena.

Segundo, incluso si decido migrar mi propio código, cualquier aplicación no trivial depende de bibliotecas de terceros, y no hay garantía de que las bibliotecas de terceros migren. Por ejemplo, Python 3 se lanzó en diciembre de 2008, pero Django (probablemente el marco web líder de Python) no tuvo soporte de Python 3 estable y listo para producción durante casi cinco años (ver aquí y aquí ).

Estás haciendo muchas suposiciones sobre el comportamiento humano. Si lo cambia demasiado, las personas evaluarán a sus competidores, ya que de todos modos tendrán que gastar un esfuerzo significativo para cambiar. Para los idiomas de código abierto, la gente simplemente bifurcará la versión anterior.

Mira python para un ejemplo. 3.x ha estado disponible durante cuatro años, y todavía no está ampliamente adoptado. La gente trata de usarlo para proyectos nuevos, pero creo que estás subestimando cuánto trabajo de código es mantenimiento.

Por supuesto, la mayoría de la gente no consideraba que python 2.x fuera "defectuoso". No tenían quejas como los usuarios de php. Php está en una posición mucho más precaria, porque mucha gente solo se queda con él debido a su gran base de código existente. Si pierde la compatibilidad con versiones anteriores, muchas personas aprovecharían la oportunidad que estaban esperando para mudarse a Python.

Para cualquier lenguaje que no sea PHP, diría que sí, ¡eso tiene sentido! Eso es exactamente lo que está haciendo Python con el cambio a Python 3.

Sin embargo, el problema con PHP es que hay demasiados defectos con el diseño del lenguaje en sí, por lo que lo que llama "PHP 8" sería un lenguaje completamente diferente. Y si tuviera que cambiar a un idioma diferente, ¿por qué se quedaría con un nuevo PHP, en lugar de cualquiera de las alternativas estables y existentes actualmente?

También la comunidad PHP es extremadamente lenta para adaptar cualquier cosa nueva. Solo mira cuánto tiempo tardó en deshacerse de él register_globals. Se sabe que es un riesgo de seguridad desde el año 2000. Solo se eliminó finalmente 12 años después. Otro ejemplo, cuando se introdujo PHP5, fue una gran mejora con respecto a PHP4, pero la comunidad no lo adaptó. Tomé 4 años y acciones masivas como GoPHP5 para impulsar la adopción. Y eso incluso no tenía una cantidad significativa de cambios hacia atrás incompatibles.

Descargo de responsabilidad: administro un grupo de usuarios de ColdFusion.

ColdFusion sufre los mismos problemas: amado por muchos, despreciado por muchos. Además, toneladas y toneladas de FUD basadas en versiones anteriores a Java. ColdFusion 10 salió el año pasado, es un gran vendedor y la semana pasada me inscribí para probar el prelanzamiento de la versión 11. Además, hay dos alternativas principales de código abierto, una respaldada por JBoss.

Hay TONELADAS de nuevas funciones en CF10 que me encantaría implementar, pero migrar desde CF 7 u 8 puede ser difícil dependiendo del tamaño de su base de código, el número de proyectos futuros y los recursos que tiene para probar la regresión todo una vez que Estás en la última versión. Me he encontrado con una serie de pequeñas diferencias sintácticas entre 8 y 9, así como casos extremos donde el código no se compila de la misma manera. Una vez encontrados, los documenté en nuestros Estándares de codificación para que no sean utilizados en proyectos futuros o por nuevos desarrolladores.

Dicho esto, si ColdFusion 11 (o cualquier lenguaje de programación) fuera a desaprobar por completo ciertas funciones y sintaxis, el nivel de esfuerzo para encontrar y reemplazar la funcionalidad podría ser enorme. El esfuerzo de prueba podría ser gigantesco. ¿Las compañías pagarán a sus desarrolladores, QA y gerentes de proyecto para encontrar, reemplazar y probar todas esas cosas obsoletas? Dudoso.

Si la última versión de un idioma es compatible con versiones anteriores, pero presenta un aumento en el rendimiento sin cambios de código (CF9 es aproximadamente un 30% más rápido que CF8 y CF10 es mucho más rápido que CF9), ¿a quién le importa cambiar las llamadas a funciones si todavía funcionan?

Como empresa, debemos preocuparnos por complacer a nuestros clientes y satisfacer sus necesidades para facturar servicios, desarrollar el negocio y reclutar más clientes.

FWIW, me encantaría llevarnos a la última versión de jQuery en algún momento, pero dado que algunas funciones fueron desaprobadas algunas versiones después de lo que usamos, y dado el volumen de JavaScript que tenemos en el sistema, no sé cómo vamos a lograr eso.

Hay una compensación aquí; algunos errores REALMENTE necesitan reparación, pero algunas cosas no se pueden cambiar sin romper el código de alguien en alguna parte. Me parece recordar que alguien declaró como "regla" que cada corrección de errores rompería el proyecto de alguien, no importa cuán oscuro u obviamente roto sea el error, alguien lo usará para algo. Tal es la naturaleza de los programadores.

Esta es (en mi opinión) la diferencia entre lanzamientos principales, lanzamientos menores y revisiones. Como principio general:

• Se supone que las versiones principales contienen cambios importantes.
• Las versiones menores pueden cambiar ligeramente el comportamiento.
• Las revisiones deberían ser más o menos compatibles.

Por ejemplo, si estoy escribiendo algo en v2.3 de un idioma, no esperaría notar ninguna diferencia si actualizo a v2.3.2. Si actualizo a v2.4, entonces algunas cosas podrían cambiar: pequeños ajustes de sintaxis, algunas funciones se comportan de manera un poco diferente, así que tengo que ajustar la lógica, etc. Si actualizo a v3.0, no me sorprendería si se rompiera completamente: funciones desaprobadas o faltantes, operaciones no admitidas o cambiadas tanto que no puedo ajustarlas de nuevo a la línea, en realidad tengo que reescribir algunas funciones para dar cuenta de los nuevos cambios.

Editar:

El documento de Steve Vance Advanced SCM Branching Strategies tiene esto que decir:

Por lo general, hay dos o tres niveles de liberación, nombrados por números relacionados con puntos (por ejemplo, 1.2.3). [...] En esta estructura, el primer número está asociado con una versión principal, lo que indica que tiene características significativas y mejoras funcionales de la anterior; También puede haber importantes incompatibilidades que requieren migración. El segundo número representa una versión menor, que contiene mejoras menores en las características y funciones, un número significativo de correcciones de errores y ninguna incompatibilidad. El tercer número se refiere a un nivel de parche, lo que significa casi exclusivamente una colección de correcciones de errores; no se permiten mejoras de características o funciones y no se permiten incompatibilidades entre niveles de parche.

La única alteración que haría a esto es el principio antes mencionado de que los programadores a menudo encuentran formas de "usar" errores, por lo que una versión menor con "un número significativo de correcciones de errores y sin incompatibilidades" podría ser difícil, porque es probable que los errores romperán algo que los usó o provocarán que una solución alternativa sea innecesaria y comience a causar problemas.

Realmente depende de cuál es el objetivo del idioma: qué tipos de aplicaciones están destinadas a ser construidas con el idioma.

Por ejemplo, ignorando Android, Java se usa principalmente en grandes sistemas empresariales y middleware; Estos tipos de aplicaciones tienden a ser muy grandes tanto en tamaño como en tiempo. Esto tiene algunas implicaciones; imagine un sistema con 500K + LoC en el que los trabajadores de más de 50 ingenieros en la fase de desarrollo. Típicamente, este tipo de sistema entra en mantenimiento después de esto con, digamos, 10 desarrolladores; ahora, si el idioma cambia y los cambios no son compatibles con versiones anteriores, el proyecto no se puede migrar fácilmente a una nueva versión porque los programadores que escribieron algunas partes se han ido y nadie quiere tocarlo. Este es el problema más pequeño, el problema más grande consiste en el hecho de que es un poco costoso adaptar una aplicación 500 LoC a nuevas restricciones de idioma. Por ejemplo, si los genéricos no se implementaron con borrado de tipo yList list = new List(); no compilaría millones de líneas de código, necesitaría ser reescrito, lo cual tiene un gran costo.

Por otro lado, PHP tiende a usarse en la web para aplicaciones más simples; Por lo general, es desarrollado por un solo programador o un pequeño equipo. La idea es que los desarrolladores conozcan bastante bien todo el proyecto y puedan integrar los cambios de idioma más fácilmente. Además, su propósito es construir un sitio muy rápido, y cuanto más rápido mejor, por lo que si una nueva función de lenguaje puede hacerlo mejor, entonces se implementa incluso con algunos costos de compatibilidad con versiones anteriores.

Se puede argumentar que Microsoft realizó un cambio similar con ASP.NET (como sucesor del ASP clásico) o con VB.NET (aunque hicieron tantas concesiones con este último que la mayoría de los beneficios de "reiniciar" el idioma se perdieron).

De todos modos, si alguien recuerda la pesadilla de migrar el código VB6 a VB.NET incluso con la ayuda de una herramienta de migración, aceptarán de inmediato que las herramientas de migración de idiomas no funcionan muy bien para las principales actualizaciones de idiomas.

Es posible que la plataforma avance, pero aún así debe brindar soporte para API "obsoletas" a través de al menos algunas revisiones.

Muchos de los "defectos" sobre los que la gente grita en los lenguajes de programación populares no lo son, son cosas que el juguete favorito del gritador del día tiene que falta ese idioma, POR LO TANTO ese idioma es fundamentalmente defectuoso porque carece de eso.
Llega la próxima exageración, el lenguaje es de repente defectuoso porque no se adhiere a esa exageración.

La falta de cierres en Java es un ejemplo clásico. Eso no es un defecto en el idioma en absoluto, y cambiar el idioma (como lamentablemente está en la agenda) para incluirlos, la OMI lo paralizará fundamentalmente o, al menos, hará que sea mucho más difícil de leer y comprender.

Lo que muchas personas pierden de vista es que cada idioma tiene sus fortalezas y debilidades y que tratar de crear algo que combine las fortalezas de todo mientras evita todas las debilidades solo creará un monstruo completamente inutilizable que es bueno para nada, increíblemente difícil de manejar, imposible de manejar. usar de manera efectiva.

Agregue, como han señalado otros, que la compatibilidad con versiones anteriores es vital para retener a los usuarios existentes, muchos de los cuales NO van a gastar las miles de horas y millones de dólares / euros para adaptar sus bases de código de millones de líneas a lo que creas que es "mejor" que la versión del lenguaje que han estado usando durante años, y tienes una gran cantidad de argumentos muy buenos para dejarlo en paz y si quieres jugar con alguna idea nueva y exagerada, ese es supuestamente el próximo "asesino de Java" d mejor juegue con ese juguete en lugar de gritar que "Java iz ded" a menos que "se arregle" para ser un clon de ese juguete.

Sugeriría que las versiones más nuevas de un lenguaje deben esforzarse por garantizar que el 99.99999% del código que se compila tanto en la versión antigua como en la nueva del lenguaje funcione de manera idéntica en ambos, a menos que esté deliberadamente diseñado para no hacerlo, y que la mayoría de las veces cuando la nueva versión rechaza el código que se compiló en la versión anterior, será porque el código era, en el mejor de los casos, dudoso, y debería haber sido escrito de una manera diferente que compilaría tanto en el compilador antiguo como en el nuevo.

Por ejemplo, si estuviera diseñando un nuevo lenguaje similar a Java o C #, prohibiría las conversiones de tipo implícito en algunos contextos donde esos lenguajes lo permitan. Como un ejemplo simple en C #, dado

int someInt;
double someDouble;

someInt.Equals(someDouble)se garantiza que la expresión devuelve falso, independientemente del contenido de las variables. Se compila porque se doublepuede convertir Objecty inttiene una Equalssobrecarga para ese tipo, por lo que el compilador realiza la conversión y realiza la llamada. Si estuviera diseñando una nueva versión de C # y .NET Framework, habría prohibido la conversión de boxeo ya que no puede hacer nada útil. Es posible que haya algún programa que haga tal comparación de una manera que sea inútil pero inofensiva, y que el compilador rechace dicho código podría romper ese programa, pero corregir o eliminar dicho código inútil sería una mejora.

Como un ejemplo un poco menos claro, suponga

float f=16777216f;
int i=16777217;

y considera la expresión f==i. Es posible que algún código hace comparaciones float / enteros y funciona correctamente, pero el código debe ser reescrito como cualquiera f==(float)i, (double)f==i;o (double)f==(double)i;[ inta doublela promoción es sin pérdidas, por lo que los dos últimos equivaldría]. Parte del código que compara directamente floaty integerlos valores siempre se pueden tratar con números que son lo suficientemente pequeños que floaty doublelas comparaciones se comportarían de forma idéntica, pero un compilador generalmente no pueden saber que; el código debe dejar claro qué tipo de comparación se necesita, en lugar de esperar que las reglas del lenguaje coincidan con la intención del programador.

Es mejor nunca romper la compatibilidad con versiones anteriores.

Microsoft reemplazó el lenguaje de programación VB6 con un nuevo lenguaje que rompió totalmente la compatibilidad. Entonces, incluso hoy, el VB6 de 16 años es aún más popular que la versión dotNet (índice Tiobe de agosto de 2014). Y Gartner estima que todavía hay 14 mil millones de líneas de código VB6 en uso.

En 2014, Microsoft nuevamente tuvo que anunciar que no actualizará ni abrirá el código fuente VB6 a pesar de las demandas de la comunidad de programación de Visual Basic. Pero han ampliado el soporte de VB6 hasta 'al menos' 2024, y funciona bien en Windows 7 y 8. Eso será más de 26 años de soporte para la misma versión de VB6.

¿Por qué debería reescribirse el software de trabajo existente, incluso Microsoft nunca "actualizó" Office para usar dotNet?

Hay algunos problemas diferentes al romper la compatibilidad con versiones anteriores. Algunos de los problemas se derivan del hecho de que la mayoría de los lenguajes de programación también son plataformas (intérpretes / tiempos de ejecución), otros problemas se derivan de una suposición de la naturaleza humana.

R. El código escrito en versiones anteriores no obtendría el beneficio de nuevas versiones que mejoren el rendimiento, la seguridad o las características. Puede mitigar este problema al admitir múltiples versiones principales del compilador / intérprete, pero eso supone una gran pérdida de recursos (es decir, es costoso o lleva mucho tiempo, y es un fastidio).

B. El código escrito para las versiones más recientes puede no ser compatible con el código escrito en versiones anteriores. Podría solucionar este problema teniendo un intérprete / compilador que pueda manejar múltiples versiones principales del lenguaje, pero esto es más complicado que admitir intérpretes / compiladores separados (la solución para A).

C. Los cambios importantes, si ocurren con demasiada frecuencia / rapidez, también simplemente hacen que el idioma sea más difícil de usar, ya que tiene más que aprender y desaprender. Los cambios en un idioma pueden empujar a las personas al límite para cambiar a un nuevo idioma, o pueden hacer que las personas sigan usando versiones obsoletas del idioma y simplemente nunca cambien a la nueva versión (como ha sucedido con python). Por otra parte, los cambios también pueden atraer a nuevos usuarios y excitar a los antiguos.

D. Se necesita mantener y mantener nueva documentación. Siempre es una experiencia bastante confusa buscar cosas en Google y descubrir que estás leyendo los documentos para una versión diferente de la que estás usando actualmente.

En general, si crea un lenguaje de programación donde los módulos externos no tienen que preocuparse por la versión que está utilizando, romper la compatibilidad con versiones anteriores por las razones correctas (para solucionar fallas importantes en el lenguaje) es casi definitivamente lo correcto. . Es probable que la razón principal por la que esto no se hace es que los diseñadores de lenguaje de programación sobreestiman ( para contradecir la respuesta de otra persona ) los costos de romper la compatibilidad, especialmente desde el principio. El hecho es que los usuarios de ese idioma pueden solucionar o resolver los problemas de ruptura de la compatibilidad. Y esto no solo es válido para los lenguajes de programación; Esto se aplica a las API, interfaces de usuario, realmente cualquier interfaz en cualquier situación.

Facebook molesta muchísimo a las personas cuando cambia su interfaz de usuario o sus API de desarrollador. En el pasado, hacía que la plataforma fuera difícil de trabajar. En algunos casos, las API simplemente dejaron de funcionar de la nada. Pero la gente siguió usándolo, y ahora las API y las IU son mucho mejores que hace 5 años. La gente se quejará del cambio, ya sea bueno o malo para ellos, pero eso (quejarse) no es una buena razón para renunciar a ese cambio. Desafortunadamente, los desarrolladores de lenguaje de programación usan esto como una razón para mantener intactos los problemas de su lenguaje.

Por lo tanto, otro par de razones para que los idiomas no hagan cambios importantes para mejorar son:

E. Los desarrolladores de idiomas piensan que sus usuarios temen al cambio es una buena razón para estancar su idioma

F. A los desarrolladores de idiomas les gustó su lenguaje cuando lo hicieron, y probablemente piensan que está bien con sus defectos.

G. Los idiomas a medida que crecen suelen dejar de tener un pequeño conjunto básico de desarrolladores, y se convierten en bestias creadas por comités. Esto significa que las decisiones sobre esos idiomas son lentas y, a menudo, conservadoras y poco creativas.

H. La última razón es que algunos cambios importantes requieren una reevaluación significativa de las decisiones de diseño tomadas para el intérprete / tiempo de ejecución. A veces, las mejoras en el idioma simplemente requieren demasiado trabajo para ser factible. Supongo que este es un problema más raro que la mayoría.

A menudo, los diseñadores de idiomas no son necesariamente diseñadores de herramientas, por lo que no piensan en buenas soluciones para este problema o no las ejecutan bien. Aquí hay algunas soluciones que puedo pensar para resolver el problema de los cambios de última hora:

1. Desprecia las cosas mucho antes de que se eliminen.

2. Proporcione una buena herramienta de conversión estándar. Python proporcionó la herramienta 2to3, pero no estaba bien publicitada, no viene estándar con python 3, según recuerdo, y ni siquiera funcionó muy bien (recuerdo haber tenido que pasar manualmente por los programas generados por 2to3 para solucionar problemas) no solucionó) Esta herramienta de conversión podría incluso ejecutarse automáticamente si su compilador / intérprete detecta una versión anterior. ¿Qué podría ser más fácil?

No sé si eso es un problema para el código PHP, pero en muchos idiomas, el código heredado nunca se actualiza después de años o, a veces, incluso décadas, porque funciona, es crítico para el negocio que lo ejecuta y es demasiado grande (digamos millones de SLOC), por lo que no tendría sentido reescribirlo. Esa es una razón por la que Java convirtió la compatibilidad con versiones anteriores en un problema casi religioso, a pesar de conocer viejos problemas, especialmente en las bibliotecas (incluso si son más fáciles de actualizar). Supongo que mucho código del kernel de Linux no se actualizó durante décadas también, a pesar de la adopción de estándares como C99 y C11.

Incluso en idiomas que son menos "entreprisey", romper el código antiguo y funcional puede ser un problema. Eso es lo que sucedió con Python 2 -> 3. Un montón de bibliotecas y scripts del sistema eran estables y ya no se mantenían, no porque fueran abandonados sino porque eran estables y estaban haciendo su trabajo. Adaptarlos lleva unos años. Por lo tanto, como desarrollador, no necesariamente puede saltar a Python 3 si su biblioteca favorita aún no se ha movido, por lo que su propio código tampoco funcionará en Python 3, lo que dará como resultado la fragmentación de la comunidad.

El problema radica en el problema de compatibilidad con versiones anteriores. La mayoría de los scripts PHP que ejecuto se ejecutan en un servidor RedHat anterior. Si tuviera que usar la versión más nueva del lenguaje para futuros scripts, entonces tendría que actualizar PHP en este servidor y correr el riesgo de que mis scripts anteriores se rompan / tener que tomar horas para reescribir todo el código antiguo con el Nuevo estándar. Además, todos mis desarrolladores están acostumbrados a que PHP reaccione de cierta manera (ya sea que esté 'rota' o no). Si ya no reacciona de esa manera, podría ser un obstáculo importante para la productividad, ya que los desarrolladores pueden tener que volver a enseñar PHP.