Accéder au contenu.
Menu Sympa

educ - Re: [EDUC] Codage à l'école : Snap! ou Scratch

Objet : Liste de discussion du groupe de travail Éducation et logiciels libres de l'April (liste à inscription publique)

Archives de la liste

Re: [EDUC] Codage à l'école : Snap! ou Scratch


Chronologique Discussions 
  • From: rodolphe robles <rodolphe.robles AT sfr.fr>
  • To: educ AT april.org
  • Subject: Re: [EDUC] Codage à l'école : Snap! ou Scratch
  • Date: Thu, 10 Mar 2016 07:02:25 +0100
  • Authentication-results: sfrmc.priv.atos.fr; dkim=none (no signature); dkim-adsp=none (no policy) header.from=rodolphe.robles AT sfr.fr

Merci pour le lien et pour votre travail, ce projet Snappy est super et la possibilité de voir le code aussi en ligne de code, sympa !
L'idée d'un serveur aussi, génial.
Le 09/03/2016 14:57, Nicolas Decoster a écrit :
Bonjour,

Comme c'est mon premier post sur cette liste je me présente. Je suis animateur à la Compagnie du Code, une coopérative toulousaine pour l'apprentissage du code. Et un de nos cœurs d'activité est l'animation d'ateliers d'initiation à la programmation pour les enfants. Et, comme beaucoup de monde, pour l'instant on utilise essentiellement Scratch.

Donc ce fil de discussion m'intéresse particulièrement ! Voici en vrac quelques contributions au débat et à l'état des lieus sur le sujet.

Tout d'abord, très récemment j'ai vu passer un post sur les forums de Scratch (https://scratch.mit.edu/discuss/topic/181459/?page=1#post-1769291) qui laisse entendre qu'une version HTML5 de Scratch pourrait ressurgir (le projet d'origine dort depuis deux ans : https://github.com/LLK/scratch-html5). Si c'est le cas et que le résultat est aussi fonctionnel que le Scratch flash, ça résoudrait pas mal de problèmes. On aurait un logiciel libre qui serait uniquement basé sur des standards. Reste à voir comment il pourra être utilisé en "offline" (sans doute qu'en téléchargeant juste le fichier HTML qui va bien et ses dépendances ça devrait être OK).

Il existe un version de Snap! modifiée par l'INRIA, qui s'appelle Snappy! et qui ajoute la possibilité de visualiser le code _javascript_ associé au programme qu'on a codé avec des blocs. Plus d'info sur le site de Pixees : https://pixees.fr/?p=5099.

En termes de choix de technos, pour moi il est évident que Scratch en flash est une impasse, ne serait-ce que parce que c'est une techno vieillissante. A priori, et en attendant un éventuel Scratch en HTML5, Snap! qui est basé sur HTML5/_javascript_ semble donc un choix plus pertinent et plus pérenne. Sauf que quand on regarde d'un peu plus près le code de Snap! on se rend compte que tout le rendu graphique est fait dans un canvas HTML5. En gros, Snap! redessine tout à la main (les frames, les blocs Snap!, la scène, les fenêtres d'alertes...) plutôt que de se reposer sur le DOM et sur le moteur de rendu du navigateur. A mon avis c'est aussi une impasse technologique : Snap! réinvente la roue et se ferme à tout l'écosystème HTML5/_javascript_ qui est très dynamique.

Au final, dans l'absolu, mon sentiment avec ma vision actuelle (et partielle !) de l'écosystème est que le mieux serait sans doute une éditeur basé sur blockly/_javascript_ qui tournerait dans le navigateur en mode "webapp". Mais il faudrait que j'aille faire un tour du côté des différentes solutions évoquées ici (Phratch...).

Autre sujet, pour nos ateliers, la plupart du temps on se connecte sur le site du MIT pour travailler. Il y a des situations où cela peut poser problème (scratch.mit.edu dans les choux, pas d'accès à internet ou internet lent...). Et des fois il n'est pas possible d'installer Scratch offline. Pour contourner ces problèmes on s'est demandé si on pouvait héberger nous-même Scratch. Ce que nous avons commencé à expérimenter c'est de partir de ScratchX (https://github.com/LLK/scratchx) et de l'héberger nous même soit en ligne, soit sur un PC en mode hotspot Wifi dans la salle de l'atelier. Et pour l'instant on a une preuve de concept qui marche pas trop mal. L'autre avantage est de pouvoir héberger d'autres lutins et/ou arrières-plans en plus de ceux fournit par le MIT. L'autre avantage (bis) est de pouvoir (éventuellement, on ne l'a pas vraiment testé) ajouter des extensions ScratchX (Ar
 duino, ac
cès à des services de données en ligne comme les données sur l'ISS...).

Sur la question de l'utilisation d'un langage textuel pour l'initiation, je pense que pour une première confrontation à la programmation et à l'algorithmie, le mieux ça reste quand même les outils visuels. Je dirais même qu'on devrait commencer toute formation en informatique par du Scratch (ou assimilé) : ça permet d'entrer très vite dans ce qu'est la pensée informatique sans que le discours soit pollué par des problèmes de syntaxe, d'erreur de frappe, de compilation, de lecture de doc (pour choper les bons appels), etc. Avec Scratch, n'importe qui passe en une heure du statut d'ignorant complet en programmation au statut de programmeur d'un jeu complet et jouable. Et rien n'empêche de basculer sur un langage en mode texte dans un deuxième temps, une fois qu'un certain nombre de notions de base de la programmation auront été abordées.

a+

Nicolas Decoster


--
Pour vous désinscrire de cette liste : https://listes.april.org/wws/sigrequest/educ

Pour gérer votre abonnement à la liste educ et vos informations personnelles :
http://listes.april.org/wws/info/educ






Archives gérées par MHonArc 2.6.18.

Haut de le page