(maths) Formation aux aménagements du programme de seconde : algo/programmation

neo-fit a écrit:
Ca devient un peu compliqué pour s’y retrouver.

Beau bazard effectivement.

Je crains que pour la majorité des collègues qui ne passent pas leurs journées sur des comptes twitter confidentiels ou des forums de profs qui glandent, cela se termine par "attendons de voir ce qui va en sortir". "Ce qui va en sortir" ayant de bonne chance d'être un programme en python simpliste de quelques lignes à analyser le jour du bac.

VinZT a écrit:Et sinon, il fait quoi dans la vie, ce M. Chéno, à part twitter comme un fou ?

IGEN.

Des esprits caustiques pourraient en déduire qu'un IGEN a finalement le temps de passer ses journées sur Twitter.

Balthazaard a écrit:
Pourquoi toujours tourner autour du pot...ce n'est pas compliqué, c'est impossible sauf comme tu l'admet pour les 5 au très grand maximum élèves auxquels tu fais allusion.
Ce déni de réalité explique pourquoi tout va foirer une fois de plus.

Je suis rassuré de ne pas être le seul à constater l'écart entre ce qui est affiché dans les programmes et la réalité de ce qu'on peut demander de la majorité des élèves.

Sinon, il y a des jours où on finit par se demander si on est vraiment mauvais, ou si on a des élèves spéciaux...Mais après avoir fait quelques lycées je n'ai pas l'impression que mes élèves soient spéciaux, et sans être excellemment bien vu je ne suis pas sûr d'être beaucoup plus calamiteux que d'autres.

celinesud a écrit:La critique sur edupython est ... surprenante ... ici, dans l'académie de Toulouse, c'est ce que l'on nous a "conseillé" ...

Pareil en bourgogne, nous avons été invité à utiliser edupython.

C'est rigolo que casio offre des calculatrices alors qu'ils font payer les émulateurs aux enseignants. C'est la raison pour laquelle je risque de recommander une ti à mes élèves l'année prochaine (leur clef usb contenant un émulateur portable est très pratique !). Bon j'ai quand même fait la demande de calculatrice gratuite car la mienne date un peu et ce n'était jamais agréable de pas avoir la même interface que mes élèves lorsqu'ils me posaient une question.

Twitter a écrit:Je n'aime [...] (pas) le print dans une fonction. Celui qui a écrit cet exemple n'a rien compris au concept de fonction.

Oh làlà que ça me met en rogne quand je lis ça. SI, une fonction peut utiliser un print, et ce n'est pas le mal, c'est juste des buts différents.

Anaxagore a écrit:Le problème n'est pas de déléguer notre travail éventuel de contrôle à une application pour s'épargner de la fatigue

C'est d'abord un moyen de gagner du temps pour expliquer, commenter, justifier, et amener davantage les élèves à réflêchir et faire preuve d'esprit critique.

, le problème est qu'il y a un monde entre le comportement que je décris et une réflexion complète qui permet de soutenir la validité d'un programme a priori

Ce n'est pas un objectif des aménagements à mettre en place. On demande de "les entraîner (les élèves) aux pratiques systématiques de vérification et de contrôle". Il n'y a aucune attente concernant une démonstration mathématique du bon fonctionnement d'un algorithme et de son implémentation.

et de l'expliquer par ses propres moyens intellectuels, sans béquille extérieure.

On tombe-là sur l'immaturité de nos élèves dans la maîtrise de la langue et de la logique. Ceci dépasse le cadre des mathématiques.

Sans nier aussi leur responsabilité à apprendre de leurs erreurs.

neo-fit a écrit:

Et puis rien ne dit que les paramètres sont flottants ; et a**b renvoie un entier quand a et b sont entiers.

— Yann Salmon (@yannsalmon) 17 mars 2018

Quand l'entier (type int) b est négatif cela retourne un flottant (type float).

Code:

>>> 5**-3
0.008


neo-fit a écrit:

Et aussi les

y = x + 2
return y (voire print(y))

au lieu de

return x + 2

— Yann Salmon (@yannsalmon) 12 juin 2016

L'intérêt de passer par y = x + 2, est de montrer qu'une fonction ne se réduit pas obligatoirement à un return, que le bloc constituant le corps de la fonction est un programme à part entière.

Il est facile de critiquer à posteriori les exemples de programmes qu'on peut donner à nos élèves. Mais ceux qui le font, oublient un peu vite que ce sont des adolescents et pas des adultes que nous avons en face de nous. Et qui pour la plupart ne jamais de programmation devenus adultes. Alors lire certains se plaindre qu'il ne faut plus mettre de print() dans les fonctions car des étudiants en informatique, adultes et ayant choisi cette voie-là, confondent avec le return ; cela ne me fera nullement changer d'avis.

Ils s'en fichent, ils parlent entre eux de leurs délires.

Dramatique de voir l'enseignement des mathématiques ruiné par ces gens-là.

S'ils ne sont pas content de l'enseignement de l'informatique par les professeurs de mathématiques, je leur propose venir le faire eux-mêmes.

Je ne leur laisse pas 5 minutes devant des élèves avant de partir en courant retourner sur leur petit twitter.

J'ai envie de dire : tant mieux pour toi.

Moi, par exemple, je me souviens on tapait déjà des Input et des Print dans le sublime Basic des CPC464.
J'ai envie d'ajouter : tant mieux pour moi, tout le monde s'en fout.

