La respuesta corta es retrocompatibilidad. Sabemos que en una empresa como Microsoft a veces es imposible deshacerse de algo, y esto es porque una de las mejores partes de Windows a veces es también su lastre: el hecho de que el sistema siga dando soporte a software y dispositivos tan antiguos como los de la era de MS-DOS o Windows 3.1, incluso hoy en día.
#18 Python2 ya no está soportado, lo que significa que no tardará mucho en desaparecer por completo de las distros (le doy menos de 2 años desde hoy, y estoy siendo generoso), con lo que el soporte para código escrito en esa variante de Python desaparecerá, a no ser que el usuario de turno esté dispuesto a compilarlo y arriesgarse a introducir agujeros de seguridad no parcheados en su sistema.
Por otro lado, he comentado explícitamente que el problema de Python va mucho, pero que mucho más allá de lo que sucedió con esa transición (que ha durado, ojo, más de 10 años). En cada nueva versión se introducen paulatinamente "breaking changes", primero se marcan métodos, clases y otras historias como "obsoletas", y pocas versiones más adelante se eliminan por completo.
Ahora, si quieres usar software antiguo que depende de esas historias... debes usar una versión antigua de Python, pero como resulta que no han cambiado el "major version number"... tadá, incompatibilidad con lo que sea que tengas instalado. Así que te tienes que compilar tu esa versión antigua, a manija, y mantenerla aislada de todo lo demás... y lo mejor, es muy fácil romper ese aislamiento por accidente.
No hablemos ya de cómo funcionan sus múltiples sistemas de gestión de paquetes y dependencias, las incompatibilidades sutiles entre ellos, su incapacidad para generar "virtual envs" relocalizables dentro del sistema de ficheros, etc.
Hasta PHP lo hace mejor que Python en ese aspecto.
¿pero qué necesidad tenéis de ponerle justo ese nombre a un fichero? ¿no tenéis otro?
Respetad a los mayores. Si os hubiéramos dejado, llamaríais aux a la mitad de vuestros ficheros, igual que hacéis con la mitad de las variables de vuestros programas. Y PRN seria vuestra carpeta alijo. No sigo que se me dispara el sintrón.
#2 Riete, pero el otro día me pilló por sorpresa tener que guardar unos ficheros de configuración de una máquina que no había tenido que modificar en mi vida y al final no me quedó más remedio que hacer semejante guarrería. A partir de ahora cuando me toque hacer algo así, sabiendo de antemano que igual me toca guardar varios nombres de configuración distintos voy a tener que pensar un "protocolo" de nombres.
No hay retrocompatibilidad en windows.
Cualquiera que haya intentado pasar programas que funcionaban en ms-dos o windows 3.11 a los nuevos sistemas lo sabe.
#7 No existe de forma automática, pero se pueden ejecutar programas en modo compatibilidad. No es perfecto, pero ofrece más compatibilidad que la que mucha gente imagina.
#9 Windows no es el único sistema operativo que rompe la retrocompatibilidad. Mac OS X lo ha hecho bastantes veces, y en el caso de Linux, aunque a nivel de syscalls se han comportado más o menos bien, a nivel de bibliotecas de código la cosa cambia bastante (como con la(s) libc).
#13 nope. En línux funciona bien lo de hace 20 años. Las bibliotecas están versionadas por diseño. Si creas una biblioteca, la creas con una versión y puedes tener distintas versiones en la misma máquina sin conflictos.
¿ Conoces algún programa antiguo que no funcione ? Porque lo pruebo en un minuto.
#15 Buena suerte si intentas instalar/usar a la vez (y sin excesivas complicaciones) software que dependa de distintas versiones de (por ejemplo) Qt, digamos app1 -> Qt1, app2 -> Qt2, app3 -> Qt3, app4 -> Qt4 y app5 -> Qt5. Es probable que con GTK la cosa sea incluso peor.
Y en este caso hablo de libs muy conocidas, probablemente sea "sencillo" encontrar las versiones que necesitamos y compilarlas. Pero la cosa se complica cuando hablamos de dependencias menos populares... aquí un podcast comentando el asunto:
El equipo de desarrollo del kernel hace un buen trabajo, las capas que hay por encima... todo lo contrario.
#15 Extiendo el comentario hecho en #16, porque lo he dejado en plan "reto", y he profundizado poco en el problema.
Por motivos X he dedicado algún tiempo a lidiar con el asunto del empaquetado, distribución, compatibilidad cruzada y compatibilidad hacia atrás de ciertos componentes de software... y es jodido, muy jodido. Casi todo el mundo lo hace mal, y aunque el núcleo provea mecanismos para mantener la retrocompatibilidad... por lo general no se aprovechan. O son anulados por las malas prácticas de terceros.
Un ejemplo paradigmático de cómo hacer las cosas mal en todos esos frentes a la vez es Python (y no me refiero solo a la transición de Python 2 a Python 3).
#16 entiendo lo que dices, pero me falta un ejemplo concreto de una aplicación que no se pueda ejecutar.
El "se dice que" en estas cosas ya sabes que no vale mucho porque el nivel de exigencia del usuario de línux es mucho mayor que el de cualquier otro sistema operativo.
Lo de python estéticamente no me gusta. Tengo python 2 y python 3 en el ordenador, a efectos es como si fueran aplicaciones distintas, así lo han diseñado los desarrolladores y los de la distribución. Es feo pero funciona. No se les puede acusar de falta de retrocompatibilidad.
Comentarios
#18 Python2 ya no está soportado, lo que significa que no tardará mucho en desaparecer por completo de las distros (le doy menos de 2 años desde hoy, y estoy siendo generoso), con lo que el soporte para código escrito en esa variante de Python desaparecerá, a no ser que el usuario de turno esté dispuesto a compilarlo y arriesgarse a introducir agujeros de seguridad no parcheados en su sistema.
Por otro lado, he comentado explícitamente que el problema de Python va mucho, pero que mucho más allá de lo que sucedió con esa transición (que ha durado, ojo, más de 10 años). En cada nueva versión se introducen paulatinamente "breaking changes", primero se marcan métodos, clases y otras historias como "obsoletas", y pocas versiones más adelante se eliminan por completo.
Ahora, si quieres usar software antiguo que depende de esas historias... debes usar una versión antigua de Python, pero como resulta que no han cambiado el "major version number"... tadá, incompatibilidad con lo que sea que tengas instalado. Así que te tienes que compilar tu esa versión antigua, a manija, y mantenerla aislada de todo lo demás... y lo mejor, es muy fácil romper ese aislamiento por accidente.
No hablemos ya de cómo funcionan sus múltiples sistemas de gestión de paquetes y dependencias, las incompatibilidades sutiles entre ellos, su incapacidad para generar "virtual envs" relocalizables dentro del sistema de ficheros, etc.
Hasta PHP lo hace mejor que Python en ese aspecto.
#19 los lenguajes de programación tienen cosas de esas.
Tanto python como php son multiplataforma.
¿pero qué necesidad tenéis de ponerle justo ese nombre a un fichero? ¿no tenéis otro?
Respetad a los mayores. Si os hubiéramos dejado, llamaríais aux a la mitad de vuestros ficheros, igual que hacéis con la mitad de las variables de vuestros programas. Y PRN seria vuestra carpeta alijo. No sigo que se me dispara el sintrón.
#1 Los nombres actuales ya son buenos.
inventario.xls
inventario_01.xls
inventario_este_es_el_bueno.xls
inventario_este_es_el_bueno02_actualizado.xls
#2 Riete, pero el otro día me pilló por sorpresa tener que guardar unos ficheros de configuración de una máquina que no había tenido que modificar en mi vida y al final no me quedó más remedio que hacer semejante guarrería. A partir de ahora cuando me toque hacer algo así, sabiendo de antemano que igual me toca guardar varios nombres de configuración distintos voy a tener que pensar un "protocolo" de nombres.
#2 En mi casa tenemos:
Nueva Carpeta
Nueva Carpeta Nueva
Nueva Carpeta más nueva
Nueva Nueva Carpeta más nueva
Lo que jode es tener que copiar archivos de usuarios con una ruta de más de 256 caracteres, que windows no deja. (Para eso uso Fast Copy )
Yo creo que más que por compatibilidad es por miedo a joder algo y luego no ser capaz de arreglarlo.
No hay retrocompatibilidad en windows.
Cualquiera que haya intentado pasar programas que funcionaban en ms-dos o windows 3.11 a los nuevos sistemas lo sabe.
#7 No existe de forma automática, pero se pueden ejecutar programas en modo compatibilidad. No es perfecto, pero ofrece más compatibilidad que la que mucha gente imagina.
#8 y por eso cualquiera que trabaje con varios sistemas operativos pone como ejemplo de no cumplir la retrocompatibilidad al windows.
#9 Windows no es el único sistema operativo que rompe la retrocompatibilidad. Mac OS X lo ha hecho bastantes veces, y en el caso de Linux, aunque a nivel de syscalls se han comportado más o menos bien, a nivel de bibliotecas de código la cosa cambia bastante (como con la(s) libc).
#13 nope. En línux funciona bien lo de hace 20 años. Las bibliotecas están versionadas por diseño. Si creas una biblioteca, la creas con una versión y puedes tener distintas versiones en la misma máquina sin conflictos.
¿ Conoces algún programa antiguo que no funcione ? Porque lo pruebo en un minuto.
#15 Buena suerte si intentas instalar/usar a la vez (y sin excesivas complicaciones) software que dependa de distintas versiones de (por ejemplo) Qt, digamos app1 -> Qt1, app2 -> Qt2, app3 -> Qt3, app4 -> Qt4 y app5 -> Qt5. Es probable que con GTK la cosa sea incluso peor.
Y en este caso hablo de libs muy conocidas, probablemente sea "sencillo" encontrar las versiones que necesitamos y compilarlas. Pero la cosa se complica cuando hablamos de dependencias menos populares... aquí un podcast comentando el asunto:
El equipo de desarrollo del kernel hace un buen trabajo, las capas que hay por encima... todo lo contrario.
#15 Extiendo el comentario hecho en #16, porque lo he dejado en plan "reto", y he profundizado poco en el problema.
Por motivos X he dedicado algún tiempo a lidiar con el asunto del empaquetado, distribución, compatibilidad cruzada y compatibilidad hacia atrás de ciertos componentes de software... y es jodido, muy jodido. Casi todo el mundo lo hace mal, y aunque el núcleo provea mecanismos para mantener la retrocompatibilidad... por lo general no se aprovechan. O son anulados por las malas prácticas de terceros.
Un ejemplo paradigmático de cómo hacer las cosas mal en todos esos frentes a la vez es Python (y no me refiero solo a la transición de Python 2 a Python 3).
#16 entiendo lo que dices, pero me falta un ejemplo concreto de una aplicación que no se pueda ejecutar.
El "se dice que" en estas cosas ya sabes que no vale mucho porque el nivel de exigencia del usuario de línux es mucho mayor que el de cualquier otro sistema operativo.
Lo de python estéticamente no me gusta. Tengo python 2 y python 3 en el ordenador, a efectos es como si fueran aplicaciones distintas, así lo han diseñado los desarrolladores y los de la distribución. Es feo pero funciona. No se les puede acusar de falta de retrocompatibilidad.
#8 un programa de MS-DOS o Win 3.11 no funciona en ningún Windows desde XP. El último en tener soporte para 16 bits fue Millenium.
#10 #11 estos dos comentarios parecen contradictorios.
#12 parecen, pero no.
Es un precio pequeño por la retrocompatibilidad.
Una de las mayores cagadas de diseño de Windows, la retrocompatibilidad obsesiva que acaba creando más problemas de los que soluciona.