¿Existe algún mecanismo para hacer que el lenguaje de programación sea más estable (compatible) para los cambios?

14

Hay un gran número de lenguajes de programación. Algunos de ellos crecen y se vuelven muy populares. La gente usa tales lenguajes cada vez más a menudo. El fundador de dicho lenguaje (u organización / comunidad fundadora) puede intentar implementar cambios para mejorar el lenguaje. Pero a veces es difícil hacer algunos cambios debido a la compatibilidad con versiones anteriores y cosas tan feas ya han existido en el idioma durante años y son utilizadas por muchos usuarios.

¿Hay algunos principios o pasos arquitectónicos, durante la fase de diseño del lenguaje, que puedan ayudar a hacerlo más estable para que los diseñadores del lenguaje no tengan tanto miedo de romper la compatibilidad con versiones anteriores?

    
pregunta Viacheslav Kondratiuk 10.11.2014 - 20:26

3 respuestas

6

La estabilidad del lenguaje no es una decisión técnica. Es un contrato entre el autor del idioma y los usuarios.

El autor anuncia una versión dada como más o menos estable. Cuanto menos estable es un idioma, más cambios puede hacer el autor. Cada usuario interesado en el idioma puede decidir si quiere invertir tiempo en él para aprender nuevas funciones o desarrollar aplicaciones que podrían romperse en la actualización del próximo mes.

El uso de un lenguaje inestable puede ser interesante porque está interesado en un nuevo concepto, o quiere ayudar con sus comentarios. Si usted es un negocio, tal vez prefiera esperar a que la tecnología sea más estable antes de invertir su tiempo en ella. Le interesan más las cosas como el tiempo de comercialización y la experiencia del usuario.

Así que esta es una comunicación & problema de confianza. Mira el desarrollo del lenguaje de herrumbre. Son muy claros sobre lo que están cambiando y lo que están manteniendo. Cuando quieren demorar una decisión sobre una característica determinada, usan lo que llaman una puerta de función. Por otro lado, el equipo angular enfrentó mucha ira por su anuncio de 2.0 porque los cambios fueron más grandes de lo esperado.

Incluso los autores de bibliotecas tienen que comunicar sobre la estabilidad de sus apis. Casi cualquier tecnología utilizada por otras personas tiene que lograr un equilibrio entre estabilidad y perfección. Un fabricante de automóviles no puede cambiar la posición de los pedales, y un diseñador de computadoras portátiles no inventará un nuevo diseño de teclado por la misma razón: no está ayudando a sus usuarios si no puede tomar una decisión sobre la forma en que usarán su producto.

    
respondido por el Simon 10.11.2014 - 21:01
5
  • Tenga en cuenta que los idiomas cambian a lo largo de su vida, independientemente de lo bien que se diseñen por adelantado. En lugar de intentar enviar de inmediato el lenguaje más asombroso del mundo, primero intente ser útil y extensible. Un lenguaje mediocre que realmente puedo usar vale más que cualquier maravilloso lenguaje de programación que solo existe en teoría.
  • Considere las facilidades para hacer que la sintaxis sea extensible, por ejemplo. macros Las macros no son automáticamente algo bueno y pueden ser demasiado poderosas. Algunos idiomas tienen una sintaxis muy flexible desde el principio, lo que reduce la necesidad de macros. Un par de escenarios a considerar:

    • ¿Puedo introducir un nuevo operador como |> sin dejar el idioma? ¿Puedo elegir la prioridad y la asociatividad para este operador?
    • ¿Cuánta ceremonia debo realizar para una función en línea / lambda / cierre?
    • ¿Puedo usar la sintaxis de lenguaje existente para implementar una sintaxis de bucle foreach? P.ej. Ruby y Scala pueden hacer esto a través de su sintaxis de llamada de método flexible con lambdas.
  • Considere las instalaciones para mantener la semántica extensible. Las necesidades comunes son:

    • Sobrecarga del operador, donde los tipos definidos por el usuario pueden asignar su propio significado a los operadores existentes. Esto hace que un lenguaje sea mucho más agradable en aplicaciones pesadas en matemáticas.
    • Sobrecarga literal. ¿Puedo hacer que los literales de cadena sean de mi propio tipo de cadena? ¿Puedo hacer que todos los literales numéricos en el alcance actual sean bignums?
    • Protocolos de metobjetos. Si el lenguaje no tiene rasgos, ¿puedo implementarlos dentro del sistema de objetos actual? ¿Puedo implementar un orden de resolución de método diferente? ¿Puedo cambiar la forma en que se almacenan los objetos o cómo se envían los métodos?
  • Tener pruebas de regresión. Mucha prueba. No solo escrito por los diseñadores de idiomas, sino también por los usuarios. Al agregar una característica rompe estas pruebas, sopese cuidadosamente los beneficios de esa característica frente al beneficio de la compatibilidad con versiones anteriores.
  • Versión de su idioma. No solo en su documentación, sino también en el propio código fuente. Una vez que lo haga, la única parte de su idioma que no puede cambiar es la sintaxis de esta versión de pragma. Ejemplos: Raqueta le permite especificar un dialecto. Perl le permite use v5.20 , lo que habilita todas las funciones incompatibles con versiones anteriores de Perl v5.20. También puede cargar entidades individuales explícitamente como use feature 'state' . Similar: from __future__ import division de Python.
  • Considere diseñar su idioma de una manera que resulte en pocas palabras reservadas. Solo porque class introduce una clase no implica que no pueda tener una variable local llamada class . En la práctica, esto resulta en palabras clave que introducen declaraciones de variables o métodos, en contra de la tradición similar a la de C de usar nombres de tipo para introducir declaraciones. Otra alternativa es usar sigilos para su $variables , como en Perl y PHP.

Las partes de esta respuesta están influenciadas por el discurso de Guy Steele "Growing a Language" (1998) ( pdf ) ( youtube ).

    
respondido por el amon 10.11.2014 - 21:40
1

Creo que un paso muy importante es promover un administrador de paquetes que también pueda administrar la versión del lenguaje en sí.

Por ejemplo, uso SBT para Scala o Leiningen para Clojure. Ambos me permiten declarar qué versión del idioma quiero usar, por proyecto . Por lo tanto, es bastante fácil iniciar proyectos ecológicos en la última versión del lenguaje, al tiempo que actualiza los proyectos existentes a un ritmo más cómodo, si es que lo hace.

Por supuesto, dependiendo del idioma, esto puede dejarle con la necesidad de esperar a que las bibliotecas relevantes se transfieran a la versión que necesita (esto sucede, por ejemplo, en Scala), pero sin embargo facilita las cosas.

    
respondido por el Andrea 11.11.2014 - 11:29

Lea otras preguntas en las etiquetas