Présentation sur HN : un nouveau langage visuel pour enseigner le code aux enfants

 (pickcode.io)
4 points par GN⁺ 2023-11-23 | 1 commentaires | Partager sur WhatsApp
  • Pickcode est un IDE en ligne pour les cours d’informatique au collège et au lycée, pensé comme une plateforme simple et fiable qui réduit le temps que les enseignants consacrent à l’organisation des cours
  • La prise en charge des Chromebook, le suivi du travail des élèves, la collaboration en temps réel et la consultation de l’historique du code constituent ses principales fonctions de gestion de classe
  • Les enseignants peuvent personnaliser et organiser les supports de cours et les devoirs, et Pickcode précise qu’il ne propose pas d’assistance IA au code
  • Des enseignants estiment que l’outil a aidé les élèves à accéder plus facilement aux cours et à travailler de manière plus autonome en Java, Web Development, Python et AP Computer Science Principles
  • Plutôt qu’un IDE professionnel complexe, c’est un outil centré sur la création de cours et la gestion des élèves, ce qui peut en faire une option pour réduire les distractions en classe

Un IDE en ligne pensé pour la classe

  • Pickcode est un IDE en ligne destiné aux cours d’informatique au collège et au lycée
  • Il met en avant une plateforme simple et fiable pour faire gagner du temps aux enseignants dans la gestion des cours
  • Il propose un parcours d’accès de base menant aux pages de démarrage, de connexion et de tarification

Fonctions de gestion de cours et retours des enseignants

  • Les principales fonctions de Pickcode sont orientées vers le déroulement des cours et le suivi du travail des élèves
    • Fonctionne sur Chromebook
    • Permet de surveiller le travail des élèves
    • Prend en charge la collaboration en temps réel
    • Permet de consulter l’historique du code
    • Permet de personnaliser les supports de cours
    • Permet d’organiser les devoirs
    • N’inclut pas d’assistance IA au code
  • Les enseignants jugent l’interface simple, mais évolutive, et estiment qu’elle plaît à des élèves de plusieurs tranches d’âge
  • Des cas d’usage existent en Java, Web Development, Python et AP Computer Science Principles
  • Les retours indiquent que l’outil aide les élèves à l’utiliser plus facilement, à suivre leur travail et à progresser de manière autonome
  • L’équipe support est aussi jugée réactive et utile, et de nombreuses suggestions auraient été mises en œuvre

À lire aussi

