barmic a écrit 927 commentaires

Ce n'est pas la première fois que je vois des francophones sortir la version anglaise de commitstrip, je ne comprends pas bien pourquoi. Les non-francophones qui après une suite de commentaires en français seront arrivé jusqu'à ton commentaire ? Ou juste parce que « ça fait mieux » de parler anglais ?

Comme il est impossible d'implementer la norme correctement (meme Microsoft n'y arrive pas en dehors du client lourd historique), ce que tu dis est faux.

Tu avance une impossibilité et en déduit que ce qu'il dit est faux. Il y a beaucoup trop d'arguments dans ton assertion… Le fait qu'il y ai des bugs n'indique pas une impossibilité, hein ?

imposer de force des trucs pourris

Ils n'utilisent que la force ? Ils font pas des menaces en plus ?

1- "délivre" le résultat des instructions dans leur ordre exacte d'arrivée. Sinon c'est le bordel, mais il va essayer en interne (c.a.d. de façon invisible ou de façon transparente pour le programme exécuté), de paralléliser, d'anticiper les branchements et tout un tas de conneries comme prefectcher les instructions, ma memoire, le TLB ou que sais-je.. c'est totalement traçable, prévisible et tu peux essayer de voir l'état interne du processeur, à tout instant.

Je ne sais pas ce qu'est "délivre" et quel est le point d'arrivée, mais le fait que les CPU soient out of order et que les programmes soient préemptables me donnent l'impression que dans l'usage courant cette propriété n'est pas exploitable. Je vois pas le besoin d'en faire un si grand cas.

J'ai l'impression que tu décris plus des propriétés qu'une définition. Je suis retourner chercher sur wikipedia et il explique que ordinateur vient de « celui qui ordonne » (il n'y a pas de présupposer sur la manière d'ordonner), mais j'avoue que vu comment fonctionne (du peu que j'en comprends) une machine quantique je trouverais sympa que ce soit le désordre. Mais je ne vois pas de problème à parler d'ordinateur. L'ordre des ordinateurs me semble plus faire référence en le respect de la causalité et je ne crois pas avoir entendu dire que la mécanique quantique remettais en cause la causalité.

Déjà utiliser le terme ordinateur, pour désigner ces machines, (ou calculateur) prouve que personne ne comprends vraiment le gap qu'il y a avec un ordinateur classique. Ordinateur renvoie a l'idée instructions ordonnancées ce qui est vraiment on ne peut plus trompeur pour une machine quantique.

Qu'entends-tu par ordonnancer ? Les ordinateurs actuels exécutent les instructions de manière non déterministes (ou plus précisément déterministe avec un ensemble de paramètres d'entrée totalement hors de notre contrôle).

Tu peux donner des exemples ? car à part l'introspection, j'ai du mal a voir ce qu'il manque par rapport au java (au niveau des capacités du langage)

Une bibliothèque standard ? Je taquine. Un troll sur les langages le jour de la pentecôte me paraît approprié.

Tu décris déploiement continue. C'est un Graal, mais ça n'est pas donné à tout le monde.

Personne ne ressent d’intimidation ou de l’hésitation quand il/elle s’exprime.
Chacun dit ce qu’il/elle pense être utile au projet.
Et personne ne bloque l’idée d’un(e) autre.

C'est un point rarement vu dans l'agilité mais c'est très important. C'est le psychological safety. C'est super intéressant, mais ça ne se décrète pas. Les turnovers et la méthode d'embauche peuvent être importante (par exemple impliquer l'équipe dans le processus d'embauche).

en fin de journée, un dernier clavardage permet de faire un débriefing de la journée, si besoin on prévoit une réunion plus formelle pour résoudre une problématique plus complexe.

Ça me paraît compliqué à tenir. J'aurais peur que des retro trop informels (et trop régulière) empêchent de se poser, regarder en arrière, avoir du recul et que ça devienne du aussi vite terminé aussi vite parti (d'autant plus quand c'est en fin de journée…). J'insiste, je ne dis pas que ça ne marche pas, juste que c'est ce dont j'aurais peur.

Ça peut être posé à l'opposé pourquoi écrire un projet en C++ aujourd'hui, plutôt qu'en python et ne coder que la partie qui prend de la puissance de calcul/mémoire en C++ ?

Ça peut faire l'affaire :)

Les défauts que je vois :

• c'est beaucoup moins agréable pour faire des proxies génériques. Par exemple le cas d'un circuit breaker. L'algo autour de ton appel est le même pour tout tes appels. Dans ton cas si tu peut factoriser cet algo tu va tout de même avoir un boiler plate pour chaque méthode proxifiée
• encore avec mon exemple du circuit breaker : tu as un couplage dans un sens, ce qui empêche d'avoir le proxy dans une bibliothèque. C'est un aspect très contraignant dans les langages statiques, mais c'est très agréable à l'usage de ne pas avoir ce couplage (oui ça a un coût non négligeable)
• évidement ça ne marche que pour les méthodes virtuelles des classes non final

