barmic a écrit 927 commentaires

Je vois pas le lien entre la qualité d'OOXML et le fait de ne pas vouloir parler de logiciel qui travail avec. ASN1 c'est tout pourri et on accepte de parler d'OpenSSL.

Il me semble que c'est plus compliqué que ça car oui l'OOXML est un standard ISO mais qui permet l'insertion de blob binaire non-libre.

Non-libre ? Tu parle d'insérer un exécutable ? Je ne sais pas si c'est possible.

À partir de ce moment, cette partie du document ne peut pas être décodée par un logiciel libre.

C'est des blob binaires copyleft ? Ils imposent leur licence aux logiciels qui les entours ? On voit ça plus ou moins dans les DRM.

Firefox accepte ou a accepté pendant longtemps l'ajout de blob binaire non libre. Est-ce qu'il faut arrêter de parler de Firefox ?
PDF permet l'ajout de blob binaires, est-ce qu'il ne faut pas parler d'evince, xpdf, etc ?

Ce n'est pas parce que c'est un standard ISO que c'est automatiquement conçu avec de bonnes pratiques. Pour moi si un standard ISO ne peut être lu par tout le monde ce n'est plus standard, mais bon, je peux me tromper :)

Un organisme de standardisation de renom, suffisamment important pour que tout le monde ce soit félicité de la documentation par celui-ci de l'OpenDocument l'a reconnu. On peut considérer que l'ISO n'est pas un organisme de standardisation valable, mais ça remet aussi en cause la standardisation de l'OpenDocument. On se retrouve alors avec 2 formats aucun des 2 n'est reconnu par un organisme de standardisation valable, mais l'un des 2 est beaucoup plus utilisé que l'autre. Je ne suis pas sûr que ce soit en faveur de ta paroisse.

Il y a une approche qui peut être très intéressante pour ça.

• tu lis le fichier et le charge en mémoire dans ta structure interne
• l'utilisateur fais les modifications qu'il veut
• au moment de sauvegarder tu regarde ce qui a était modifié et tu n'applique que ces changements

C'est compliqué à faire, mais ça permet de ne pas exploser le formatage de la 15ème page du document sous prétexte que tu as modifié une typo dans le titre de la première page.

Et dans ce cas il n'y a pas de conversion.

OOXML est un standard ISO, je vois pas pourquoi en faire un tabou.

ASAN et BSAN de g++ et clang++ font 95% pourcent du boulot de valgrind, sans les problèmes de performances, et sans la complexité de mise en oeuvre.

Si je comprends bien ça reste runtime. Je présume que ce n'est pas utilisé pour du code de prod, il faut passer les tests avec l'instrumentation qui va bien. Même si c'est cool, ça reste une classe de bug que l'on trouve en C++ et qu'on ne trouve pas en python.

Pour le typage structurel, on peut tout à fait faire cela statiquement et sans écrire d'annotation.

C'est ce que fait go. Typescript a un typage structurel vérifié à la compilation, mais il est optionnel.

Enfin, pour ce qui est des objets et du typage structurel, la façon dont ils sont globalement utilisés en pratique cela en fait surtout des modules du pauvre. En OCaml on utilisera plutôt des modules, en Haskell des type classes, en Rust des traits et en C++ des template.

L'intérêt c'est de pouvoir avoir un polymorphisme qui ne soit pas nommé. Quand on veut créer une méthode qui va manipuler des données qui ont un id qui est un UUID par exemple. Le typage structurel peut permettre d'avoir des données qui ne sont pas liées entre elles, mais qui possèdent toutes un id de la bonne forme.

Je ne connais pas les autres, mais je ne suis pas certains que C++ permettent d'être aussi souple que go. En go (et c'est pour moi le gros intérêt), ta structure n'a pas a connaître la structure nécessaire à ta méthode pour être utilisable.

package main

import "fmt"

type User interface {
    Greeting() string
}

type Plouf struct {
    FirstName, LastName, Addr string
}

func (p Plouf) Greeting() string {
    return fmt.Sprintf("Dear %s %s", p.FirstName, p.LastName)
}

func Foo(u User) {
    fmt.Println(u.Greeting())
}

func main() {
    u := Plouf{"Matt", "Aimonetti", "chez moi"}
    Foo(u)
}

