Je trouve que la définition donnée du "culte du cargo pour la programmation" est assez mauvaise en VF. Elle n'est pas strictement fausse mais pourrait-être mal comprise. Le cargo culte programming relève de l'incantation, où on balance des trucs en général assez brefs assez souvent dans un quasi réflexe car cette "incantation" (qu'effectivement on ne comprend pas du tout, où alors de travers) permet de résoudre un problème ayant une vague ressemblance (ou carrément pas :p ) voire permettait dans le passé de résoudre un problème. On ne sait pas vraiment ce que fait _fonctionnellement_ l'incantation (et encore moins techniquement, mais c'est le fonctionnel qui est important) et on fait l'hypothèse que l'incantation produira un certain résultat par fausse inférence de causalité, observé dans un contexte totalement différent (ou juste entendu parlé)
Exemples :
- balancer des "sync" dans un shell avant de rebooter (ou avant de démonter...)
- rajouter des memory barriers un peu partout dans un driver sans avoir compris en détail le concept des memory barriers, en espérant débugguer quelque chose sans pour autant savoir pourquoi ça pourrait effectivement debugguer quelque chose (et bien que dans certains cas ça pourrait effectivement marcher suite à un gros coup de chance, ça relève néanmoins d'un comportement de type culte du cargo).
# allez plutôt lire la version en.
Posté par Guillaume Knispel . En réponse au journal La méthode du culte du cargo. Évalué à 4.
Exemples :
- balancer des "sync" dans un shell avant de rebooter (ou avant de démonter...)
- rajouter des memory barriers un peu partout dans un driver sans avoir compris en détail le concept des memory barriers, en espérant débugguer quelque chose sans pour autant savoir pourquoi ça pourrait effectivement debugguer quelque chose (et bien que dans certains cas ça pourrait effectivement marcher suite à un gros coup de chance, ça relève néanmoins d'un comportement de type culte du cargo).