Je pense sincèrement que c'est l'un des cas où l'AOP a du sens (je suis contant d'avoir trouvé un cas d'usage amha pertinent à l'AOP :) ). Ça permet de remplir tous les critères : souplesse d'un langage dynamique sans aucun coût à l'exécution.

Merci sincèrement pour l'exemple qui peut être pertinent dans beaucoup de cas.

Et on touche du doigt l'un des gros problèmes de la FSF à mon humble avis. Quand rien (ou presque) est assez bien au sens de la FSF, ils deviennent inaudibles. Il n'y a pas de nomenclature clair qui distingue Windows, Debian, OSX,… Ils sont tous non libres. Quand on regarde dans les détails oui ils décrivent plus précisément les problèmes de chacun et on verra une liste bien plus grande pour Windows et OSX que pour Debian (on peut même utiliser une Debian libre en suivant quelques conseils). Mais ça ne rend pas particulièrement clair la chose.

À force de crier systématiquement, on perds l'amplitude permettant de lever une alerte quand le problème est plus grave. La FSF qui est une organisation pouvant en principe faire du lobbying n'est plus du tout en mesure de discuter avec le reste du monde. Ils posent leur ligne et ne sont pas dans la discussion.

C'est peut être utile, mais ça ne peut pas fonctionner sans avoir des organisations bien plus pragmatiques qui donnent la possibilité d'aller vers le libre.

Pour continuer dans ce sens : "non libre" ne veut pas dire "c'est mal".

Ils ont tout de même tout un discours pour expliquer que "non libre" ce n'est pas éthique.

Je pose cette question pas tant pour faire avancer le débat que pour voir s'il n'y a pas quelque chose qui m'échappe…

Le découplage entre le proxy et l'objet proxifié. Tu peux vouloir proxifier des objets d'une bibliothèque dont tu n'a pas la charge du code source et tu voudrais alors que l'évolution de cette bibliothèque ne te coûte le moins possible (ajout, suppression, changement des méthodes de cet objet).

De l'autre coté d'un point de vu utilisateur le fait que l'objet soit proxifié devrait être transparent (par définition un proxy doit avoir un contrat équivalent, sinon c'est un adapteur). Donc tu ne devrais pas toucher au typage pour ça.

Ce sont 2 grosses contraintes mais elles donnent une grande flexibilité et ce n'est pas des cas théoriques. Spring est très largement basé sur des proxies par exemple (il ne le fait pas comme ça, mais s'ils pouvaient ils le ferraient).

Dans les autres façons de faire que je vois il y a :

• utiliser de l'AOP, tu patch le code ou le code généré
• utiliser MOP de groovy (mais le __call() de php peut faire la même chose) intercepter les appels vers ton objet
• java possède une API spécifique aux proxy

Cependant le type de l'objet va changer (i.e. ce sera celui du Proxy) et donc il faudra que tes fonctions acceptants l'objet initial puisse accepter le nouveau. Si tes fonctions sont initialement "templatées", c'est faisable, sinon, c'est mort. Point de plus pour le langage dynamique.

C'est pas le dynamisme qui joue là, mais le stypage structurel/duck typing.

Le type d'une fonction étant défini juste par ses arguments / valeur de retour, si ton proxy à la même interface, cela passera sans problème.

Elles bénéficient d'un typage structurel. C'est la forme de la fonction qui donne son type et pas son nom. On peut imaginer des langages où tu peut définir le type injectionInt qui est un type de fonction qui pour tout entier te renvoie un entier et qui t'obligerais à déclarer des fonctions add, mult,… comme étant du type injectionInt. Tu n'aurais plus de typage structurel et les même problèmes qu'avec les objets.

Cependant cela demande de penser son interface en avance et c'est donc moins souple. De mon expérience, je suis rarement limité par ce point, mais j'admet cette limitation.

C'est un usage qui arrive pour ceux qui font de grosses bibliothèques (injection de dépendance par exemple).

Merci de m'avoir fourni un exemple valide de l’intérêt d'un typage dynamique.

De rien :)

Effectivement j'ai oublié un mot. La syntaxe est généralement, surtout pour les usages interactifs classiques, compatible (contrairement à tcsh par exemple).

He ben voila c'est le premier commentaire qui répond autre chose que « OOXML saynul ! ». J'ai utilisé un mot particulièrement fort pour tenter de garder le sujet sur ce que l'on est sensé s'interdire de parler ou non sur linuxfr et pas sur est-ce que OOXML est bon ou pas.

«Ne pas promouvoir» n'est pas «refuser d'en parler».

Promouvoir tu ne pense pas que c'est fort comme mot ? On a pleins de cas où on parle de formats qui ne devraient pas plaire : PDF, ntfs, flash,… Parler d'un concurrent n'est pas manquer de respect aux autres concurrents (effectivement quand tu parle de sophisme, tu sais de quoi tu parle).

