¿Por qué se siguen revisando los lenguajes de programación antiguos?

46

Esta pregunta no es, "¿Por qué la gente todavía usa lenguajes de programación antiguos?" Lo entiendo bastante bien. De hecho, los dos lenguajes de programación que mejor conozco son C y Scheme, ambos de los cuales se remontan a los años 70.

Recientemente estuve leyendo sobre los cambios en C99 y C11 versus C89 (que parece ser la versión más usada de C en la práctica y la versión que aprendí de K & R). Mirando alrededor, parece que cada lenguaje de programación en uso intensivo obtiene una nueva especificación al menos una vez por década. Incluso Fortran sigue recibiendo nuevas revisiones, a pesar del hecho de que la mayoría de las personas que lo usan siguen usando FORTRAN 77.

Contraste esto con el enfoque de, digamos, el sistema de composición tipográfica TeX. En 1989, con el lanzamiento de TeX 3.0, Donald Knuth declaró que TeX estaba completo y que las futuras versiones contendrían solo correcciones de errores. Incluso más allá de esto, ha declarado que, tras su muerte, "todos los errores restantes se convertirán en características" y no se realizarán más actualizaciones. Otros son libres de bifurcar TeX y lo han hecho, pero los sistemas resultantes se renombran para indicar que son diferentes del TeX oficial. Esto no se debe a que Knuth piense que TeX es perfecto, sino porque entiende el valor de un sistema estable y predecible que hará lo mismo en cincuenta años que hace ahora.

¿Por qué la mayoría de los diseñadores de lenguajes de programación no siguen el mismo principio? Por supuesto, cuando un lenguaje es relativamente nuevo, tiene sentido que pasará por un período de rápido cambio antes de establecerse. Y nadie puede realmente objetar los cambios menores que no hacen mucho más que codificar los pseudo estándares existentes o corregir lecturas no deseadas. Pero cuando un idioma parece necesitar una mejora después de diez o veinte años, ¿por qué no simplemente bifurcarlo o volver a empezar, en lugar de intentar cambiar lo que ya está en uso? Si algunas personas realmente quieren hacer programación orientada a objetos en Fortran, ¿por qué no crear el "Objetivo Fortran" para ese propósito y dejar a Fortran solo?

Supongo que se podría decir que, independientemente de las revisiones futuras, C89 ya es un estándar y nada impide que las personas continúen usándolo. Esto es cierto, pero las connotaciones tienen consecuencias. GCC, en modo pedante, advertirá sobre la sintaxis que está obsoleta o tiene un significado sutilmente diferente en C99, lo que significa que los programadores de C89 no pueden ignorar totalmente el nuevo estándar. Por lo tanto, debe haber algún beneficio en C99 que sea suficiente para imponer esta sobrecarga a todos los que usan el lenguaje.

Esta es una pregunta real, no una invitación a discutir. Obviamente tengo una opinión sobre esto, pero en este momento solo estoy tratando de entender por qué esto no es solo cómo se hacen las cosas. Supongo que la pregunta es:

  

¿Cuáles son las ventajas (reales o percibidas) de actualizar un estándar de idioma, en lugar de crear un nuevo idioma basado en el antiguo?

    
pregunta Ian 01.11.2012 - 18:24

5 respuestas

14

Creo que la motivación de los diseñadores de idiomas para revisar los idiomas existentes es introducir la innovación al tiempo que garantiza que su comunidad de desarrolladores objetivo permanezca unida y adopte el nuevo idioma: mover una comunidad existente a una nueva revisión de un idioma existente es más efectivo que crear Una nueva comunidad en torno a un nuevo idioma. Por supuesto, esto obliga a algunos desarrolladores a adoptar el nuevo estándar, incluso si estaban de acuerdo con el anterior: en una comunidad a veces hay que imponer ciertas decisiones a una minoría si desea mantener unida a la comunidad.

Además, tenga en cuenta que un lenguaje de propósito general trata de servir a la mayor cantidad posible de programadores y, a menudo, se aplica en áreas nuevas para las que no fue diseñado. Entonces, en lugar de apuntar a la simplicidad y estabilidad del diseño, la comunidad puede elegir incorporar nuevas ideas (incluso de otros idiomas) a medida que el lenguaje se traslada a nuevas áreas de aplicación. En tal escenario, no puede esperar hacerlo bien en el primer intento.

Esto significa que los idiomas pueden sufrir cambios profundos a lo largo de los años y la última revisión puede parecer muy diferente de la primera. El nombre del idioma no se conserva por razones técnicas, sino porque la comunidad de desarrolladores acepta usar un nombre antiguo para un idioma nuevo. De modo que el nombre del lenguaje de programación identifica la comunidad de sus usuarios en lugar del lenguaje en sí.

OMI, la motivación por la que muchos desarrolladores encuentran esto aceptable (o incluso deseable) es que una transición gradual a un lenguaje ligeramente diferente es más fácil y menos confusa que un salto a un lenguaje completamente nuevo que les tomaría más tiempo y esfuerzo para dominar . Tenga en cuenta que hay varios desarrolladores que tienen uno o dos idiomas favoritos y no están muy interesados en aprender nuevos idiomas (radicalmente diferentes). E incluso para aquellos a los que les gusta aprender cosas nuevas, aprender un nuevo lenguaje de programación siempre es una actividad difícil y que requiere mucho tiempo.

Además, puede ser preferible ser parte de una comunidad grande y un ecosistema rico que de una comunidad muy pequeña que usa un idioma menos conocido. Entonces, cuando la comunidad decide seguir adelante, muchos miembros deciden seguir para evitar el aislamiento.

