critique de Scratch

Pierre-Christophe Diviné · May 2016

Dans les nouveaux programmes de collège, la programmation fait son entrée, sans qu’aucun langage de programmation ne soit recommandé (ce que je trouve curieux...).

Néanmoins, dans les documents d’accompagnement, sur les sites des académies, dans le « sujet zéro » du nouveau DNB, etc. on voit s’installer comme une évidence l’utilisation de SCRATCH. Ce choix ne me semble être le résultat d’aucune discussion, d’aucun débat. Sur internet, ce logiciel est accueilli avec des tombereaux d‘éloges. (Pour commencer, tout le monde rappelle que SCRATCH a été produit par le MIT : sans doute parce que ce gage de sérieux est nécessaire pour compenser l’impression de ridicule qu’on a d’abord quand on découvre son design).

Pour ma part, je trouve que SCRATCH présente un grand nombre d’inconvénients. Suis-je le seul à le penser ? En voici une petite liste :

• il est lent
• l’éditeur est pénible (codes couleur pas très pratiques, pas de touche « annuler » ni « copier-coller », la méthode du « glisser-coller » est vite fastidieuse si on veut faire des choses un peu élaborées, les sauvegardes automatiques permanentes entérinent toutes les erreurs...)
• il fait par défaut des choses qu’on ne demande pas (exemple : le simple fait de créer un « lutin » (ou sprite) fait que celui-ci sera automatiquement affiché à l’écran : il faut préciser « cacher » si on ne le veut pas)
• certaines options (comme « si lutin touché ? alors ») fonctionnent mal ou de façon très imprécise

mais surtout :

• SCRATCH exécute toutes les boucles et toutes les instructions en même temps : je trouve que cela n’est pas propice à un apprentissage structuré de la logique de déroulement d’un programme
• les instructions sont éclatées en plusieurs fenêtres : une par lutin. Il est très compliqué de lire un tel programme, d’en avoir une vision d’ensemble.
• pour la même raison, mais aussi à cause du système des « briques d’instruction » un programme ne peut pas imprimé

enfin :

• SCRATCH réalise beaucoup de choses en très peu d’instructions (c’est un langage de très haut niveau). Les élèves auront l’impression de pouvoir programmer « Call of Duty » en quelques clics seulement ! Ça peut être attrayant dans un premier temps, mais c’est vite agaçant, car quand on veut faire autre chose que ce que la logique SCRATCH suggère, on est amené à devoir bidouiller, contourner, tricher et, finalement, très souvent renoncer.

samok · May 2016

Bonjour,

je suis en lycée cette année, mais comme je suis TZR, je regarde ce qui se passe au collège.
Je n'ai pas beaucoup manipulé scratch mais j'ai commencé à parcourir quelques livres et cahiers d'activité. Il est à noter que le langage python a maintenant aussi une interface|jeu d'instructions à la scratch où on dispose de briques de couleurs.

En première approximation, on assiste à la mise en place de l'équivalent de la lecture globale pour l'apprentissage de la programmation.

Vos objections techniques sont très intéressantes, et je suis sceptique aussi quant à la pertinence de ces outils.
Un bon vieux turtle me semble déjà bien comme début.
De plus en plus, quasiment tous les livres et cahiers qui paraissent ou sont à paraître ont un titre qui finit par en s'amusant, ce qui laisse entendre à ceux qui n'ont jamais programmé, les enfants en particuliers, qu'on va bien rigoler et surtout ne pas peiner à apprendre des choses. Moi, je dis : mensonge!

S

Dom · May 2016

SCRATCH n'est pas autre chose que La tortue LOGO qu'on trouvait, par exemple, sur MO5.

Je me souviens même des commandes : AG (avance gauche), TD (tourne droite) etc.

C'est inadmissible d'avoir imposé un logiciel particulier comme on le pressent sur un sujet 0 deposé sur le site Euler-Versailles des inspecteurs de l'académie de Versailles.

C'est vraiment comme en politique : je vais me plaindre de ce SCRATCH alors que le vrai fond du problème c'est l'Algorithmique (enfin on peut déjà s'interroger sur ce terme) dans les programmes de mathématiques.

Tout ça pour dire qu'en effet, c'est inadmissible, quel que soit le prisme par lequel on le regarde (sauf celui de la démagogie et celui du nivellement par le bas - expression bien galvaudée, pardon).

