Et moi je ne comprends pas comment tu peux généraliser à partir de ton expérience personnel sur un projet, sachant qu'en plus tu étais seul donc que tu n'avais ni recul ni regard objectif.

Moi je crois que tu as confondu le début de ce que j'ai dit avec la fin surtout.

Non.

Je suis ravi de voir que tu comprend mieux ce que je veux dire que moi, heureusement que tu es encore la Kata, tu va nous manquer.

c'est relatif, la plupart du temps les compilateurs font mieux que toi en pure asm.

Rien que de par cette phrase on voit que tu ne cernes pas ce que l'on cible par couche...

Je ne vois pas ce que tu veux dire.

Portabilité et optimisation compilateur font bande à part.

Pas forcément mais passons.

Prenons un exemple bénin et dénué d'intérêt. Un handler de mémoire.
Cette couche va exécuter des algorithmes pour te trouver une zone mémoire, te la réserver, vérifier que ce que tu veux y stocker ne dépasse pas, ect.
Toi en tant que bon développeur tu vas vérifier que tu n'y stockes pas n'importe quoi (pointeur dont le contenu grossi en permanence ?).
Nous avons donc deux conditions qui font la même chose pour la protection de dépassement.
Trouves moi un seul compilateur qui optimise cela et je mange mon chapeau.

Tu veux dire un compilateur qui fait en sorte d'éviter les fuites mémoire à l'exécution ?

Je suis ravi de voir que tu comprend mieux ce que je veux dire que moi, heureusement que tu es encore la Kata, tu va nous manquer.

Ou plutôt que tu ne souhaite pas comprendre ma réponse parce qu'elle te dérange.

Tu veux dire un compilateur qui fait en sorte d'éviter les fuites mémoire à l'exécution ?

Euh non... T'es un sacré troll tout de même... =D>
Tu sembles reprocher qu'on ne cherche pas à comprendre tes réponses mais...
L'inverse est fortement vrai aussi.
La barrière de la langue est un sacré mur en fait non ?

Tu veux dire un compilateur qui fait en sorte d'éviter les fuites mémoire à l'exécution ?

Euh non... T'es un sacré troll tout de même... =D>
Tu sembles reprocher qu'on ne cherche pas à comprendre tes réponses mais...
L'inverse est fortement vrai aussi.
La barrière de la langue est un sacré mur en fait non ?

Oui mais c'est kata aussi, il aimerait secrètement (bon avec ses sabots quand même) qu'on le retienne, qu'on lui montre qu'on l'aime et tout.
Alors une bonne fois pour toute Kata, on t'aime on ne souhaite pas te voir partir parce que tu es un des personnages de ce forum qui certes, crée de la polémique futile (autrement appelée trolling), mais qui au fond le font vivre, bref si tu pars tu va vraiment nous manquer. Sans vouloir jouer les bisounours bien sûr, et prends bien en compte le fait que tu m'énerves profondément quand même.

kata, (...) tu es un des personnages de ce forum qui (...) crée de la polémique futile (autrement appelée trolling)

C'est bizarre j'ai l'impression que ça ne s'applique pas qu'à lui...

kata, (...) tu es un des personnages de ce forum qui (...) crée de la polémique futile (autrement appelée trolling)

C'est bizarre j'ai l'impression que ça ne s'applique pas qu'à lui...

Nagol il ne troll pas il Nagol...

Tu veux dire un compilateur qui fait en sorte d'éviter les fuites mémoire à l'exécution ?

Euh non... T'es un sacré troll tout de même... =D>
Tu sembles reprocher qu'on ne cherche pas à comprendre tes réponses mais...
L'inverse est fortement vrai aussi.
La barrière de la langue est un sacré mur en fait non ?

Là pour le coup c'est pas du troll, je ne comprends pas ce que tu veux dire.

