Pourquoi sortir du cadre, pourquoi expérimenter ? Parce que c’est fun et que cela demande de réfléchir… La bidouille, le hacking ne sont rien d’autre que cela : détourner un objet de son usage premier pour découvrir de nouvelles possibilités.
Dans le domaine du code, c’est quasi-implicite et assez curieusement avec Scratch, nous abordons cette notion dès les premiers pas. En effet, quand il s’agit de déplacer un personnage, les enfants trouvent naturellement la commande « avancer » mais butent face à l’absence de la commande « reculer ». Nous apprenons alors à faire un premier détournement en faisant avancer le personnage de -10 pas. Cela n’a rien de logique et pourtant rapidement la question ne se pose plus et nous avançons de -10 pas ou plus comme si nous avions fait cela toute notre vie.
L’intérêt dans cela n’est pas le détournement en lui-même mais la compréhension du positionnement à l’écran et du déplacement dans l’espace. « Avancer » et « Reculer » sont des constructions purement humaines. La machine, quant à elle, comprend qu’un élément se situe à un point bien précis de l’écran et qu’il s’agit d’augmenter ou de diminuer la valeur des coordonnées X ou Y.
Lorsque l’on fait des ateliers autour du code et plus particulièrement de Scratch, l’habitude est souvent de limiter l’usage à la création de petits jeux vidéos, de dessins animés, d’animations simples. Certes, il ne faut pas mettre la barre trop haut pour les enfants mais il n’est pas interdit avec les plus aguerris d’essayer de pousser un peu plus loin. On rejoint ici le vaste débat sur l’usage de l’impression 3D trop souvent limité à la fabrication de petites figurines ou d’objets dont on pourrait en fait se passer. Il s’agit de dépasser le simple cadre de la démonstration pour aller à l’usage véritable. Comme je le dis souvent, je m’achèterai une imprimante 3D le jour où j’aurai trouvé personnellement mon usage au quotidien et non une fois tous les 36 du mois.
Cette réflexion, je la mène aussi au niveau de Scratch pour que cela ne reste pas qu’un outil d’apprentissage mais que l’on puisse aller plus loin dans son utilisation. Faire un dessin animé avec Scratch, c’est très bien mais qu’en est-il si soudain on demande la réalisation d’une application ? Les tenants et les aboutissants ne sont pas les mêmes et cela peut être extrêmement formateur. Certains projets sur Scratch sont particulièrement bien faits, à la limite du professionnel, et on sent que de nombreuses heures ont été passées autant sur la réflexion que la conception.
Se limiter à des petits programmes sous Scratch minimise l’aspect réflexion. Encore une fois, j’insiste : il ne s’agit pas de demander à des débutants de coder un programme particulièrement complexe. Une fois un certain niveau atteint, il peut être intéressant de pousser plus avant l’utilisation. On en apprend alors beaucoup plus sur Scratch mais aussi sur plusieurs points essentiels que l’on retrouve dans n’importe quel langage informatique : la conceptualisation du projet, l’optimisation du code et la définition d’algorithmes (liste non exhaustive…).
Prenons un simple exemple. Lors d’une session de code avec quelques amis, chacun s’est lancé sur un projet d’animation. Pour ma part, j’ai choisi de développer un générateur de mots de passe en Scratch. Il faut l’avouer : ce n’est pas le langage le plus adapté pour ce type d’usage mais cela m’a forcé à conceptualiser au maximum mon projet, à contourner certaines commandes et à développer une véritable réflexion. Je revenais en cela aux racines de la programmation où il ne s’agit pas que d’aligner des commandes.
Autre projet un peu plus complexe : lorsque j’ai effectué ma thèse, je me suis appuyé sur de petits logiciels permettant d’analyser rapidement des textes. J’ai pour cela utilisé des commandes dans le terminal de GNU/Linux mais aussi le langage Rebol. Ce dernier apporte un confort indéniable dans ce type de manipulations. Ainsi, par exemple, compter les occurrences de tous les mots d’un texte se fait en deux-trois commandes, mais on passe à coté de l’algorithme qui permet cette action.
On retrouve à ce point le concept de boîte noire que l’on évoque souvent au sujet de la technologie. Certes, la création de ce petit programme d’analyse de mes textes en Rebol m’a obligé à coder mais, en termes d’algorithmie, il n’y a pas eu grande réflexion. Avec Scratch, cela m’a obligé à reconsidérer entièrement le processus et à en définir les différentes étapes.
Ainsi :
- éliminer la ponctuation du texte : soit examiner le texte lettre par lettre et supprimer tous les caractères hors lettres, chiffres et espace
- établir une liste unique de mots : soit refaire le même processus mais en utilisant l’espace comme symbole de coupure entre chaque mot
- enfin, compter les occurrences : soit reprendre la liste, reparcourir le texte mot à mot et créer une liste de données parallèle
Quand on sait que Scratch ne permet pas la création de bases de données véritables, à part des listes, et que le texte ne peut être manipulé qu’au niveau de la lettre, cela constitue un vrai défi et un constant aller-retour entre des variables et des listes. Ainsi, ne serait-ce que pour repérer les mots, les lettres sont stockées une à une dans une liste jusqu’à ce que l’on rencontre un espace. Le mot est alors reconstitué et stocké. On efface la liste et on recommence jusqu’à rencontrer un nouvel espace.
Je n’ai effectué aucune révolution et il est certain que Scratch ne sera jamais utilisé pour analyser des textes. Trop fastidieux mais néanmoins l’exercice en valait la peine.
Classé dans:Code, Réflexions, Scratch Tagged: bidouille, code, hack, scratch