nicolas.patrois · May 2016

Autre trucs qui m’embêtent dans Scratch :
* Pas de moyen de pondre le code dans un éditeur de texte
* Tourne avec une technologie propriétaire

samok, je suis curieux de voir l’interface de Python avec des bidules colorés.

Rescassol · May 2016

Bonsoir,

Un autre problème est que Scratch n'est utilisé nulle part en dehors de l'EN.
A quoi sert d'apprendre quelque chose dans ses études, qui ne servira plus jamais après ?

Cordialement,

Rescassol

samok · May 2016

Bonsoir sieur Nicolas,

j'espère répondre à ta question avec ce scan, il est question du module pygame, un truc dans le genre, pas du bas niveau en tout cas.

Il y a un renvoi vers kidscod.in que je n'ai pas encore exploré parce que j'ai envie de vomir.

S

nicolas.patrois · May 2016

Pygame est visiblement derrière, mais le puzzle à droite ne fait pas partie de Pygame à ma connaissance.
Je pense que c’est un serveur bidouillé pour faire interagir Python avec un bazar en HTML5 mais je me trompe sûrement.

Pierre-Christophe Diviné · May 2016

Je précise une chose : pour ma part, je pense que le langage le plus simple et le plus adapté à ce que les nouveaux programmes demandent est le BASIC.

Voici un petit programme facile qui fait rebondir une balle sur les bords d'une fenêtre en BASIC, en C++ et sur SCRATCH (bien sûr sur SCRATCH, j'ai choisi de ne pas utiliser la fonction "rebondir sur les bords", pour être cohérent avec les autres langages). Personnellement, il me semble que celui en BASIC est le plus accessible. Qu'en pensez-vous ? (Si quelqu'un sait programmer ça en un autre langage, par exemple PYTHON que je ne maîtrise pas assez bien, ce serait intéressant).