Ben voilà, c'est pareil.

Call_BB5A a écrit:

neo-fit a écrit:

Et puis rien ne dit que les paramètres sont flottants ; et a**b renvoie un entier quand a et b sont entiers.

— Yann Salmon (@yannsalmon) 17 mars 2018

Quand l'entier (type int) b est négatif cela retourne un flottant (type float).

Code:

>>> 5**-3
0.008


neo-fit a écrit:

Et aussi les

y = x + 2
return y (voire print(y))

au lieu de

return x + 2

— Yann Salmon (@yannsalmon) 12 juin 2016

L'intérêt de passer par y = x + 2, est de montrer qu'une fonction ne se réduit pas obligatoirement à un return, que le bloc constituant le corps de la fonction est un programme à part entière.

Il est facile de critiquer à posteriori les exemples de programmes qu'on peut donner à nos élèves. Mais ceux qui le font, oublient un peu vite que ce sont des adolescents et pas des adultes que nous avons en face de nous. Et qui pour la plupart ne jamais de programmation devenus adultes. Alors lire certains se plaindre qu'il ne faut plus mettre de print() dans les fonctions car des étudiants en informatique, adultes et ayant choisi cette voie-là, confondent avec le return ; cela ne me fera nullement changer d'avis.

Cela dénote quand même un mépris assez consternant pour les dits étudiants. On considère que puisqu'ils ne sont pas capables de faire la différence entre deux notions basiques (on parle de gens de plus de 20 ans, pas d'ados de seconde) on va les transformer en petits chiens de Pavlov dés la seconde en leur inculquant une crainte quasi religieuse de l'usage du "print" ou du "input". Consternant de bêtise...et "bêtise" n'est pas le mot auquel je pense.

Call_BB5A a écrit:

Anaxagore a écrit:Le problème n'est pas de déléguer notre travail éventuel de contrôle à une application pour s'épargner de la fatigue

C'est d'abord un moyen de gagner du temps pour expliquer, commenter, justifier, et amener davantage les élèves à réflêchir et faire preuve d'esprit critique.

, le problème est qu'il y a un monde entre le comportement que je décris et une réflexion complète qui permet de soutenir la validité d'un programme a priori

Ce n'est pas un objectif des aménagements à mettre en place. On demande de "les entraîner (les élèves) aux pratiques systématiques de vérification et de contrôle". Il n'y a aucune attente concernant une démonstration mathématique du bon fonctionnement d'un algorithme et de son implémentation.

et de l'expliquer par ses propres moyens intellectuels, sans béquille extérieure.

On tombe-là sur l'immaturité de nos élèves dans la maîtrise de la langue et de la logique. Ceci dépasse le cadre des mathématiques.

Sans nier aussi leur responsabilité à apprendre de leurs erreurs.

Minute de l'humour.

Balthazaard a écrit:

Call_BB5A a écrit:C'est d'abord un moyen de gagner du temps pour expliquer, commenter, justifier, et amener davantage les élèves à réflêchir et faire preuve d'esprit critique.

Minute de l'humour.

Non, non, combien de fois a-t-on entendu les élèves dire, à l'occasion d'un exercice, qu'il y a une erreur dans le sujet parce qu'ils ne trouvaient pas le même résultat qu'annoncé ? Là au moins, ils ne viennent pas dire que c'est l'ordinateur qui s'est trompé :-)

Tout ça en parlant d'élèves qui tremblent dans leur futal pour lire un énoncé de deux phrases et poser un équation du premier degré...

VinZT a écrit:Et sinon, il fait quoi dans la vie, ce M. Chéno, à part twitter comme un fou ?

Tweete depuis février 2016, 2812 tweets, je ne sais pas si c'est beaucoup.
En complément à ce qui a été répondu, je crois (pas sûr donc) qu'il fait (faisait ?) partie du groupe mathématiques au CSP.

