Journal La méthode du culte du cargo

Posté par  .
Étiquettes : aucune
-7
29
oct.
2008
Une petite citation:
En informatique, on parle de culte du cargo pour la programmation copier-coller où un programmeur emprunte un bout de code sans le comprendre et espère qu’il fera la chose attendue dans un tout autre contexte. À un niveau supérieur, ce phénomène peut également se retrouver dans l’adoption d’une méthode de développement logiciel par le chef de projet.


http://fr.wikipedia.org/wiki/Culte_du_cargo#Informatique

Une verion plus détaillé en angais:
http://en.wikipedia.org/wiki/Cargo_cult_programming

Il ne serait guère étonnant que le le logiciel libre encourage la programmation par cette méthode.

On peut probablement imaginer aussi que les concepteurs des langages objets soient des prêtres d'un culte du cargo qui tenaient à fournir un modèle de développement basé sur leur religion.

  • # Ô My God !

    Posté par  . Évalué à 2.

    J'ai utilisé la bibliothèque libstdc++ sans regarder le code et en espérant que ça fasse ce que je veux... Suis-je un adepte du culte ?
    Je vais de ce pas comprendre parfaitement toutes les bibliothèques que j'utilise avant de les utiliser.

    • [^] # Re: Ô My God !

      Posté par  . Évalué à -5.

      J'ai utilisé la bibliothèque libstdc++ sans regarder le code et en espérant que ça fasse ce que je veux...

      Commence déjà par comprendre bien le code du malloc. Ensuite tu pourras commencer à envisager l'idée de devenir apprenti programmeur.

      (Un conseil : reste loin de KDE)

      • [^] # Re: Ô My God !

        Posté par  . Évalué à 10.

        bah, il y en a bien qui font un journal en copiant collant un article de wikipedia... ;)

        blague à part, il me semble fréquent en programmation de recopier des parties de code (quand il est libre bien sûr), en visant que s'il fonctionne dans un contexte, il refonctionnera dans un autre similaire (parfois en faisant quelques ajustements bien entendu).

        Cela me semble un peu loin de l'idée initiale de ce culte du cargo, où là on serait plutôt à copier des formules issues du Necronomicon pour espérer faire tourner un programme en Perl avec... (comment ça cela y ressemble ??)

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

        • [^] # Re: Ô My God !

          Posté par  . Évalué à 5.

          blague à part, il me semble fréquent en programmation de recopier des parties de code (quand il est libre bien sûr), en visant que s'il fonctionne dans un contexte, il refonctionnera dans un autre similaire (parfois en faisant quelques ajustements bien entendu).


          Personellement je le fais de temps en temps, mais seulement avec du code bien doccumenté, propre et codé par des gens qui sont de toute façon bien meilleur que moi en C.
          Sans vouloir créer de troll, le code inclus dans la base du projet OpenBSD est une vraie mine d'or à ce niveau.

        • [^] # Re: Ô My God !

          Posté par  . Évalué à 2.

          Faut bien délimiter le code à copier/coller aussi. Reprendre une fonction complète dont on connait les paramètres en entrée, et le résultat en sortie, ça marche en général parfaitement. Reprendre un bout de code obscur en plein milieu d'une fonction, c'est déjà plus casse-gueule. D'où l'intérêt de découper le code en petites entités relativements indépendantes (en fonctions, méthodes et classes, quoi...).

          • [^] # Re: Ô My God !

            Posté par  . Évalué à 2.

            Reprendre une fonction complète dont on connait les paramètres en entrée, et le résultat en sortie, ça marche en général parfaitement.

            À condition que ta fonction ne te "cache" pas quelque-chose, par l'entremise d'une globale. Maintenant, effectivement, connaître des E/S d'une fonction devrait impliquer de connaître ce genre de détails. Mais autant dire que connaître les E/S d'une fonction revient à comprendre toute la fonction, en ce cas.

            • [^] # Re: Ô My God !

              Posté par  . Évalué à 2.

              Je veux bien que les abstractions aient dans certains cas tendance à fuir, et que dans certains cas ça puisse porter à conséquence, mais tout de même, on ne peut pas prétendre que pour comprendre le niveau fonctionnel il faille impérativement comprendre l'implémentation, dans tous les cas ! En appliquant le concept à l'extrême autant arrêter de faire de l'informatique, ou alors maîtriser parfaitement la physique, l'électronique, la logique, les ALU, MMU, etc, le code binaire, le langage d'assemblage, etc. jusqu'au niveau abstrait où tu programmes.

              En passant faudrait aussi arrêter d'utiliser des serrures pour la majeure partie d'entre nous. (et des vélos, etc.)

      • [^] # Re: Ô My God !

        Posté par  . Évalué à 3.

        Hello Mister Troll & FUD

        Pourquoi rester loin du code de KDE ?

        • [^] # Re: Ô My God !

          Posté par  . Évalué à 1.

          Personnellement, je ne vois aucun troll là dedans... tout le monde sera d'accord que plus la librairie est haut niveau et possède des dépendances, plus comprendre son fonctionnement implique connaitre ses dépendances, toussa...

          Le troll aurait été de parler du code de gnome...

        • [^] # Re: Ô My God !

          Posté par  . Évalué à 0.

          Pourquoi rester loin du code de KDE ?
          Tentative d'humour (ratée apparament).
          La bonne façon de coder en KDE est de reprendre les templates C++ et les bouts de codes de Trolltech/Nokia sans trop se poser de questions existentielles. Parceque les widgets transcient d'éditeur de texte avec copier coller multi-format dedans (par exemple) c'est pas tip top facile à capter. Par contre reprendre le code d'exemple de référence pour en faire un éditeur de texte c'est pas horriblement complexe.

          • [^] # Re: Ô My God !

            Posté par  . Évalué à 2.

            KDE et Qt n'aiment vraiment pas les templates ... Le code de Qt et de KDE n'est pas très compliqué à appréhender, et il est très bien fait (c'est du c++ bien optimisé)

    • [^] # Re: Ô My God !

      Posté par  . Évalué à 8.

      Il dit qu'il voit pas le rapport entre un copier-coller et l'utilisation d'une bibliothèque.

      • [^] # Re: Ô My God !

        Posté par  . Évalué à 3.

        Il dit que non seulement il ne voit pas le rapport mais qu'en plus la réutilisation de libraries (objet ou procédurales, il y a de bons programmeurs qui ne font pas du C, si si) lui semble une très bonne pratique du moment que c'est documenté et compris.

        Il dit qu'il a vu beaucoup plus de programmeur qui font parti du culte dans le logiciel propriétaire que dans le logiciel libre, et que plus c'est propriétaire plus il y en a, parce qu'il a fait pas mal de SSII différentes pour le constater, et qu'il pense que le fait de pouvoir bénéficier de libraries ouvertes et gratuites est un bon moyen de ne pas avoir à copier-coller-adapter à la va vite du code pas prévu pour répondre à tes besoins.

        Il dit enfin qu'en tant que développeur il n'aime pas les coucours de mesurage de kikicodelemieu, ni les trolls de cémoikisaitmieukodékvou, surtout quand ils sont nourris d'arguments mal compris.

      • [^] # Re: Ô My God !

        Posté par  . Évalué à 0.

        Simplement que l'utilisation d'un bibliothèque et un copier coller de code c'est EXACTEMENT la même chose. Un bibliothèque, n'est-ce juste l'utilisation de code écrit par quelqu'un d'autre ?

        Personnellement, ça m'arrive parfois que faire du copier coller de petit morceau de code, quand j'ai pas envie de me prendre la tête... Du moment que j'ai ce que je veux en entrée et ce que je veux en sortie, je vois pas où est le problème. Et je comprend absolument pas la critique que fait l'auteur de ce journal.

        • [^] # Re: Ô My God !

          Posté par  . Évalué à 5.

          Oh non, c'est TRES TRES loin d'etre la meme chose.

          Exemple:

          Tu prends le code de libpng et le met dans ton soft.

          Deux mois plus tard une faille de securite est reportee dans libpng.

          Les gens installent l'update de libpng, les softs l'utilisant sont proteges, toi avec ton code duplique tu l'as profond, et faut que tu sorts ton propre patch.

          C'est d'ailleurs une des grosses raisons d'utiliser une libraire en dynamique et pas en statique.

          • [^] # Re: Ô My God !

            Posté par  . Évalué à 3.

            il y a surtout le gains mémoire d'avoir qu'une seul instance de la librairie chargée. Pour faire du copier/coller d'une lib faut vraiment être un gorêt ça peut servir pour réduire les dépendances mais bon.

  • # Il ne faut pas se méprandre

    Posté par  (Mastodon) . Évalué à 5.

    Je pense que cette citation ne veut surtout pas dire qu'il ne faut pas faire de copier/coller.

    Elle veut dire que quand on fait un copier/coller il faut faire attention à ce que l'on fait, et que l'on devient en quelque sorte garant du code, contrairement à une bibliothèque par exemple. (evidemment on l'est toujours, mais c'est une façon de parler).

    Pour faire une analogie, je prendrais le garagiste auto. Vous avec une synchro morte sur votre boite de vitesse.
    - Bibliothèque : Le garagiste vous met une boite de vitesse neuve, il est donc responsble du montage, mais si la boite de vitesse déconne c'est la faute au constructeur
    - Copier/Coller de code : Il ouvre la boite et la répare, et devient garant de l'ensemble.

    On comprend au passage pourquoi de nos jours un garagiste faut bcp plus d'échanges standards que de réparations (-;

    Et j'achève par une magnifique phrase d'un collègue : Le copier/coller c'est aussi pratique que dangereux... et c'est très pratique !

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # allez plutôt lire la version en.

    Posté par  . Évalué à 4.

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

    • [^] # Re: allez plutôt lire la version en.

      Posté par  (site web personnel) . Évalué à 1.

      - balancer des "sync" dans un shell avant de rebooter (ou avant de démonter...)

      Arrête c'est pratique. Un ptit sync dans une console et on peut appuyer sur le bouton reset du pc >< en espérant ainsi garder le FS cohérent (les applis bah euh...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.