barmic 🦦 a écrit 5214 commentaires

Python a plus ou moins 3 syntaxe il me semble :

• impératif avec des boucles classiques
• "fonctionnel" avec map/filter
• comprehension

Il me semble clair que le dernier est mis en avant sur les autres.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Exactement sauf que je n'utilise jamais de conjonction de bloque donc pas de {…} && {…} || {…} (c'est verbeux et piégeux, par exemple il manque un ; dans ton dernier exemple d'après mon dash 0.5.12) et j'évite les return en shell particulièrement parce que maintenant bash ne les accepte plus que dans certaines conditions.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

J'avais écris le code rapidement sur téléphone, la version vérifiée c'est :

sealed interface A {
   record B(int i) implements A {}
   record C(long l) implements A {}
}

Mais je pense avoir compris ce que tu veux dire et je me suis clairement mélangé les pinceaux entre propriété de classe et d'instances.

Sans parler de Liskov ou de subtyping behavior, à mon avis il faut avoir conscience de ce que ça contraint sur le code et qu'il faut choisir une balance entre implémenter des comportements dans les class et faire porter le comportement dans des méthodes extérieures aux classes.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Euh je vois pas. Quelle est la propriété que décrite sealed que tu peux appliquer aux filles ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Pas tellement d’accord, j’ai l’impression que c’est plutôt une utilisation du principe de liskov pour implémenter un pseudo type somme en java.

Comment l'absence de partage de trait pourrait être une utilisation du principe de Liskov ?

Si j'écris

sealed interface A {
   record B(int i) extend A {}
   record C(long l) extend A {}
}

Et si on applique le principe de Liskov, il n'y a pas de propriétés prouvable sur A a appliquer à B ou C. Le behavioural subtyping de la même façon parle d'un comportement défini dans le parent qui doit être respecté dans les enfants.

Tout le principe du sealed/switch c'est de ne pas faire porter le comportement sur le type. Je suis d'accord pour dire que ce n'est pas un viol du behavioral subtyping ou du principe de Liskov, mais c'est fait en se plaçant hors de leur champ : on retire la propriété prouvable sur le type parent.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C’est pas plutôt le Principe ouvert fermé (O de SOLID), ça ? Si c’était impliqué par le principe de Liskov il n’y aurait pas besoin de l’avoir en principe en plus.

Tu montre bien qu'il y a des recoupements entre les concepts que l'on nomme 😊

Et je ne vois pas vraiment que le principe de Liskov implique que ton code doive compiler si tu rajoutes un sous type. Le seul truc du principe c’est qu’un sous type ne doit pas casser les invariants comportementaux d’un super type.

Non effectivement il ne s'intéresse pas ou peu à l'utilisation, mais je pense qu'il s'agit d'un évitement du principe de Liskov, car l'objectif c'est de retirer des traits du parents et de les implémenter dans le code utilisateur.

Le fait que le code ne compile pas est extrêmement important et il faut vraiment y faire attention. Le type A peut techniquement être dans une bibliothèque chargée dynamiquement par exemple. L'utilisation et l'exposition de ce genre de type est plus risqué que du polymorphisme car l'arbre de type va faire partie du contrat (et pas uniquement le type parent).

Notamment parce que par principe le fait que ce soit "Sealed", justement, empêche l’extension. Le sous typage est toujours possible en sous-typant les cas connus ?

En java en tout cas oui. À noter qu'il n'est pas possible de tricher par contre. Sealed est vérifié à la compilation et à l'exécution. La jvm t'interdira de charger une nouvelle sous classe ni vu ni connu en jouant avec le bytecode.

Je n'ai aucun problème à utiliser sealed, il y en a déjà un certains nombre dans mon code de prod et je suis impatient de pouvoir enfin utiliser les switch expression avec. Mais je comprends les gens qui sont un peu orthodoxes de la POO qui voient des problèmes avec cette forme de polymorphisme (il y en a aussi dans le polymorphisme de classe mais ils ne sont pas nouveaux pour eux).

Désolé pour mon commentaire plus bas j'avais oublié de le soumettre

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Comme je le disais plus haut ça viole un principe de substitution (sans parler de Liskov) car le code appelant est conscient de l'ensemble du typage et donc que tu ne peu plus ajouter un sous type sans récrire le code qui utilise ton objet.