Sinon, donc, il n'y a pas que l'Apmep (libre de ces publications) qui évoque Edupython, deux académies au moins l'ont conseillé en formation.
Pour voir comment l'information circule entre l'IGEN et les académies, si ça vous tente (je ne sais pas si c'est réservé aux abonnés twitter) :

#prof #maths #lycee
En formation pour les aménagements de seconde (algo/programmation), vous a-t-on conseillé Edupython ?
Merci pr vos RT (je n'ai pas bcp d'abonnés)
cc @Alice8076 @panlepan @mtiques

— Prudence (@br1borion) 22 mars 2018

#prof #maths #lycee
Utilisez-vous EduPython avec vos élèves de lycée dans le cadre du cours de maths ?
Merci pr vos RT (je n'ai pas bcp d'abonnés)
cc @Alice8076 @panlepan @mtiques

— Prudence (@br1borion) 22 mars 2018

Anaxagore a écrit:Tout ça en parlant d'élèves qui tremblent dans leur futal pour lire un énoncé de deux phrases et poser un équation du premier degré...

je n'en ai jamais vu trembler , par contre des harassés par l'effort à fournir au point de s'affaler sur la table souvent. D'autres suent, contemplent les yeux hagards comme si on leur avait donné une version en copte archaïque...

Alors que l'on tente de justifier la chasse aux input et print pour l'enseignement de l'#algo en #maths au #lycée par des arguments "scientifiques", que voit-on dans le manuel d'#ISN de Gilles Dowek (cité continuellement en référence) des programmes pleins d'input et de print.... pic.twitter.com/FLiFB1SbJ0

— algobox (@PascalBrachet) 20 février 2018

Le programme sur le second degré contient d'ailleurs de bien jolis tests d'égalité entre flottants.

Call_BB5A a écrit:Là au moins, ils ne viennent pas dire que c'est l'ordinateur qui s'est trompé :-)

Attends de rencontrer les futurs lycéens.
Si tu savais le nombre de fois où mes collégiens disent "M'sieur, l'ordinateur s'est trompé !"

Alors que l'on tente de justifier la chasse aux input et print pour l'enseignement de l'#algo en #maths au #lycée par des arguments "scientifiques", que voit-on dans le manuel d'#ISN de Gilles Dowek (cité continuellement en référence) des programmes pleins d'input et de print.... pic.twitter.com/FLiFB1SbJ0

— algobox (@PascalBrachet) 20 février 2018

Sur ce coup là, je trouve la critique un peu injuste. Il s'agit de rejeter l'usage des print() et des input() dans l'écriture des fonctions. Or les exemple cités, sont en fait des programmes et non des fonctions.

Maintenant le livre de Dowek adapté à Python n'est pas exempt de défauts. On peut lui reprocher plein de choses :

* ne pas utiliser l'indentation de 4 (PEP8)

* placer un "if" dans un "else" au lieu d'utiliser le mot clé "elif" qui améliore la lisibilité et réduit le niveau d'imbrication

* utiliser des compréhensions pour initialiser des tableaux d'éléments identiques là où l'opérateur * fait parfaitement l'affaire :

Code:

nom = [ "" ] * 10

# plus simple que

nom = ["" for i in range(0,10)]

* faire des successions de print() au lieu d'utiliser une sortie formatée :

Code:

x1 = (- b - sqrt(delta)) / (2 * a)
x2 = (- b + sqrt(delta)) / (2 * a)
print("Deux solutions : {} et {}".format(x1,x2))

# plus clair que

print("Deux solutions : ",end="")
print((- b - sqrt(delta)) / (2 * a),end="")
print(" et ",end="")
print((- b + sqrt(delta)) / (2 * a))

* présenter des bouts de code qui sont syntaxiquement incorrects, comme cet exemple avec e' qui n'est pas un nom de variable valide :

Code:

for i in range(e,e'):
   p

* utiliser systématiquement "range(0,n)" au lieu de "range(n)" , définir une fonction "def f (x)" mais faire des appels avec "f(x)" sans l'espace de séparation, écrire "n = n + 1" pour incrémenter n au lieu de faire un "n += 1"

Ces choix sont bien entendu justifiables, l'important étant d'abord de faire passer les concepts, mais du point de vue de la programmation en Python ça ne fait vraiment pas très propre.

Au final, on est vraiment pas aidé. Comment en effet, enseigner la programmation (en Python) quand on nous donne de part et d'autres des mauvais exemples...

Call_BB5A a écrit:Au final, on est vraiment pas aidé. Comment en effet, enseigner la programmation (en Python) quand on nous donne de part et d'autres des mauvais exemples...

Je ne crois pas que ce soit propre à la programmation, hélas... :|

Call_BB5A a écrit:
* placer un "if" dans un "else" au lieu d'utiliser le mot clé "elif" qui améliore la lisibilité et réduit le niveau d'imbrication
[...]
* utiliser systématiquement "range(0,n)" au lieu de "range(n)" , définir une fonction "def f (x)" mais faire des appels avec "f(x)" sans l'espace de séparation, écrire "n = n + 1" pour incrémenter n au lieu de faire un "n += 1"

Ces choix sont bien entendu justifiables, l'important étant d'abord de faire passer les concepts, mais du point de vue de la programmation en Python ça ne fait vraiment pas très propre.

Au final, on est vraiment pas aidé. Comment en effet, enseigner la programmation (en Python) quand on nous donne de part et d'autres des mauvais exemples...

Très sincèrement....C'est sans doute parce que je ne suis pas vraiment et j'en suis conscient un vrai développeur informatique, mais j'ai l'impression qu'on me parle du sexe des anges.

En encore plus quand Yann Salmon nous explique qu'il est insupportablement mauvais écrire

y = x + 2
return y (voire print(y))

au lieu de

return x + 2.

Cela me fait penser aux formateurs et aux collègues, qui, au moment de l'introduction des intervalles de fluctuation en seconde, m'expliquaient que lorsqu'on calculait un intervalle de fluctuation au seuil de 95% à l'aide de la formule [p-1/racine(n);p+1/racine(n)], il était très important que la première borne soit arrondie par défaut et la seconde par excès pour être sûr que l'intervalle contienne bien 95% des valeurs. Le pire est que certains de leurs élèves finissaient par le retenir...Mais qu'ils appliquaient de façon pavlovienne ce sur quoi ils savaient qu'ils allaient être évalués, sans probablement avoir rien compris sur le fond.

Pour parler de mon quotidien à moi : j'ai fait cette semaine une petite séance de programmation en Python avec une demi-classe de 1S, plutôt pas mauvaise et motivée au regard de la moyenne actuelle. Séance avec une série d'algorithmes axés autour du produit scalaire. Petite précision : la séance ayant été décidée à l'arrachée pour cause d'emploi du temps bousculé, j'ai repris une fiche de l'année dernière sans l'adapter aux nouvelles instructions en matière d'écriture des algorithmes. J’imagine déjà Laurent Chéno en train de me poursuivre avec un fouet sur Twitter.

La première question était du type

"On donne l'algorithme suivant.

Variables :
x 1 , y 1 , x 2 , y 2 réels
p prend la valeur x 1 x 2 + y 1 y 2
Afficher  p

Expliquez ce que fait cet algorithme puis programmez-la à l'aide de Python".


Et bien j'ai plusieurs élèves qui ont commencé par recopier, mot à mot et lettre à lettre, consciencieusement,

"Variable : x1, x2 réel..."

dans la fenêtre de l'éditeur. Je veux dire : ils ont vraiment tapé le texte a l'identique sans rien traduire.

Diagnostic : après quelques séances de python, et alors qu'ils sont censés avoir déjà fait de l'algorithmique en seconde, ces élèves n'ont toujours pas compris ce qu'était un langage de programmation ou une instruction.

Soyons juste : avec un peu (beaucoup) d'aide, la plupart des élèves du groupe ont fini par être capable, en une heure, d'écrire quelques courts programmes python qui tournaient. Par contre, ces séances sont très éprouvantes : l'autonomie des élèves est faible, on y est énormément sollicité pour les guider pas à pas.

Je peux comprendre la démarche des informaticiens qui souhaitent que les élèves prennent d'emblée de bonnes habitudes...Mais si on ne part pas d'une bonne analyse du niveau initial des élèves, qu'on n'analyse par les prérequis nécessaires à telle ou telle notion, qu'on ne raisonne pas en terme de progressivité ou d'étapes pédagogiques...J'ai peur, comme Balthasaard, qu'on aille au fiasco. Ou au truc dont la majorité des élèves retiendrons comme "un truc à faire automatiquement sans comprendre le jour du bac". Et sur ce point, j'ai l'impression que l'enseignement de l'informatique est très en retard sur celui des mathématiques, sans doute parce que l'enseignement des mathématiques est beaucoup plus ancien.

… ou comment passer une heure pour faire de la programmation sur un truc inutile (parce que, hein, xx'+yy' ça va quand même beaucoup plus vite à la main).
Les manuels sont remplis de ces exercices sans aucun intérêt, à part celui de faire un sacrifice au Dieu Numérique.
Je ne jette d'ailleurs pas la pierre à @Prezbo, ni aux autres collègues qui font ces activités, ayant moi-même eu la faiblesse d'y avoir eu recours.

Je sais bien qu'il faut commencer par des trucs simples, mais j'ai la faiblesse de penser que si on veut intéresser, autant que faire se peut, quelques élèves à la programmation, il faut faire des trucs où la machine apporte un réel avantage : dichotomie, sommes de termes, recherches exhaustives de solutions dans un cadre contraint, etc.
Je ne suis d'ailleurs pas sûr que cela soit faisable avec des lycéens actuels (la surcouche informatique au moment même où on découvre la notion mathématique générant sans doute plus de confusion qu'autre chose), et je suis à peu près persuadé qu'il n'y aura aucun bénéfice sur la compréhension mathématique. J'avais fait de la dichotomie (avec algobox, honte à moi) il y a quelques bonnes années, avec une bonne classe de seconde (je veux dire des élèves qui travaillent, écoutent, et qui savent calculer de tête -3+5 sans se tromper), cela avait à peu près bien marché, mais surtout j'avais eu le temps de prendre mon temps pour le faire (étant en avance sur le programme). Algobox a ses défauts, mais, en s'affranchissant des contraintes du langage, on se focalisait finalement sur l'algorithme en lui-même …

Les mandarins qui nous infligent ces trucs n'ont aucune idée réelle de ce que cela signifie concrètement d'avoir 4 fois 55 minutes de mathématiques par semaine, en seconde ou en première S. Comment peuvent-ils penser, alors même que l'étude des algorithmes n'est pas une franche réussite, que la compliquer par la prise en charge d'un langage de programmation pourra améliorer les choses ?

Quant aux querelles byzantines via touiteure sur le bien-fondé des fonctions et autres input/print, elles sont en effet assez ahurissantes face à la réalité du terrain.

On est bien d’accord. Ce que tu dis là Preszbo ne me surprend pas. Apprendre un langage demandé du temps. Demandez donc aux profs de langue? Ce n’est pas pour rien qu’ils font régulièrement des évaluations de vocabulaire. Perso en Seconde je leur fais apprendre le langage petit à petit. Enfin apprendre, façon de parler : les instructions propres aux affectations, aux types de variables, aux fonctions, puis aux instructions conditionnelles, puis aux boucles, le tout jalonné par les différentes bibliothèques. Ça en fait déjà du langage! Et pas de manuel pour le moment pour unifier le tout. Feuilles collées à la fin du cahier mais comme c’est déjà leur troisième, impossible pour eux de retrouver tout le vocabulaire pour programmer. Du coup, c’est toujours moi qui demande si qqn se souvient comment on va traduire telle instruction de l’algorithme. Généralement, 5 au grand maximum s’en souviennent... Vinzt, je suis d’accord avec toi qu’il faut que la programmation apporte quelque chose. Calculer un PS, c’est vrai que c’est assez limité. Après c’est vrai aussi que pour s’approprier le langage, il faut commencer par des choses simples. Le plus compliqué qui repose sur un vrai raisonnement mathématique nécessite déjà une bonne maîtrise du langage de programmation, donc impossible en début d’année, contrairement à ce qu’on m’a vendu en formation.

Prezbo a écrit:

Call_BB5A a écrit:
* placer un "if" dans un "else" au lieu d'utiliser le mot clé "elif" qui améliore la lisibilité et réduit le niveau d'imbrication
[...]
* utiliser systématiquement "range(0,n)" au lieu de "range(n)" , définir une fonction "def f (x)" mais faire des appels avec "f(x)" sans l'espace de séparation, écrire "n = n + 1" pour incrémenter n au lieu de faire un "n += 1"

Ces choix sont bien entendu justifiables, l'important étant d'abord de faire passer les concepts, mais du point de vue de la programmation en Python ça ne fait vraiment pas très propre.

Au final, on est vraiment pas aidé. Comment en effet, enseigner la programmation (en Python) quand on nous donne de part et d'autres des mauvais exemples...

1) Très sincèrement....C'est sans doute parce que je ne suis pas vraiment et j'en suis conscient un vrai développeur informatique, mais j'ai l'impression qu'on me parle du sexe des anges.