1. en BASIC (en l'occurence : freebasic)
screen 15
dim as integer x, y, xx, yy, i
x=5 : y=11 : xx=1 : yy=1
for i = 1 to 1000
locate y,x : print " "
x=x+xx : y=y+yy
if x>48 or x<3 then xx=xx*-1
if y>35 or y<3 then yy=yy*-1
locate y,x : print"O"
sleep 50
next

2. en C++
#include <iostream>
#include <windows.h>
using namespace std;
HANDLE C = GetStdHandle(STD_OUTPUT_HANDLE);
COORD P;
void at(int x, int y)
{P.X = x ; P.Y = y ;
SetConsoleCursorPosition(C,P);}
int main()
{
int x=5 ; int y=5 ; int xx=1 ; int yy=1 ;
for(int i(1);i<=1000;i++)
{
at(x,y);cout << " ";
x+=xx;y+=yy;
if(x>76||x<2)xx=xx*-1;
if(y>22||y<2)yy=yy*-1;
at(x,y);cout << "O";
Sleep(20);
}
}

3. sur SCRATCH 52447

Dom · May 2016

[small]La balle qui rebondit sur les bords de l'écran était un virus, nommé virus ping-pong, dans les années 90 de mémoire. Hihihi. [/small]

michael · May 2016

nicolas.patrois : tu dis que Scratch tourne avec une technologie propriétaire, tu peux m'en dire plus, stp ?
En effet, "on" nous a vendu Scratch comme étant un logiciel libre et gratuit, qui tourne sur toutes les plate-formes (personnellement, je n'ai pas encore réussi à installer la V2 sur ubuntu) donc ce que tu dis m'intéresse assez.

Merci par avance.

m.

nicolas.patrois · May 2016

Le code source de Scratch 1 est disponible et protégé par la GNU/GPL2, certes, mais Scratch 2 a besoin d’Adobe Air pour tourner.

michael · May 2016

Ah bin oui, j'aurais pu trouver tout seul vu que c'est justement ce qui me pose souci pour l'installation sous ubuntu...
Merci pour ta réponse que j'avais pourtant "sous les yeux".

aléa · May 2016

Pour installer Adobe Air simplement, il suffit d'ajouter la source

deb http://update.devolo.com/linux/apt/ stable main

puis d'installer le paquet adobeair.

michael · May 2016

Merci aléa, je regarderai ça.

celastus · June 2016

Bonjour à tous. J'ai été informaticien pendant 15 ans et je suis maintenant prof de maths en collège. Je déteste la programmation impérative et la programmation par effets de bords (i.e. l'affectation), j'adore tout ce qui est récursif, voire récursif terminal, et mon langage fétiche est scheme (un dialecte de lisp).

Pour les 6èmes et 5èmes, je trouve la programmation visuelle par blocs très pratique : pas d'erreurs de syntaxe, une vision globale de tout ce qui est possible. Ainsi, scratch réponds bien à mes attentes.

La programmation événementielle, les clones, le parallélisme sont intéressants.

Le principal problème, pour moi, ce sont les blocs : il n'y a pas de fonction, un bloc ne peut pas renvoyer de valeur.

Sinon, je déteste python. La gestion des variables locales/globales, variable d'instance ou de classe, la gestion de la récursivité (pas de récursivité terminale !!), la syntaxe qui change d'une version à l'autre et n'assure même pas la rétro-compatibilité...

Mon exemple fétiche qui fait planter python :

def foo(n):
  print(n)
  foo(n+1)
 
foo(0)

Pour moi scratch n'est pas idéal, mais c'est un très bon compromis. Et surtout, il n'y a pas véritablement de concurrence...

[Écrire du code python sans les balises "code" (5ème bouton par la droite au dessus de la fenêtre d'édition) n'est ni lisible ni utilisable ! AD]

nicolas.patrois · June 2016

C’est normal que Python plante, ta fonction n’a pas de bloc d’instructions. :-D
Une boucle infinie aussi fait planter n’importe quel langage, on peut même en faire en Bash.

parisse · June 2016

celastus: vouloir absolument tout faire en recursif est a mon avis absurde, il y a des algorithmes pour lesquels c'est facile (par exemple la puissance rapide modulaire), et d'autres pour lesquels c'est catastrophiques (par exemple la suite de Fibonacci). De plus j'ai le sentiment par mon experience personnelle et d'enseignement que pour la tres grande majorite des gens, concevoir et mettre au point un algorithme recursif est difficile (en-dehors de situations ad-hoc) et necessite du recul en programmation plus classique.
Pour en revenir a scratch, le vrai probleme a mon avis ce n'est pas scratch, c'est plutot qu'il semble devoir etre impose d'en haut comme *le* langage pour la programmation au college (meme probleme que python en CGPE).

samok · June 2016

Bonsoir,

thèse_anti-thèse_foutaise a écrit:

Il n'y a pas de bon langage de programmation,
il n'y a que des bons programmeurs.

Personnellement j'aimerais que le langage soit imposé, ce qui n'est pas le cas encore sieur Parisse.

S

parisse · June 2016

Ça me parait contradictoire avec le reste de votre message. Je vois des inconvénients à imposer un langage, je ne vois pas où est le problème si on laisse l'enseignant choisir. Plus les élèves auront vu de langages, plus ils s'adapteront facilement, ce qui ne semble apparemment pas le cas des décideurs : même si formellement aucun langage n'est imposé au collège, on n'est pas dans la meme situation qu'au lycée.

christophe c · June 2016

J'ai téléchargé scratch (sans droit administrateur) au bahut sans problème. J'ai quelques élèves qui ont fait mumuse et se sont lassé vite. Il n'est pas plus facile qu'un langage de programmation classique (y a juste des couleurs et du clicage à la place de taper des mots)

Un EDI simplifié avec un compilateur attaché de free pascal est largement mieux que tout le reste pour initier des gens à programmer. Le pascal est parfait pour ça (tout est simple, tout en exigeant une déclaration des variables, bref l'idéal: il s'enseigne en 15mn chrono à n'importe quel non handicapé mental (alors que scratch, moi-même ai eu la flemme de lire le mode d'emploi lourdingue de ce truc))

paraisse a écrit:

celastus: vouloir absolument tout faire en recursif est a mon avis absurde, il y a des algorithmes pour lesquels c'est facile (par exemple la puissance rapide modulaire), et d'autres pour lesquels c'est catastrophiques

Je n'ai pas lu ce à quoi tu réponds, mais je suis en grand désaccord avec toi. Tu mélanges 2 choses profondément différentes: programmer et programmer de manière optimisée. Ca n'a rien à voir!! ***

La programmation récursive est naturelle justement (on demande "ce qu'on veut" au programme et il s'exécute, point!). C'est la programmation impérative qui ne l'est pas (enfin, qui exige de demander des choses hyperdétaillées, faut tout macher à la machine). La récursivité n'étant pas un confort implémenté mais une simple offre de la Nature (un compilateur qui offre la récursivité n'a rien de plus à faire qu'un compilateur qui l'interdirait), profitons-en.

*** c'est parce que les machines sont limitées qu'il est maladroit de programmer:

let f n = if n=0 then 0 else if n=1 then 1 else f(n-1)+f(n-2)

Il ne s'agit absolument pas d'une erreur ou d'une incompréhension de ce que veut dire programmer.

Pour les lecteurs, je précise: le script que j'ai écrit est maladroit parce qu'il va exiger de la machine qu'elle fasse 1024 calculs pour calculer f (10). En effet, le calcul de f(10) est d'appeler le calcul de f(9) et de f(8) et de les ajouter, puis le calcul f(9) va appeler le calcul de f(8) (une deuxième fois, bêtement pour rien) et celui de f(7) et les ajouter, etc.

Mieux vaut écrire : [small]let f n = if n=0 then 0 else if n = 1 then 1 else begin a:=0; b:=1; for i:=2 to n do (a,b):=(b,a+b); b end[/small]

parisse · June 2016

Les machines étant limitées, programmer veut pour moi aussi dire avoir conscience de l’efficacité de l'algorithme utilise (apparemment ce point de vue n'est pas partagé par le sujet 0 de capes info ce qu'on ne peut que regretter).
La récursivité (de même que l'utilisation de certains types non atomiques, d'ailleurs souvent associés) a un gros défaut qui est justement de masquer l’efficacité. Il faut sans doute maîtriser les suites récurrentes pour pouvoir évaluer l’efficacité d'un programme récursif hors cas très simples (par exemple la programmation de Fibonacci récursif fait intervenir une suite de Fibonacci pour en évaluer l’efficacité). Il est par contre parfaitement comprehensible a tout niveau qu'une boucle for definie (avec corps de boucle s’exécutant en temps constant) va nécessiter un temps proportionnel au nombre d’itérations inscrit dans le code source. D'ailleurs de mon expérience d'enseignement, la boucle for définie est la structure de contrôle qui est acquise le plus aisément.

[Leonardo Fibonacci (v. 1175-v. 1250) prend toujours une majuscule. AD]

christophe c · June 2016

Je suis d'accord avec toi qu'il ne suffit pas d'avoir compris la programmation pour programmer efficacement sur des machines limitées. Mais je voulais insister sur la différence essentielle entre les deux.

[small]C'est un peu comme en maths, où j'insiste dès que possible sur les forums et autre pour que ne soit pas confondu les recherches inabouties et les fautes: choses qui sont trop souvent confondues et qui ont provoqué les désastres** qu'on sait. C'est exactement la même problématique!!! Un stack overflow n'atteste pas d'une erreur de programmation mais juste des limites en mémoire de la machine. Une attente interminable idem (limite en vitesse)

** filer le corrigé (ou la manière de le produire) aux évaluations, suite à crash des pédagogies pour transmettre les sciences.[/small]

Nîmes-man · June 2016

Parisse a écrit:

Les machines étant limitées, programmer veut pour moi aussi dire avoir conscience de l’efficacité de l'algorithme utilise (apparemment ce point de vue n'est pas partagé par le sujet 0 de capes info ce qu'on ne peut que regretter).

Bonjour,

Il me semblait au contraire que cet aspect des choses était évoqué dans le premier problème du sujet (on commence par tracer avec turtle, on fait remarquer que c'est trop long, puis on fait utiliser matplotlib). Ai-je fait un contresens sur ce passage ou bien cette critique porte-t-elle sur d'autres passages du sujets ? Et dans ce cas, lesquels ?

Merci d'avance.

parisse · June 2016

Disons que c'est aborde de maniere un peu anecdotique.

Nîmes-man · June 2016

La critique adressée au sujet c'est donc qu'il manque de questions sur la complexité des algorithmes qu'on y fait écrire ?

parisse · June 2016

par exemple la Q7 du probleme 1 partie A est une simple application numerique relative a la longueur de la chaine obtenue, donc de la complexite en taille. On aurait pu se poser la question de la comparaison avec la complexite en temps pour obtenir cette chaine (tres souvent cette complexite est superieure, par exemple si on multiplie 2 polynomes) ou/et d'un trace sans derecursification.

christophe c · June 2016

parisse a écrit:

tres souvent cette complexite est superieure

Pas "très souvent", mais "toujours" (sauf si on triche dans le calcul, par exemple si on admet la chaine déjà écrite, etc)

parisse · June 2016

par tres souvent superieure, je voulais dire que tres souvent la complexite en espace est un petit o de la complexite en temps, meme si ce n'est pas toujours vrai (par exemple pour l'addition de polynomes).

christophe c · June 2016

Je ne comprends pas ta réponse. Par définition(?), un changement atomique de la mémoire nécessite 1 unité de temps. Donc la complexité en temps est toujours supérieure à la complexité en espace.

Sauf si tu prends d'autres définitions bien sûr... Mais je ne sais pas desquelles tu parles.

parisse · June 2016

Ca me semblait pourtant clarifie... Si on note T(n) la complexite en temps et E(n) en espace, en fonction de parametres de taille caracteristique n, alors on a bien sur E(n)<=T(n), tres souvent E(n)=o(T(n)) lorsque n tend vers l'infini (exemple multiplication de polynomes) et parfois T(n)=O(E(n)) (exemple addition de polynomes).
A ce sujet, un cas a disserter pour les amateurs de Python: si on fait une boucle for pour calculer la somme des n premiers entiers modulo 1234567, a-t-on E(n)=o(T(n)) ou T(n)=O(E(n)) ?
Bon, j'arrete la sur cette parenthese hors-sujet...

christophe c · June 2016

oups pardon, au lieu de lire "par très souvent", j'ai cru lire "pa[large]s[/large] très souvent", c'est pour ça que je n'ai pas compris.

Nîmes-man · June 2016

Merci pour la réponse parisse,

Pour aller dans ton sens, dans la partie B du problème 1, on fait engendrer une règle en tirant au hasard des chaines de caractères et en recommençant tant que la chaine n'est pas une règle valide... et le sujet ne fait pas remarquer que ce n'est pas très raisonnable.

bisam · June 2016

Lorsque j'ai fait le corrigé de cette épreuve, j'ai testé le nombre moyen d'essais à effectuer pour obtenir le nombre de règles demandées... Il est considérable !
En gros, il faut 35 essais pour obtenir une règle valide... mais en plus, il faut que la règle simplifiée soit suffisamment complexe (on en enlève encore 1 sur 2 en moyenne) et qu'elle ne soit pas présente dans la liste déjà constituée...

Pour obtenir 100 règles différentes, il faut donc produire près de 15000 règles au hasard !

Mais on est en train de détourner le sujet... Je pense qu'il vaut mieux continuer sur le sujet dédié.

samok · August 2016

Bonjour,

j'ai pris du temps pour voir le fonctionnement et les possibilités de scratch; par rapport au post de départ je dois reconnaître qu'il est quand même bien foutu, aussi vais-je pondérer et préciser quelques propos.
J'ai travaillé à partir des livres édités chez Eyrolles :
- cahier d'activités Scratch pour les kids,
- Scratch pour les kids,
ainsi que leurs fichiers disponibles sur leur site.

Il est vrai que du fait que cela intègre la programmation dite objet(+évènementielle), l'exécution du programme n'est pas nette lorsque des lutins (les objets en terme de programmation objet) fonctionnent en parallèle.
Ceci dit pour des programmes liés à des algorithmes de maths, la programmation procédurale avec les instructions fournis est suffisante.

-> Cela me paraît aussi valable qu'algobox pour ce qui est de l'affranchissement de la syntaxe.
-> Quant à la conception et l'utilisation des lutins cela me paraît très bien pour la technologie ou un E.P.I mais pour ce qui est des maths, à part le fait d'utiliser sa petite tête c'est, là où j'en suis, limité pour ce qui d'aborder des contenus mathématiques.
-> Cela me donne enfin un outil pour montrer que faire un jeu vidéo et loin de jouer à un jeu vidéo : j'ai toujours été frustré de ne pas pouvoir le montrer aux élèves qui souhaitent une orientation style "concepteur de jeux vidéo" parce que gamer.

voili, voilou

S

Vecteur Libre · August 2016

Un problème que je suis en train de découvrir, moi, c'est que ce n'est pas toujours intuitif et qu'il faut sans cesse chercher dans les différents menus où se trouve l'instruction qu'on cherche.
Par exemple, je vous donne mon petit problème : je suis en train de préparer le projet 1 qui se trouve dans myriade 5è. Il s'agit de faire un petit jeu dans lequel on doit guider un chat au clavier sur un parcours jusqu'à une souris en suivant un parcours qui est dessiné sur un arrière-plan. Mon problème se situe lorsque le chat s'approche suffisamment de la souris et qu'il faut changer d'arrière-plan (pour en quelque sorte passer au 2è niveau du jeu). Or je n'y arrive pas, la gestion des arrière-plans n'est pas du tout intuitive, ou alors j'ai une version de Scratch qui n'est pas celle du manuel, mais les commandes permettant de changer d'arrière-plan sont introuvables.
Je sais programmer, j'ai même été informaticien pendant plusieurs années, mais là je sèche depuis un bon moment.
Bref, si quelqu'un peut me montrer c'est sympa.

Vecteur Libre · August 2016

J'essaye d'être plus précis : il y a une commande qui s'appelle "basculer sur l'arrière-plan ..." ou alors "arrière-plan suivant", donc il doit y avoir moyen de s'en servir. Mais cette commande n'est accessible que pour des scripts relatifs au décor. Alors que si je veux déplacer mon chat je fais tourner un script relatif à l'objet chat. Et je n'arrive pas à faire le lien entre les deux, modifier le décor à partir d'un mouvement félin.

Vecteur Libre · August 2016

Et apparemment, tout ça vient du fait que la version que j'utilise est celle par défaut sur Ubuntu, à savoir 1.4, alors que dans les tutos on est sur une version 2, où la gestion des événements semble plus intuitive. Bref c'est ennuyeux de perdre du temps là-dessus au lieu d'enseigner les maths. Je suppose que d'autres élèves risquent comme moi de perdre beaucoup de temps sur des détails inutiles.

reuns · August 2016

à mon avis il faut utiliser Javascript+html, rien d'autre.
Notamment parce que les élèves pourront facilement montrer ce qu'ils ont fait. Et que de toute façon quitte à dégoûter 90% des gamins de la programmation, autant les dégoûter de javascript.

soleil_vert · August 2016

C'est bien la première fois que je lis un argument valable sur l'enseignement du javascript (:D

parisse · September 2016

Franchement, je ne vois pas pourquoi programmer en javascript (pas en un dialecte avec des raccourcis abscons) serait nefaste. Et javascript/HTML5 permet de montrer son programme sur n'importe quel navigateur sans installation prealable, ce qui est tres motivant, en tout cas c'est ce que je ressens personnellement.

Mauricio · September 2016

Parisse: toi qui est un expert qu'est-ce que tu conseilles exactement ? Si je comprends bien ta pensée
Scratch= dialecte avec des raccourcis abscons.
Javascript=Ok.
Python=plus tard, une fois qu'ils sont passés par la case Javascript.
C'est bien ça?
Mauricio

veronique77240 · September 2016

Bonjour à tous,

Je suis aussi très en colère de devoir me plier à une directive laissant si peu de liberté.
Toute interface est pour moi mensongère et "cache" aux élèves de nombreuses actions. Donner les moyens de simplicité revient à mentir aux élèves (tels les jouets magnétiques qui défient l'attraction terrestre). Je peux paraître extrémiste et, je sais, ce n'est pas le moment...
L'an dernier j'ai initié mes élèves de 3e à l'algorithmique en leur montrant qu'ils étaient déjà familiers de cette activité (algorithme d'Euclide, décomposition d'un nombre en base 2, suite de Fibonacci, flocon de Von Koch, conjecture de Syracuse, ou tout simplement la division posée). Toutes ces activités ont été présentées au cours de leur scolarité comme des jeux/énigmes depuis la 5e et ont été approchés de manière intuitive. Les français sont bien rompus à la pensée cartésienne. Les quatre préceptes de Descartes (que je vois avec mes 2nde) sont à la base de la pensée algorithmique.
Nous avons utilisé les calculatrices scientifiques pour coder les algorithmes après les avoir pensés et représentés sous forme d'organigramme puis en liste d'instruction en langage naturel. (en 5e déjà, un élève peut "jouer" être un ordi et executer pas à pas une pensée algorithmique telle que le changelment de base numérique; il s'amuse beaucoup à "planter" en cas d'erreur...).
L'important pour moi est le travail de la pensée et de la logique. L'optimisation est une question que j'ai aussi posée aux élèves de 3e après avoir étudié les actions que nous avions à notre disposition grâce aux calculatrices.
Alors, bien sûr, pas de jeux vidéos mais mes élèves étaient déjà bien mordus par la puissance qu'ils exerçaient sur la machine. Et ça, c'est sain car l'intelligence a besoin de revenir à l'homme dans leur esprit (le dieu ordinateur a souvent besoin d'être détronné). Ils étaient fiers et bluffés!

Le langage de programmation à mon avis doit être en cohérence avec les habitudes de la fac et des prépas. Je vois souvent python mais je considère que pour le collège, je n'ai pas besoin d'aller plus loin que la calculatrice.

Cette même 3e a eu un cours d'électronique/techno avant celui d'algorithmique où nous avons testé le transistor, à la base de toute calculatrice jusqu'au principe d'un additionneur en portes logiques). Encore une fois, mon but est de faire que les élèves sachent ce qui se cache dans les outils technologiques qu'ils utilisent et la calculatrice en premier lieu.

Ma question est: comment réagir afin de ne pas être soumis à scratch?

Bonne rentrée à tous!

Véronique

Mauricio · September 2016

Si on regarde les programmes Scratch n'est pas obligatoire. Il me semble que c'est juste une suggestion des inspecteurs. J'aurais aimé avoir l'avis d'experts.
L'avis d'un collègue qui enseigne en 4ème et qui a été autrefois informaticien est que Scratch ne vaut pas grand chose et que Algobox est bien pour s'initier. Ceci dit tant qu'à faire quelque chose pourquoi ne pas faire du python? Ca me semble bien plus simple que les calculatrices programmables qui me semble des objets archaïques.
On attend les recommandations des experts en informatique.

Mauricio

parisse · September 2016

Certaines calculatrices programmables ont un langage un peu sous-developpe (mais permettent quand meme d'ecrire des algorithmes de complexite comparable a ce qui peut etre fait avec algobox), alors que d'autres soutiennent tres bien la comparaison avec ce qu'on trouve dans un logiciel de calcul formel ou scientifique ou avec des langages de script comme python (en tout cas dans l'optique de ce qu'on peut faire dans l'enseignement). L'avantage de la calculatrice c'est qu'on peut l'utiliser pendant une partie d'un cours et donc bien l'integrer. L'avenir de l'enseignement de l'algorithmique, c'est sans doute la programmation directement sur smartphone.

Mauricio · September 2016

Quelles sont ces calculatrices? Personnellement je ne connais que la TI et la Casio et c'est franchement l'enfer. Je dirais qu'elles sont devenues pire que celle que j'avais quand j'ai passé le Bac (en 1989!).
M

aléa · September 2016

Bien d'accord avec Mauricio. Sur instruction des profs, j'ai acheté pour mes enfants des TI 83; l'interface est franchement pourrie.

nicolas.patrois · September 2016

La dernière de chez HP intègre un langage proche de Python.

Mauricio · September 2016

D'un autre côté, si les gamins peuvent mettre python sur leur smartphone (comme je n'ai pas de smartphone, je n'y avais pas pensé), la calculatrice ne sert plus à rien?

M.

nicolas.patrois · September 2016

Ils peuvent toujours y accéder via un site comme ideone.com.

noix de totos · September 2016

Mauricio a écrit:

[...] la calculatrice ne sert plus à rien?

Encore faudrait-il :

1. Autoriser l'emploi en classe des téléphones portables (et là, bonjour la discipline...) ;

2. Qu'ils sachent programmer en Python.

J'ajouterais que, même si l'interface d'une calculette n'est pas idéale (l'interface Casio surtout est pénible, la TI est relativement simple d'emploi, quoique basique) , elle permet au professeur du secondaire :

1. D'éviter d'aller en salle info et donc d'éviter tous les inconvénients liés à l'utilisation de ces salles (matériel qui ne fonctionne pas toujours, problème de réservation de la salle, etc) ;

2. De rester dans sa salle, et ainsi de ne pas passer toute une heure complète à faire ça !