Dans le même commentaire tu nous dis que la documentation d'OOXML fait semble grande et de l'autre que ce n'est pas documenté.

Mais surtout tu parle d'éthique et ça devient un débat purement philosophique et ça mène à des débats sans fin. D'autres bien plus légitimes que toi ou moi en ont parlé ici. La définition même d'éthique reste un gros débat. Ne pas avoir d'humilité sur le sujet et non seulement se pointer en s'imaginant avoir LA bonne raison et en plus vouloir l'imposer aux autres ne me semble pas pertinents. Il y a suffisamment d'arguments contre OOXML pour ne pas avoir besoin d'invoquer ce genre de choses AMHA.

La syntaxe de zsh est compatible avec celle de bash.

Ce format est une bouse enorme, comme les documents crées avec mais bon si cela te convient c'est cooooool.

Sérieux… il y a un moment on a l'impression de parler à des collégiens. Je n'utilise ni ODF, ni OOXML, ni le format d'Abiword ou de je ne sais quel autre suite bureautique. Je n'en ai pas le besoin et je m'en porte très bien. Je n'aime aucun de ses outils et aucun de ses formats. À l'usage je ne trouve pas ça agréable sans être allé me farcir le pourquoi techniquement ils sont intéressants ou pas. Encore une fois mon point de vu n'est pas de savoir si OOXML est bon ou pas, mais de ne pas rendre tabou des logiciels libres sur linuxfr.

Vous jouez à vous faire ostensiblement vomir dès que quelqu'un dit "OOXML" faut vraiment vous poser des questions sur la mentalité qui mène à être aussi obtus. Encore une fois la qualité d'OOXML n'a jamais était la question dans aucun des mes commentaires.

Il y a une différence entre en parler en en faire l'apologie.

Tu vois ça où ?

Bref, comparer ce qui est comparable, quand on accepte des impacts de l'autre côté. Juste qu'en C++, la perte de perf est optionnelle ;-).

AMHA tu te trompe de comparaison. Sinon en comparant ce qui est comparable, tu peux implémenter le runtime python en C++ et là tu es comparable. Il me semble que la démarche que nous poursuivions avant que tu arrive consistait à comparer les pratiques dans divers langages. Dis autrement on tente de répondre à la question : « Comment est-ce que les développeurs python et C++ s'assurent de la qualité de logiciel ? » (ce qui est différent de la question « Comment on peut réimplémenter l'un dans l'autre »¹). Je ne vois pas en quoi ça ne serait pas comparable.

Je doute que les développeurs C++ laissent l'instrumentation asan en prod. Ça pose tout de même un sacré paquet de problème. Et au contraire je ne vois pas en quoi une instrumentation qui va alerter et/ou crasher ton programme serait équivalent à un runtime qui gère la mémoire pour toi.

OOXML serait le diable en personne, je ne vois pas pourquoi s'interdire d'en parler. C'est quoi cette idée de vouloir créer des tabous comme ça ? On parle d'un logiciel libre qui gère ce format, ça a l'air de te déplumer, mais ça existe, pourquoi est-ce qu'on s'interdirait d'en parler ? Que tu le veuille ou non il y a des gens qui doivent interagir avec ce format.

Les aspcts sont une façon d'implémenter des proxy, mais ce n'est ni la seule façon ni la façon la plus logique.

En java standard tu as la classe Proxy par exemple (qui fait grand usage des RTTI). Spring implémente ces proxies soit via Proxy soit via de l'AOP (AOP par défaut depuis la version 5).

Au dessus il est question de groovy, le metaobject protocol peut aussi servir à ça.

Qui est un langage dynamique :p

Mais je ne dis pas qu'il n'existe pas d'autres façon de faire. Par contre la solution que tu montre ne permet pas (il me semble) d'ajouter du code autour des appels délégués.

https://linuxfr.org/users/oliver_h/journaux/moi-expert-c-j-abandonne-le-cxx#comment-1773668

Le sujet c'est quelqu'un qui ne veut pas qu'on parle sur linuxfr d'un logiciel libre qui manipule un format standard mais dont une partie hors du standard n'est pas documenté.

Même si ooxml était totalement fermé, je ne vois pas pourquoi on s'interdirait de parler d'outils libres qui le manipule. On l'a déjà fait.

Vous tentez une vendetta contre ooxml avec des arguments qui frôlent le FUD. Dire qu'il n'y a que des logiciels non libres qui peuvent le lire dans un thread qui demande à ne pas parler des logiciels libres qui le lisent. Ça n'est clairement pas correct.

Je trouve donc assez incroyable d'appeler ça un "standard ISO".

Et

Ma principale remarque était de dire que par sa conception le format OOXLM n'était pas un vrai standard ISO.

Ça ne te plaît pas, mais par définition c'est un standard ISO. Ce test pas un avis, mais un fait.

Ça l'est : tu veux faire du polymorphisme ad-hoc; mais je ne vois pas où on a besoin de typage dynamique pour cela.

Mon exemple utilise un langage avec un typage statique ;)