2) En encore plus quand Yann Salmon nous explique qu'il est insupportablement mauvais écrire

y = x + 2
return y (voire print(y))

au lieu de

return x + 2.

Cela me fait penser aux formateurs et aux collègues, qui, au moment de l'introduction des intervalles de fluctuation en seconde, m'expliquaient que lorsqu'on calculait un intervalle de fluctuation au seuil de 95% à l'aide de la formule [p-1/racine(n);p+1/racine(n)], il était très important que la première borne soit arrondie par défaut et la seconde par excès pour être sûr que l'intervalle contienne bien 95% des valeurs. Le pire est que certains de leurs élèves finissaient par le retenir...Mais qu'ils appliquaient de façon pavlovienne ce sur quoi ils savaient qu'ils allaient être évalués, sans probablement avoir rien compris sur le fond.

Pour parler de mon quotidien à moi : j'ai fait cette semaine une petite séance de programmation en Python avec une demi-classe de 1S, plutôt pas mauvaise et motivée au regard de la moyenne actuelle. Séance avec une série d'algorithmes axés autour du produit scalaire. Petite précision : la séance ayant été décidée à l'arrachée pour cause d'emploi du temps bousculé, j'ai repris une fiche de l'année dernière sans l'adapter aux nouvelles instructions en matière d'écriture des algorithmes. J’imagine déjà Laurent Chéno en train de me poursuivre avec un fouet sur Twitter.

