Flix – un puissant langage de programmation orienté effets

• Flix est un langage innovant qui combine la programmation fonctionnelle et un modèle orienté effets
• Il facilite la modélisation des règles logiques et des dépendances de données, avec une forte capacité d’expression déclarative des connaissances
• Il permet d’écrire de façon concise le code de relations de dépendance complexes et de flux de processus
• Cette approche apporte de l’efficacité pour les tâches de conception d’algorithmes et de raisonnement
• Les fonctionnalités de requête permettent d’explorer facilement des données fondées sur une base de connaissances

---

Aperçu du langage Flix

• Flix est un nouveau langage fonctionnel qui introduit un paradigme de programmation orienté effets
• Au lieu d’écrire du code procédural, le programmeur peut décrire le système à partir de relations logiques et de règles
• Avec des règles logiques (déclarées dans #{}), il est possible d’exprimer de manière concise des scénarios industriels complexes impliquant composants, dépendances, temps d’assemblage et délais de livraison

Règles déclaratives et modélisation des données

• Dans l’exemple de code, des faits et des règles tels que PartDepends, AssemblyTime, DeliveryDate, ReadyDate sont utilisés
  • PartDepends("Car", "Chassis") définit par exemple une relation de dépendance entre produits
  • AssemblyTime("Engine", 2) définit le temps d’assemblage d’un composant
  • DeliveryDate("Piston"; 1) indique également le délai de livraison d’un composant
• La règle logique ReadyDate permet de calculer la date finale de disponibilité des pièces dont le délai de livraison est défini, ainsi que des pièces assemblées
• En d’autres termes, il devient simple d’inférer les cycles d’approvisionnement et d’assemblage de chaque composant

Raisonnement orienté effets et requêtes

• Le moteur de règles logiques de Flix combine une approche orientée effets et la transparence référentielle, ce qui favorise une conception de programmes intuitive et moins sujette aux erreurs
• La syntaxe de requête permet d’obtenir facilement les dates de disponibilité de tous les composants correspondant à ReadyDate
• Cette approche peut s’appliquer à de nombreux domaines, comme la fabrication, la gestion de la chaîne logistique et l’automatisation fondée sur le raisonnement

Synthèse et avantages

• Flix combine les effets (Effects) et le raisonnement fondé sur des règles logiques pour modéliser de manière concise les relations entre composants et processus dans des systèmes complexes
• Par rapport aux langages existants, il se distingue par des avantages en matière de clarté logique et de concision du code
• Il peut offrir une solution adaptée à divers problèmes logiciels modernes, notamment les graphes de connaissances, moteurs de workflow et inférence de données

[GN⁺]

Commentaires sur Hacker News

• Je suis profondément impressionné par la profondeur et l’ampleur de ce langage
  Tous les éléments essentiels — types de données algébriques, programmation logique, mutabilité, etc. — sont intégrés dès le départ
  Ce qui m’a le plus plu dans le tableau comparatif, c’est qu’un seul exécutable fait office à la fois de gestionnaire de paquets, de LSP et de compilateur
  Avec Haskell, le LSP devait réimplémenter beaucoup de choses entre ghc et les fichiers cabal, et stack était aussi utilisé, donc le caractère « officiel » du gestionnaire de paquets restait ambigu
  Ce n’est pas une critique de Haskell, c’est vraiment un excellent langage
  Mais c’est dommage que ses meilleures fonctionnalités soient un peu cachées
  Je me demande à quel point Flix s’intègre confortablement avec Java et le reste sur la JVM
  Comme les compilateurs JVM effacent la plupart des informations de type, le concept de regions dans Flix est un point positif puisqu’il prend en charge les interactions impératives comme des citoyens de première classe
  Le fait d’utiliser la JVM est un énorme avantage, puisqu’on peut profiter facilement de bibliothèques standard de très haute qualité valant des milliards de dollars
  C’est pourquoi je pense que la JVM ou .net core reste le choix le plus raisonnable pour plus de 90 % des projets
  F# me semble être le seul véritable langage de comparaison
  J’aimerais vraiment qu’il existe un document récapitulant les limites de l’interopérabilité entre Flix et la JVM
  À noter qu’il y a des informations à ce sujet ici
  En gros, les valeurs Flix/Java passent par des étapes de boxing/unboxing
  Et les Record sont aussi des citoyens de première classe

  • Si le fait que le gestionnaire de paquets, le LSP et le compilateur soient tous réunis dans un seul exécutable te plaît, alors tu aimeras probablement aussi beaucoup Unison

  • La partie programmation logique et Datalog donne un peu l’impression d’avoir été ajoutée en plus
    Les autres fonctionnalités renforcent clairement la sûreté de typage de la base de code, mais la programmation logique ressemble davantage à une fonctionnalité de niche, donc je me demande s’il ne vaudrait pas mieux qu’elle existe séparément du langage

  • Dire que les compilateurs JVM effacent toutes les informations de type n’est pas tout à fait exact (dans le cas des classes anonymes, les paramètres de type sont conservés)
    Il existe aussi plusieurs contournements
    Et en réalité, ce n’est pas un gros problème du point de vue du compilateur
    Il suffit de randomiser le nom des classes auxquelles on applique des constructeurs de type, puis de les rendre comme des classes ordinaires

  • F# ne prend pas (encore) en charge les type classes, donc la programmation basée sur les monades y est assez limitée
    Si F# sautait directement aux effets algébriques au lieu de passer par des monades à la Haskell, je pense que ce serait plus cohérent avec sa philosophie

  • La partie StringBuilder me laisse un peu dubitatif
    Sur ce point, on dirait que le langage penche davantage du côté de Java, donc je ne suis pas totalement convaincu
    Le reste a l’air plutôt correct à première vue

• Du point de vue de la sémantique du langage, on dirait que la sémantique d’extension/restriction des enregistrements polymorphes suit l’approche des labels scopés de Leijen (lien vers l’article)
  Par exemple, si on a un enregistrement r1 = { color = "yellow" }, on peut l’étendre avec r2 = { +color = "red" | r1 }
r2#color renverra "red", puis si on supprime à nouveau le champ "color", on obtient r3 = { -color | r2 }
  Et r3#color redonne la valeur d’origine, "yellow"
  Cette approche me paraît bien plus raisonnable que l’ancien style, qui allait vers des systèmes de types extrêmement complexes pour interdire d’ajouter deux fois un champ avec le même label

• Je me demande pourquoi Aarhus (surtout l’université / le hub tech) exerce une influence aussi forte dans la recherche sur les langages de programmation
  C++, C#/Typescript, Dart, etc. ont tous des racines importantes dans cette petite région du Danemark
  Ce n’est pas une université d’élite typique type Ivy League ou Oxbridge, comme Delft ou INRIA
  Qu’est-ce qui la rend si spéciale ? L’eau ? Ou autre chose ? C’est juste une curiosité un peu légère

  • Pour préciser un point, C# a été créé par Anders Hejlsberg, qui a étudié au DTU (Copenhague)
    C’est aussi lui qui a créé Turbo Pascal, et Borland a été fondée par un Danois
    De manière générale, le Danemark est fort en théorie des langages de programmation
    Par exemple, le manuel de référence en analyse statique de programmes au niveau master/doctorat (par Nielson & Nielson) est aussi danois
    Mads Tofte a énormément contribué à Standard ML
    Aarhus n’est peut-être pas au niveau de l’Ivy League ou d’Oxbridge, mais c’est une excellente université
    En Europe, il existe des dizaines d’universités de ce genre, peu célèbres mais remarquables par la qualité de leur enseignement et de leur recherche

  • Aarhus a une longue tradition en logique, théorie des types et langages fonctionnels / orientés objet
    Beaucoup de chercheurs influents dans ces domaines viennent d’Aarhus
    Et j’ai l’impression que la recherche sur les langages de programmation souffre d’un fort biais pro-américain à l’échelle mondiale
    Les institutions comme Aarhus ont tendance à être nettement moins portées sur le marketing ou l’auto-promotion, et davantage concentrées sur la qualité de la recherche
    Ce n’est ni mieux ni moins bien, mais cela rend plus difficile l’obtention d’une attention mondiale

• Flix continue de m’impressionner comme l’un des langages de la famille ML les plus soigneusement conçus
  La combinaison des paradigmes fonctionnel, impératif et logique, avec un système polymorphe de types et d’effets ainsi que des contraintes Datalog prises en charge comme citoyens de première classe, est vraiment unique
  Le fait de distinguer strictement au niveau des types le code pur du code impur est une alternative rafraîchissante aux monades, plus facile pour l’inférence des effets
  J’aime aussi la philosophie « un seul langage, sans flags » et la recherche exclusive des erreurs à la compilation, car cela rend l’ensemble simple et prévisible
  Le fait que Flix ait implémenté une élimination complète des appels terminaux alors même que la JVM ne prend pas en charge nativement l’optimisation de récursion terminale constitue une réalisation technique remarquable
  J’aimerais beaucoup avoir des retours d’expérience de personnes qui utilisent réellement Flix en production ou en recherche
  En particulier, j’aimerais entendre parler des difficultés rencontrées autour de la programmation logique ou de la concurrence, comme l’hypothèse du monde clos (closed-world assumption) ou l’absence de prise en charge des exceptions, ainsi que des différences entre son intégration de Datalog et celle d’autres langages logiques comme Prolog

• J’avais regardé Flix il y a quelque temps, et j’avais trouvé ça tellement intéressant que j’en ai même écrit un billet intitulé « Flix pour les programmeurs Java »
  Il date un peu maintenant et aurait besoin d’une mise à jour, bien sûr...
  Si ça vous intéresse, on peut le lire ici

  • Le billet est vraiment excellent
    Avec votre permission, ce serait bien de l’ajouter à la collection officielle de billets de blog Flix (lien)
    Le langage Flix a beaucoup évolué depuis cet article
    En particulier, le système d’effets s’est fortement étendu, l’interopérabilité Java a été améliorée, et la syntaxe a été mise à jour

  • Ce blog a vraiment l’air d’un trésor
    J’ai l’impression d’y trouver une version plus raffinée de pensées qui me travaillent depuis longtemps
    J’ai hâte de tout lire

• Le support des HKT est aussi très appréciable
  En revanche, je ne vois pas d’explication sur les type classes, donc je me pose la question
  S’il y avait les type classes et des macros à la Scala, je serais tenté de porter en Flix mes bibliothèques (distage, izumi-reflect, BIO) et j’envisagerais sérieusement de passer de Scala à Flix
  Plus tard, j’ai découvert que Flix appelle les type classes des traits
  Je me demande ce qu’il en est des macros
  Et je trouve aussi dommage que Flix ne prenne pas en charge l’héritage nominal explicite
  Puisqu’il n’autorise même pas la forme la plus inoffensive des traits à la Scala
  Les type classes ne peuvent pas remplacer les interfaces, et sans cette abstraction, j’ai l’impression que beaucoup de fonctionnalités utiles deviennent soit impossibles à implémenter, soit franchement peu élégantes

  • Flix prend en charge les type classes (appelées ici traits) avec les HKT, les associated type et les associated effect
    Les traits peuvent aussi fournir des implémentations par défaut pour les fonctions, que les instances peuvent ensuite redéfinir
    Flix n’a tout simplement aucun mécanisme d’héritage
    Les traits ne sont utilisés qu’à la compilation et passent par une monomorphization, donc il n’y a aucun surcoût à l’exécution
    L’inliner de Flix optimise aussi l’intérieur des traits, en supprimant agressivement jusqu’aux closures
    Par exemple, des fonctions d’ordre supérieur ou des pipelines deviennent au niveau bytecode de simples boucles ordinaires, sans aucune allocation de closure ni indirection
    Flix ne prend pas encore en charge les macros
    Ils semblent hésiter à les introduire à cause d’expériences d’abus dans d’autres langages
    Ils cherchent de nouveaux auteurs de bibliothèques, donc si ça vous intéresse, passez sur le canal Gitter

• À propos de la section « fonctionnalités non prises en charge dans Flix » de la documentation officielle
  Il y a un point intitulé No Code Before Main
  Mais l’explication dit en réalité : « Flix n’exécute aucun code avant main et n’a rien comme des initialiseurs statiques »
  Je pense qu’il serait plus exact d’appeler cette fonctionnalité Code Before Main

• Je me demande pourquoi Flix demande de marquer explicitement qu’une fonction est pure
  On dirait que dans presque tous les cas, une analyse statique suffirait à l’inférer, donc j’aimerais comprendre pourquoi

  • Si j’ai bien compris, lorsqu’on marque une fonction comme pure, le compilateur garantit alors cette propriété

  • Quand on lit la phrase « Flix suit précisément la pureté de chaque expression dans le programme » et qu’on regarde des exemples de définitions de fonctions sans annotation pur/impur, on a l’impression que, dans la majorité des cas, le compilateur est effectivement capable d’inférer automatiquement la pureté
    Cela donne l’impression que l’annotation de pureté/impureté pourrait être optionnelle

• La FAQ de Flix (lien) commence de façon assez classique puis devient de plus en plus drôle
  Quelques exemples amusants :

  • Q : si on divise par zéro, le vrai résultat est-il vraiment 0 ?<br> A : oui. Mais se focaliser là-dessus, c’est un peu comme ne s’intéresser qu’à la couleur des sièges d’un vaisseau spatial
  • Q : « ce site nécessite JavaScript »<br> A : nombre de personnes ayant critiqué l’usage de JavaScript : [1],[2],[3],[4],[5], nombre de personnes ayant proposé une aide concrète pour tout refactorer en HTML : 0
  • Q : je suis déçu qu’il y ait la fonctionnalité X au lieu de ma fonctionnalité préférée Y<br> A : désolé
  • Q : c’est la pire syntaxe de langage fonctionnel que j’aie jamais vue. On dirait que des points-virgules, des accolades et un chaos de symboles se sont rencontrés. Comme si Scala, Java et Haskell avaient passé une nuit ensemble au beau milieu de Tchernobyl<br> A : en un sens, n’est-ce pas une sacrée réussite ?

• Je me demande si les agents de code compatibles avec ce langage fonctionnent bien, ou s’il faut encore utiliser son cerveau soi-même
  Je plaisante, mais en réalité le langage a l’air vraiment cool, ce qui me rend un peu triste
  J’ai l’impression que les LLM risquent au contraire de freiner l’adoption des nouveaux langages, et je me demande comment résoudre ce problème

  • Mon intuition est plutôt que les LLM vont abaisser la barrière d’adoption des nouveaux langages
    Le code de la bibliothèque standard suffit à un LLM pour apprendre une nouvelle syntaxe, et même si ce n’est pas le cas, un agent peut apprendre en observant la sortie du compilateur
    Le portage de code lui-même demande relativement peu de créativité de haut niveau : c’est une tâche bien définie, donc cela deviendra probablement l’un des premiers domaines d’automatisation par les LLM
    À l’avenir, je pense que nous devrons surtout utiliser notre cerveau pour réfléchir sérieusement au « pourquoi » de ce que nous faisons et à son impact sur le monde

  • En indiquant dans le prompt qu’il faut impérativement utiliser les types indexés / dépendants d’Idris, j’obtiens des résultats corrects
    (sans ce genre d’instruction, il semble se limiter au niveau des GADT)