So Long, and Thanks for All the Fish

par **xTG** » 02 sept. 2013, 19:10

Même sans parler d'écarts avec la spéc tu as de manière tout un tas d'implémentations qui ne sont pas sous forme de spec.
Pour des systèmes parallèles par exemple tu peux avoir des enchaînements de commande dont le temps entre chaque commande peut provoquer un crash ou un retour d'erreur.
S'il faut spécifier chaque temps minimum entre chaque commande je plains les pauvres qui codent ce système...

par **Sékiltoyai** » 02 sept. 2013, 14:20

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.

Je plussoie sur ce point. Une maxime très connue en réseau et qui s'applique dans ce cas là également:
"Be conservative in what you send, be liberal in what you accept".

Sur la libc notamment on peut linker avec des implémentations très différentes, on ne peut pas prévoir ce qu'elles accepteront ou non (dont certaines fonctionnalités non-implémentées). Il faut prévoir le maximum de choses, y compris des écarts par rapport à la spec.

par **xTG** » 02 sept. 2013, 13:11

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.

par **katagoto** » 01 sept. 2013, 20:03

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°.

par **moogli** » 01 sept. 2013, 13:35

, 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>

par **xTG** » 01 sept. 2013, 12:31

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...

par **katagoto** » 01 sept. 2013, 11:33

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.

par **xTG** » 31 août 2013, 23:43

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.

par **katagoto** » 30 août 2013, 22:04

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

par **xTG** » 29 août 2013, 08:22

Pour résumer avec un exemple encore plus simple :

Code : Tout sélectionner

uint32* maFonction()
{
  uint32* ptr;
  //....
  if( ptr > 0xDFFF )
    // ...
  // ...
}
uint32* monPtr = NULL;
monPtr = maFonction();
if( monPtr > 0xDFFF )
  // ....

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.

par **katagoto** » 28 août 2013, 22:23

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.

par **xTG** » 28 août 2013, 15:25

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...

par **Sékiltoyai** » 28 août 2013, 14:07

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...

par **Nagol** » 28 août 2013, 13:47

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.

par **xTG** » 28 août 2013, 09:15

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 ?

So Long, and Thanks for All the Fish

Répondre

Étendre la vue Revue du sujet : So Long, and Thanks for All the Fish

Re: So Long, and Thanks for All the Fish

Re: So Long, and Thanks for All the Fish

Re: So Long, and Thanks for All the Fish

Re: So Long, and Thanks for All the Fish

Re: So Long, and Thanks for All the Fish

Re: So Long, and Thanks for All the Fish

Re: So Long, and Thanks for All the Fish

Re: So Long, and Thanks for All the Fish

Re: So Long, and Thanks for All the Fish

Re: So Long, and Thanks for All the Fish

Re: So Long, and Thanks for All the Fish

Re: So Long, and Thanks for All the Fish

Re: So Long, and Thanks for All the Fish

Re: So Long, and Thanks for All the Fish

Re: So Long, and Thanks for All the Fish