La première question était du type

"On donne l'algorithme suivant.

Variables :
x 1 , y 1 , x 2 , y 2 réels
p prend la valeur x 1 x 2 + y 1 y 2
Afficher  p

Expliquez ce que fait cet algorithme puis programmez-la à l'aide de Python".


Et bien j'ai plusieurs élèves qui ont commencé par recopier, mot à mot et lettre à lettre, consciencieusement,

"Variable : x1, x2 réel..."
3) dans la fenêtre de l'éditeur. Je veux dire : ils ont vraiment tapé le texte a l'identique sans rien traduire.

Diagnostic : après quelques séances de python, et alors qu'ils sont censés avoir déjà fait de l'algorithmique en seconde, ces élèves n'ont toujours pas compris ce qu'était un langage de programmation ou une instruction.

Soyons juste : avec un peu (beaucoup) d'aide, la plupart des élèves du groupe ont fini par être capable, en une heure, d'écrire quelques courts programmes python qui tournaient. Par contre, ces séances sont très éprouvantes : l'autonomie des élèves est faible, on y est énormément sollicité pour les guider pas à pas.

Je peux comprendre la démarche des informaticiens qui souhaitent que les élèves prennent d'emblée de bonnes habitudes...Mais si on ne part pas d'une bonne analyse du niveau initial des élèves, qu'on n'analyse par les prérequis nécessaires à telle ou telle notion, qu'on ne raisonne pas en terme de progressivité ou d'étapes pédagogiques...J'ai peur, comme Balthasaard, qu'on aille au fiasco. Ou au truc dont la majorité des élèves retiendrons comme "un truc à faire automatiquement sans comprendre le jour du bac". Et sur ce point, j'ai l'impression que l'enseignement de l'informatique est très en retard sur celui des mathématiques, sans doute parce que l'enseignement des mathématiques est beaucoup plus ancien.

1) C'est bien évidemment consternant. Pour certains, genre --moi je suis un pro de Python--- on doit non pas initier avec peine à une forme de pensée nouvelle mais former des spécialistes...bien sur n=n+1 c'est nul tandis que n+=1  c'est très clair et combien plus classe...surtout devant les newbies.
Bine sur il faut donner de "bonnes habitudes"  mais à force de tout noyer sous les bonnes habitudes l'essentiel passe à côté...enfin chacun sa dope.

2) Ça aussi ,cela finit de me toucher, je pense qu'on est beaucoup à faire autre chose que des maths...musique...sport ...etc que dans ces domaines on a parfois une compétence plus forte que dans notre matière. Je crois qu'on a tous rencontré ces ayatollahs de bazar avides de pouvoir qui professent leurs lubies comme étant LA vérité, j'en ai vu pas mal en équitation où ils viennent vous dire que vous faites mal mais se gardent bien de vous montrer commet ils feraient...eux. J'ai vu aussi des gens au sommet, sans rien à avoir à prouver, et j'ai été frappé par le recul dans leur propos et somme toute la modestie affichée face à la réalité des choses.

