Deja de diseñar lenguajes y, en su lugar, escribe bibliotecas

• La clave de la productividad en programación está en un ecosistema rico de bibliotecas, más que en el lenguaje en sí
• Frameworks como Ruby on Rails, que aprovechan funciones avanzadas del lenguaje, ofrecen alta productividad incluso a personas no especialistas
• Sin embargo, debido a las limitaciones estructurales del lenguaje, es difícil implementar en Java o C frameworks del nivel de Rails
• El diseño del lenguaje determina directamente la forma y la complejidad de las bibliotecas que se pueden escribir, y ese es el propósito esencial de la evolución de los lenguajes
• Desde esta perspectiva, el lenguaje Stanza muestra la importancia del diseño de lenguajes que permita crear bibliotecas potentes y fáciles de usar

---

La relación entre los lenguajes de programación y las bibliotecas

• La mayoría de los lenguajes de programación tienen elementos básicos similares, como variables, arreglos, bucles y funciones
  • Algunos lenguajes ofrecen funciones avanzadas como funciones de primera clase o corutinas, pero las personas no especialistas rara vez las usan
• Para muchos desarrolladores, lo que aumenta la productividad son las bibliotecas más que el lenguaje
  • Por ejemplo, Ruby on Rails permite construir con facilidad aplicaciones web basadas en bases de datos
  • Gracias a Rails, la preferencia suele inclinarse más por el framework que por el lenguaje Ruby en sí

La interacción entre Ruby on Rails y las funciones del lenguaje

• Rails aprovecha diversas funciones de Ruby como metaprogramación, evaluación en tiempo de ejecución, funciones de primera clase y recolección de basura
  • Por ejemplo, ActiveRecords usa metaprogramación, y el sistema de plantillas usa evaluación en tiempo de ejecución
  • El manejo de eventos se implementa pasando funciones de primera clase como callbacks
• En Java o C faltan estas capacidades, por lo que no es posible implementar un framework del nivel de Rails
  • La metaprogramación de Java no es lo bastante potente como para implementar ActiveRecords
• Por eso Rails es posible gracias a la estructura del lenguaje Ruby, y el diseño del lenguaje determina las posibilidades de las bibliotecas

El diseño del lenguaje determina la forma de las bibliotecas

• El lenguaje C solo soporta reutilización mediante declaraciones y llamadas a funciones, por lo que la mayoría de las bibliotecas en C tienen la forma de conjuntos de funciones
• Ruby soporta funciones de primera clase, lo que permite expresar de forma concisa “qué hacer cuando se hace clic en un botón”
  • En cambio, en Java hay que definir una clase manejadora, lo que complica el código
• La expresividad del lenguaje define de manera directa la estructura y la usabilidad de las bibliotecas

Software interactivo y aparición de frameworks extensibles

• En la computación por lotes de la década de 1970, las bibliotecas centradas en funciones eran suficientes
• En el software interactivo moderno se necesitan bibliotecas extensibles
  • En GUI o sistemas basados en eventos, se requiere una estructura del tipo “ejecuta mi código cuando el usuario haga clic”
• Java y C++ soportan extensibilidad mediante herencia y sobrescritura de métodos, y esta estructura evolucionó hacia los frameworks

Trasfondo del diseño de Stanza y límites de los lenguajes

• La motivación detrás del diseño de Stanza surgió de la dificultad de escribir en Java una biblioteca de programación de juegos fácil de usar
  • En Java, la concurrencia tenía que expresarse como una máquina de estados (state machine)
  • Scheme soporta continuation, lo que permite una implementación más intuitiva
• Sin embargo, Scheme no soporta verificación estática de tipos, por lo que la eficiencia de depuración es baja
  • Actualmente, la mayoría de los lenguajes no permiten extender el sistema de tipos como una biblioteca
• Stanza ofrece un sistema de tipos opcional, recolección de basura y un sistema de objetos basado en multimétodos
  • Pero no permite volver a escribir desde cero un sistema de objetos definido por el usuario

El propósito del lenguaje y la dirección de la investigación

• El propósito de un lenguaje de programación de propósito general es apoyar la creación de bibliotecas potentes y fáciles de usar
  • Cuanto más potente es el lenguaje, más conciso se vuelve el uso de las bibliotecas
• Cuando el código usa una biblioteca bien diseñada, tiene una naturalidad que se lee como si se le dieran instrucciones a un colega
• Racket, Shen y la investigación sobre protocolos metaobjeto exploran sistemas de tipos y de objetos extensibles
• En última instancia, los lenguajes se distinguen por “qué bibliotecas se pueden usar y cuáles no”
• Detrás de las bibliotecas elegantes hay décadas de investigación y esfuerzo de diseño de lenguajes

[GN⁺]

