Flix – un potente lenguaje de programación orientado a efectos

• Flix es un lenguaje innovador que combina la programación funcional con un modelo orientado a efectos
• Facilita el modelado de reglas lógicas y dependencias de datos, y destaca por su expresión declarativa del conocimiento
• Permite escribir en código de forma concisa relaciones de dependencia complejas y flujos de proceso
• Este enfoque aporta eficiencia a tareas de diseño de algoritmos y razonamiento
• Mediante sus capacidades de consulta, permite explorar fácilmente datos basados en conocimiento

---

Panorama general del lenguaje Flix

• Flix es un nuevo lenguaje funcional que introduce un paradigma de programación orientado a efectos
• En lugar de escribir código procedimental, los programadores pueden describir sistemas centrados en relaciones y reglas lógicas
• Con reglas lógicas (declaradas dentro de #{}), es posible expresar de manera concisa escenarios complejos de manufactura como componentes, dependencias, tiempos de ensamblaje y fechas de entrega

Reglas declarativas y modelado de datos

• En el código de ejemplo se usan hechos y reglas como PartDepends, AssemblyTime, DeliveryDate, ReadyDate
  • Se definen relaciones de dependencia entre productos, como en PartDepends("Car", "Chassis")
  • Se establecen tiempos de ensamblaje por componente, como en AssemblyTime("Engine", 2)
  • También se especifican fechas de entrega de componentes, como en DeliveryDate("Piston"; 1)
• Mediante la regla lógica ReadyDate, es posible calcular la fecha final de disponibilidad de componentes con fecha de entrega definida o de piezas ensambladas
• En otras palabras, permite inferir de forma sencilla los ciclos de suministro y ensamblaje de cada componente

Razonamiento orientado a efectos y consultas

• El motor de reglas lógicas de Flix combina la orientación a efectos con la transparencia referencial, promoviendo el diseño de programas intuitivos y con menos errores
• Con la sintaxis de consulta, se pueden obtener fácilmente las fechas de disponibilidad de todos los componentes correspondientes a ReadyDate
• Este enfoque puede aplicarse en diversos campos como manufactura, gestión de cadenas de suministro y automatización basada en razonamiento

Resumen y ventajas

• Flix combina efectos (Effects) e inferencia basada en reglas lógicas para modelar de forma concisa las relaciones entre componentes y procesos en sistemas complejos
• Frente a lenguajes tradicionales, ofrece ventajas diferenciadas en claridad lógica y concisión del código
• Puede ofrecer una solución adecuada para diversos problemas modernos de software como grafos de conocimiento, motores de flujo de trabajo e inferencia de datos

[GN⁺]

Comentarios de Hacker News

• Me impresiona mucho la profundidad y amplitud de este lenguaje
  Incluye desde el inicio características esenciales como tipos de datos algebraicos, programación lógica y mutabilidad
  Lo que más me gustó al ver la tabla comparativa fue que un solo ejecutable cumple el papel de gestor de paquetes, LSP y compilador
  En el caso de Haskell, el LSP tenía que reimplementar muchas cosas entre ghc y los archivos de cabal, y además se usaba stack, así que la oficialidad del gestor de paquetes era algo ambigua
  No lo digo para criticar a Haskell; de verdad es un lenguaje excelente
  Pero da un poco de pena que sus mejores características parezcan algo escondidas
  Me da curiosidad qué tan cómoda es la integración de Flix con Java y otros lenguajes sobre la JVM
  Como los compiladores para la JVM eliminan la mayor parte de la información de tipos, me parece positivo que el concepto de regions de Flix apoye la interacción imperativa como ciudadano de primera clase
  Usar la JVM también es una ventaja enorme porque te permite aprovechar fácilmente bibliotecas estándar de altísima calidad respaldadas por miles de millones de dólares
  Por eso creo que la JVM o .NET Core son la opción más razonable en más del 90% de los proyectos
  F# parece ser el único lenguaje realmente comparable
  Estaría buenísimo tener un documento que resuma las limitaciones de interoperabilidad entre Flix y la JVM
  Por cierto, hay información relacionada aquí
  Básicamente, los valores de Flix/Java pasan por procesos de boxing/unboxing
  Además, Record es ciudadano de primera clase

  • Si te gusta que el gestor de paquetes, el LSP y el compilador sean un solo ejecutable, probablemente también te encantaría Unison

  • La parte de programación lógica y Datalog se siente un poco como un añadido
    Las otras funciones claramente mejoran la seguridad de tipos del código, pero la programación lógica es una característica bastante de nicho, así que quizá sería mejor que existiera separada del lenguaje

  • No es del todo cierto que los compiladores de la JVM eliminen toda la información de tipos (las clases anónimas conservan los parámetros de tipo)
    También existen varios rodeos
    Y de hecho, para el compilador no es un gran problema
    Basta con aleatorizar el nombre de la clase al aplicar el constructor de tipos y renderizarla como una clase normal

  • F# todavía no soporta type classes, así que tiene muchas limitaciones para la programación basada en monads
    Si F# se saltara los monads estilo Haskell y brincara directo a los efectos algebraicos, creo que encajaría mucho mejor con la filosofía de F#

  • La parte de StringBuilder me deja un poco dudoso
    En ese aspecto parece inclinarse más hacia Java, así que no me termina de convencer
    Fuera de eso, a simple vista se ve bien

• Desde el punto de vista de la semántica del lenguaje, parece que la semántica de extensión/restricción de los registros polimórficos sigue el enfoque de labels con scope de Leijen (enlace al paper)
  Por ejemplo, si tienes un registro r1 = { color = "yellow" }, puedes extenderlo con r2 = { +color = "red" | r1 }
r2#color da como resultado "red", y si luego eliminas otra vez el campo "color", obtienes r3 = { -color | r2 }
r3#color vuelve a dar el valor original, "yellow"
  Me parece mucho más razonable hacer esto que el estilo anterior, que recurría a sistemas de tipos extremadamente complejos para impedir añadir dos veces un campo con el mismo label

• Me da curiosidad por qué Aarhus (especialmente la universidad/el hub tecnológico) tiene una influencia tan fuerte en la investigación de lenguajes de programación
  C++, C#/Typescript y Dart tienen raíces fuertes en esta pequeña región de Dinamarca
  No es una universidad de élite típica como Ivy League u Oxbridge, ni algo como Delft o INRIA
  ¿Qué fue lo que la hizo tan especial? Solo me da curiosidad si será por el agua o por alguna otra razón

  • Solo por precisar: C# fue creado por Anders Hejlsberg, y él estudió en DTU (Copenhague)
    Turbo Pascal también fue obra suya, y Borland fue fundada por un danés
    En general, Dinamarca es fuerte en teoría de lenguajes de programación
    Por ejemplo, el libro de posgrado estándar en análisis estático de programas (de Nielson & Nielson) también es de autores daneses
    Mads Tofte hizo contribuciones importantes a Standard ML
    Aarhus no está al nivel de Ivy League u Oxbridge, pero es una gran universidad
    En Europa hay decenas de universidades así: con menos fama, pero con una calidad excelente en enseñanza e investigación

  • Aarhus tiene una tradición muy fuerte en lógica, teoría de tipos y lenguajes funcionales/orientados a objetos
    Muchos investigadores influyentes en estas áreas vienen de Aarhus
    Además, siento que la investigación en lenguajes de programación está muy sesgada globalmente hacia EE. UU.
    Instituciones como Aarhus suelen ser notablemente menos dadas al marketing o a la autopromoción, y tienden a concentrarse en hacer buena investigación
    No es que sean mejores o peores, pero eso sí dificulta que reciban atención global

• Flix me sigue pareciendo el lenguaje mejor diseñado dentro de la familia ML
  La combinación de paradigmas funcional, imperativo y lógico, junto con un sistema polimórfico de tipos y efectos, y soporte de primera clase para restricciones Datalog, es realmente única
  El hecho de distinguir estrictamente en el nivel de tipos entre código puro e impuro se siente como una alternativa fresca a los monads, más fácil para inferir efectos
  También me gusta la filosofía de “un solo lenguaje, sin flags” y la búsqueda de tener únicamente errores en tiempo de compilación, porque lo hace simple y predecible
  Que Flix haya implementado eliminación completa de tail calls, a pesar de que la JVM no soporta de forma nativa la eliminación de recursión de cola, es un logro técnico digno de atención
  Me interesa saber cómo ha sido la experiencia de quienes usan Flix en producción o en investigación
  Sobre todo me gustaría escuchar sobre dificultades al usarlo en programación lógica o concurrencia, por ejemplo con la "closed-world assumption" o la falta de soporte para excepciones, y en qué se diferencia integrar Datalog frente a otros lenguajes lógicos como Prolog

• Cuando revisé Flix hace tiempo, me pareció tan interesante que incluso escribí un artículo titulado “Flix for Java Programmers”
  Ya tiene algo de tiempo y le vendría bien una actualización, pero...
  Si a alguien le interesa, puede verlo aquí

  • El post está realmente genial
    Si das permiso, estaría muy bien añadirlo a la colección oficial de posts del blog de Flix (enlace)
    El lenguaje Flix ha evolucionado bastante desde ese artículo
    En particular, el sistema de efectos se ha ampliado mucho, hubo mejoras en la interoperabilidad con Java y actualizaciones de sintaxis

  • El blog de verdad parece un tesoro
    Se siente como una versión más refinada de ideas que me han estado rondando la cabeza durante mucho tiempo
    Me emociona pensar en leerlo todo

• Qué bien que también soporte HKTs
  Pero no veo explicación sobre type classes, así que me da curiosidad
  Si además soportara type classes y macros estilo Scala, me darían muchas ganas de portar mis librerías (distage, izumi-reflect, BIO) a Flix e incluso pensar seriamente en migrar de Scala a Flix
  Luego descubrí que a futuro llaman traits a las type classes
  También me pregunto cómo va el tema de las macros
  Y me da un poco de pena que Flix no soporte herencia nominal explícita
  Ni siquiera permite la forma más inocua de los traits de Scala
  Siento que las type classes no pueden reemplazar a las interfaces, y sin esa abstracción hay muchas cosas útiles que simplemente no se pueden implementar o hacen que el código se vea feo

  • Flix sí soporta type classes (aquí las llaman trait) junto con HKT, associated type y associated effect
    Los trait también pueden ofrecer implementaciones por defecto de funciones, pero se pueden sobrescribir en cada instancia
    Flix no tiene herencia en absoluto
    Los trait se usan únicamente en tiempo de compilación y pasan por monomorphization, así que no tienen overhead en runtime
    El inliner de Flix también optimiza el interior de los trait, eliminando agresivamente incluso los closures
    Por ejemplo, funciones de orden superior o pipelines terminan convertidos en loops comunes al nivel de bytecode, sin asignación de closures ni indirecciones
    Flix todavía no soporta macros
    Parece que les da miedo introducirlas por las experiencias de abuso en otros lenguajes
    Están buscando nuevos autores de librerías, así que si a alguien le interesa, estaría bueno que se pase por el canal de Gitter

• Sobre la sección “funciones que Flix no soporta” en la documentación oficial de Flix
  Hay un punto llamado No Code Before Main
  Pero la explicación real dice: “Flix no ejecuta ningún código antes de main y no tiene nada parecido a inicializadores estáticos”
  Creo que sería más preciso llamar a esa característica Code Before Main

• Me da curiosidad por qué en Flix hay que marcar explícitamente que una función es pura
  En casi todos los casos parecería que el análisis estático bastaría para inferirlo, así que quisiera entender por qué

  • Hasta donde yo sé, si marcas la pureza de una función, el compilador se asegura de garantizarla

  • Al ver la frase “Flix tracks the purity of every expression in the program exactly” y también ejemplos de definiciones de funciones sin marcas de pureza/impureza
    da la impresión de que en la mayoría de los casos el compilador sí puede inferir automáticamente la pureza
    Así que parece que la anotación de pureza/impureza podría ser opcional

• El FAQ de Flix (enlace) empieza bastante normal y luego se va poniendo cada vez más divertido
  Algunos ejemplos graciosos:

  • P: ¿De verdad el resultado de dividir entre 0 es 0?<br> R: Sí. Pero enfocarse solo en eso es como preocuparse por el color de los asientos de una nave espacial
  • P: “Este sitio requiere JavaScript”<br> R: Personas que criticaron el uso de JavaScript: [1],[2],[3],[4],[5], personas que realmente ofrecieron ayudar a refactorizarlo a HTML: 0
  • P: Me decepciona que hayan incluido la función X en lugar de mi función favorita Y<br> R: Lo sentimos
  • P: Es la peor sintaxis que he visto en un lenguaje funcional. Es como si punto y coma, llaves y un caos de símbolos se hubieran mezclado. Parece que Scala, Java y Haskell tuvieron una aventura de una noche en medio de Chernóbil<br> R: ¿No sería más bien un logro impresionante?

• Me pregunto si los agentes de código compatibles con este lenguaje funcionan bien, o si aquí sí toca pensar por cuenta propia
  Lo digo medio en broma, pero la verdad es que el lenguaje se ve tan bueno que hasta da tristeza
  Si los LLM van a frenar la adopción de lenguajes nuevos, me pregunto cómo se podrá resolver eso

  • Yo más bien tengo la intuición de que los LLM van a bajar la barrera de adopción de lenguajes nuevos
    El código de la biblioteca estándar basta para que un LLM aprenda una sintaxis nueva, y si no, un agente igual puede aprender observando la salida del compilador
    Portar código es justamente el tipo de trabajo bien definido que no requiere demasiada creatividad y que será de los primeros en automatizarse con LLM
    En adelante, creo que nosotros tendremos que dedicar el cerebro a pensar seriamente por qué hacemos esto y qué impacto tiene en el mundo

  • Me ha ido bien cuando en el prompt indico explícitamente que use los tipos indexados/dependientes de Idris
    (si no se lo dices, normalmente apenas llega al nivel de GADT)