3) Dans une séance, il y a longtemps, j'avais fait programmer un digicode...il y avait un print "taper le code"...qui était le dicigode demandé....beaucoup d'élèves avaient enregistré "taper le code" comme étant une instruction du langage préalable à l'écriture du code.  Donc je retrouvais "taper le code" au début de n'importe quel programme.  Cela prouve le niveau de compréhension et comme tu dis le degré de réflexe pavlovien que nous développons en lieu d'apprentissage.

Prezbo a écrit:

Call_BB5A a écrit:
* placer un "if" dans un "else" au lieu d'utiliser le mot clé "elif" qui améliore la lisibilité et réduit le niveau d'imbrication
[...]
* utiliser systématiquement "range(0,n)" au lieu de "range(n)" , définir une fonction "def f (x)" mais faire des appels avec "f(x)" sans l'espace de séparation, écrire "n = n + 1" pour incrémenter n au lieu de faire un "n += 1"

Ces choix sont bien entendu justifiables, l'important étant d'abord de faire passer les concepts, mais du point de vue de la programmation en Python ça ne fait vraiment pas très propre.

Au final, on est vraiment pas aidé. Comment en effet, enseigner la programmation (en Python) quand on nous donne de part et d'autres des mauvais exemples...

Très sincèrement....C'est sans doute parce que je ne suis pas vraiment et j'en suis conscient un vrai développeur informatique, mais j'ai l'impression qu'on me parle du sexe des anges.

En encore plus quand Yann Salmon nous explique qu'il est insupportablement mauvais écrire

y = x + 2
return y (voire print(y))

au lieu de

return x + 2.

Cela me fait penser aux formateurs et aux collègues, qui, au moment de l'introduction des intervalles de fluctuation en seconde, m'expliquaient que lorsqu'on calculait un intervalle de fluctuation au seuil de 95% à l'aide de la formule [p-1/racine(n);p+1/racine(n)], il était très important que la première borne soit arrondie par défaut et la seconde par excès pour être sûr que l'intervalle contienne bien 95% des valeurs. Le pire est que certains de leurs élèves finissaient par le retenir...Mais qu'ils appliquaient de façon pavlovienne ce sur quoi ils savaient qu'ils allaient être évalués, sans probablement avoir rien compris sur le fond.

Pour parler de mon quotidien à moi : j'ai fait cette semaine une petite séance de programmation en Python avec une demi-classe de 1S, plutôt pas mauvaise et motivée au regard de la moyenne actuelle. Séance avec une série d'algorithmes axés autour du produit scalaire. Petite précision : la séance ayant été décidée à l'arrachée pour cause d'emploi du temps bousculé, j'ai repris une fiche de l'année dernière sans l'adapter aux nouvelles instructions en matière d'écriture des algorithmes. J’imagine déjà Laurent Chéno en train de me poursuivre avec un fouet sur Twitter.

La première question était du type

"On donne l'algorithme suivant.

Variables :
x 1 , y 1 , x 2 , y 2 réels
p prend la valeur x 1 x 2 + y 1 y 2
Afficher  p

Expliquez ce que fait cet algorithme puis programmez-la à l'aide de Python".


Et bien j'ai plusieurs élèves qui ont commencé par recopier, mot à mot et lettre à lettre, consciencieusement,

"Variable : x1, x2 réel..."

dans la fenêtre de l'éditeur. Je veux dire : ils ont vraiment tapé le texte a l'identique sans rien traduire.

Diagnostic : après quelques séances de python, et alors qu'ils sont censés avoir déjà fait de l'algorithmique en seconde, ces élèves n'ont toujours pas compris ce qu'était un langage de programmation ou une instruction.

Soyons juste : avec un peu (beaucoup) d'aide, la plupart des élèves du groupe ont fini par être capable, en une heure, d'écrire quelques courts programmes python qui tournaient. Par contre, ces séances sont très éprouvantes : l'autonomie des élèves est faible, on y est énormément sollicité pour les guider pas à pas.

Je peux comprendre la démarche des informaticiens qui souhaitent que les élèves prennent d'emblée de bonnes habitudes...Mais si on ne part pas d'une bonne analyse du niveau initial des élèves, qu'on n'analyse par les prérequis nécessaires à telle ou telle notion, qu'on ne raisonne pas en terme de progressivité ou d'étapes pédagogiques...J'ai peur, comme Balthasaard, qu'on aille au fiasco. Ou au truc dont la majorité des élèves retiendrons comme "un truc à faire automatiquement sans comprendre le jour du bac". Et sur ce point, j'ai l'impression que l'enseignement de l'informatique est très en retard sur celui des mathématiques, sans doute parce que l'enseignement des mathématiques est beaucoup plus ancien.

Les mathématiques sont une science, l'informatique est une technique, que l'on cherchera en vain à faire passer pour profonde au moyen d'un jargon et de discussions oiseuses sur le sexe des anges. Quelqu'un qui a été formé correctement aux mathématiques fera un informaticien honorable en quelques mois, cela s'est vu au moment de la bulle internet. Quelqu'un qui n'a qu'une formation informatique ne sera jamais un bon praticien des mathématiques.

