Les analogies en informatique, partie 2

Comme je l’avais promis lors de mon dernier poste à propos de l’avenir de ce blog, je viens de publier un nouveau tutoriel sur zeste de savoir. Cette fois-ci c’est la programmation asynchrone qui est à l’honneur.

Ce tutoriel est dans les bacs depuis pas mal de temps mais si je lui consacre un article qui s’appelle “les analogie en informatique”, en écho au premier article qui tentait d’expliquer le fonctionnement d’un ordinateur, c’est avant tout parce que la rédaction de ce tutoriel a été fortement conditionnée au fait de trouver la bonne analogie.

En effet, le multithreading, l’asynchrone… ce sont avant tout des mots très techniques qui n’appellent aucun imaginaire “sexy”. Ni même un aspect “pratique de tous les jours” comme la création de site web avec ASP.NET. Pourtant, en informatique, ils sont la clef d’un programme réactif dans bien des cas. D’ailleurs, ce n’est pas pour rien que les différents SDK mobile ont une partie qui leur est dédiée et même qu’ils obligent certaines tâches à s’exécuter selon ces préceptes.

Alors comment faire comprendre à des non initiés des concepts aussi importants tout en leur permettant de pratiquer? En effet, c’est bien beau de comprendre à coup de pseudo code mais ça ne fait pas avancer la personne qui veut savoir faire son application mobile.

par le théorème de thalès appliqué à la relativité générale du quantum hilbertien…. (crédit http://lancelot.pecquet.org)

A l’opposé, les tartines de codes, c’est pratique pour le copier/coller mais on tombe vite dans le mode “git” où chacun apprend par coeur une floppée de commandes sans prendre le temps de les comprendre et les adapter ni même de transmettre leur savoir faire à quelqu’un.

credit xkcd

Sans faire durer le suspens, pour ceux qui n’ont pas cliqué sur le lien du tutoriel, j’ai choisi l’analogie de la cuisine. Et comme la private joke des cookies s’allie bien avec zeste de savoir (on a un easter egg sur la page de la cnil) c’est donc la création de cookies qui a guidé ce tutoriel.

cookies de clem à la cnil

Les derniers cookies de la communauté zds

Le principe est alors très simple : on “personnifie” le processeur et les concepts de file d’attente, d’événements, et de tâches apparaissent seuls !

Mon prochain défi, dans le cadre de la co-rédaction d’un tutoriel sur l’apprentissage de la programmation avec C# est de trouver une analogie qui explique ce qu’est la POO. Je pense en avoir trouver une pas trop mauvaise en fait, à coup de paiement des impôts. Mais ce “réflexe analogie” me fait un peu peur. Dans le précédent article, je critiquais les analogies de la présentation du fonctionnement des ordinateurs à coup de comparaison avec les organes car elles sont trop vite trop limitées. En plus elle donne une vison fausse de la situation.

Et c’est là que j’ai un poil peur, car comment être sûr que l’analogie que j’ai choisi, bien qu’elle me paraisse 100 fois meilleures que celles des autos marron et des personnages de RPG ne sera pas in fine tout aussi limitée? Il va falloir que je me tappe des heures de rédaction, de fignolage, de création de schémas pour comprendre à la fin que les limites de cette analogie sont les miennes. Je ne suis pas encore un “vieux de la vieille”, j’ai encore découvert des implémentations de pattern aujourd’hui même sans être sûr au départ que c’était “propre”.

Bref, ma question philosophique du jour : existe-t-il un “juste milieu” (ou au moins un juste barycentre) entre le too much code et l’abstraction théorique ad nauseam qui ne passe pas par des analogies douteuses? Ceux qui ont déjà enseigné, vous en pensez quoi?

5 thoughts on “Les analogies en informatique, partie 2

  1. C’est une question intéressante que tu poses là. Il existe bien sûr un juste milieu, mais il est dur à atteindre. Je pense aussi que les analogies ont leurs limites et quand je donnais des formations, je me suis vite rendu compte qu’il fallait les utiliser au minimum.

    L’idée c’est juste d’apporter une autre perspective, à un seul moment donné, pour expliquer le même problème. Faut pas que ça devienne systématique. Pour la POO par exemple, les termes utilisés de base sont déjà très parlants (objet, attribut, classe, méthode…). Prend 30 secondes et faire une analogie avec une voiture, c’est bidon mais ça apporte la petite perspective nécessaire pour bien saisir le sens de ces mots clef. Par contre, à mon sens il ne faut pas rester dessus et vite revenir dans le concret. Comme ça, on a pas peur d’être limité, ou de mal faire passer un concept.

    Pour faire plus court : la voiture, c’est classique, mâché et remâché, mais un enfant de 6 ans pourrait comprendre et c’est ce qu’on veut. 🙂 Par contre, une fois l’analogie faite, on repasse sur du concret (pas d’exercice à base de voiture par exemple).

    • Maîtriser les limites de ses analogies c’est important. C’est même primordial.
      Mais justement, la POO c’est un truc tellement abstrait et tellement éloigné de ce que le vocable de base veut faire apparaitre (objet, attribut…) que la limite de l’analogie de la voiture c’est… qu’elle est fausse immédiatement. Et du coup on aura beau fait comprendre le truc à un gamin de 6 ans, il ne pourra pas passer au concret avec ce qu’il vient de comprendre.

      • Je ne suis pas d’accord du tout, pour l’avoir vécu sur le terrain. Je ne trouve pas la POO vraiment éloignée de son vocabulaire, au contraire, c’est parlant… Non ? 🙂

        Quant à la voiture, l’idée c’est juste de dire :
        – classe -> voiture
        – attribut -> roue
        – méthode -> rouler
        – …

        Et repasser au concret, arrêter immédiatement avec l’analogie, sinon tu as raison, ça devient vite faux.

        En tout cas c’est en limitant les métaphores à de simples remises en perspectives que j’ai constaté la meilleure assimilation chez mes élèves. C’est bête, ça prend 30 secondes mais c’est nécessaire, et derrière rien ne vaut le concret (faire un exercice avec les voitures comme objets, c’est idiot et immédiatement faux comme tu le dis) ! 🙂

        • Bah justement, à part “roue” en tant qu’attribut, je trouve que voiture en tant que classe et rouler en tant que méthode c’est discutable, surtout voiture en tant que classe.
          Pour le reste, je suis d’accord, et j’apprécie le retour d’expérience, ça m’aide bien plus que tu ne le crois.

          • C’est vrai, ça reste discutable et c’est pour ça qu’à mon sens il ne faut pas aller plus loin. 😉 Mais ça permet de comprendre le concept et d’affirmer le sens les mots à retenir.

            En tout cas c’est toujours intéressant d’en discuter, ça fait partie des choses qu’on expérimente, qu’on affine, qu’on retient, mais derrière on n’a pas trop l’occasion de le partager.

Leave a Reply

Your email address will not be published. Required fields are marked *