Opiniones de Hacker News

• El mejor ejemplo es Prolog. A menudo se le llama el lenguaje representativo de la programación lógica, pero en realidad no es más que una colección de algoritmos, y podría implementarse como una librería en distintos lenguajes. Pienso que bastaría con ofrecer la expresión sintáctica de Prolog adaptada a la gramática de cada lenguaje

  • El núcleo de Prolog no es el algoritmo, sino la forma de expresar reglas lógicas de manera declarativa. Por ejemplo, si defines la regla “un abuelo es el padre de un padre”, con eso puedes encontrar abuelos o, a la inversa, inferir relaciones de parentesco. Esa inferencia bidireccional es el atractivo de Prolog. Claro, para imitar algo así en un lenguaje general harían falta código sin efectos secundarios y un DSL limitado. Además, así como PyTorch o TensorFlow ejecutan CUDA desde Python, también es posible hacer llamadas entre lenguajes, así que una estructura no dependiente del lenguaje me parece totalmente viable
  • La sintaxis de Prolog es un subconjunto de la lógica de primer orden (First Order Logic), donde a las variables no se les asigna un valor fijo, sino que se exploran conjuntos de valores posibles hasta satisfacer las condiciones. El motor de Prolog hace más que una simple llamada de librería: por ejemplo, incluye representación comprimida del espacio de soluciones, ejecución paralela y poda automática. Por eso normalmente Prolog se integra como servicio backend o mediante generación de código. Prolog es especialmente potente en planeación, resolución de restricciones, demostración de teoremas, pruebas combinatorias y modelado de precios. Por eso me cuesta verlo simplemente como “un lenguaje que podría resolverse con una librería”
  • Siguiendo la misma lógica, también podría decirse que la programación orientada a objetos no hace falta en un lenguaje porque puede imitarse con closures. Pero hay ventajas claras en la capacidad expresiva que da una sintaxis explícita
  • Para implementar como librería una programación relacional al estilo de Prolog, el lenguaje tendría que soportar como ciudadanos de primera clase la manipulación de símbolos y variables. Los lenguajes tipo Lisp lo permiten hasta cierto punto, pero en los lenguajes comunes la usabilidad cae muchísimo. Una vez hablé de esto con Bob Harper y él dijo: “simplemente crea un lenguaje nuevo”, y la verdad es que sonó bastante convincente
  • Quiero aprender Prolog, pero me cuesta encontrar material de nivel intermedio entre los tutoriales introductorios y los ejemplos avanzados. Estoy tratando de resolver variantes de Sudoku con Prolog, pero los ejemplos existentes están demasiado optimizados y se hace difícil aprender a definir relaciones más generales. En particular, me interesa cómo modelar situaciones donde algunas reglas pueden estar equivocadas. Como referencia, estoy viendo el ejemplo de Sudoku de SWI-Prolog

• Hace 10 años era fan de Scala. Me atraía la idea de “Scalable Language”, eso de poder construir DSL dentro del sistema de tipos. Pero perdí el interés cuando la comunidad empezó a usarlo como una especie de Haskell sobre la JVM. Últimamente tengo esperanza en tecnologías como WASM o Graal, porque podrían dar más flexibilidad al elegir lenguaje. Muchas veces JavaScript basta, pero está bueno tener la opción de usar un lenguaje de bajo nivel como Rust cuando haga falta

  • Yo también creo que el mayor problema de Scala es el abuso de los DSL. No solo aprendes el lenguaje en sí, sino que además sientes que tienes que aprender otro lenguaje dentro de frameworks de testing y demás. Claro, impresiona poder expresar un Hadoop MapReduce en una sola línea, pero para la mayoría del trabajo es demasiado. Y además, a los desarrolladores de Scala no les gusta escribir “código aburrido”. He visto muchos casos de gente que se luce un rato y luego deja un infierno de mantenimiento
  • No toda la comunidad de Scala está orientada a Haskell. Solo algunos magos de los tipos muestran esa tendencia. Scala también funciona muy bien si la usas simplemente como “un Java mejor”. Te deja aprovechar ventajas de la programación funcional sin tanta carga
  • Haskell se usa a menudo precisamente como lenguaje para crear DSL. Buenos ejemplos son Haxl de Meta o TidalCycles, el DSL para música. Eso sí, las librerías basadas en tipos de orden superior suelen degradar bastante el rendimiento y ser innecesariamente complejas
  • ¿Has usado alguna vez Clojure(Script)? Como buen Lisp, permite extender el lenguaje según el problema mediante programación bottom-up. Paul Graham enfatiza mucho este enfoque en On Lisp. También recomiendo la charla relacionada Bottom Up vs Top Down Design in Clojure
  • Yo empecé a aprender Scala hace poco y me está gustando mucho, incluso desde el lado de la programación funcional. Me parece lo bastante generalista como para usarse de muchas formas, no solo para crear DSL. ¿Tú sientes que a Scala le falta algo?