VinZT a écrit:… ou comment passer une heure pour faire de la programmation sur un truc inutile (parce que, hein, xx'+yy' ça va quand même beaucoup plus vite à la main).
Les manuels sont remplis de ces exercices sans aucun intérêt, à part celui de faire un sacrifice au Dieu Numérique.
Je ne jette d'ailleurs pas la pierre à @Prezbo, ni aux autres collègues qui font ces activités, ayant moi-même eu la faiblesse d'y avoir eu recours.

Je sais bien qu'il faut commencer par des trucs simples, mais j'ai la faiblesse de penser que si on veut intéresser, autant que faire se peut, quelques élèves à la programmation, il faut faire des trucs où la machine apporte un réel avantage : dichotomie, sommes de termes, recherches exhaustives de solutions dans un cadre contraint, etc.
Je ne suis d'ailleurs pas sûr que cela soit faisable avec des lycéens actuels (la surcouche informatique au moment même où on découvre la notion mathématique générant sans doute plus de confusion qu'autre chose), et je suis à peu près persuadé qu'il n'y aura aucun bénéfice sur la compréhension mathématique. J'avais fait de la dichotomie (avec algobox, honte à moi) il y a quelques bonnes années, avec une bonne classe de seconde (je veux dire des élèves qui travaillent, écoutent, et qui savent calculer de tête -3+5 sans se tromper), cela avait à peu près bien marché, mais surtout j'avais eu le temps de prendre mon temps pour le faire (étant en avance sur le programme). Algobox a ses défauts, mais, en s'affranchissant des contraintes du langage, on se focalisait finalement sur l'algorithme en lui-même …

Les mandarins qui nous infligent ces trucs n'ont aucune idée réelle de ce que cela signifie concrètement d'avoir 4 fois 55 minutes de mathématiques par semaine, en seconde ou en première S. Comment peuvent-ils penser, alors même que l'étude des algorithmes n'est pas une franche réussite, que la compliquer par la prise en charge d'un langage de programmation pourra améliorer les choses ?

Quant aux querelles byzantines via touiteure sur le bien-fondé des fonctions et autres input/print, elles sont en effet assez ahurissantes face à la réalité du terrain.

je ne suis pas tout à fait d'accord avec toi...je crois que beaucoup d'élèves n'ont pas la moindre idée de ce qui se passe dans l'exécution d'un programme. Bien qu'ils soient utilisateur de Facebook ou autre, ils ne font pas le lien entre la programmation et ce qu'ils utilisent. C'est simplement magique un ordinateur...

Mon plus grand succès à été le programme suivant en seconde

Tape ton année de naissance...
Réponse du programme (sur la calculatrice) "tu es âgé de ...ans"

Je résiste à l'idée de poster le corps du programme..

Eh bien, des élèves ont été (bien qu'ils sachent qu'il y a une soustraction dans le programme et que cette soustraction a été discutée en classe lors de la mis au point) époustouflés par le fait que la calculatrice soit capable de donner (deviner?)  leur age!!!

C'était une excellente seconde, une des meilleures que j'ai eue ces dernières années.

Pour dire le chemin qu'il y a entre calcul   intuitif....programmation....exécution...résultat

Je pense qu'on a pas besoin de chercher trop loin et même que ce la peut être contre productif

Prezbo a écrit:Très sincèrement....C'est sans doute parce que je ne suis pas vraiment et j'en suis conscient un vrai développeur informatique, mais j'ai l'impression qu'on me parle du sexe des anges.Cela me fait penser aux formateurs et aux collègues, qui, au moment de l'introduction des intervalles de fluctuation en seconde, m'expliquaient que [...]

Pour des secondes c'est tout à fait juste. Ma critique portait en fait sur l'enseignement de l'informatique en terminale S, puisque le livre de Dowek est destiné à l'enseignement de l'ISN, l'option Informatique et Sciences du Numérique. Et sur l'intervalle de fluctuation, je suis surtout horrifié du fait que le résultat donné dans le programme officiel de l'époque ait été faux (puisqu'on descend parfois en dessous des 95%).

Toujours est-il que l'algorithmique et la programmation sont deux activités très différentes, à l'image de l'étude de la grammaire et de la dissertation. Même si elles sont complémentaires, on peut très bien commencer la programmation sans avoir fait d'algorithmique. C'est d'ailleurs préférable. Il vaut mieux réduire les difficultés là où c'est possible vu le niveau des élèves (qui doit être considéré comme nul, sans vouloir être péjoratif), et essayer d'obtenir des résultats concrets et perceptibles, comme le permet l'exécution d'un programme simple :

Code:

nom = input("Comment t'appelles-tu ? ")
print("Bonjour", nom)

qu'on ne raisonne pas en terme de progressivité ou d'étapes pédagogiques...

L'institution ne joue pas son rôle. On nous demande de nous débrouiller sans nous conseiller, ou alors après avoir suivi une formation de quelques heures qui se borne simplement à montrer quelques activités sans transmettre cette analyse.

Le fiasco est déjà bien enclenché malheureusement : les aménagements à destination des premières n'étant pas sortis, l'affaire est tombée à l'eau pour le BAC de 2020.

Ou au truc dont la majorité des élèves retiendrons comme "un truc à faire automatiquement sans comprendre le jour du bac".

C'est déjà le cas en série ES, puisque les consignes données à l'occasion de la correction du BAC de l'an passé, étaient d'accepter un intervalle de fluctuation comme réponse, là où il n'y avait pas d'échantillon constitué aléatoirement et qu'une proportion ou un pourcentage (je ne sais plus trop) devait être établi...

Call_BB5A a écrit:

Alors que l'on tente de justifier la chasse aux input et print pour l'enseignement de l'#algo en #maths au #lycée par des arguments "scientifiques", que voit-on dans le manuel d'#ISN de Gilles Dowek (cité continuellement en référence) des programmes pleins d'input et de print.... pic.twitter.com/FLiFB1SbJ0

— algobox (@PascalBrachet) 20 février 2018

Sur ce coup là, je trouve la critique un peu injuste. Il s'agit de rejeter l'usage des print() et des input() dans l'écriture des fonctions. Or les exemple cités, sont en fait des programmes et non des fonctions.
[…]

Au final, on est vraiment pas aidé. Comment en effet, enseigner la programmation (en Python) quand on nous donne de part et d'autres des mauvais exemples...

J'avais compris que input/print étaient à bannir de tout, pas seulement dans les fonctions.
Ce que je ne comprends pas, pourquoi avoir incité à entrée/traitement/affichage si longtemps, si c'est le mal ?
N'était-ce pas déjà connu de ceux qui ont inscrit cela dans les programmes, ils ne le savaient donc pas à ce moment là ?

VinZT a écrit:
Je sais bien qu'il faut commencer par des trucs simples, mais j'ai la faiblesse de penser que si on veut intéresser, autant que faire se peut, quelques élèves à la programmation, il faut faire des trucs où la machine apporte un réel avantage : dichotomie, sommes de termes, recherches exhaustives de solutions dans un cadre contraint, etc.
Je ne suis d'ailleurs pas sûr que cela soit faisable avec des lycéens actuels (la surcouche informatique au moment même où on découvre la notion mathématique générant sans doute plus de confusion qu'autre chose), et je suis à peu près persuadé qu'il n'y aura aucun bénéfice sur la compréhension mathématique.