Como comentario adicional, creo que el argumento de permitir la evolución y mantener la compatibilidad con el código heredado es bastante débil: Java puede llamar código C, Scala puede integrarse fácilmente con código Java, C # puede integrarse con C ++. Hay muchos ejemplos que muestran que puede interactuar fácilmente con el código heredado escrito en otro idioma sin necesidad de compatibilidad con el código fuente.

NOTA

Por algunas respuestas y comentarios, parece entender que algunos lectores han interpretado la pregunta como "¿Por qué los lenguajes de programación deben evolucionar?"

Creo que este no es el punto principal de la pregunta, ya que es obvio que los lenguajes de programación deben evolucionar y por qué (nuevos requisitos, nuevas ideas). La pregunta es más bien "¿Por qué esta evolución tiene que suceder dentro de un lenguaje de programación en lugar de generar muchos nuevos lenguajes?"

    
respondido por el Giorgio 09.11.2012 - 19:27
22

Compatibilidad con versiones anteriores es tu respuesta. Un lenguaje dado, particularmente uno ampliamente utilizado como C puede tener un código que está en funcionamiento, sin alteraciones, durante décadas. Si es necesario realizar un mantenimiento, es útil tener compiladores que puedan seguir dirigiéndose a ese tipo de plataforma mientras se ejecutan en sistemas modernos para el trabajo de desarrollo. Las estandarizaciones y las actualizaciones de la versión del idioma ayudan a mantener las prácticas de programación actualizadas, a la vez que proporcionan una sensación de familiaridad para los programadores veteranos que pueden resistirse a aprender un lenguaje "nuevo" completo.

Tenga en cuenta que muchos de los idiomas actualizados se actualizan tanto menos como "se han activado nuevos bits brillantes". Las bestias de antaño a menudo todavía se esconden dentro.

En lo que respecta a Knuth, recuerde que él es un académico y que TeX solo ha demostrado ser correcto, no actualizado.

    
respondido por el World Engineer 01.11.2012 - 18:28
5

Creo que la respuesta obvia es que todavía se está progresando en el diseño del lenguaje y en la arquitectura del sistema, y hay suficientes personas que se preocupan por los idiomas más antiguos que quieren aprovechar las nuevas técnicas (varios núcleos, mejores hilos o modelos de memoria) que Se atornillan o se fijan en el estándar de idioma. También ayuda tener "una forma verdadera" de hacer las cosas (por ejemplo, análisis de XML, acceso a bases de datos) con las que puede contar para estar allí sin importar en qué compilador o plataforma se encuentre, en lugar de depender de algún tercero. biblioteca que puede o no estar instalada (y puede o no ser la versión que necesita, etc.)

    
respondido por el TMN 01.11.2012 - 20:50
1

Los conceptos o metas fundamentales sobre los que se construye un lenguaje de propósito general no pierden relevancia; sin embargo, los cambios menores en el entorno de trabajo o el hardware exigen que se agreguen actualizaciones o pequeñas funciones a un idioma.

La forma en que se expresan los algoritmos en un idioma no cambiará, aunque puede necesitar un soporte más limpio para los tipos de 64 bits, un soporte de expresiones regulares más estándar o un soporte más sólido para los nuevos tipos de sistemas de archivos.

Hay algunos casos en los que se están agregando características 'nuevas' a los idiomas existentes, pero en muchos casos esos cambios equivalen a simplificaciones de cosas que las personas ya estaban haciendo por las malas. (Consulte C ++ con funciones de orden superior en lugar de punteros y functores de función).

    
respondido por el Ben 01.11.2012 - 20:53
-2

Esto es un poco como una consideración del lenguaje hablado.

En el pasado, donde las palabras no se usaban con la frecuencia que tienen ahora (o se usan para un significado diferente).

por ejemplo. agradable: en inglés (muy antiguo) tiene el significado casi inverso al que usamos hoy, especialmente cuando se usa para describir el carácter de alguien.

Malo: no hace mucho mal, solo tenía un único significado, ¡ahora puede significar algo que es "súper asombroso" (se usa de una manera fesica (probablemente me he perdido la palabra Fesicous)!

otro nuevo desarrollo es el teléfono móvil 'Texto hablado' para idiomas escritos.

Personalmente no veo por qué un lenguaje de programación no se va a desarrollar de manera similar, las palabras y las funciones tienen significados / acciones específicas, y se requiere que cambie para incorporar nuevas ideas, nuevas metodologías.

Conozco personas que hablan muchos idiomas diferentes, y a menudo sugieren que después del 3 o 4 es más fácil aprender uno nuevo.

No sé si hay programadores que tienen una experiencia similar, no me sorprendería si lo hubiera.

Sé que me siento feliz programando en JAVA (por mucho que me sienta feliz hablando en inglés) Esto no significa que no pueda comunicarme en 'inglés americano' o 'inglés australiano' aunque hay algunos 'errores' para cuidado con Al igual que al pasar de Java a PHP a Perl, las construcciones son similares, pero hay pequeñas trampas para atraparme y hacerme golpear mi cabeza contra la pared.

Esto es diferente a pasar de inglés a francés o de Java a SAS. estos son tan diferentes que toma bastante tiempo llegar a dominarlos.

De todos modos, esa es mi opinión sobre esto.

    
respondido por el DaveM 30.11.2012 - 17:02

Lea otras preguntas en las etiquetas