La tragedia de Common Lisp: por qué los idiomas populares crecen en complejidad

Adaptado de la discusión en 2015 . Aquí, Common Lisp es solo uno de los muchos buenos ejemplos.


El futuro de JavaScript?

He estado trabajando en el Comité de Estándares de JavaScript (TC39) desde 2007. Apreciamos la simplicidad del lenguaje, pero con el tiempo hemos perdido la vigilancia. La complejidad comenzó a crecer sin control. Deberíamos averiguar por qué sucede esto naturalmente, cuál es el precio y qué hacer al respecto. Este artículo está dirigido no solo a colegas de TC39, sino también a todos los que quieran influir en la ruta de desarrollo de JavaScript o cualquier estándar que haya enfrentado una presión similar. ¡Aprende de nuestros errores!

Algol, Smalltalk, Pascal y Scheme temprano fueron amados como lenguas pequeñas y hermosas. Los principios de C y JavaScript fueron criticados con razón por mucho y rara vez se los llamó hermosos. Pero también eran pequeños, y fue muy apreciado. Cuando el lenguaje es pequeño, nuestra evaluación a menudo está determinada por el sentimiento: "Puedo aprender todo y dominarlo" , y luego: "Sé todo. Me gusta que no queden detalles desconocidos " . Pero en el caso de C y JavaScript, es poco probable que alguien tenga una sensación de dominio completo del lenguaje, ya que los detalles son en realidad diabólicamente complejos. Sin embargo, la sensación de un "lenguaje pequeño" en muchos sentidos determinó la satisfacción del uso diario.

La estética del minimalismo de JavaScript se ha conservado en el estándar EcmaScript-5. Participé activamente en el desarrollo de EcmaScript-5 y EcmaScript-2015, y en ambos casos estoy orgulloso de mi contribución. EcmaScript-2015 ha crecido significativamente en tamaño, pero ha traído mejoras con él. Dado dónde comenzamos, era imposible mejorar JavaScript sin tal aumento de tamaño. No me arrepiento de la mayoría de los complementos que llevaron a inflar EcmaScript-5 a EcmaScript-2015. Si regresa, probablemente en muchos casos sugeriría adiciones similares.

Cada una de las adiciones tuvo que superar una barra muy alta. Psicológicamente, esto tenía sentido, porque observamos el minimalismo EcmaScript-5. Cuando el idioma es pequeño, cada función adicional se siente intuitivamente como un aumento porcentual significativo en el tamaño del idioma. Los beneficios específicos de una característica siempre son visibles para sus proponentes. Para un idioma pequeño, la contribución de la nueva característica al aumento total también es visible para todos.

Tan pronto como un lenguaje va más allá de una cierta complejidad, por ejemplo, LaTeX, Common Lisp, C ++, PL / 1, Java moderna, la programación se vuelve más como cortar un subconjunto de funciones para uso personal de un mar infinito de funciones, la mayoría de las cuales nunca dominaremos y reconciliaremos con eso Una vez que el lenguaje se percibe como "infinito", los beneficios específicos de la nueva característica aún se entienden. Pero los costos generales asociados con la complejidad adicional ya no son obvios. Ya no los sienten quienes discuten una nueva característica.

$$ .

Incluso $$ .

Esta es la muerte de mil cortes, lo que hace que estos monstruos crezcan sin restricciones.

Por lo tanto, les pido a todos los que influyen en el lenguaje que consideren un estándar más alto al considerar una nueva función que "es bueno tener esa oportunidad, ¿no es así?" Creo que EcmaScript-2015 se encuentra en el territorio fronterizo donde aún se puede prevenir el crecimiento desenfrenado, pero solo si comenzamos a restringirnos mutuamente con altos estándares para cualquier nueva característica propuesta. Como comunidad, necesitamos una sensación de pánico más general sobre el tamaño que ya alcanzó EcmaScript 2015. Idealmente, con el crecimiento de la lengua, cuando el tamaño se acerca al punto de no retorno, el pánico debería aumentar, no disminuir.

Algunas diferencias

Mantenga una presión mínima desigual

La relevancia del minimalismo disminuye a medida que pasamos de un lenguaje base a las bibliotecas. El lenguaje estándar en su conjunto se puede representar como la siguiente estructura:

• Sintaxis fundamental : formas especiales que no pueden expresarse con precisión por extensión local a otra sintaxis.
  
• Estado semántico : un estado que es manipulado por la computación.
  
• Kernel builtins: una parte de la biblioteca integrada que proporciona una funcionalidad que el código personalizado no puede proporcionar por sí solo.
  
• Intrínsecos no del núcleo: bibliotecas integradas que se pueden implementar en JavaScript, pero el estado semántico o los módulos integrados en el núcleo dependen de ellos. Por ejemplo, a través de un proxy, puede implementar una matriz en el código de usuario. Pero otros módulos integrados en el núcleo ya dependen de Array, lo que le da a esta matriz en particular una posición privilegiada sobre cualquier reemplazo propuesto.
  
• Azúcar sintáctico : sintaxis que se puede expresar por extensión local a la sintaxis fundamental.
  
• Bibliotecas globales por conveniencia : se pueden implementar con código de usuario sin privilegios, pero teniendo en cuenta las rutas de nombres globales estándar en el espacio de nombres global original.
  
• Módulos estándar para mayor comodidad : módulos desarrollados por la comunidad aprobados como estándar.

Los enumeré en orden, de acuerdo con mi sensación de aumentar los costos de crecimiento y la urgente necesidad de minimalismo. Todo esto requiere disciplina. Solo en el último punto podemos permitir un crecimiento ilimitado, pero es aconsejable que los candidatos sean evaluados por la comunidad y aceptados de facto. Idealmente, el comité TC39 dejará de ser un cuello de botella, ya que los procesos externos de facto y de jure podrán desarrollar módulos estándar de forma independiente por conveniencia.