- PrezboVénérable
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.
- wilfried12Habitué du forum
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.
- MatheodHabitué du forum
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.
- Call_BB5ANiveau 5
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.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
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., 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
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.et de l'expliquer par ses propres moyens intellectuels, sans béquille extérieure.
Sans nier aussi leur responsabilité à apprendre de leurs erreurs.
- Call_BB5ANiveau 5
Quand l'entier (type int) b est négatif cela retourne un flottant (type float).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
- Code:
>>> 5**-3
0.008
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.neo-fit a écrit:Et aussi les
— Yann Salmon (@yannsalmon) 12 juin 2016
y = x + 2
return y (voire print(y))
au lieu de
return x + 2
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.
- ProtonExpert
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.
- JPhMMDemi-dieu
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.
_________________
Labyrinthe où l'admiration des ignorants et des idiots qui prennent pour savoir profond tout ce qu'ils n'entendent pas, les a retenus, bon gré malgré qu'ils en eussent. — John Locke
Je crois que je ne crois en rien. Mais j'ai des doutes. — Jacques Goimard
- BalthazaardVénérable
Call_BB5A a écrit:Quand l'entier (type int) b est négatif cela retourne un flottant (type float).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
- Code:
>>> 5**-3
0.008L'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.neo-fit a écrit:Et aussi les
— Yann Salmon (@yannsalmon) 12 juin 2016
y = x + 2
return y (voire print(y))
au lieu de
return x + 2
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.
- BalthazaardVénérable
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.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
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., 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
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.et de l'expliquer par ses propres moyens intellectuels, sans béquille extérieure.
Sans nier aussi leur responsabilité à apprendre de leurs erreurs.
Minute de l'humour.
- Call_BB5ANiveau 5
Balthazaard a écrit:Minute de l'humour.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.
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é :-)
- AnaxagoreGuide spirituel
_________________
"De même que notre esprit devient plus fort grâce à la communication avec les esprits vigoureux et raisonnables, de même on ne peut pas dire combien il s'abâtardit par le commerce continuel et la fréquentation que nous avons des esprits bas et maladifs." Montaigne
"Woland fit un signe de la main, et Jérusalem s'éteignit."
"On déclame contre les passions sans songer que c'est à leur flambeau que la philosophie allume le sien." Sade
- neo-fitNiveau 9
Tweete depuis février 2016, 2812 tweets, je ne sais pas si c'est beaucoup.VinZT a écrit:Et sinon, il fait quoi dans la vie, ce M. Chéno, à part twitter comme un fou ?
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
— Prudence (@br1borion) 22 mars 2018
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
#prof #maths #lycee
— Prudence (@br1borion) 22 mars 2018
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
- BalthazaardVénérable
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...
- VinZTDoyen
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.
_________________
« Il ne faut pas croire tout ce qu'on voit sur Internet » Victor Hugo.
« Le con ne perd jamais son temps. Il perd celui des autres. » Frédéric Dard
« Ne jamais faire le jour même ce que tu peux faire faire le lendemain par quelqu'un d'autre » Pierre Dac
« Je n'ai jamais lâché prise !» Claude François
« Un économiste est un expert qui saura demain pourquoi ce qu'il avait prédit hier ne s'est pas produit aujourd'hui. » Laurence J. Peter
- JPhMMDemi-dieu
Attends de rencontrer les futurs lycéens.Call_BB5A a écrit:Là au moins, ils ne viennent pas dire que c'est l'ordinateur qui s'est trompé :-)
Si tu savais le nombre de fois où mes collégiens disent "M'sieur, l'ordinateur s'est trompé !"
_________________
Labyrinthe où l'admiration des ignorants et des idiots qui prennent pour savoir profond tout ce qu'ils n'entendent pas, les a retenus, bon gré malgré qu'ils en eussent. — John Locke
Je crois que je ne crois en rien. Mais j'ai des doutes. — Jacques Goimard
- Call_BB5ANiveau 5
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.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
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...
- William FosterExpert
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... :|
_________________
Tout le monde me dit que je ne peux pas faire l'unanimité.
"Opinions are like orgasms : mine matters most and I really don't care if you have one." Sylvia Plath
Vérificateur de miroir est un métier que je me verrais bien faire, un jour.
- PrezboVénérable
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.
- VinZTDoyen
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.
_________________
« Il ne faut pas croire tout ce qu'on voit sur Internet » Victor Hugo.
« Le con ne perd jamais son temps. Il perd celui des autres. » Frédéric Dard
« Ne jamais faire le jour même ce que tu peux faire faire le lendemain par quelqu'un d'autre » Pierre Dac
« Je n'ai jamais lâché prise !» Claude François
« Un économiste est un expert qui saura demain pourquoi ce qu'il avait prédit hier ne s'est pas produit aujourd'hui. » Laurence J. Peter
- Badiste75Habitué du forum
- BalthazaardVénérable
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.
- wanaxFidèle du forum
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.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.
- BalthazaardVénérable
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
- Call_BB5ANiveau 5
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%).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 [...]
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)
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.qu'on ne raisonne pas en terme de progressivité ou d'étapes pédagogiques...
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.
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...Ou au truc dont la majorité des élèves retiendrons comme "un truc à faire automatiquement sans comprendre le jour du bac".
- neo-fitNiveau 9
J'avais compris que input/print étaient à bannir de tout, pas seulement dans les fonctions.Call_BB5A a écrit: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.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
[…]
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...
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à ?
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.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.
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.
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.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 …
- e1654dNiveau 7
- Code:
an_n = int(input("Quelle est ton année de naissance ?"))
print("Au 31 décembre, tu auras", 2018-an_n, "ans")
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.