• Estaría bien poder reemplazar bash con un lenguaje de scripting tipado. Hice un script sencillo en Elixir para parsear JSON y quedó bastante bien

  • ¿Has probado Nushell? Permite resolver en una sola línea tareas para las que antes sentías que necesitabas un “lenguaje de verdad”. Por ejemplo, puedes escribir fácilmente un pipeline que ordene archivos y los emita en JSON
  • En realidad, con shebang puedes escribir scripts en muchos lenguajes. Por ejemplo, se puede con C#, Java y Go. Si usas Scriptisto, prácticamente puedes hacer scripts con shebang en casi cualquier lenguaje
  • OCaml también puede usarse como si fuera scripting. Puedes ejecutarlo directamente con #!/usr/bin/env ocaml. Eso sí, no tiene instalación automática de dependencias externas en un solo archivo
  • En Go también hay un truco para imitar shebang. La discusión relacionada está aquí
  • Para scripting cotidiano, Python o PowerShell también son buenas opciones

• El lenguaje y la librería no son mutuamente excluyentes. Algunas librerías en la práctica funcionan como lenguajes, y a la inversa, hay lenguajes diseñados para cierta librería. Por ejemplo, Julia es un buen caso de equilibrio entre rendimiento y facilidad de uso. Puedes escribir directamente en Julia código de alto rendimiento y obtener ejecución optimizada mediante compilación con especialización de tipos a nivel JIT. Su modelo parece una simple llamada a funciones, pero por dentro opera de forma muy sofisticada

  • Exacto, al final el punto central era que se necesitan tanto lenguajes como librerías

• Raku está diseñado como una estructura que une varios sublenguajes (slang). Por ejemplo, regex, PEG y quoting se tratan como minilenguajes separados, y con Slangify puedes añadir fácilmente tu propio DSL

  • Pero personalmente no me gusta la sintaxis donde el tipo va después del nombre de la variable, así que no prefiero Raku

• Una vez un desarrollador senior dijo: “si veo Rails en un currículum, lo tiro de inmediato”. Eso me hizo pensar otra vez en lo tonto que es juzgar a la gente por el lenguaje

  • No es casualidad que el auge de Rails y el declive de J2EE ocurrieran al mismo tiempo. Rails mostró una forma simple y con opiniones claras de escribir backend, y por esa influencia aparecieron frameworks de Java como DropWizard, Javalin y Spring Boot
  • Me da curiosidad cuál era el stack tecnológico de ese senior
  • Hasta me dan ganas de ir a recoger la basura de alguien así. Es difícil encontrar buenos desarrolladores de Rails. Yo también tengo experiencia con RoR y todavía me gusta
  • Claro, si estás buscando desarrolladores Java, quizá filtrar currículums con Rails sí sea eficiente
  • Al final, los criterios para evaluar personas dependen de la compatibilidad cultural de la organización y del estilo de colaboración. No existe un método perfecto de filtrado

• Al final, el lenguaje o la librería son medios para comunicarse tanto con la máquina como con las personas. Con la máquina te comunicas mediante bits y voltajes; con las personas, mediante intención y conceptos. Por lo tanto, si un lenguaje o una librería permite a la gente expresar algo con claridad y rapidez, da igual si se le llama lenguaje o librería. Rails o Stanza, si sirve para el propósito y el equipo lo entiende bien, entonces esa es la respuesta correcta

• Yo pienso que “la librería es el lenguaje final”. Por ejemplo, Ruby on Rails es un excelente lenguaje para servicios web construido sobre Ruby. Ruby y Rails evolucionaron el uno para el otro. Al final, creo que programar es un proceso continuo de traducción entre lenguajes

  • C# y ASP.NET Core también evolucionaron juntos de forma parecida. Se lograron al mismo tiempo una sintaxis amigable para el usuario y optimizaciones a nivel de sistema

• Es cierto eso de que “cuanto más poderoso es el lenguaje, más fácil es usar librerías”. Antes, en Java, era difícil hacer un framework como Express

  • No sé exactamente qué es Express, pero creo que Java se consolidó como lenguaje empresarial gracias a su facilidad para aprovechar librerías
  • La minimal API de ASP.NET Core es un caso de implementar casi tal cual Express. Eso solo es posible cuando lenguaje y framework evolucionan juntos
  • En Java también existen frameworks parecidos a Express, como Javalin. El problema es que la comunidad no quiere simplicidad

• Si hablamos de un framework web para el lenguaje C, ¿entonces PHP no cuenta? ;)

  • Eso suena como un chiste que estira demasiado el concepto de librería