deft/journal/2021-01-03--12-08-46Z--voeux_2021_alexandre.org

voeux 2021 alexandre

tags

source

Bonjour Alexandre, je te souhaite à toi et toute ta famille une très bonne année 2021 !

Je vous souhaite à tous une très bonne santé surtout dans le climat actuel. De trouver un bon équilibre entre la vie familiale les passions et le travail.

J'en profite aussi pour parler d'autres choses techniques. Je n'écris plus vraiment de nouvel article sur Haskell/Purescript. Cependant, j'ai passé pas mal de temps à réfléchir à comment architecturer du code à la fois dans Haskell/Purescript et Clojure. Et j'ai l'impression qu'une solution qu'on utilise actuellement en Clojure bien qu'à première vue très inférieure aux solutions proposées par Haskell/Purescript sont en fait supérieure lorsqu'on les regardes selon le bon angle.

L'idée de fond c'est que les systèmes d'effets/Free Monad (et les sous-systèmes, style MTL, handler pattern) sont en fait une sorte de sous ensemble de ce que l'on peut obtenir avec un système de "Services".

Si on regarde l'intérêt de ces système d'organisation de code – le plus évolué étant les Free Monads et les systèmes d'effets – leur objectif est toujours plus ou moins le même.

Changer le comportement du même bloc de code en fonction du contexte d'exécution. En gros si on prend une function qui ressemble à:

my_function arg1 ... argn = do
  x1 <- action1 arg1 .. argn
  x2 <- action2 arg1 .. argn x1
  ...
  z <- actionK arg1 .. argn x1 .. x<K-1>
  return z

les action1 à actionK auront des comportement différents en fonction du contexte dans lequel il va être initialisé. Dans le cas de Haskell, on fait au mieux pour déterminer le contexte à compile time en utilisant les types. Du genre:

main = do
  effect1 <- initEffect1
  effect2 <- initEffect2 effect1
  ...
  effectM <- initEffectM effect1 ... effect<M-1>
  runWithEffects [effect1,effect2,...,effectM] my_function

Ce système présente ainsi beaucoup d'avantanges:

1. mettre toute la business logic dans la fonction my_function en se débarrassant des détails techniques au mieu en les envoyant dans les "Effets".
2. Pouvoir facilement changer les Effects par des Effects purs et pouvoir ainsi écrire des tests déterministes et reproductibles aisément.
3. Controller "par le haut" les sous-effets disponibles dans certaines branches du code. On peut du coups facilement contraindre et voir que certaines fonction ne pourront jamais accéder à la DB par exemple.

Par contre ce système à un coût sur les performances. Je pense que le coût est négligeable dans la majorité des cas et qu'il s'agit d'"Haskell circle jerking" lorsque les gens refusent d'utiliser des systèmes d'effects pour cette raison.