Je comprends que Liskov ne s'intéresse qu'à la modélisation et pas à comment ils sont utilisés, mais ici il s'agit de retirer les traits du type pour le mettre dans le code appelant. On peut effectivement dire que ça n'est pas un viol du principe de Liskov, mais c'est une manière de s'en passer. Dans des cas extrêmes, mais qui ne sont pas difficiles à trouver, tu n'a aucun trait dans le type parent.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Dans ton exemple la méthode foo doit pouvoir prendre en paramètre n’importe quel sous-type de A en respectant le contrat (sur A) de la méthode formatted, donc si formatted est implémentée correctement à mon avis on est bon pour le principe de substitution.

Si tu crée un nouveau sous type de A, ta fonction ne compile plus.

Le fais que du code utilisateur soit conscient des sous type de ses paramètres (ou de ce qu'il reçoit d'une fonction) empêche la substitution.

Mais tu veux ptete parler du principe d’encapsulation ?

On parle de typage et pas de l'état interne des objets donc je dirais que non.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

La classe mère qui liste ses classes filles d'une part et parce que c'est globalement fait pour écrire :

public String foo(A a) {
    return switch(a) {
        case B b -> "B: %s".formatted(b);
        case C c -> "C: %s".formatted(c);
    };
}

Ce qui blesse le cœur de tout ceux qui expliqueraient (non sans raison) que le polymorphisme c'est bien et qu'il faudrait une méthode décrite dans A et implémentée dans B et C. Ici le fait qu'une méthode hors de A, B ou C, cherche à déterminer le type sous-jacent de la référence a est la violation la plus classique de Liskov.

Présenté autrement : en respectant Liskov si tu crée un sous-type du type T tu devrais pouvoir remplacer n'importe quelle référence de T par une instance de ton sous-type sans changement du code qui utilise la référence. Ce n'est évidement pas le cas ici et c'est même un effet recherché.