Pour résumer avec un exemple encore plus simple : Aucun compilateur ne sait optimiser cela (bien que j'ai tout de même un doute pour ce cas très simple), c'est le problème qu'on a lorsqu'on travaille par couche tu auras toujours un morceau de code qui sera en doublon car lorsqu'on créé une couche on la fait générique au possible et on gère tous les cas possibles. Mais en rajoutant couche sur couche on fini par obtenir des aléas de ce genre.

Tu veux dire qu'il n'optimise pas la duplication des tests (par exemple) ?

Du fait de l'accumulation de couche tu as obligatoirement au minimum des portions de code qui font la même chose du fait que chaque couche provient d'une philosophie différente. (a moins que tu ne sois l'auteur des X couches)
Et ça aucun compilateur au monde ne te l'optimisera.

GHC le fait en partie, quand tu fais de la sciences des compilateurs on appel ça l'optimisation inter-procédures, c'est formalisé et ça existe.
Maintenant ton compilateur ne devrait pas le faire, pour la simple et bonne raison que tu ne devrais pas dupliquer tes conditions, c'est dû au SRP, enfin si tu regarde anti-if campaign tu verra qu'on peut aisément virer 90% des conditions et cloisonner les 5% restantes dans des factories.

Je ne duplique jamais MES conditions.
Tu parles bien pour des optiques petits projets...
Mais as-tu déjà parlé optimisation sur des projets de plusieurs millions de ligne avec des couches et des interfaces développées par plusieurs équipes ?
Vérifier ce que font les autres est une perte de rendement très inquiétante...
On te file une doc d'une cinquantaine de page par interface, si tu la maitrise c'est déjà un énorme boulot, alors savoir le détail derrière relève de l'utopie ou de la folie furieuse...
Le but n'est pas de passer le temps de dev de 10ans à 70ans...

, enfin si tu regarde anti-if campaign tu verra qu'on peut aisément virer 90% des conditions et cloisonner les 5% restantes dans des factories.

<troll mode >
Je découvre que les pourcentage c'est sur 95 et pas 100.
Tous un monde qui s'écroule autour de moi, tant de certitude qui s'envole
</troll>

Je ne duplique jamais MES conditions.
Tu parles bien pour des optiques petits projets...
Mais as-tu déjà parlé optimisation sur des projets de plusieurs millions de ligne avec des couches et des interfaces développées par plusieurs équipes ?
Vérifier ce que font les autres est une perte de rendement très inquiétante...
On te file une doc d'une cinquantaine de page par interface, si tu la maitrise c'est déjà un énorme boulot, alors savoir le détail derrière relève de l'utopie ou de la folie furieuse...
Le but n'est pas de passer le temps de dev de 10ans à 70ans...

Ce n'est pas ce que j'ai dit, tu n'as pas besoin de savoir ce qui se cache derrière une interface si elle est bien conçue (ou si elle respecte au moins une partie de la petite dizaine de règles "d'usage").
Après on a pas de projets qui font des millions de LoC en Haskell (principalement par ce que le langage n'est pas assez verbeux pour y arriver), mais c'est faisable relativement automatiquement.

, enfin si tu regarde anti-if campaign tu verra qu'on peut aisément virer 90% des conditions et cloisonner les 5% restantes dans des factories.

<troll mode >
Je découvre que les pourcentage c'est sur 95 et pas 100.
Tous un monde qui s'écroule autour de moi, tant de certitude qui s'envole
</troll>

Mauvaise formulation, je pensais plutôt à 90/9/1.
Mais ne rigole pas il y a des mathématiques qui considèrent que la somme des angles d'un triangle ne fait pas 180°.

Ce n'est pas ce que j'ai dit, tu n'as pas besoin de savoir ce qui se cache derrière une interface si elle est bien conçue (ou si elle respecte au moins une partie de la petite dizaine de règles "d'usage").
Après on a pas de projets qui font des millions de LoC en Haskell (principalement par ce que le langage n'est pas assez verbeux pour y arriver), mais c'est faisable relativement automatiquement.

Sauf que c'est pas à la lecture de la doc d'interface que tu sais si ce qu'il y a derrière est bien conçu...
Donc pour éviter les ouvertures de rapport d'anomalie en série (surtout que ça prend du temps de trouver quelle équipe est fautive...) le plus simple reste de faire tes contrôles avant l'interface.
Et donc tu as des chances de dupliquer du code entre le tien et celui de la couche que tu attaques.