1 commentaires

 
GN⁺ 2023-11-23
Avis sur Hacker News

  • Je me demande s’il y a une bonne raison d’exiger absolument les mots-clés var, set et call. BASIC n’avait rien de tel, et d’après mes souvenirs flous de mes premiers pas en programmation enfant, ce genre de mots-clés aurait été une complexité inutile.
    Par exemple, en LOGO, on écrivait simplement forward 10, left 90, alors que call paint.forward(10), call paint.left(90) paraît excessif et verbeux.

    • Les mots-clés sont là pour rendre chaque ligne facile à lire à voix haute. En particulier, dans set x = 7, le mot-clé indique clairement si l’on veut modifier une variable ou affirmer une égalité.
      Techniquement, dans le contexte d’un programme de dessin, on pourrait faire de forward() une méthode de premier niveau, mais nous avons choisi une approche un peu plus orientée objet en prévision du moment où les élèves passeront plus tard à un moteur de jeu 2D et devront contrôler plusieurs sprites.
    • Ici, les noms me semblent un peu peu intuitifs. forward et left ressemblent à des directions de déplacement, ce qui prête particulièrement à confusion quand on veut faire “aller le peintre vers la gauche”.
      En réalité, forward dessine/déplace et left est une rotation antihoraire qui accepte aussi des arguments négatifs ; call paint.draw(10), call paint.rotate(90) ou rotate("up") me parleraient donc davantage.
    • Ça va trahir mon âge, mais le premier BASIC que j’ai appris avait bien une commande gosub pour appeler des sous-routines.
      Au passage, comme les premiers BASIC faisaient ça, j’ai aussi numéroté les liens en commençant à 1 :)
      [1] https://picaxe.com/basic-commands/program-flow-control/gosub...
      [2] https://alandix.com/blog/2021/07/27/a-brief-history-of-array...
    • Dans le Basic que j’utilisais, il y avait LET X=10.
    • J’ai eu la même première impression. Je vois du code bien plus complexe toute la journée, mais en me mettant à la place d’un jeune enfant, je pense que ce bruit inutile pourrait être assez trompeur.

  • Je suis en train de présenter Godot à un enfant de 10 ans. Ces six derniers mois, il a créé des jeux avec Scratch et il aime Scratch, mais il était aussi frustré par ses limites.
    Je pensais qu’il apprécierait davantage un vrai langage de script, mais dès qu’il a commencé avec GDScript, il s’est vite découragé à cause de la quantité de frappe. Ses mains sont petites, donc apprendre la frappe au clavier est difficile, et taper des noms de variables et des appels de méthodes lui prend beaucoup trop de temps.
    Ça semble offrir un très bon équilibre, donc je vais regarder ça.

    • La limite liée à la vitesse de frappe est un très bon point, et bizarrement je n’y avais jamais pensé.
      Je fais des cours de Python très légers avec un enfant de 3 ans, et je me demandais pourquoi la progression était si lente par rapport à sa compréhension. Maintenant je vois bien que rien que taper des parenthèses et des guillemets lui prend beaucoup de temps.
      J’aime ce projet et j’ai hâte de l’essayer. Je suis en train de changer d’avis pour me dire que, pour la programmation destinée aux enfants, plus il y en a, mieux c’est. Les exposer à la dynamique du choix entre plusieurs langages et workflows peut être une bonne chose.
    • Je me demande pourquoi ne pas utiliser un clavier à la taille des enfants.
    • Mon expérience est similaire. J’ai fait découvrir Scratch à mon fils quand il avait 8 ans, et deux ans plus tard, il crée des jeux bien plus avancés que je ne l’aurais imaginé.
      Mais quand je lui montre un “vrai” langage de programmation, il me dit qu’il peut faire tout ça avec Scratch aussi, sans avoir à taper autant.
      Nous avons aussi essayé GameMaker ensemble et obtenu des résultats sympas, mais dès que j’ai le dos tourné, il retourne à ses projets Scratch. Parfois, je me demande s’il n’aurait pas mieux valu qu’il commence directement par le code, comme moi à l’époque ;-)
    • J’ai eu l’impression que la limite de Scratch tient au fait qu’il n’est pas évident pour un enfant de savoir comment gérer la complexité quand le programme devient trop gros.
      Cela dit, rien que pointer le problème et lui demander ce qu’il pourrait faire pousse l’enfant à y réfléchir et à trouver plusieurs approches possibles dans Scratch, par exemple en découpant le programme en plusieurs objets ou agents.
      Scratch est bien plus puissant que ne le laissent penser la première impression ou le premier programme.
    • GDScript est un langage étonnamment bon. À bien des égards, il est meilleur que Python, avec par exemple var et const.

  • Félicitations pour le lancement de Pickcode. Le niveau de finition est bon et on voit que c’est fait avec soin.
    Je pense qu’il existe au moins deux courants dans la programmation visuelle qui cherche à rendre la programmation plus accessible aux non-développeurs.
    Certaines tentatives réduisent, via une interface visuelle, la charge d’apprentissage de la syntaxe, mais ne masquent pas le caractère impératif ni la nécessité de la pensée algorithmique. On peut essentiellement y voir des IDE avec un autre niveau d’accessibilité, et je pense que Pickcode et Scratch entrent dans cette catégorie.
    L’autre courant explore d’autres paradigmes de programmation qui peuvent plus ou moins bien s’accorder avec des métaphores visuelles. Il amène aussi les utilisateurs à penser différemment de la programmation impérative. Node-RED est un bon exemple d’exploration de la programmation orientée flux, très proche parente de la programmation fonctionnelle réactive. LabVIEW en est aussi un proche parent, fondé sur le flux de données, mais avec davantage d’éléments un peu magiques. En pratique, il s’agit surtout de valeurs par défaut assez intelligentes et de noms de variables internes. Apple Automator me vient aussi à l’esprit.
    Je ne pense pas qu’une approche soit nécessairement meilleure ou pire que l’autre, mais quand on regarde les langages visuels, il est utile de garder en tête la distinction entre impératif et réactif, car elle change fortement l’expérience utilisateur finale.

    • Je garde le souvenir qu’enseigner un atelier sur un langage fonctionnel comme Elm à des débutants était en fait plus facile que de l’enseigner à des experts. L’esprit des débutants n’avait pas été contaminé par une forme de pensée impérative à la C.

  • Ce qui est vraiment chouette, c’est que « l’expérience d’édition du code est entièrement structurée, et qu’on choisit dans des menus au lieu de taper »
    J’aimerais qu’il existe quelque chose comme ça pour les programmeurs adultes : un éditeur structurel généraliste utilisable avec plusieurs langages de programmation. Quand on programme, l’intention qui vient d’abord à l’esprit est sémantique : définir une fonction ici, vérifier une condition là, etc.
    Dans ce cas, je ne vois pas pourquoi on ne transmettrait pas directement cette intention sémantique à l’éditeur. Pourquoi faut-il d’abord sérialiser son intention en chaîne de caractères, puis laisser l’éditeur la parser de nouveau, avec une méthode propice aux erreurs ? Cela laisse la place à des erreurs de syntaxe idiotes, comme des fautes de frappe, des parenthèses non appariées ou des erreurs de priorité des opérateurs ; il vaudrait mieux ne garder que les erreurs sémantiques.
    Un tel éditeur n’aurait pas forcément besoin d’être hostile au clavier. Un peu comme Excel ne l’est pas. Il pourrait fonctionner à la manière des méthodes de saisie des langues d’Asie de l’Est : on tape dans une « fenêtre de composition », puis on choisit dans une « fenêtre de candidats » avant d’insérer.

    • Il y a eu beaucoup de tentatives de ce genre. Ce n’est pas tant « une idée à laquelle personne n’a jamais pensé » qu’« une idée à laquelle énormément de gens ont pensé et qu’ils ont essayée, avant de se heurter très vite à de gros problèmes ».
      D’après ce que j’en comprends, le gros problème ici est qu’on finit par vouloir imposer que tous les états intermédiaires par lesquels passe le code soient sémantiquement valides. Sur le papier c’est séduisant, mais en pratique c’est une contrainte fatale. Même des personnes brillantes pensent d’abord de façon un peu lâche, puis corrigent le code plus tard, y compris à l’échelle d’une seule ligne. Forcer une validité à 100 % en permanence va fortement à l’encontre de la manière réelle de penser.
      J’ai tendance à considérer ce décalage comme fondamental. Je ne sais pas si ne serait-ce qu’une infime partie des humains pense de cette façon. On dit que même les mathématiciens professionnels, dans leur travail réel, prennent souvent de l’avance dans leur raisonnement puis comblent la rigueur ensuite. Si eux n’avancent pas strictement étape par étape, qui le ferait ?
      En programmation, on s’est stabilisé sur l’autocomplétion consciente de la sémantique et les suggestions, et il est fort possible que ce ne soit pas le simple résultat de la paresse, mais un véritable optimum.
      Peut-être que quelqu’un finira par résoudre le problème en poussant l’idée jusqu’au bout, mais même s’il y a quelque chose à récolter ici, je dirais que ce n’est pas un fruit à portée de main.
      Comme l’a dit saurik, le monde Lisp avec Emacs est ce qui s’en rapproche le plus, mais on peut quand même faire ce qu’on veut. Il y a simplement beaucoup d’outils qui aident à travailler de manière plus sémantique ; rien n’est imposé absolument.
    • J’ai l’impression qu’il y a déjà pas mal de choses comme ça. Scratch ou son cousin Snap(https://snap.berkeley.edu/snap/snap.html), un éditeur visuel de flux pour React(https://app.flowhub.io/#project/c111454c9fd2f74d37d1e8a4e739...), ainsi que des choses similaires comme https://retejs.org/.
    • Tu disais vouloir quelque chose comme ça pour les programmeurs adultes, mais Blythe Omnis 7 existait déjà en 1996, voire avant. C’était une plateforme/solution RAD qui prenait en charge à la fois Windows et Macintosh.
      J’ai obtenu un poste parce que j’étais le seul candidat à avoir entendu parler de ce logiciel. Tout ça parce que j’avais lu un court article dans un magazine.
      https://en.wikipedia.org/wiki/Omnis_Studio
      La programmation en cliquant dans des listes déroulantes et des popups n’était pas particulièrement bien conçue. Le programme ressemblait à une liste, et quand on voulait modifier une ligne, une boîte de dialogue modale s’ouvrait pour ne permettre de modifier que cette ligne-là. Évidemment, il n’y avait ni IntelliSense ni complétion de code.
      Rien que d’y penser, j’ai l’impression que mon PTSD remonte ; il me faudrait presque un verre ou une cigarette.
    • Par exemple, https://github.com/nocode-js/sequential-workflow-designer est conçu dans cet esprit. On programme la logique en plaçant des actions prédéfinies dans le bon ordre, et on programme à un haut niveau.
    • D’après ce que je sais, les gens qui utilisent Lisp avec Emacs vivent ce genre d’expérience. Ils peuvent penser et travailler en termes de formes, pas simplement de texte.

  • L’une de mes fonctionnalités préférées de Scratch, c’est qu’il est impossible de créer une erreur de syntaxe. Les blocs s’emboîtent, ou ne s’emboîtent pas. Je pense donc que les enfants peuvent s’y mettre et jouer plus facilement, sans explications séparées ni cours particuliers.
    Après avoir suivi les premières étapes du tutoriel du carré, j’ai cliqué un peu partout pour essayer par moi-même, et cela a généré call math paint.forward(), provoquant une erreur de syntaxe. Évidemment, cette ligne est inutilisable, mais je n’ai pas réussi à comprendre comment la commande math était censée fonctionner. Le tutoriel l’explique peut-être plus loin, mais je pense que la découvrabilité compte aussi.

    • Scratch ne permet pas de créer des erreurs de syntaxe, mais il ne se plaint pas non plus quand quelque chose n’est pas à sa place. Par exemple, si un bloc se détache pendant qu’on manipule les blocs, le programme s’exécute, mais ne fonctionne pas correctement.
      Quand il y a beaucoup de blocs, ils peuvent aussi se chevaucher, ce qui rend le problème assez difficile à trouver. Il y a aussi le cas des arguments manquants dans les blocs. Là encore, ça s’exécute, mais ça ne fonctionne pas.
      La programmation visuelle est clairement meilleure pour les enfants, mais je pense qu’il faut une approche plus stricte que Scratch et de meilleures capacités de débogage.
    • Un autre avantage de Scratch — plus précisément des blocs — est qu’ils peuvent être assez facilement adaptés à un nouveau langage. Nous avons utilisé des blocs pour permettre à des clients IoT de configurer des appareils afin qu’ils réagissent à des événements et envoient des événements à d’autres appareils, le tout étant converti en configuration JSON à téléverser.

  • C’est vraiment très beau. Cela me rappelle l’époque où, à la Khan Academy, nous développions une version basée sur des blocs de l’éditeur ProcessingJS.
    L’UI était un peu brute et difficile à maintenir, donc nous avons fini par l’abandonner, mais celui-ci semble assez fluide. J’aime le fait que cela offre davantage de chemins aux nouveaux programmeurs pour entrer dans la programmation typée. Je pense aussi que la plupart des environnements de code par blocs sont trop éloignés du vrai code.

    • Il me semble que ce type d’UI d’édition par blocs devrait pouvoir être généré automatiquement à partir d’une description abstraite de la grammaire, comme celles qu’utilisent les parseurs tree-sitter.
      Parfois, ce type d’édition par blocs est combiné à la vérification de types, ce qui permet de remplir intelligemment des « trous » via des requêtes. On le voit sans doute le plus clairement dans les éditeurs pour langages purement fonctionnels comme Agda.

  • Cela me rappelle le BASIC du ZX81. On ne tapait pas les mots-clés : le clavier spécial avait une touche pour chacun d’eux
    L’éditeur était sensible au contexte ; autrement dit, l’analyseur lexical piloté par le parseur, c’était l’utilisateur lui-même. À l’époque, comprendre si l’on voulait saisir un mot/nombre ou un mot-clé, et quel type de mot-clé, avait quelque chose d’un peu magique. En réalité, l’élément important sur le plan pédagogique, c’est que je le savais
    Ce qui comptait sur le ZX81, c’était qu’il stockait des tokens au lieu d’une représentation textuelle afin d’économiser de la mémoire. Il avait 1 Ko de RAM, mémoire d’affichage comprise. Il n’y avait pas non plus de GPU séparé. Le fait de parser à la saisie devait aussi rendre l’exécution plus rapide

  • Le site est très bien peaufiné, mais je ne suis pas entièrement d’accord avec l’objectif. C’est un IDE impressionnant, mais je pense que je me serais concentré sur un sous-ensemble de Python plutôt que sur un nouveau langage
    Sinon, il risque d’être ignoré parce que Scratch est plus facile à enseigner, et Python plus utile à apprendre. Le premier cas concerne les écoles qui ont des enseignants développeurs, le second les parents programmeurs qui apprennent à coder à leurs enfants
    En tant que développeur logiciel, j’ai aidé ma femme dans ses cours de programmation en primaire/maternelle, donc je connais un peu les problèmes de ce domaine

    • Je me demande s’il existe une alternative correspondant à un « sous-ensemble de Python ». Un pont naturel vers la « vraie » programmation serait intéressant

  • Articles liés :
    Show HN: Pickcode – A new way to introduce programming to kids - https://news.ycombinator.com/item?id=33562193 - novembre 2022, 14 commentaires
    Show HN: PickCode – An educational coding environment for students after Scratch - https://news.ycombinator.com/item?id=32230329 - juillet 2022, 32 commentaires
    Show HN: Pickcode – A graphical code editor for education - https://news.ycombinator.com/item?id=31426331 - mai 2022, 4 commentaires
    Les republications sont acceptables au bout d’environ un an, et les liens vers les fils précédents sont là pour les lecteurs qui veulent en savoir plus

  • Je travaille sur un concept similaire du côté de la programmation musicale :
    https://glicol.org
    Ce serait bien d’avoir quelques exemples directement sur la landing page
    Quand on essaie le cours, on se retrouve bloqué ; les indices sont à droite, mais ils ne sont pas très visibles. Il serait peut-être possible de les repositionner comme dans le Svelte Tutorial (https://learn.svelte.dev/tutorial/welcome-to-svelte)
    Je ne suis pas convaincu par la syntaxe. Je me demande si l’usage de LOGO a aussi été envisagé