Le type Plouf n'a aucun rapport avec l'interface User. Ça permet d'écrire après coup des fonctions qui définissent des interfaces décrivant le contrat que doivent remplir leur arguments sans impact sur les types créé ailleurs. Dans l'usage on peut généraliser une fonction à un ensemble de type qui sont dans différentes bibliothèques. Je sais pas si c'est très clair…

En java je fais un hack a coup de lambda pour ça.

C++20 est toujours compatible avec C++98, tu ne réécris pas pour le plaisir de réécrire. Tu migres lentement la code-base pièce par pièce en utilisant les nouvelles fonctionnalités du C++ moderne quand requises.

C'est ce que j'appelle une réécriture. J'ai pas dis que c'était fais d'un bloc. Je dis que tu es passé partout pour passer ton code de C++ non normalisé à C++98 puis de C++98 à C++11. Tu as eu un travail spécifique de montée de version de ton code. Et c'est pas une critique c'est normal. C'est juste que quand on vient me dire qu'une base de code est maintenu depuis 30 ans, le maintiens d'une base de code ça consiste à la faire évoluer qu'il a fallu prendre en compte au moins C++98 et C++11 etc.

Boost.UnitTest ou Catch2 permet d'écrire des tests en 5 lignes de code.

Je n'ai même pas besoin d'aller voir ce qu'ils font exactement pour savoir qu'on ne parle pas de la même chose. Avoir un runtime de test c'est un premier point, mais il y a un paquet d'autres choses qui peuvent aider :

• une bibliothèque de mock, ne pas dépendre d'une base de données ou d'un brocker de message pour exécuter tes tests est très utile
• une bibliothèque de génération de données, ça permet de construire bien plus rapidement les inputs de tes tests. nbuilder du monde .Net ou faker.js sont pas mal pour ça
• avoir une bibliothèque d'assertions ce qui permet de se rapprocher de test de propriétés (de tester des nombres à virgules flottantes, du temps, des structures complexes,…).

Après le runtime de tests peut aussi servir à créer des tests suites et de faire des tests paramétrés, générer des rapports pour des outils comme sonarqube.

De ce que j'en vois Boost.UnitTest et Catch2 font des choses bien, mais ils sont loin de faire toutes ces choses.

Le duck typing n'apporte rien ici, le duck typing et le typage dynamique ont généralement l'effet inverse. Ils rendent nécessaires des batteries de testes larges et complexes pour gérer le large eventail d'input / possibilité que le duck typing autorise sur ton code et tes fonctions.

Le duck typing consiste a vérifier que la référence que l'on te donne possède les propriétés nécessaires à ce que tu en fais. C'est le typage dynamique qui rend la chose plus difficile. Mais c'est clairement une aide au mocking.

5 ans en arrière j'aurai dit oui. Aujoud'hui je dis non.

Oui ça aura mis du temps à arrivé, mais la situation s'est bien amélioré. Je l'ai découvert ici en discutant.

Je pense que l'exemple le plus parlant sera le proxy.

Le proxy en POO c'est le fait de créer un objet qui s'utilise comme l'objet proxifié. On utilise le proxy sans savoir qu'il s'agit du proxy et pas de l'objet d'origine. Le proxy va pouvoir faire quelque chose avant, après et/ou à la place de l'objet qu'il proxyfie.

Il peut y avoir différents cas d'usage à ça : ajouter un cache à un objet, faire des vérifications de sécurité, mettre en place un circuit breaker, avoir du log, mettre en place un pattern stratégie,…

Pour faire ça en POO tu as besoin de faire de la délégation, mais j'ai pas vu beaucoup de langages courants qui permettent vraiment de faire de la délégation propre. Avec un langage dynamique, c'est assez simple à mettre en place.

Il existe d'autres façons de faire (java a une API de proxy par exemple), mais c'est un point qui est tout de même facilité par un typage dynamique.

Ce que tu dis sur le RTTI est peut-être juste, mais je te trouve agressif dans ta réponse.

Tu m'en vois sincèrement désolé, ce n'était vraiment pas mon objectif. J'ai essayé d'apporter réellement quelque chose dans mes commentaires. Notamment on assez peu de gens qui explique à quoi sert un typage dynamique par ici, donc ça me paraissait intéressant. Si j'ai paru agressif ce n'était pas du tout mon intention.

Que donne ce petit bout de fonction ?

Il crée 2 entiers en outrepassant le cache d'entier donc leur référence n'est pas égale. En incrémentant chacun d'eux on utilise le cache donc leur référence deviennent identiques. En incrémentant une seconde fois, on sort du champ par défaut du cache d'entier donc leur référence est différente.