Et pour pouvoir se rendre compte de la plus-value apportée par un algorithme et sa programmation, il serait important de pouvoir transpirer suffisamment longtemps sur les problèmes mathématiques.
Or,

VinZT a écrit:
Les mandarins qui nous infligent ces trucs n'ont aucune idée réelle de ce que cela signifie concrètement d'avoir 4 fois 55 minutes de mathématiques par semaine, en seconde ou en première S. Comment peuvent-ils penser, alors même que l'étude des algorithmes n'est pas une franche réussite, que la compliquer par la prise en charge d'un langage de programmation pourra améliorer les choses ?

Quant aux querelles byzantines via touiteure sur le bien-fondé des fonctions et autres input/print, elles sont en effet assez ahurissantes face à la réalité du terrain.

VinZT a écrit:Algobox a ses défauts, mais, en s'affranchissant des contraintes du langage, on se focalisait finalement sur l'algorithme en lui-même …

Il est finalement assez bien adapté à la réalité du terrain (n'a-t-il pas a été conçu pour cela ?), ça doit être pour ça qu'il faut s'en passer.

Ce que je comprends dans l'évolution du programme, et en lisant les docs de l'IG, c'est qu'ils entendent bannir l'emploi systématique du triptyque input/traitement/print (ou équivalent) qui avait cours auparavant, et non pas les fonctions input et print en tant que telles quand c'est l'objet du programme. Par exemple, le programme évoqué ci-dessus de l'année de naissance et de l'âge me parait bien, si on décide de traiter la question des interfaces texte et des conversions de type

Code:


an_n = int(input("Quelle est ton année de naissance ?"))
print("Au 31 décembre, tu auras", 2018-an_n, "ans")


Et ça n'est pas pertinent, informatiquement parlant, de définir une fonction pour réaliser une opération aussi simple que la soustraction (on peut le faire pour des raisons pédagogiques, pour présenter les fonctions en Python, par exemple, encore que je ne suis pas sûr que ça soit le meilleur exemple).

C'est toujours difficile de trouver les exemples introductifs : trop compliqué et l'esprit est focalisé sur la difficulté du problème ; trop simple et on ne voit pas pourquoi on s'embête à le programmer.

Pour ma part, avec des élèves qui ont pourtant plus de math dans les pattes, je reste modeste : le tout premier exercice de mon premier TP en sup consiste à recopier un court programme Python (je ne le donne pas en pseudo-langage) à peine plus compliqué que celui ci-dessus, et tous mes élèves n'y arrivent pas du premier coup ; le deuxième consiste à recopier une fonction qui calcule la valeur absolue d'un entier ; le troisième c'est d'écrire (là je ne donne pas le code) une fonction qui donne l'aire d'un carré dont on a retiré un disque inscrit (exercice qui me vient de la fac, et je dois dire que contrairement à ce que j'ai vécu là bas, personne parmi mes étudiants de CPGE n'a essayé de mettre pi comme paramètre) ; ensuite on traite une figure un peu plus compliquée…

Quant à la question : pourquoi est-ce qu'avant on faisait faire systématiquement du input/traitement/print ? Franchement, à part une contrainte technique (pouvoir faire ça sur calculatrice ?), je ne vois pas bien. Ça serait intéressant de savoir qui avait rédigé cette partie de l'ancien programme et pourquoi ils ont fait ça ainsi. D'un point de vue purement algorithmique (qui était celui employé alors), ça me parait vraiment idiot ; la présentation prévue pour le bac 2018 est bien meilleure et se concentre vraiment sur l'aspect algo.