Python 3.0 rompe la compatibilidad con versiones anteriores y divide el idioma en dos rutas (al menos temporalmente). ¿Conoce algún otro idioma que pasó por una fase de diseño tan importante en su madurez?Python 3.0 y la evolución del lenguaje
Además, ¿cree que así es como deberían evolucionar los lenguajes de programación o el precio a pagar es simplemente demasiado alto?
C# y el .NET Framework rompieron la compatibilidad entre las versiones 1.0 y 1.1, así como entre 1.1 y 2.0. Ejecutar aplicaciones en diferentes versiones requiere tener instaladas múltiples versiones del tiempo de ejecución .NET.
Al menos incluyeron un asistente de actualización para actualizar el código fuente de una versión a la siguiente (funcionó para la mayoría de nuestro código).
Perl 6 también está pasando por este tipo de división en este momento. Los programas Perl 5 no se ejecutarán directamente en Perl 6, pero habrá un traductor para traducir el código a un formulario que pueda funcionar (no creo que pueda manejar el 100% de los casos).
Perl 6 incluso tiene su propio artículo en Wikipedia.
Primero, aquí está un video talk sobre los cambios que Python llevará a cabo. En segundo lugar, los cambios no son buenos. Tercero, por mi parte, me complace la evolución y creo que es necesario.
El único lenguaje que se me ocurre para intentar un cambio a mitad de temporada sería Perl. Por supuesto, Python está superando a Perl en esa línea de llegada en particular lanzando primero. Sin embargo, debe tenerse en cuenta que los cambios de Perl son mucho más extensos que los de Python y probablemente será más difícil desenredarlos.
(Hay un precio para Perl de "Hay más de un camino para hacer esto" filosofía.)
Hay ejemplos como los cambios de una versión a de lenguajes basados en .NET (irónico, teniendo en cuenta el punto entero de .NET se suponía que era estabilidad API y compatibilidad multiplataforma). Sin embargo, difícilmente llamaría a esos idiomas "maduros"; siempre ha sido más un enfoque de diseño en movimiento, construir el avión a medida que volamos.
O, como tiendo a pensarlo, la mayoría de los idiomas provienen del "crecimiento orgánico" o de la "construcción diseñada". Perl es el ejemplo perfecto de crecimiento orgánico; comenzó como una herramienta de procesamiento de texto elegante ala awk/sed y se convirtió en un lenguaje completo.
Python, por otro lado, está mucho más diseñado. Pase un poco de tiempo deambulando por los extensos libros blancos en su sitio web para ver el extenso debate que se desarrolla en cada cambio, aunque sea menor, en la sintaxis y la implementación del idioma.
La idea de realizar este tipo de cambios de gran alcance es algo nuevo para los lenguajes de programación porque los propios lenguajes de programación han cambiado por naturaleza. Solía ser que las metodologías de programación cambiaban solo cuando salía un nuevo procesador que tenía un nuevo conjunto de instrucciones. Los primeros idiomas tendían a ser de tan bajo nivel y estar unidos al lenguaje ensamblador (por ejemplo, C) o tan completamente dinámico en naturaleza (Forth, Lisp) que dicho cambio a mitad de ciclo ni siquiera se consideraría como una consideración.
En cuanto a si los cambios son buenos o no, no estoy seguro. Tiendo a tener fe en las personas que guían el desarrollo de Python, sin embargo; los cambios en el lenguaje hasta ahora han sido en gran medida para mejor.
Creo que en los días venideros el Global Interpreter Lock resultará más central que los cambios de sintaxis. Aunque la nueva biblioteca multiprocesador podría aliviar la mayor parte de eso.
El equipo de python ha trabajado arduamente para que la falta de compatibilidad con versiones anteriores sea lo menos dolorosa posible, hasta el punto en que la versión 2.6 de python fue creada pensando en un proceso de actualización sin complicaciones. Una vez que haya actualizado a 2.6 hay scripts que puede ejecutar que lo moverán a 3.0 sin problema.
Donde "sin problema" debe calificarse con "siempre que el código no sea tan dinámico que el traductor 2to3 no pueda determinar si es necesario cambiarlo". –
En el mundo de Lisp ha sucedido algunas veces. por supuesto, el lenguaje es tan dinámico que, por lo general, la evolución simplemente está desaprobando parte de la biblioteca estándar y haciendo estándar otra parte.
también, Lua 4 a 5 fue bastante significativo; pero el núcleo del lenguaje es tan mínimo que incluso los cambios de gran alcance se documentan en un par de páginas.
Vale la pena mencionar que la compatibilidad con versiones anteriores genera costos propios. En algunos casos, es casi imposible desarrollar un idioma de la manera ideal si se requiere una compatibilidad hacia atrás del 100%. La implementación de Java de los genéricos (que borra la información del tipo en tiempo de compilación para ser compatible con versiones anteriores) es un buen ejemplo de cómo la implementación de funciones con una compatibilidad hacia atrás del 100% puede dar como resultado una característica de lenguaje no óptima.
Hablando en términos generales, se puede reducir a una elección entre una nueva característica implementada deficientemente que es compatible con versiones anteriores, o una nueva característica muy implementada que no lo es. En muchos casos, este último es una mejor opción, particularmente si hay herramientas que pueden traducir automáticamente código incompatible.
Creo que hay muchos ejemplos de roturas de compatibilidad con versiones anteriores. Muchos de los idiomas que hicieron esto fueron pequeños o se extinguieron en el camino.
Muchos ejemplos de esto implican el cambio de nombre del idioma.
Algol 60 y Algol 68 eran tan diferentes que las reuniones en Algol 68 se dividieron en facciones. La facción Algol 68, la facción Pascal y la facción PL/I.
Wirth's Pascal se transformó en Modula-3. Era muy similar a pascal - sintaxis y semántica muy similares - pero varias características nuevas. ¿Fue realmente un Pascal-2 sin compatibilidad retroactiva?
La cosa de Lisp to Scheme implicaba un cambio de nombre.
Si rastreas un escaneo del viejo manual B programming language, verás que la evolución a C parece un poco incremental, no radical, pero rompió la compatibilidad.
Fortran existe en muchas formas. No estoy seguro, pero creo que Digital's Fortran 90 para VAX/VMS no era completamente compatible con los antiguos programas Fortran IV.
RPG pasó por grandes trastornos: creo que realmente hay dos idiomas incompatibles llamados RPG.
línea de base creo que pensando y aprendiendo son inevitables. Tienes tres respuestas para aprender las limitaciones de un idioma.
Inventa un nuevo lenguaje totalmente incompatible.
Incrementa chagne hasta que te fuercen a inventar un nuevo idioma.
Rompe la compatibilidad de forma controlada y cuidadosa.
Creo que el # 1 y el # 2 son ambos una salida cobarde. Arrancar lo viejo es más fácil que tratar de preservarlo. Preservar cada característica matizada (no importa cuán mala) es mucho trabajo, algunas de ellas de poco o ningún valor.
Las empresas comerciales optan por enfoques cobardes en nombre de la "nueva comercialización" o "preservación de nuestros clientes existentes". Es por eso que las empresas de software comercial no son un hervidero de innovación.
Creo que solo los proyectos de código abierto pueden incorporar la innovación en la forma en que la comunidad de Python está abordando este cambio.
El precio de insistir en la compatibilidad casi absoluta es demasiado alto. Pase dos minutos programando en C++ si quiere ver por qué.
¿No sería VB6 a VB.net el mayor ejemplo de esto? ¿O todos los consideran dos idiomas diferentes?
Creo que el cambio del tiempo de vida del objeto determinístico (COM) a la recolección de basura hizo que la migración de cualquier aplicación de VB no trivial fuera una tarea enorme. Los proyectos de IMO, VB6 se convirtieron en obsoletos sin una ruta de actualización. – mackenir
Aunque técnicamente VB.NET puede considerarse separado de VB6 en términos de evolución de lenguajes de programación y de empresa, no lo es. Microsoft eligió obsolar millones de aplicaciones a la vez. Teniendo en cuenta que VB6 era una de las plataformas más exitosas, esta fue una decisión arriesgada. – kgiannakakis
Muchos consideran que son dos idiomas diferentes. Muchos programadores VB6 enojados llamaron a VB.NET Visual Fred ya que era muy diferente. – projecktzero
gcc regularmente cambia la forma en que maneja C++ casi cada versión menor. Por supuesto, esto es más una consecuencia de que gcc apriete cómo siguen las reglas, y menos de que C++ cambie.
La nueva versión del lenguaje de programación Ruby también romperá la compatibilidad.
Y piense en las bibliotecas que se podrían usar: gtk, Qt, etc. (también tienen versiones incompatibles).
Creo que la incompatibilidad es necesaria algunas veces (pero no demasiado a menudo) para apoyar el progreso.
Python 3000 proporciona herramientas de migración y 2.6 tendrá algunas configuraciones de compatibilidad con versiones anteriores. –