Pour être franc, j'avais plutôt en tête les langages fonctionnels (OCaml, Haskell), mais je répondais surtout à la question de savoir si le typage pouvait éviter de faire des tests ou non.

Oui mais tu réponds à une comparaison entre C++ et python. Donner un exemple pourquoi pas venir dire que le langage foobar lui il est mieux, c'est hors sujet.

Je ne vois pas trop où tu veux en venir quand tu dis : avec le typage dynamique on a beaucoup plus d'informations de typage au runtime (ou alors j'ai peur de comprendre ce que tu proposes. Mon avis personnel est que le typage dynamique induit des risques et ne garantie pas que le programme soit sûr, mais c'est un autre débat dont il n'est pas l'objet ici).

Le RTTI pour parler avec des termes plus précis. Le typage dynamique ne convient pas à toutes les situations et certaines approches statiques peuvent résoudre des problèmes auparavant traitées par le typage dynamique, mais il y a des fois où tu ne peux faire que peux d'hypothèses sur les données d'entrées par exemple, d'autres fois tu va vouloir cloner une structure sans pour autant la connaître initialement, tu as aussi des approches qui vont se rapprocher de l'AOP ou des proxy qui peuvent être infiniment plus simples,…

La question n'est pas de savoir si toi ou moi on aime ça (j'aime le turquoise, je présume que ça te fait une belle jambe), mais de savoir à quoi sert le typage dynamique et donc comment s'en servir et quand est-ce qu'il est pertinent. Le plus mauvais système de type, c'est celui qui est mal utilisé.

Tu utilise l'une des approche du typage celle du typage statique et oui on peut encoder potentiellement ce que l'on veut dans les types et le typage est prouvé par le compilateur.

Là où une approche structurelle plutôt que par nom se démarque c'est que l'approche structurelle ne regarde pas la forme de la donnée en mémoire mais les propriétés qu'elle possède. Si je peux appeler les la méthode foo() sur ta variable on ne s'intéresse pas à qu'elle est la forme de cette donnée. C'est une souplesse qui est très structurante et elle évite d'avoir des arborescences de classes complexes et pas toujours pertinentes. On peut le vérifier dynamiquement comme en python ou statiquement comme en go.

Avec le typage dynamique on a beaucoup plus d'informations de typage au runtime. C'est très utile quand tu fais des programmes configurés par les données par exemple.

Après tu parle de cas général le typage du C++ est relativement pauvre, on peut faire des circonvolutions pour tenter d'encoder des choses en plus dans les types à coup de templating, mais plus aucun humain ne sera en mesure de reprendre le code en question.

Il y a tout un tas de test que tu fais en python qui sont simplement inutiles en C++ du fait du typage statique de C++.

Le typage ? Tu n'écrit pas un test en python pour vérifier ton typage. Sinon c'est que tu n'utilise pas l'outil comme il faut. Le principe même du duck-typing fais que la notion de type n'a rien à voir et que tu ne fais pas les mêmes hypothèses sur ce qui t'es donné. La vérification du type n'est qu'un effet de bord de tes tests fonctionnels.

Par contre on ne teste pas la cohérence de la mémoire en python. Donc pas besoin de valgrind et vu la complexité de mise en place de valgrind (il faut jouer des scénarios etc). Je pense que tu y gagne.

Il existe aussi des outils pour t'aider à améliorer ton code (il te propose même de patcher ton code directement).

Trop cool ! J'espérais voir apparaître un outil comme ça avec llvm l'ouverture de gcc, ils ont fini par le créer c'est super. Il est même capable de te pousser à faire du code moderne c'est parfait :) La dernière fois que j'avais cherché je n'avais rien trouvé.

Je comprends ton point, je dis juste qu'il te suffit de regarder plus haut ou plus bas pourvoir un certains nombre d'exemples de développeurs qui n'ont pas envie de toucher à cette base de code. Ils sont prêt à changer de boulot plutôt que d'y toucher. Le manager fait bien ce qu'il veut de son coté. Je ne parle que de ce que je vois.

Après il y a un tas de raisons à mettre à jour sa base de code :

• c'est une dette technique que tu accumule et que tu va probablement devoir payer un jour
• un code pas touché pendant un certain nombre d'années devient très difficile à maintenir (quelque soit le langage)

Par exemple, le Brainfuck est extrêmement simple (seulement 8 instruction à apprendre en 2 minutes), mais il est en fait très compliqué de faire des programmes avec.

Ce n'est pas si compliqué, sa notoriété est galvaudée. C'est juste une syntaxe embêtante. Malbolge est vraiment complexe.

If it works, don't fix it !!!

On voit ici des gens qui n'ont pas du tout envie de bosser sur ta vielle base de code.

il y a pas mal de composant de test (cppunit, google test suit) qui rendent l'écriture de test très aisée.

On ne parle pas des même magnitude. Je viens du monde Java du test on en a plus que ce que peut imaginer en C++ (une bibliothèque de test qui fait référence avec un format qui fait standard de fait dans le reporting de tests, des bibliothèques d'assertion et de mock on en a pleins), mais le typage de java (ou du C++) rendent l'écriture de test bien moins pratique qu'en python/go. En java on a la chance d'avoir un runtime extrêmement flexible ce qui permet d'avoir spock, mais il faut remercier groovy et sa compatibilité avec java.

• Python est fait pour faire du prototypage rapide avec du code qui finira difficilement maintenable due à son typage dynamique et ses performances.
• C++ est fait pour du code système avec des code base où la performance compte et des projets qui peuvent tourner 30 ans et toujours faire le boulot et être maintenu (déja vu).

Je ne suis pas d'accord avec ça :

• ton application C++ en 30ans tu l'a réécrite 2 fois au moins (une fois pour prendre en compte C++98 et une pour C++11) si tu t'en es bien sorti. Oui tu as aussi dû réécrire ton application python pour passer à python3 on est d'accord. C'est juste pour dire que la maintenance de ce genre de code même en C++ ce n'est pas trivial du tout.
• la performance de python n'est pas aussi pathologique que ce que tu avance. C'est du code compilé, il n'est pas aussi véloce que d'autres, mais on est pas dans l'univers PHP5
• son typage dynamique par rapport au typage statique du C++ est contrebalancé par 2 choses :
  • il est beaucoup plus simple d'écrire des tests, mais vraiment beaucoup. Le duck typing (ou le typage structurel) est un bonheur pour ça
  • il existe un outillage autour de python beaucoup plus riche que pour C++. Par exemple pour reprendre mon premier point, tu es beaucoup plus aidé pour passer de python2 à python3 que pour passer mettre à jour ta base de code C++ vers le nouveau standard. Oui en python c'est bloquant et en C++ c'est rétrocompatible, mais on voit dans les commentaires que les développeurs C++ sont bien moins indulgents que les compilateurs C++.

Et puis, soit disant "techno". Je ne vois pas en quoi le nouveau langage bidule ou la nouvelle API machin révolutionne mon monde. Ah si, ça va ajouter un overhead ici ou là, merci pour les perfs …

Je connais 3 contre exemples :

• go: il semble faire ce que tu recherche, il est simple, vraiment. go ne fais pas de templating ou d'autres choses sophistiquées. Son overhead est vraiment minimal.
• rust: il me semble que c'est un descendant de C++. Il a des objectifs proches sans l'âge et la dette technique qui va avec.
• julia: cherche la performance du C avec des choses plus user-friendly que le C++ (moins de piège, une bibliothèque standard plus fournie,…)

donner des clef sur comment se débrouiller sans documentation

Même si tu donnes quelques éléments pour étayer, on peut pas laisser passer çà :)

L'agilité n'a jamais prétendu qu'il fallait se "passer" de la documentation, bien au contraire.
Le principe, comme pour le reste, est de faire ce qui est suffisant au bon moment çar le changement peut, enfin non, va, arriver. Tout comme on n'se fait pas plaisir avec une archi géniale qui servira jamais (overdesign) et qu'on fait "juste ce qu'il faut".

Mon point n'était pas qu'il ne faut pas de doc, mais que des approches agiles donnent des approches différentes de la documentation et justement les 2 points que j'ai donné servent à produire de la documentation.

Normalement tu ne livre pas de dockerfile, mais bien une image docker.

Vous avez pas de CI avec une analyse statique de code ? Ni de revue ?

C'est ce que je reproche à chaque fois au C++, c'est cool d'avoir un C++17 qui est cool, mais on a aucun moyen de garantir qu'on ne continue pas d'utiliser les anciennes méthodes.

Donc vous n'avez pas de documentation, ok. Ça ce n'est pas la faute de l'agilité, comment vous faites pour vous en sortir sans ?

Pas.

Tu dis « l'agilité ça ne marche pas chez nous à cause de la doc », c'est qu'il y a bien un moment où quelque chose à fonctionné. Sinon tu n'a aucune idée de si c'est l'agilité qui n'a pas fonctionné ou juste vous qui êtes une équipe de shadoks (rien de personnel).

Si rien n'a jamais fonctionné, alors oui c'est qu'on vous a vendu l'agilité comme une solution miracle et que vous y avez cru.

• En C++, le développement est lent, mais l’application est très rapide ;
• En Python, le développement est rapide, mais l’application est très lente. ¹

¹ Utiliser Pythran/PyPy/Cython/Numba/… accélère l’exécution, mais cela ralentit le développement : compilation plus lente, développement plus complexe, bug difficile à investiguer…

Je sais que c'est une caricature, mais une démarche en python est un peu différente. Elle dit que la majeure partie de ton application n'a pas besoin d'une performance importante. Donc coder la partie qui demande une grosse performance en c/c++/go/rust/julia et l'interfacer¹ avec le reste de ton application en python peut être pertinent. Ça permet en plus d'avoir de coder la partie métier dans un langage de très haut niveau et la partie technique dans un langage qui permet d'accéder au très bas niveau.

la méthode (et le contexte) : tu décris la méthode agile, mais elle ne peut pas s'appliquer partout. Déjà, j'imagine que Airbus, Bombardier, Arcelor et plein d'autre regarder ça avec encore beaucoup de méfiance. Ensuite, ça se passe bien de ton côté, mais dans ma boite, quelle fumisterie ! On a "fait de l'agile" parce que c'était à la mode ! Mis à part l'absence de maîtrise par le management, mon ressenti est que ce n'est pas applicable à mon métier ou à mon niveau. En effet, une carte sur un Trello n'a jamais constitué une spécification pour moi. A la limite, si le manager/client avait su étoffer ces cartes … Mais comme les gens qui ont déjà vu de vraies specs et des vrais chef de projet se compte sur les doigts d'une main dans la boite … Sur 800 personnes quand même, hein !

C'est surtout une agilité mal maîtrisée, il me semble. L'idée principal de l'agilité c'est d'avoir une boucle de rétroaction sur la façon de travailler d'une équipe. Pour ça, une façon de faire (celle de scrum) est de mettre en place des segments courts (les sprints) que l'on évalue via les rétrospectives. Mais ce n'est pas la seule façon.

Se concentrer sur les outils (trello, des post-it, jira, whatever) ce n'est pas agile du tout :)

En effet, une carte sur un Trello n'a jamais constitué une spécification pour moi. A la limite, si le manager/client avait su étoffer ces cartes … Mais comme les gens qui ont déjà vu de vraies specs et des vrais chef de projet se compte sur les doigts d'une main dans la boite … Sur 800 personnes quand même, hein !

Donc vous n'avez pas de documentation, ok. Ça ce n'est pas la faute de l'agilité, comment vous faites pour vous en sortir sans ? L'agilité peut justement donner des clef sur comment se débrouiller sans documentation (la mise en place de démo pour échanger sur une fonctionnalité, d'autres types de réunions comme l'eventstorm peuvent aussi aider).

Mon point ce n'est pas qu'il faut forcément faire de l'agile, juste reprendre ton point pour donner des pistes sur comment ça aurait pu mieux se passer pour vous.

C'est très très très bizarre. Soit on est beaucoup à avoir beaucoup de chance, soit il y a un problème avec ton utilisation (je ne suis pas que ton utilisation est mauvaise, mais que tu fais des choses ou visite des sites qui font planter ton Firefox) ou ton installation (peut-être que le Firefox d'aujourd'hui est is sensible à une bibliothèque qui ne lui convient pas).

Évidemment, à ta place, j'aurais tendance à investiguer ce qui peut être réglé de ton côté. Si tu ne trouves pas de site qui pose problème, je regarderai au niveaux de ton profile et des extensions.

Mon point n'est pas d'incriminer toi plutôt que Firefox, juste d'essayer de comprendre d'où ça vient. Au contraire ça montre un problème dans Firefox de résilience, mais qui devrait être évitable.

J'imagine que Firefox est plus lent (ou plus consommateur de ressources) que la concurrence, qu'il n'a plus beaucoup de part de marché mais s'il en était au point que tu décrit, il n'existerait plus.