barmic 🦦 a écrit 5919 commentaires

À quoi ça sert ? Je veux dire la manière de répondre à ça c'est du chiffrement de bout en bout. C'est pas "simplement" omemo qui répond à ça ?

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

mais je pensais que les guillemets autour suggéreraient que je ne lui donnais pas son sens premier

Les mots gardent du sens. C'est un peu comme une prétérition. Le fait de lâcher un mot n'est pas anodin même avec tous les guillemets du monde.

Quelqu'un peut arrêter son activité sans te devoir d'explication à toi commentateur des internets.

et la suite de ton message : je ne comprends pas ce procès d'intention à mon égard.

Il s'agissait d'un "toi" impersonnel, mais oui tu commence à parler de son incompétence (ou peut être sa maladresse) - ← tu ne vois pas ici la hiérarchisation des qualificatifs ? - alors que tu n'a aucune once d'information pertinente pour en juger même pour le moins sévère. J'imagine qu'affirmer ce qu'elle aurait dû ou pas faire, pour ses affaires dont tu ne sait rien, était une tentative de disqualifier les hypothèses qui n'étaient pas la première que tu as eu.

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

fermer un site pour cette raison ne marche pas : ça va plus alimenter la polémique qu'autre chose, en particulier dans une communauté tech (Effet Streisand)

Parce que tu parle encore de cacher alors que je parle d'arrêter de se faire insulter. Ce serait comme les gens qui ferment leur compte twitter par harcèlement. Encore une fois je n'en sais rien, je dis juste qu'une simple fermeture ne me permet pas de savoir. Si elle subi ce genre d'agression je serait surpris que ça ne soit pas énoncé pour exprimer publiquement des soutiens, mais en même temps si l'alt-right s'est chauffé ça ne m'étonnerait pas que ça lui arrive.

Ça pourrait, bien sûr, mais faire comme ça n'est pas une méthode "correcte" : cet arrêt de ces autres activités n'est pas annoncé sur ses autres pages, et son site perso pourrait juste annoncer simplement cet arrêt, pas indiquer qu'il a été désactivé : ce n'est pas bien pour ses anciens clients.

D'une c'est ton avis que c'est correct ou pas et de 2 tu ne sais pas. Elle a peut être un CRM qui lui a permis de contacter ces clients sans passer par une annonce publique. Quelqu'un peut arrêter son activité sans te devoir d'explication à toi commentateur des internets.

Après, bien sûr, avec les informations à ma disposition, je ne peux aussi que formuler des hypothèses, ou dans le cas présent soulever des questions.

Non pour moi ce n'est pas ce que tu fais. Tu a un à priori et tu regarde les éléments au travers de ce dernier. Tu émet un avis en ayant choisi au départ une raison pour ces fermetures. Tu continue d'émettre un avis quand tu lance l'idée de son incompétence bien sûr en faisant mine de ne pas y toucher.

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

[…] du fait de la mise en "fermeture" de ses pages en lien avec cette activité est douteux.

Je suis pas sûr qu'on puisse trop avancer de choses sur les raisons de ces fermetures. Est-ce que le travail chez Gnome lui fait arrêter ces autres activités ? Est-ce que la médiatisation a ramené des vagues de trolls à son encontre ?

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

Pour illustrer le "c'est pas parce qu'il existe déjà une façon de faire qu'on va pas en créer une autre", en perl, tu peux écrire :

cond and b()
cond && b()
not cond or b()
not cond || b()
if (cond) b()
b() if cond
unless (not cond) b()
b() unless not cond

Je dois évidemment en oublier, il n'y a pas de forme intrinsèquement supérieure, mais elles tour à tour être plus pratique ou exprimer de manière un peu plus naturelle l'intention (naturelle pour celui qui code au moment où il code).

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

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