Fork me on GitHub
#clojure-france
<
2021-04-19
>
Yehonathan Sharvit04:04:50

Salut les gars, je sais qu’il est tot en France mais je ne peux pas m’empecher de vous donner matiere a reflexion pour votre cafe du petit dej! Je viens d’ecrire mon premier article en francais. Il est en mode draft pour l’instant. J’aimerais avoir votre avis ainsi que vos idees d’amelioration avant de le publier. https://blog.klipse.tech/dop/2021/04/18/memete-programmation.html

Yehonathan Sharvit12:04:06

Allez les gars. Un petit effort. L’article n’est pas tres long ^^^

😛 3
jeremie16:04:16

Bravo Yehonathan pour ton article et tes efforts pour diffuser les idées du Data-Driven Programming 👏 c’est précieux 🙏 En math et en prog fonctionnelle, une valeur est intangible c-à-d qu’elle existe en dehors du temps et de l’espace (donc exit les problèmes liés à l’espace - l’unicité - et le temps), un objet ou plus précisément une entité existe dans le temps (et prend différentes valeurs dans le temps) et l’espace (une seul entité existe à un seul endroit, de même les algos de consensus font que l’entité existe dans l’espace distribué mais en fait ce sont juste des copies synchronisés par consensus). Je pousserais plus le parallèle avec le bateau de Thésée : • prog objet : l’entité c’est le bateau, les différentes mutations font que l’entité change avec son état qui change mais son identité reste la même. “le bateau de Thèsée” c’est l’identité alors que la réalité, le monde, change. Une identité (“le bateau de Thèsée) est un outil mental qui superpose une continuité au-dessus d’une série de valeurs dans le temps (les pièces du bateau qui change). • math et prog. fonct : pas de notion d’entité (et donc de temps) c’est à nous d’introduire ce concept (Entité = identité + état représenté par des valeurs) et c’est souvent là que les problèmes commencent (chgt d’état concurrent, quid des précédents états de l’entité ? implicitement on est toujours sur le HEAD de l’entité) > Ce qu’il entend par un objet, c’est une entité ayant un ensemble d’attributs à un moment donné. Alors qu’une valeur est une entité qui ne change jamais. -> Une valeur ne change jamais…par définition my 2 cents

cgrand16:04:51

Et les entités composites ? L’exemple classique de l’équipe de foot.

jeremie16:04:46

Pour moi une entité composite peut avoir une identité qui est la somme des entités qui la compose. Son état étant la somme des états unitaires. Ce qui est plus intéressant c’est le comportement que l’entité composite expose, en DDD c’est dénommé un Aggrégat (terme un peu confusant car beaucoup y voit juste une composition) car l’entité racine (l’équipe) maintient un invariant (on pourrait dire un prédicat) sur l’ensemble de ses composants et c’est cela qui est essentiel : comment garantir la cohérence des entités entre elles exprimée à travers cet invariant ? Ce qui impose que toute action changeant l’état de l’aggrégat passe forcément par la racine pour maintenir cet invariant, les composants ne peuvent être accédés qu’en lecture seule. Ex : une voiture est composé de 4 roues et d’un moteur, l’état de la voiture contient le kilométrage, si on maintient également le kilométrage de chaque roues et du moteur, ceux-ci sont mutés par la voiture pour maintenir l’invariant (km roues = km moteur = km de l’aggrégat voiture).

cgrand20:04:58

La notion de racine (et en plus de sa responsabilité dans le maintien des invariants) est très hiérarchique/objet.(Clojure est hiérarchique/valeur tendant vers le relationnel si Datomic et cie. Après mon credo actuel est que toute modélisation héirérachique est problématique...).