C'est pour ça qu'il faut manier avec précaution dans un langage comme java qui utilise surtout le polymorphisme de classe et qui commence tout juste à utiliser ce genre de mécanismes (tout le monde appel ça du pattern matching, mais ça n'en est pas en java).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Le sens de la phrase c'est : les entreprises de la Silicone Valley ne feront plus de LL pas n'en utiliseront plus.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

[…] potentiellement au prix d'avoir atomise les autres transactions qui étaient potentiellement en cours dans le meme process (donc potentiellement, pas nul du tout).

En erlang les threads userlands sont appelés process (ouai je trouve pas que ce soit un super nommage) et je pense que ça de ça qu'il parlait donc ça ne devrait pas être aussi impactant.

Tu peux probablement trouver une variante de ce probleme qui ne se résoud pas en changeant l'énoncé de la question, mais dans ce cas ci, ca se résoud tres facilement.

Oui le nommage de ma fonction à l'arrache n'était pas génial et tu as mieux exprimé que moi ce que je voulais dire par le fait que c'est une question de sémantique.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il me semble que l'on a un tropisme à ce sujet. La Chine et le Brésil font beaucoup de choses qu'on ne connaît pas trop. Et pour la Chine ils ont même leurs Big tech qui font du libre à la marge quand ça les arrange à la Google.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C'est le PDG qui a décidé de passer d'une licence open source qui a fait connaître son produit à une licence non open source car plus bankable une fois le produit connu et utilisé, car ça marche pour le moment plutôt pas mal comme méthode pour maximiser le business.

Ça n'est pas un rappel, c'est le sujet de l'article.

Pour ceux qui lisent plus les commentaires que les articles. Le PDG d'Hashicorp réagi au fait que la Linux Fondation héberge le fork sous licence MPL de Terraform qui est passé sous BUSL en août dernier. Évidement qu'il n'est pas content. La phrase mise en avant vient du fait qu'il dit qu'il n'est que l'une des entreprises qui ont fait ce mouvement et il croit que si le libre « n'évolue pas » tous les acteurs finiront par faire ce mouvement.

Je pense que la question peut tout de même être intéressante posée autrement :

Il existe un mouvement depuis quelques années de logiciel qui sortent du libre comme ça. D'où est-ce que ça vient et où est-ce que ça va aller ? Et peut être est-ce qu'il y a un moyen de l'endiguer et est-ce que c'est souhaitable ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

J'ai mis trop de temps pour éditer mon message

J’ai lu une fois qu’on pouvait toujours utiliser || ou && (avec les accolades qui vont bien si nécessaires) pour remplacer, de manière fort élégante je trouve aussi, l’utilisation d’un if (et des then et fi sans lequel il n’est rien qu’une erreur de syntaxe !). Il semblerait donc que ce soit toujours possible sauf dans le cas[…]

Pour moi c'est un peu comme si tu trouve un vert très joli et que du coup tu repeins TOUT ton logement dans cette couleur du sol au plafond, fenêtres et vaisselles inclue. Il y a des cas où c'est très élégant d'utiliser ce genre de construction, mais quand on l'utilise là où elle n'a pas particulièrement de sens voir qu'elle oblige à faire des circonvolutions ça devient moche.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Sinon en dehors de ça, pour ce qui est est des constructions programmatique contre-intuitives mais souvent pratiques et concises, il y a l’utilisation du mécanisme de gestion des exceptions pour implémenter la logique du programme, c’est manifestement une chose souvent bien vue, en Python notamment, bien que ce langage se présente comme le plus « évident », le moins piégeux. Le try() … catch … n’a pourtant pas été créé comme une construction usuelle à la base !

J'ai pas compris ce que tu voulais dire.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Non, c’est plus vaste que ça, ça permet en particulier d’écrire des chaines d’appels complètes sans avoir à gérer des null en plein milieu et de couper la logique fonctionnelle avec des batteries de if.

Ça n'est pas plus vaste, c'est un choix de vouloir continuer à avoir une API fluent un peut plus loin que les Stream. Je ne crois pas que le prix en vaille la chandelle. Avoir une API fluent ce n'est pas de la programmation fonctionnelle, ça vient à mon avis d'un mélange : la programmation fonctionnelle ne connaît que des expressions et pas d'instruction et éventuellement ils ont des monades quand ils ont besoin.

Note aussi que, dès aujourd’hui, tu peux aussi utiliser l’un des trop nombreux frameworks qui permettent de gérer les null avec des annotations @Nullable / @NonNull. C’est juste moins intégré au langage lui-même.

La JSR305 est sympa même si elle mériterait d'avoir un peu plus d'amour (de la part de ces concepteurs et des utilisateurs). Elle a l'avantage d'être utilisable dans bien plus de cas.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Bof si c'est pour findAny() et findFirst(), ils auraient pu retourner des valeur null comme le fait l'API de collection. Ça me parait moins pire que de se coltiner du code des décennies alors qu'on avait déjà planifié au moment de son écriture qu'elle allait être désuète. Le plus drôle c'est que vavr utilise déjà ce genre de design avec java 7…

Dans 2 ans on aura :

• les fonctions qui retournent null
• les fonctions qui retournent Optional
• les fonctions qui retournent Neither ou un truc comme ça qui tirera profit de ce qu'on a actuellement

Ouai !…

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

A quel point la notion est utile ou même obligatoire en informatique?

À moins que ça m'échappe je ne connais pas de langages de programmation commun¹ qui ne l'implémentent pas il me semble. Mais il y a 2 manières de faire soit c'est une valeur qui est valide dans tous les types nullables (donc toute références en java, tout pointeur en C/C++, etc) soit c'est un type.

Quand c'est un type généralement le langage permet de créer des types sommes ce qui permet de créer un type « entier ou null » et ça t'oblige à vérifier que c'est un entier avant de pouvoir utiliser ta variable. Je trouve ça plus élégant personnellement.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Null n'est pas un type en java.

Ça m'embête supposé très doctrinal. Ça dépend complètement de la sémantique que tu donne. Si je compte la taille d'un message, je peux vouloir considérer que sa taille est nulle ou valant 0 qu'il s'agisse d'une chaîne vide, d'un champ absent ou d'un champ ayant pour valeur null ou undefine si c'est représenté par du json par exemple. Multiplier les chemins d'exécutions pour ça n'a pas de sens et planter pour relancer le processus est un bug : une valeur nulle n'est pas synonyme d'erreur.

Penser que les choses ont un sens intrinsèque et que ton modèle est universel est à mon avis une erreur pas lié au langage ou à la stack utilisée.

Tu peux vouloir éliminer les valeurs null en les représentants dans ton typage et c'est très bien, tu n'a plus à avoir ce genre de garde dans tes fonctions mais c'est pas une absence de programmation défensive, elle est déplacée aux entrées de ton programme. Mais ça ne me paraît pas pertinent si le langage ne permet pas de l'exprimer. Java ne le permet pas et il me semble qu'erlang non plus toute références peuvent être nil il me semble.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ça n'est pas forcément un cas exceptionnel.

Tu peux vouloir écrire :

int size(String str) {
    return str == null ? 0 : str.size();
}

Mais sinon c'est une option à prendre en compte : ne rien faire et laisser l'exception arriver. Maintenant que les NullPointerException donnent (enfin !) des informations sur ce qui était null. Ça vaut le coup de laisser faire le langage naturellement.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Sealed c'est un moyen de contrôler l'héritage d'une classe ou d'une interface.

Jusqu'à l'arrivée de sealed on avait le mot clef final qui indiquait qu'une classe ne pouvait avoir de fille. sealed permet d'indiquer la liste exhaustive des filles direct d'une classe. Dans l'exemple au dessus, Optional<T> n'a que 2 soustype Present et Absent.

Ça peut être assez déroutant parce que ça contreviens au principe de substitution de Liskov, mais c'est pratique pour certaines choses. Ça ne doit pas être utilisé pour tout, mais pour des cas où on sait qu'on a un arbre de types limité qui ne devrait pas évoluer sans que le code qui l'utilise le prenne en compte.

Imaginons (je tire l'exemple de mon chapeau c'est peut être pas un bon exemple), tu veut gérer une machine à états finis, mais ça t'arrangerait que l'état soit plus qu'une simple valeur (donc pas un enum) par exemple pour aider au debug. Tu peut alors créer une classe ou une interface et dont tu sais que toutes les filles direct représente un état de ta machine.

L'intérêt c'est de pouvoir utiliser ça avec le pattern matching et les switch expressions, puisque tu va pouvoir manipuler ton état tout en garantissant l’exhaustivité des cas. Si tu ajoute un nouvel état c'est un nouveau sous-type et tu devra l'implémenter dans tout les endroits où tu a eu besoin de traiter tes états.

Une autre manière de voir c'est de s'en servir comme un type somme du pauvre. Tu peut créer un type T qui est soit A, soit B, soit C,… et écrire des fonctions qui sont polymorphiques sur leur paramètre (tu prend en paramètre un type T et en fonction du sous-type tu réagi différemment). Du pauvre parce que les sous-type ne peuvent pas être arbitraires comme tu le ferait en haskel.

Je suis un peu loquace ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

J'aime beaucoup perl pour ça :

condition or die "Arg !";

et je le reproduit en shell quand le cas se présente en écrivant ma propre méthode die()

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je n'ai jamais compris pourquoi ils ont implémenté Optional aussi tôt… Ils avaient déjà l'idée de ce qui allait se faire et aujourd'hui je trouve que c'est une classe qui utilise mal le langage. À mon avis Optional devrait être une interface sealed implémentée par un record disons Present et une classe (voir un singleton) Absent. Il ne devrait pas y avoir de méthode get() et l'interface ne devrait porter que le méthodes qui en font une monade. Tu aurais une classe dont aucune des méthodes ne peut lever de NPE et au lieu d'avoir tous les analyseurs statiques qui doivent tenter de vérifier si tu utilise get() dans un endroit sûr ce serait vérifié dans le langage par le typage (et pour le quel l'inlining peut rendre ton code efficace). Et tu n'aurait plus besoin de la méthode get() grâce au pattern matching (qui n'en est pas vraiment un en java). On va garder encore 20 ans une classe qui aura finalement rapidement était hors de ce que Java peut produire.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Pour moi aussi c'était une référence en non https, mais je pense plutôt que le domaine a était perdu et que DreamHost fais des redirections https dans ce genre de cas.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu compte l'argent en mille romain ? :p

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll