Discussion :

[Neckara]

Décision encore une fois appuyée par ce débat qui me pompe mon énergie pour rien d’intéressant, zéro, quedalle, peaudeballe.

Eh bien, il t'en faut vraiment peu pour te pomper ton énergie.


Et donc tout le passage où je te réponds sur le point de vue technique... ?


Là je suis en train de visionner la vidéo de 45 minutes que tu as posté.
Dès les 7 premières minutes, il semble dire qu'il ne s'oppose pas vraiment à l'OOP à un haut niveau d'abstraction, mais plutôt lorsque utilisé à un bas niveau d'abstraction. Tiens, tiens, tiens, cela ne rejoint-il pas ce que nous disions ?

[Invité]

Dans toust ce merdier, at least au moins, nous ne nous sommes pas rabaissés à faire dans le grammarnazisme.

Désolé, je n'ai pas pu résister...

[Neckara]

Bon, je viens de finir la vidéo de 45 minutes…


En gros, il ne s'oppose pas à la création de classes avec des attributs et méthodes, mais précise qu'il ne faut pas faire que cela, et aussi utiliser des fonctions. De même, il précise que les longues fonctions ne doivent pas être découpées pour le plaisir d'être découpées.

Cela n'a donc pas grand chose à voir avec la POO, mais plus avec des problèmes de conceptions et de l'application de règles de manière bêtes et méchantes (voire dogmatique) sans les avoir comprises, ou avoir l'expérience nécessaire.

La POO n'empêche en effet pas d'avoir des fonctions, ou au pire des méthodes statiques dans une classe "vide" (i.e. une sorte de pseudo-namespace). Le problème n'est pas sur l'aspect POO, mais sur un aspect plus haut niveau, sur l'architecture de l'application, c'est un problème de conception, de prendre le temps nécessaire à la conception et de ne pas se laisser aller à des solutions de simplicités par manque de temps.

En ce il fait un faux-dilemme entre une utilisation trop stricte du POO en mode full-class, et une utilisation "je fais n'importe quoi" de la POO, il y a des juste milieux.


Pour les problèmes d'échanges de messages, cela peut provenir de la mauvaise définition des classes, ou d'un manque de gestion de système d'événements ce qui n'est en soit que quelques lignes à coder. Peut-être un peu plus tricky sur des langages fortement typés, mais très facile à faire en e.g. JS.



Pour le découpage des fonctions, je ne suis absolument pas d'accord avec lui, il faut découper les fonctions qui font 36 pages… mais il ne faut pas le faire n'importe comment, ou bêtement, ou de manière absolue. Il faut découper la fonction de manière cohérente, de sorte à ce qu'on comprenne son fonctionnement rien qu'en voyant son code abstrait. C'est à dire ne pas faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
foo(a) {
step1(a);
step2(a);
step3(a);
}

mais

foo(a) {
a = sortByNameAsc(a);
a = slice(a, 0, 10);
a = sortByAddrDesc(a);
}

Ce qui est beaucoup plus lisible, et on comprend tout de suite ce que le code fait, sans devoir lire l'implémentation.
Ce qui parfois signifie de produire du code moins optimisé et de répéter certains calculs, ce afin de rendre le code plus lisible.


Aussi, il est possible de faire des fonctions dans des fonctions, mais les mettre à l'extérieur (en dessous) ne devrait pas poser problème si la fonction est trop grosse, le fichier n'est pas censé faire 36 000 lignes, cela ne devrait donc pas trop poser problèmes tant qu'on ne les exporte pas.

[Pyramidev]

bein quid de la vidéo de 45 min que j'ai apporté d'un mec qui présente les mêmes arguments sans pour autant travailler pour cette entreprise.

Je viens de revoir la vidéo de 45 minutes (que j'avais déjà vue il y a longtemps) de Brian Will et les arguments ne sont généralement pas les mêmes que ceux de Ilya Suzdalnitski, l'auteur de l'article qui est l'objet de ce fil.
Brian Will pense qu'il faut revenir au bête paradigme procédural alors que Ilya Suzdalnitski pense qu'il faut faire de la programmation fonctionnelle.
Le plus gros point commun entre leurs argumentations est que les deux affirment que Java a eu du succès pour d'autres raisons que la POO.
Mais les arguments sont globalement différents : Brian Will passe la plus grande partie du temps à argumenter contre l'encapsulation alors que Ilya Suzdalnitski passe la plus grande partie de son temps à argumenter contre les états muables partagés.

[el_slapper]

J'ai toujours été une bête étrange, affectée à des tâches bêtement procédurales(auxquelles j'ajoutais souvent une dose subtile, mais limitée, de fonctionnel - limitée parce-que je connaissais le genre de gugusse qui passerait après moi, et c'était à lui qu'il fallait penser), alors qu'autour de moi la POO fleurissait de partout.

Je ne peux dont pas juger des a-priori théoriques qui fleurissent partout dans ce fil. Le peu de POO que j'ai fait ne me donne pas autorité à ce sujet. Donc je vais me contenter de faire quelques réflexions vu de loin. Basées sur ma seule expérience(qui n'est donc pas un échantillon statistique valide).

En premier, à chaque fois qu'on a été mis en concurrence avec de l'objet(souvent du JAVA), nous avons gagné. Soit nous étions moins chers au développement(du genre moitié moins cher au devis, et moitié moins de dépassements du devis), soit le méga projet JAVA moderne qui devait nous remplacer avait des performances inacceptables (20 semaines pour faire tourner 100% de la volumétrie de prod sur un seul des innombrables batches de fin d'année, ouate de phoque?).

En second, nous étions bien plus faciles à déployer. Je ne dis pas que nous faisions face à de l'objet bien conçu(vous allez sans doute me dire que non, et il est bien possible que vous ayez raison). Je dis juste qu'en procédural, là ou je suis passé, on a pas besoin de tout recompiler à chaque fois qu'on modifie un pet de mouche. A certains endroits, je livrais en prod en 4 minutes, là ou les gens du JAVA en avaient pour une semaine de casse-tête à l'"intégration"(quoi que ça veuille dire) pour faire leur build. Quand je voulais modifier un composant, ben, je travaillais sur ce composant, sans me soucier du reste, juste de ses entrées sorties, alors que les collègues du JAVA étaient obligés de se farcir l'intégralité du projet sur leur machine pour arriver à bosser. Ce qui explique probablement au moins partiellement leurs temps de développements rajoutés.

la différence fondamentale que je perçois entre l'objet et le procédural, c'est qu'en objet, on couple fortement la définition de données et le code qui s'applique aux données. Exemple. En bancaire, on peut avoir une structure de données pour le compte en banque, avec le numéro, l'agence, le numéro du client, le solde, et quelques autres données. En procédural, on aura juste une structure vierge(qui ne serait autre qu'une classe avec juste des getters-setters, au final), et tout le code sera ailleurs. Par exemple, on aura, ailleurs, un fichier qui contient la fonction qui calcule la clef RIB. En objet, cette fonction sera plus ou moins une méthode appartenant à la classe. Ce qui est intellectuellement bien plus élégant : là ou est défini le RIB est calculé sa clef.

Dit autrement, le jour ou on modifie le calcul de la clef RIB(par exemple pour des raisons de performances, le fonctionnel ne change pas souvent), en procédural, on charge le module, on le modifie, on le teste, on le livre. Seul. Basta. En objet, il faut recompiler tout le projet. Parce-que tous les composants utilisent la classe "compte"(en bancaire, c'est un peu la base...). Ce qui rend les manipulations bien plus lourdes.

J'ai bien conscience que ce ne sont que des exemples, et qu'il existe probablement plein de bonnes pratiques que les vrais bons informaticiens POO utilisent pour éviter ce genre d'horreurs. N'en reste pas moins qu'avec la qualité moyenne de l'informaticien moyen, l'objet me semble une mauvaise idée, parce-qu’il pose trop de problèmes lorsqu'il est mal utilisé. Et il sera mal utilisé. Comme le procédural, d'ailleurs, mais pas avec des conséquences aussi massives.

(oui, je m'attends à un flot d'injures. Acceptées par avance)

[Neckara]

Dit autrement, le jour ou on modifie le calcul de la clef RIB(par exemple pour des raisons de performances, le fonctionnel ne change pas souvent), en procédural, on charge le module, on le modifie, on le teste, on le livre. Seul. Basta. En objet, il faut recompiler tout le projet. Parce-que tous les composants utilisent la classe "compte"(en bancaire, c'est un peu la base...). Ce qui rend les manipulations bien plus lourdes.

Euh non... il n'y a pas besoin de recompiler tout le projet et heureusement.

Imaginez qu'il faille recompiler la moindre application au moindre changement d'une bibliothèque partagée (.so en C++ / .jar en Java ?), ce serait invivable.
Tant que l'API/ABI ne change pas, il n'y a pas besoin de recompiler, juste de mettre à jour les .so / .jar (?).

Au pire, refaire l'édition des liens, mais cela vaut pour tous les langages compilés.


À ne pas confondre avec les templates du C++ où là, oui, il faudra recompiler tous les fichier utilisant le template modifié.
Quoiqu'encore, en fonction du besoin précis, on peut trouver des solutions.

N'en reste pas moins qu'avec la qualité moyenne de l'informaticien moyen, l'objet me semble une mauvaise idée, parce-qu’il pose trop de problèmes lorsqu'il est mal utilisé. Et il sera mal utilisé. Comme le procédural, d'ailleurs, mais pas avec des conséquences aussi massives.

Avec le procédural, tu peux te retrouver avec de la duplication de code en c/c, des fonctions réparties à droite et à gauche, du code mort caché dans un des fichiers, des structures modifiées de façon incohérentes par des fonctions qui ne devraient pas y toucher, etc.

Il me semble donc difficile d'affirmer que les erreurs en POO seraient plus "graves" qu'en procédural.

[Kikuts]

le jour ou on modifie le calcul de la clef RIB, en procédural, on charge le module, on le modifie, on le teste, on le livre. Seul. Basta. En objet, il faut recompiler tout le projet. Parce-que tous les composants utilisent la classe "compte"(en bancaire, c'est un peu la base...). Ce qui rend les manipulations bien plus lourdes.

Pas forcément vrai : c'est tout l'intérêt de l'injection de dépendance : je ne vais pas te résumer tout ça car pas le temps et l'espace mais regarde un Framework comme Prism (il y a pléthore de framework du genre) en C#.
Si l'architecture d'une solution est bien établie, ton argument ne tient pas

Avec l'exemple que tu donnes : j'ai un service du type IRibKeyGenerator avec dedans une méthode qui me retourne la clé. C'est tout. Et partout dans mon programme, je vais utiliser cette interface et demander au framework d'injection de dépendance de me donner une implémentation de cette interface. L'implémentation est dans une micro DLL qui est injecté au runtime du coup si je switch la micro DLL, on verra que du feu. (edit : évidemment il faut recompiler la micro DLL)

[Nebulix]

... demander au framework d'injection de dépendance de me donner une implémentation de cette interface. L'implémentation est dans une micro DLL qui est injecté au runtime du coup si je switch la micro DLL ...

Au secours !
Il me semble ( comme el_slapper ) qu'appeler une fonction ...

[el_slapper]

Euh non... il n'y a pas besoin de recompiler tout le projet et heureusement.

Je parle de ce que j'ai vu, et par définition, c'est fort limité. ravi d'apprendre qu'il y a des alternatives.

Imaginez qu'il faille recompiler la moindre application au moindre changement d'une bibliothèque partagée (.so en C++ / .jar en Java ?), ce serait invivable.
Tant que l'API/ABI ne change pas, il n'y a pas besoin de recompiler, juste de mettre à jour les .so / .jar (?).

Tiens, on a une appli secondaire en java, là ou je suis. Un truc dont on va se débarrasser, d'ailleurs, mais qui pour l'instant survit(malheureusement, les clients en sont contents...). On livre un seul .war. J'en déduis que le programmeur compile tout à chaque nouvelle livraison. Ce n'est pas méchant parceque ça devient rare, mais c'est un bloc de 50 Mo à chaque fois. Pour un gadget additionnel, pas pour notre produit principal. Après, si tu me dis que c'est une mauvaise pratique, OK. Dans ce cas, c'est juste une mauvaise pratique que j'ai vu partout ou je suis passé(j'ai pu ne pas avoir de chance).

Au pire, refaire l'édition des liens, mais cela vaut pour tous les langages compilés.

oui, ça vaut pour tout, les liens. Mais quelle est la taille moyenne de ta dll? Moi, je livrais des composants unitaires de quelques ko maximum. Tous indépendants.

Avec le procédural, tu peux te retrouver avec de la duplication de code en c/c, des fonctions réparties à droite et à gauche, du code mort caché dans un des fichiers, des structures modifiées de façon incohérentes par des fonctions qui ne devraient pas y toucher, etc.

Jamais eu de soucis avec les structures(et pourtant j'en ai vu, des horreurs), par contre, tout le reste est vrai(et le plus dangereux me semble être la duplication de code, bien plus facile en objet, enfin, de mon expérience limitée).

Il me semble donc difficile d'affirmer que les erreurs en POO seraient plus "graves" qu'en procédural.

Encore une fois, je ne regarde pas la cuisine en interne, je n'ai pas le niveau(en POO) pour ça. Je regarde vu de loin. Quand COBOL fait un devis de 120 jours, JAVA un devis de 250 jours, que COBOL dépasse de 10%, et JAVA de 20%, tu te poses des questions. Surtout quand tu te retrouves à voir ça plusieurs fois de suite, dans plusieurs équipes différentes, dans plusieurs boites différentes, avec ton code COBOL(plein de redites, de code mort caché, et de procédures un peu perdues à droite à gauche; je dis procédures parce qu’il n'y a pas vraiment de fonctions en COBOL) bien plus performant(mesuré 20 fois plus rapide) et maintenable(mesuré 2 fois plus rapide) que du JAVA soi-disant suivant les normes les plus modernes.

Les raisons exactes, je ne les connais pas. Peut-être est-ce juste JAVA. Peut-être les cobolistes étaient-ils bien meilleurs que les javaistes dans mon contexte(j'en doute fort, et même si c'était vrai, ça serait une raison suffisante pour préférer COBOL). Mais ça me fait douter de l'objet plus propre, plus maintenable.

Pas forcément vrai : c'est tout l'intérêt de l'injection de dépendance : je ne vais pas te résumer tout ça car pas le temps et l'espace mais regarde un Framework comme Prism (il y a pléthore de framework du genre) en C#.
Si l'architecture d'une solution est bien établie, ton argument ne tient pas

Donc il faut un framework objet complet pour imiter ce que fait une bête fonction/procédure?

Avec l'exemple que tu donnes : j'ai un service du type IRibKeyGenerator avec dedans une méthode qui me retourne la clé. C'est tout. Et partout dans mon programme, je vais utiliser cette interface et demander au framework d'injection de dépendance de me donner une implémentation de cette interface. L'implémentation est dans une micro DLL qui est injecté au runtime du coup si je switch la micro DLL, on verra que du feu. (edit : évidemment il faut recompiler la micro DLL)

ça règle le problème de la livraison(en admettant qu'on aie les outillages pour faire tout ça de manière industrielle, comme le souligne Nebulix, ça n'est pas rien), mais pas celui de la performance. Combien ça coûte en overhead, tous ces trucs là? Si un appel passe par le framework, ben, il exécute du code framework, pas que du code fonctionnel. donc c'est coûteux en temps d’exécution. ce qui est un problème - ou pas, suivant les contextes, mais il y a des contextes ou c'est un problème.

Encore une fois, je ne dis pas "procédural bieeeeen, objet maaaaaaal", l'objet permet déjà de limiter fortement les redites, et c'est un avantage dont on aura du mal à sous-estimer les bienfaits. Je ne suis juste pas sur que le discours associé, qui veut que ça soit le graal, soit toujours pertinent. Je garde cette impression, spécialement en lisant cette réponse, qu'on ajoute de hauts niveaux de complexités qui peuvent fortement obérer l'avantage pourtant évident à limiter les redites.

[Neckara]

oui, ça vaut pour tout, les liens. Mais quelle est la taille moyenne de ta dll? Moi, je livrais des composants unitaires de quelques ko maximum. Tous indépendants.

Pour le moment je fais plus du JS qu'autre chose.

La taille de ta dll dépendra de la quantité que tu y mettra. Mais généralement, je dirais que c'est de l'ordre de la dizaine de ko (?). Il ne faut pas non plus faire une dll par fonction .
Si tu as du Mo, c'est qu'à priori tu y as inclus des ressources (images, vidéos, ...), et personnellement je ne pense pas que ce soit une très bonne idée.


Après, il faut différencier le développement de la distribution. Pour la distribution, tu peux vouloir n'avoir qu'un seul fichier signé (qui serait par ailleurs généralement une archive zip).
Mais cela est plus lié au langage et à son mode de distribution qu'au paradigme utilisé.

Quand COBOL fait un devis de 120 jours, JAVA un devis de 250 jours, que COBOL dépasse de 10%, et JAVA de 20%, tu te poses des questions. Surtout quand tu te retrouves à voir ça plusieurs fois de suite, dans plusieurs équipes différentes, dans plusieurs boites différentes, avec ton code COBOL(plein de redites, de code mort caché, et de procédures un peu perdues à droite à gauche; je dis procédures parce qu’il n'y a pas vraiment de fonctions en COBOL) bien plus performant(mesuré 20 fois plus rapide) et maintenable(mesuré 2 fois plus rapide) que du JAVA soi-disant suivant les normes les plus modernes.

Tu as peut-être aussi un biais d'échantillonnage. Le Java, tout le monde peut se prétendre dev Java après avoir lu un tutoriel sur Internet. On pourra trouver plein de pisseurs de code sortant d'école, qui ne sont pas parmi les meilleurs de leur promotion, voire des personnes qui n'ont pas fait d'études en informatique venant e.g. de chimie. Le Cobol est beaucoup moins répandu, et tu y trouvera peut-être plus de personne très compétentes, ainsi que des vieux de la vieille avec une très longue expérience.

Les raisons exactes, je ne les connais pas. Peut-être est-ce juste JAVA. Peut-être les cobolistes étaient-ils bien meilleurs que les javaistes dans mon contexte(j'en doute fort, et même si c'était vrai, ça serait une raison suffisante pour préférer COBOL). Mais ça me fait douter de l'objet plus propre, plus maintenable.

Disons qu'il ne faut pas confondre le paradigme, le langage, et ses utilisateurs.

Donc il faut un framework objet complet pour imiter ce que fait une bête fonction/procédure?

Je pense surtout qu'il parle de grands projets, où il faut avoir une vision globale de l'architecture pour ne pas faire du code dans tous les sens et se récupérer en sorti une usine à gaz non-maintenable.
Ce n'est donc pas une question de "bête fonction", mais de l'application dans son entièreté et dans toute sa complexité.


Après, cela dépend aussi ce que tu codes, si tu fais des machines-état, juste des calculs, de la GUI, ...

Combien ça coûte en overhead, tous ces trucs là? Si un appel passe par le framework, ben, il exécute du code framework, pas que du code fonctionnel. donc c'est coûteux en temps d’exécution. ce qui est un problème - ou pas, suivant les contextes, mais il y a des contextes ou c'est un problème.

Comme on dit l'optimisation prématurée est diabolique.

Quand j'ai commencé la programmation, j'étais un peu allergique aux codes non-optimisé. Mais quand cela te fait gagner en lisibilité et maintenabilité, pour un coût dont tu t'en fiche 99,99% du temps, franchement, le bénéfice est là.

Après, c'est comme tout, il faut voir les besoins réels et les contraintes qu'il y a derrière.

[BugFactory]

je livrais en prod en 4 minutes,

Ca, ça me fait sérieusement tiquer. Pas de recette? Pas de tests pour vérifier que les procédures qui utilisent le composant fonctionnent toujours?

là ou les gens du JAVA en avaient pour une semaine de casse-tête à l'"intégration"

Parce que eux font ces tests, qui sont souvent bien plus longs que le développement lui-même.

A lire ton post, je n'ai pas l'impression de voir la différence entre la POO et la programmation procédurale. Je vois juste qu'un développeur très expérimenté va très vite et commet assez peu d'erreurs pour se passer de tests d'intégration. Sinon, je suis moi-même un développeur Java expérimenté et je note que la plupart des problèmes que tu cites sont typiques d'une équipe de juniors mal encadrés. Au final, j'ai l'impression que dans le cas que tu présentes, on ne voit pas la différence entre POO et procédural mais entre expérimenté et junior.

Sinon, la critique que tu émets concernant la livraison de .war est valide, mais ça n'a rien à voir avec la POO.

[transgohan]

Comme on dit l'optimisation prématurée est diabolique.

Quand j'ai commencé la programmation, j'étais un peu allergique aux codes non-optimisé. Mais quand cela te fait gagner en lisibilité et maintenabilité, pour un coût dont tu t'en fiche 99,99% du temps, franchement, le bénéfice est là.

Après, c'est comme tout, il faut voir les besoins réels et les contraintes qu'il y a derrière.

T'as de la chance, dans mon domaine le pourcentage tombe en dessous de 50%.
Je suis justement en train de passer du code C en assembleur pour gagner des microsecondes... (ce serait sans doute pas arrivé si j'utilisais un compilateur récent cela dit, mais j'ai pas le choix)

[Neckara]

T'as de la chance, dans mon domaine le pourcentage tombe en dessous de 50%.
Je suis justement en train de passer du code C en assembleur pour gagner des microsecondes... (ce serait sans doute pas arrivé si j'utilisais un compilateur récent cela dit, mais j'ai pas le choix)

En même temps tu es dans du temps réel/embarqué, donc tu es déjà dans les 0.01%


Sachant que tu as toujours la loi de Pareto, i.e. tu as peut-être 20% du code qui faut optimiser pour gagner 80% de performances.

[disedorgue]

Ici, j'ai l'impression de voir un débat sur la religion....
Qui n'aboutira jamais puisque par définition c'est "MA Religion" la mieux quoique que l'on puisse dire ou argumenter.

Alors que la vraie question est: pourquoi s'imposer ou nous imposer des limites dans notre façon de développer ?

Ce que je veux dire par là, c'est par exemple, pourquoi se prendre la tête à faire de l'objet quand il existe une autre méthode, procédurale par exemple, qui serait plus efficace, plus succincte et plus simple à maintenir ?

On dit toujours, tel langage c'est pour ceci ou cela et tel autre pour autre chose...

De mon point de vue, c'est un peu la même chose sur le style de programmation employé selon ce que permet le langage et le besoin final.

[Jipété]

Bonsoir,

Je suis justement en train de passer du code C en assembleur pour gagner des microsecondes...

Depuis le temps que cet aspect des choses me turlupine, ce soir je me lance : est-ce que des tests pointus de comparaison ont été réalisés pour savoir si cette assertion était vérifiée ?

Parce que dans mon petit cerveau surchauffé (c'est d'actualité), je ne peux pas m'empêcher de penser que ce bout de code

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
#include <stdio.h>
int main(int argc, char **argv)
{
        printf ("Hello, World!\n");
        return 0;
}

en le faisant mouliner par un compilateur ou en le réécrivant en assembleur puis en le passant à l'outil qui va bien (éditeur de liens ? Je ne suis pas spécialiste), dans les deux cas on va se retrouver avec des 0 et des 1 dans des fichiers sur le disque dur, et comme ces fichiers devront fournir le même boulot, je ne vois pas pourquoi l'un serait plus lent que l'autre.

Merci d'éclairer ma lanterne.

[Neckara]

Depuis le temps que cet aspect des choses me turlupine, ce soir je me lance : est-ce que des tests pointus de comparaison ont été réalisés pour savoir si cette assertion était vérifiée ?

De manière générale un code écrit en C serait presque toujours plus rapide qu'un code écrit en assembleur, car le compilateur est très doué pour optimiser (en tout cas plus que ton stagiaire en L3).

En revanche, si on veut faire encore mieux, là il faut passer à la main et toucher l'assembleur pour écrire du code encore plus rapide. Tout simplement parce que le compilateur ne peut pas deviner ce qu'on n'écrit pas. En revanche cela demande beaucoup plus de temps et d'efforts à faire.

Par exemple, le compilateur peut inliner des fonctions, dérouler une boucle afin d'exécuter les instructions sur un pipeline, i.e. il réparti les différentes opérations sur les différentes ALU du CPU i.e. peut faire plusieurs opérations en parallèles, puis commence une nouvelle itération avant de finir la précédente. Cela plus des opérateurs sur des vecteurs qui permet de faire en une opération plusieurs e.g. additions (?). Plus tout ce qui est prédiction du CPU, i.e. commence à exécuter des instructions à l'intérieur d'un if avant d'avoir évalué la condition.

Si tu donnes les bonnes options au compilateur il saura se débrouiller assez bien, mais il n'est pas magique et ne lit pas dans tes pensées.
Tu peux essayer les profils avec gcc pour exécuter ton code, et l'optimiser en fonction du code qui est exécuté.

Mais par exemple, le compilateur ne peut pas deviner e.g. pour for(let i = 0; i < n ; ++i), la plage de valeur de n. En tant que développeur tu peux savoir que n est compris entre 1 et 2, et donc que cela vaut la peine de dérouler la boucle, mais si tu ne l'écris pas, le compilateur ne va pas le deviner. En embarqué, il y a possibilité parfois d'ajouter des indications à destination du compilateur pour rajouter des informations, mais cela dépend du compilateur et a aussi des limites.

Il ne faut pas oublier que le but d'un compilateur c'est d'être générique, i.e. d'avoir en moyenne du code qui s'exécute rapidement, quoi que tu écrives. Alors que le code qu'on cherche à optimiser est spécifique, et donc qu'en tenant compte de ses spécificités on peut aller plus loin.

[Jipété]

ah, Neckara, ses exemples embrouillés, ses phrases alambiquées...

De manière générale un code écrit en C serait presque toujours plus rapide qu'un code écrit en assembleur, car le compilateur est très doué pour optimiser (en tout cas plus que ton stagiaire en L3).

En revanche, si on veut faire encore mieux, là il faut passer à la main et toucher l'assembleur pour écrire du code encore plus rapide. Tout simplement parce que le compilateur ne peut pas deviner ce qu'on n'écrit pas. En revanche cela demande beaucoup plus de temps et d'efforts à faire.

Et récrivant à peine et en enlevant ce qui est inutile, on obtient ça :

un code écrit en C serait presque toujours plus rapide qu'un code écrit en assembleur.
si on veut faire encore mieux, là il faut passer à l'assembleur pour écrire du code encore plus rapide.

Ligne 1 c'est presque toujours le compilo qui gagne, ligne 2 c'est peut-être l'assembleur, mais il n'y a pas de précisions sur comment ça se passe, or ma question portait là-dessus.

Par exemple, le compilateur peut inliner des fonctions, dérouler une boucle afin d'exécuter les instructions sur un pipeline, i.e. il répartit les différentes opérations sur les différentes ALU du CPU i.e. peut faire plusieurs opérations en parallèle, puis commence une nouvelle itération avant de finir la précédente. Cela plus des opérateurs sur des vecteurs qui permet de faire en une opération plusieurs e.g. additions (?). Plus tout ce qui est prédiction du CPU, i.e. commence à exécuter des instructions à l'intérieur d'un if avant d'avoir évalué la condition.

"le compilateur peut inliner des fonctions, dérouler une boucle afin d'exécuter les instructions sur un pipeline, i.e. il répartit les différentes opérations sur les différentes ALU du CPU", toutes choses qui peuvent être mises en place par celui qui écrit en assembleur, hein.

"plusieurs opérations en parallèle", "faire en une opération plusieurs additions" sont des concepts de haut niveau battus en brèche par les suites d'instructions en 0 et 1 dans le fichier, où l'on est obligé de rajouter une énorme couche de gestion de ces optimisations, pas sûr qu'on soit gagnant.

"commence une nouvelle itération avant de finir la précédente", "commence à exécuter des instructions à l'intérieur d'un if avant d'avoir évalué la condition", ça oblige à des tests lourds en fin de manip pour être sûr que le code ne s'est pas pris les pieds dans le tapis, là aussi pas sûr qu'on soit gagnant, plus les problèmes de failles dont on a longuement parlé il y a un an ou deux.

Bon, je reste sur ma faim d'explications.

[el_slapper]

(.../...)Comme on dit l'optimisation prématurée est diabolique.

ça dépend. En batch bancaire, les traitements durent toute la nuit, et doivent avoir fini avant 07h00. Pas besoin de micro-optimiser, mais une surcouche qui te coûte à chaque appel de fonction aussi simple(et fréquent) qu'un calcul de clef RIB?

Plus généralement, il y a plein d'optimisations qui sont super-faciles, et qui ne coûtent quasiment rien en lecture et optimisation. Truc très fréquent en batch(ou les données arrivent généralement triées, souvent sur la clef de recherche en base) : on fait une bufferisation manuelle. On met en mémoire les données d'entrée et sortie de l'appel précédent, et quand on se fait rappeler, si l'entrée n'a pas changé, alors on recopie la sortie sauvegardée au lieu de refaire les calculs. Ça m'a toujours fait gagner entre 10 et 20%(mesuré), ça coûte 4 lignes que personne ne regarde jamais et n'a jamais besoin de maintenir. Quand ton traitement passe de 6 heures à 5 heures, ça te fait carrément gagner du temps de développement.

Autre optimisation super-facile : sortir d'une boucle si on a fini ce qu'on y faisait. Ca, c'est de l'optimisation prématurée indispensable.

Après, si tu me ressors ce vieux code ou les gugusses avaient fait une dichotomie à la main(fort merdique, en plus) pour gagner 3-4% par rapport à une fonction standard du langage(le SEARCH), oui, on est d'accord, c'est du dernier recours. A éviter tant qu'on peut. Mais des trucs de base, il faut les faire systématiquement.

Le plus juteux est sans doute, quand on toutouille des données EXCEL au delà de ce que les formules et autres tableaux croisés dynamiques savent faire, donc en VBA, de rapatrier les données dans un tableau interne au lieu d'aller taper sur les cellules. On gagne un facteur 100, à peu près. ça prends 3 lignes. Après, si on a vraiment un truc compliqué, avec besoin d'accès directs, on peut se farcir des dictionnaires - on regagne un facteur 100(seulement en accès direct, hein), mais là, par contre, c'est pas mal de code en plus. Je ne l'ai fait qu'une seule fois, mais mon temps d’exécution est passé de vingt minutes à 10 secondes. Ce qui signifie que le développement et débogage ont été plus rapides, malgré le surcoût massif en termes de développement des dictionnaires(ben oui, je ne savais pas faire, j'ai du apprendre, c'est coûteux - mais moins que de dormir devant un code qui s’exécute).

Le dictionnaire, c'est facultatif. La mise en tableaux, c'est obligatoire. Ça fait TOUJOURS gagner du temps, beaucoup de temps, y compris de développement - sauf sur des feuilles petites et/ou triviales ou de bêtes formules auraient suffi(et là, c'est le simple fait de sortir un outil de développement qui est une erreur).

Quand j'ai commencé la programmation, j'étais un peu allergique aux codes non-optimisé. Mais quand cela te fait gagner en lisibilité et maintenabilité, pour un coût dont tu t'en fiche 99,99% du temps, franchement, le bénéfice est là.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
PERFORM MODULE-RIB 
  USING NUMERO-RIB 
        CLEF-RIB

Ouais, vachement compliquée à maintenir, l'optimisation... Bon, on rajoute en haut une ligne de COPY(en gros un include) pour rajouter la définition des données utilisée, et c'est fini. Compare avec les surcouches frameworkiennes qu'on m'a proposé...

Après, c'est comme tout, il faut voir les besoins réels et les contraintes qu'il y a derrière.

oui, tout à fait. Je n'ai jamais dit que l'Objet était toujours une mauvaise idée. J'ai plutôt souligné que dans certains contextes, il n'était pas forcément la panacée. Si je reprends le titre de l'article, c'est l'aspect "standard" qui est remis en question, pas l'existence même de l'objet(d'ailleurs, parfois, j'en utilise un peu). Moi aussi je remet en cause cet aspect standard évident qu'on a pas le droit de discuter. La plupart des gens qui sortent de formation ont eu leur cerveau lavé sur le thème "objet bieeeeen, procédure pas bieeeeeen". C'est ça que je veux dire.

"ça dépend" est la vraie bonne réponse. Suivant l'existant, suivant les personnels disponibles, suivant la typologie de projet, l'un ou l'autre choix peuvent être préférables. Je m'oppose juste à la doctrine du "tout objet parce-que". Ce n'est pas de l’ingénierie, c'est de la religion, ce genre d'attitudes.

Ca, ça me fait sérieusement tiquer. Pas de recette? Pas de tests pour vérifier que les procédures qui utilisent le composant fonctionnent toujours?
Parce que eux font ces tests, qui sont souvent bien plus longs que le développement lui-même.

Je suis désormais à plus de 50% coté test. Non, on ne consomme pas autant que les développeurs. Loin s'en faut. Oui ça prend du temps, même avec une bonne couche d'industrialisation. Non, ce n'est pas de ça que je parle

Oui, les éléments que je livrais avaient été validés. Une minute pour livrer en intégration, je testais, une minute pour livrer en recette, ils testaient, et hop on livre en prod. Comme les éléments sont fortement découplés, le risque d'effet de bord est faible. Je n'en ai jamais eu.

A lire ton post, je n'ai pas l'impression de voir la différence entre la POO et la programmation procédurale. Je vois juste qu'un développeur très expérimenté va très vite et commet assez peu d'erreurs pour se passer de tests d'intégration. Sinon, je suis moi-même un développeur Java expérimenté et je note que la plupart des problèmes que tu cites sont typiques d'une équipe de juniors mal encadrés. Au final, j'ai l'impression que dans le cas que tu présentes, on ne voit pas la différence entre POO et procédural mais entre expérimenté et junior.

Possible, mais maintenant, admettons que ce soit la seule raison(j'ai des doutes), et penses business : tu as des séniors efficaces qui bossent rapidement en procédural, et des juniors inefficaces qui se traînent en objet. Sur le marché du travail, tu ne trouve rien d'autre que ce que tu as déjà. Qu'est-ce qui est le plus rationnel?

Sinon, la critique que tu émets concernant la livraison de .war est valide, mais ça n'a rien à voir avec la POO.

Partout ou je suis passé, c'était comme ça. Je ne parle pas des bonnes pratiques, je parle de la réalité telle que je l'ai vue(réalité locale évidemment, mais les noyaux batchs de plusieurs grandes banques Française, ça fait une grosse localité). Si les gens qu'on trouve pour faire de l'objet ne savent pas faire de l'objet de manière correcte, est-ce pertinent de s'accrocher à l'objet(même si en théorie c'est mieux)?

[Neckara]

Ligne 1 c'est presque toujours le compilo qui gagne, ligne 2 c'est peut-être l'assembleur, mais il n'y a pas de précisions sur comment ça se passe, or ma question portait là-dessus.

Pour peindre un mur, tu prends un grand rouleau, pas un pinceau. En revanche si tu as des petits détails à faire à 2-3 endroit, il faudra utiliser le pinceau, mais cela te prendra plus de temps. C'est la même chose avec le C++ et l'assembleur.

Je donne des précision dans la suite de mon message.

"le compilateur peut inliner des fonctions, dérouler une boucle afin d'exécuter les instructions sur un pipeline, i.e. il répartit les différentes opérations sur les différentes ALU du CPU", toutes choses qui peuvent être mises en place par celui qui écrit en assembleur, hein.

Oui, mais cela demande bien plus de réflexion et de temps de le faire soit-même que te laisser le compilateur se débrouiller. En règle général, il sera meilleur que ce qu'on pourrait écrire directement en assembleur.
Ce qui fait que souvent on écrit son code en C, puis sur les parties critiques, on passe en assembleur, en s'appuyant sur ce que le compilateur C aura déjà fait.

Tu peins ton mur avec ton gros rouleau, puis tu repasses dessus avec ton petit pinceau pour les 2-3 endroits critiques.

"plusieurs opérations en parallèle", "faire en une opération plusieurs additions" sont des concepts de haut niveau battus en brèche par les suites d'instructions en 0 et 1 dans le fichier, où l'on est obligé de rajouter une énorme couche de gestion de ces optimisations, pas sûr qu'on soit gagnant.

Non, ce sont des fonctionnalités du CPU qui possède plusieurs ALU.

Je ne te parles pas de processus ou de thread, mais bien d'ALU. Il n'y a pas besoin de synchronisation à base de mutex car les opérations s'exécutent en un nombre fixe de tics d'horloge (ou avec un maximum de tics fixé), le compilateur va donc prendre cela en compte pour déterminer à quels moment telle ou telle opération doit débuter. Et cela il est capable de faire intelligemment alors que ce sera bien plus compliqué pour un humain qui peut se tromper ou prendre une ordonnancement (?) moins optimal.

"commence une nouvelle itération avant de finir la précédente", "commence à exécuter des instructions à l'intérieur d'un if avant d'avoir évalué la condition", ça oblige à des tests lourds en fin de manip pour être sûr que le code ne s'est pas pris les pieds dans le tapis, là aussi pas sûr qu'on soit gagnant, plus les problèmes de failles dont on a longuement parlé il y a un an ou deux.

C'est pourtant ce que font tous les CPU récents: https://fr.wikipedia.org/wiki/Pr%C3%...de_branchement

Et les gains en performances sont bien là.

Bon, je reste sur ma faim d'explications.

En fait pour bien comprendre, il faut comprendre comment fonctionne un CPU.

En gros, en C, tu vas écrire du code relativement rapidement et le compilateur va faire toutes les optimisations pour toi. En assembleur, il te faudra beaucoup plus de temps, et beaucoup réfléchir, mais le fait que tu aies des connaissances sur ta fonction que tu ne peux pas écrire en C, et que le compilateur ne peut pas deviner, tu peux éventuellement réussir à gagner quelques pouillèmes en bidouillant à gauche et à droite, mais toujours en comparant les performances avec ce qu'aurait donné un code C compilé pour servir de témoin. Si tu arrives à faire mieux, tu es content, sinon ben tant pis.

Gagner un cycle, c'est rien (1 ns ?), mais quand cela est dans une boucle appelée très souvent, cela peut vite faire grimper le gain à un ordre de la micro-seconde, voire plus.

[Neckara]

ça dépend. En batch bancaire, les traitements durent toute la nuit, et doivent avoir fini avant 07h00. Pas besoin de micro-optimiser, mais une surcouche qui te coûte à chaque appel de fonction aussi simple(et fréquent) qu'un calcul de clef RIB?

Mais si de telles optimisations doivent être faites, tu les fais après avoir identifié les goulots d'étrangements et avoir vu que tu avais effectivement des problèmes de performances.
Tu ne vas pas t'amuser à optimiser une fonction qui est appelée une fois par an.

Plus généralement, il y a plein d'optimisations qui sont super-faciles, et qui ne coûtent quasiment rien en lecture et optimisation.

Ce n'est donc pas de l'optimisation prématurée, mais des bonnes pratiques/idiom. Comme par exemple utiliser des références constantes au lieu de copier, utiliser ++i au lieu de i++, parcourir les tableaux à partir du dernier index de préférence, faire quelques pré-calculs, vérifier la complexité algorithmique (e.g. O(1), O(n), O(n²),...) etc. etc.

Autre optimisation super-facile : sortir d'une boucle si on a fini ce qu'on y faisait. Ca, c'est de l'optimisation prématurée indispensable.

Non, justement. Ce n'est pas de l'optimisation prématurée, c'est juste ne pas coder avec les pieds .

Si je reprends le titre de l'article, c'est l'aspect "standard" qui est remis en question, pas l'existence même de l'objet(d'ailleurs, parfois, j'en utilise un peu). Moi aussi je remet en cause cet aspect standard évident qu'on a pas le droit de discuter. La plupart des gens qui sortent de formation ont eu leur cerveau lavé sur le thème "objet bieeeeen, procédure pas bieeeeeen". C'est ça que je veux dire.
[...]
Je m'oppose juste à la doctrine du "tout objet parce-que". Ce n'est pas de l’ingénierie, c'est de la religion, ce genre d'attitudes.

Vous confondez standard et dogme.

Un standard ne signifie pas qu'on ne puisse pas le remettre en cause, ni même qu'on soit obligé de l'utiliser.

Partout ou je suis passé, c'était comme ça. Je ne parle pas des bonnes pratiques, je parle de la réalité telle que je l'ai vue(réalité locale évidemment, mais les noyaux batchs de plusieurs grandes banques Française, ça fait une grosse localité). Si les gens qu'on trouve pour faire de l'objet ne savent pas faire de l'objet de manière correcte, est-ce pertinent de s'accrocher à l'objet(même si en théorie c'est mieux)?

Sauf que cela n'est pas la "faute" à la POO. Ce n'est pas dû à l'essence de la POO, mais à l'incompétence de ses utilisateurs. C'est à dire qu'on pourrait retrouver les même problèmes dans n'importe quel autre paradigme si ses utilisateurs sont pour la plupart incompétents.

On se trompe donc de débat, c'est un problème de formation plus que de paradigme.