Re: Apprendre à programmer avec Unity

Posté par Bibi09 le 14/7/2022 17:20:39

Hello Redstar, merci pour ton retour.

Avant de commencer à voir comment aborder le sujet de la programmation, j'ai cherché pas mal de tutoriels. Beaucoup partent bille en tête pour expliquer ce qu'est une variable, un tableau, une fonction... Les pires, et ils sont nombreux, sont ceux qui fournissent un code prémâché que l'utilisateur doit simplement recopier sans réfléchir. C'est le genre de chose que je veux absolument proscrire de mes articles. Le lecteur doit être acteur, il doit réfléchir constamment. Je pense qu'une personne qui n'est pas assez curieuse sur le fonctionnement d'un ordinateur ne pourra pas apprendre correctement à programmer.

La programmation a cela de compliqué que n'importe qui peut l'apprendre dans son coin. Il est donc très et trop facile d'acquérir un semblant de connaissances sur le sujet et de partir du mauvais pied, de prendre de très mauvaises habitudes et de passer complètement à côté de certains automatismes bénéfiques. Or, on le sait, les mauvaises habitudes sont très difficiles à effacer.

Je suis fondamentalement contre la société actuelle que "nous" (l'Humain) avons développée au fil des décennies, où tout doit aller vite, être immédiat. J'aime personnellement prendre le temps de faire les choses et de les faire bien. L'apprentissage par explication ne peut pas être instantané, en quelques clics ou quelques minutes. Je ne vois pas pourquoi il faudrait que j'aille directement droit au but en passant sur des notions importantes sous prétexte que le lecteur n'en verrait pas le bénéfice immédiat.

Le but de cette intro est en effet de fournir un bagage minimal. Déjà, comment en est-on arrivés à avoir nos ordinateurs actuels ? Quel cheminement, quels objectifs, bref pourquoi a-t-on des ordinateurs ? A travers ces questions, je souhaite attiser la curiosité du lecteur. Pour le dire autrement, l'inciter à se cultiver sur le domaine qu'il veut découvrir. Quand on veut apprendre à faire quelque chose, il est indispensable de s'intéresser un minimum à l'outil qu'on va utiliser. C'est peut-être long et barbant mais si on n'accepte pas de lire un texte qui fourni clef en main un historique, je pense qu'on prend déjà une mauvaise voie.

Concernant le fonctionnement du CPU, attention à ne pas passer à côté du nom du site et du message sur l'accueil. Il me semble donner le ton dès le départ : j'y parle de programmation mais aussi de matériel !
Et là encore, c'est ma façon d'aborder l'apprentissage de la programmation. Il me semble impératif d'avoir un bagage minimal - ici il est très succinct - sur le fonctionnement d'un processeur et de la mémoire pour le programmer correctement. Sans ça, on peut faire prendre l'habitude de mal faire certaines choses. Comme je le disais, mon but est de correctement cadrer pour éviter au maximum la prise de mauvaises habitudes.

Tu me demandes à propos du cache du processeur : "est-ce un élément important qui va m'aider à programmer de manière optimale ?". Justement, si j'en parle, c'est que la réponse est "oui". J'en parle ici car ça fait la suite logique avec le sujet des registres abordé. J'essaie d'optimiser la fluidité de mon propos en évitant au maximum les aller-retours pour le lecteur. Quand j'en aurai besoin, il me suffira de proposer aux personnes qui en auraient besoin d'aller lire ce paragraphe sans être obligé de faire une coupure dans mon explication de la programmation.

Je peux très bien dire qu'il est mieux de lire un tableau 2D colonne par colonne en C#. Point. Mais pourquoi ? Et si on ne l'explique pas, est-ce que le lecteur va s'en souvenir et faire attention dans ses programmes suivants ?
Si maintenant j'explique que le C# est un langage dit "row-major", c'est-à-dire pour lequel les données d'une même ligne dans un tableau sont contiguës en mémoire. De plus, quand on accède à une donnée, le processeur charge aussi les autres données proches dans son cache pour anticiper une utilisation prochaine. On comprend mieux alors que lire les données colonne par colonne (donc successives en mémoire) est le plus optimal pour avoir un code efficace, car le processeur n'a pas besoin d'aller chercher encore des données qu'il n'a pas. Et par la même occasion, que toutes les structures de données (tableau, liste...) ne sont pas à utiliser n'importe quand et n'importe comment selon la situation.

Pour bien comprendre ma vision de la didactique, je travaille énormément sur la fluidité des chapitres et les suites logiques des thématiques abordées. Il m'est absolument impossible de parler d'un tableau de données sans expliquer comment fonctionne la mémoire, et il ne m'est pas possible d'expliquer la mémoire sans parler du processeur. Sinon j'aurais l'impression de brûler des étapes ou de ne pas pouvoir approfondir autant que possible les choses. Si dans la majorité des langages, on utilise l'indice 0 et non 1 pour le premier élément d'un tableau, ce n'est pas pour rien. Et ça, soit on laisse le lecteur dans l'ignorance totale, soit on ne peut pas l'expliquer si on n'a pas au préalable expliqué l'histoire des ordinateurs et leur fonctionnement.

Enfin, des langages comme Python ou C# sont certes des langages de haut niveau, éloignés des considérations matérielles. Cependant, ils héritent d'une histoire commune à tous les langages de programmation. Il me semble là encore nécessaire de bien comprendre que tous les langages, qu'ils soient récents ou non, abstraits ou non, ont tous des points communs pour des raisons purement historiques en s'inspirant les uns des autres, pour palier les faiblesses de leurs prédécesseurs, etc.

Donc pour résumer, AMHA, il m'est impossible d'expliquer **correctement** la programmation sans entrer a minima dans des détails techniques. Ou bien je laisse plein de vides que la personne cherchera - au mieux si elle est curieuse - à combler par elle-même et peut-être mal si elle ne trouve pas des explications claires à ses questions.

Je suis bien conscient que ma philosophie ne plaira pas à tout le monde. Cependant, comme je le disais il m'est impossible de faire les choses à moitié sans aller au fond des choses pour bien expliquer le pourquoi du comment. Cette introduction est certes longue, sans doute que d'autres personnes ne verront pas a priori le lien avec la programmation. Le "vite fait, mal fait", ce n'est pas dans ma méthodologie.
Je suis cependant persuadé que ceux qui daigneront poursuivre la lecture comprendront que tout est lié pour faciliter leur apprentissage ; que tout ce qui est écrit jusqu'à présent est intimement lié à des notions qui seront vues et expliquées au moment de programmer. Ce n'est qu'en comprenant le pourquoi du comment que le lecteur pourra mémoriser et donc avancer efficacement dans son apprentissage.