Transition algorithmique collège/lycée

Prezbo a écrit:Je n'ai jusqu'ici jamais vu un cours de programmation qui commence directement par la programmation fonctionnelle, sans avoir préalablement parlé d'entrée et de sortie et fait un minimum de programmation impérative. Renverser cet ordre traditionnel de présentation me semble un pari pédagogique pour le moins risqué. Un peu comparable, toute proportion gardée, à celui des maths modernes, cette époque où on présentait la théorie des ensembles avant l'arithmétique sur les entiers.

Cela correspond pourtant à une longue tradition de l'enseignement de l'informatique. Je ne sais pas si tu as déjà entendu parler du langage Logo (qui a donné le module turtle de Python) ou de Scheme mais ce sont deux dialectes de Lisp créés pour l'enseignement (peut être même les deux premiers langages d'enseignement), les dialectes de Lisp ont en général une console interactive intégrée, inutile donc de commencer par des prints/input, c'est plutôt expression puis fonction.
Il y a un excellent livre le SICP qui correspond au cours d'introduction à l'informatique du MIT (ce cours a 40 ans maintenant..) qui illustre ce principe. L'accent est mis dès le départ sur le fait de bien structurer son code, de bien poser les problèmes et les gains de l'abstraction. Il existe un livre qui se veut plus ou moins l'équivalent pour des lycéens.

Les grandes fac américaines dont est issue cette tradition (MIT, Berkeley) ont justement abandonné Scheme/Logo pour leur cours d'introduction et sont passés à Python, mais en gardant le même état d'esprit.

(Logo étant inspiré des travaux de Piaget, le procès en math modernisme n'est pas totalement infondé)

Prezbo a écrit:
Il est possible d'ailleurs que certains informaticiens et matheux de haut vol, ayant fait ce type d'initiation avec leurs propres enfants -qui grandissent dans un contexte familial et culturel exceptionnellement favorable, et n'ont probablement pas eu de difficultés d'entrée dans l'écrit, dans la numération ni dans l'abstraction-, en déduisent que les enfants peuvent beaucoup et que ce type d'initiation est accessible à tous. En oubliant que tous les lycéens n'ont pas bénéficiés des mêmes bases, ni du même contexte.

Un des problèmes est peut-être d'ailleurs non pas d'essayer d'introduire l'informatique, la programmation et Python au lycée, mais de croire que cela est indispensable ou prioritaire pour tous les élèves. Quand je vois mes term STMG de cette année, l'idée qu'il faudra apprendre à leurs successeurs à lire et produire du code informatique me fait rire jaune. Pour l'instant, ils trainent et contestent quand je leur dis qu'une calculatrice est obligatoire, et ont du mal avec les indices base 100.

Je trouve ce genre d'argument dangereux, ils me font en tout cas penser à ceux utilisés pour supprimer l'enseignement de la géométrie. (ce qui m'attriste plus que le manque d'info) Cela dit, je ne vois pas l'intérêt de faire du Python en maths en STMG.

Prezbo a écrit:
D'ailleurs, vous même, avez-vous souvent écrit un programme dépassant quelques lignes en évitant systématiquement le recours à input et à print ?

Je n'ai jamais d'input (sauf quand je code un pendu), j'utilise la console ou argv pour une interface en ligne de commande. Ecrire un input et le "parser", c'est déjà trop long, et c'est plus pratique d'entrer les arguments de son programme dans la ligne qui sert à l'appeler.
Un ou deux print en fin de programme mais ça c'est relativement récent, avant d'apprendre à utiliser un débuggeur j'avais un print une ligne sur deux en cas de bug.

BR a écrit:

nc33 a écrit:Outre les boucles for, il y a un autre point qui m'agace et qui a posé problème aux élèves hier. Avec input, il faut utiliser float ou int si on veut procéder à un calcul ensuite. J'imagine que cela aurait pu être inutile si Python avait été conçu autrement.

La fonction eval est plus appropriée : float("2+2") renvoie une erreur, eval("2+3.") par contre renvoie le nombre réel 5.
La meilleure solution est encore de ne pas utiliser d'input : on définit une fonction, les données en input dans le script devenant les paramètres de la fonction et on utilise la fonction à la console.

Entièrement d'accord sur le fait d'utiliser des fonctions (même si, comme ça a été souligné par d'autres, on n'a pas du tout besoin d'utiliser moult choses avancées comme zip, etc.).

En revanche attention avec eval : c'est une fonction dangereuse et il ne faut pas prendre l'habitude de l'utiliser innocemment. Elle pose beaucoup plus de problèmes que float parce qu'elle permet réellement l'évaluation de n'importe quelle expression Python. Pour peu que le module os ait été importé, eval("os.mkdir('/tmp/machin')") provoquera la création d'un dossier machin. Je vous laisse imaginer ce qu'on peut faire d'autre…

C'est donc un problème de sécurité grave d'écrire dans un programme eval(input("Entrez un entier")) parce que ça permet à l'utilisateur de faire exécuter beaucoup de choses (même si pas autant que exec, qui permet en plus d'exécuter des instructions) : il peut par exemple saisir la chaine "print(variable_qui_contient_un_secret)" pour forcer le programme à révéler une donnée secrète.

e1654d a écrit:En revanche attention avec eval : c'est une fonction dangereuse et il ne faut pas prendre l'habitude de l'utiliser innocemment. Elle pose beaucoup plus de problèmes que float parce qu'elle permet réellement l'évaluation de n'importe quelle expression Python. Pour peu que le module os ait été importé, eval("os.mkdir('/tmp/machin')") provoquera la création d'un dossier machin. Je vous laisse imaginer ce qu'on peut faire d'autre…

C'est donc un problème de sécurité grave d'écrire dans un programme eval(input("Entrez un entier")) parce que ça permet à l'utilisateur de faire exécuter beaucoup de choses (même si pas autant que exec, qui permet en plus d'exécuter des instructions) : il peut par exemple saisir la chaine "print(variable_qui_contient_un_secret)" pour forcer le programme à révéler une donnée secrète.

Je n'ai à peu près rien compris, mais je retiens qu'utiliser eval c'est mal !

Spoiler:

Sinon, pour en revenir à l'affaire du range, les documents d'accompagnement sur les automatismes (le pdf est ici) proposent des exemples de "questions flash" portant sur Python et ceux qui sont en bas de la page 25 et en haut de la page 26 reposent justement sur la bonne maîtrise de l'instruction range ; quand on regarde les réponses proposées à ces QCM et particulièrement le piège qui est tendu dans celui de la page 26, on voit que c'est donc bel et bien la connaissance du langage Python et de sa différence par rapport au "langage naturel" qui est évaluée.


J'ai aussi survolé quelques ressources d'accompagnement sur l'algorithmique et la programmation, (on trouve les liens sur cette page) et ça me semble franchement peu réaliste. Alors que je n'ai pas de problème à déterminer les algorithmes concernés et que je sais donc ce qui est attendu comme structure, cela me demande pas mal de temps pour décrypter la syntaxe des programmes correspondants en Python ; ce temps, il va falloir le démultiplier pour des élèves qui n'auront généralement pas une meilleure connaissance du langage Python que moi et qui en plus ne pourront s'appuyer sur aucune compréhension du contexte mathématique puisqu'il est déjà en lui-même un obstacle pour eux.

Ces dernières années, on a déjà pu constater que l'objectif d'intégrer au cours de maths de l'algorithmique en "langage naturel" ajoutait déjà une couche de difficulté à l'étude de certaines notions mathématiques, mais en imposant la programmation en Python, on atteint un degré de complexité pédagogique nettement plus élevé qui supposerait qu'on ait le temps en amont de travailler d'un côté les notions mathématiques et de l'autre la syntaxe de ce langage avant que les deux ne puissent se rejoindre dans de bonnes conditions.

Mais si je prends l'exemple de l'activité Python sur la dérivation d'une fonction (elle est là), elle est présentée comme une activité d'introduction de la notion de dérivée, ce qui est quand même assez hallucinant quand on connaît la difficulté à faire passer cette introduction sans qu'on demande en plus aux élèves d'expliquer des fragments de codes.
Même quand on se contente d'utiliser l'informatique comme simple outil de visualisation, cette présentation de la dérivée est déjà un moment pénible depuis de nombreuses années car elle constitue un "point de collision" provoqué par le manque de cohérence et de progressivité des programmes : elle mobilise des connaissances supposées connues mais concrètement peu solides sur les équations de droites, elle les croise avec l'analyse et fait apparaître un taux d'accroissement (donc des fractions et les difficultés calculatoires qui vont avec) et enfin on cumule avec la notion de limite d'une fonction qui, selon la progression choisie par l'enseignant, sera découverte à cette occasion ou, au mieux, aura fait l'objet d'une approche succincte dans le cadre des suites qui paraît trop distinct aux yeux des élèves pour que le transfert soit éclairant. Et là, on nous propose d'y rajouter le décryptage de lignes de programme en Python pour faire encore davantage diversion...

Eh bien, je viens de jeter un œil sur le lien donnée par Moonchild, c'est du brutal !
Et comme par la plupart (pas toutes) des « activités », on aura rendu les choses tellement confuses qu'il est à peu près certain que personne n'y comprendra plus rien, même en étant volontaire et sérieux. On aura perdu une heure (voire deux) d'un temps précieux, quelques litres de transpiration à aller d'un poste à l'autre (le fameux « m'sieur, moi mon code y marche pas, pourtant j'ai tout tapé comme vous »), mis en péril la paix des ménages (encore plus si le conjoint est dans la même galère numérique) et ni la compréhension de la notion (difficile) de dérivée, ni la maîtrise de python n'auront progressé d'un iota.

Sans être grand clerc, on peut prédire que la grande majorité des collègues de maths se dépêchera de tenter de boucler la partie mathématique du programme de maths*, et réservera la programmation pour les rares heures obtenues en demi-groupe, ou refilera le bébé au prof de l'année prochaine, tout en faisant une prière à Sainte Rita pour que le sujet de bac choisi n'accorde pas plus d'un point à cette histoire d'algorithme.

Un bilan neutre et officiel a-t-il été fait de l'introduction de l'algorithmique dans les cours de maths ? À ma petite échelle (académie mono-départementale ultra-marine), j'ai bien l'impression que c'est pénible pour la plupart des collègues, qui se sentent peu compétents sur le sujet, et, par rebond, sur les élèves. Mais non bien sûr, on continue, comme d'habitude, la grande course en avant sur l'air connu de « si ça ne marche pas c'est qu'on est pas allé assez loin ». Quant aux IPR, au delà des yakafokon, j'attends toujours qu'ils me montrent leur expertise à ce sujet.

Pour ce qui est de la fonction eval, j'avoue l'utiliser sans trop de scrupule (pour la dernière année d'ISN qui me reste). C'est un peu bizarre, je trouve, de vanter d'un côté python comme facile à utiliser (pas besoin de déclarer les types des variables, super !) pour finalement se poser quand même la question lors de l'utilisation d'un input. Ah oui, c'est vrai, input c'est devenu forbidden depuis que la notion universelle de fonction est le nouveau paradigme.

*:

Il est urgent de faire simple et efficace.

Live and let die.

Tiens, c'est rigolo, en étalant ma pâte à pizza, j'ai consulté les documents trouvables ici. Alors, c'est très joli, vraiment. Et farci de print  
On sent que ces documents ont été faits à l'arrache (plein de coquilles dans les pdf par exemple) et par plusieurs personnes (ce qui est normal, après tout) et relus par des ipéhères entre la poire et le fromage (tiens, je leur conseille pour faire plus vrai cette belle extension LaTeX : coffee).
Visiblement parmi les rédacteurs, il y a (au moins) deux écoles :
— les tenants de la console façon IPython
— les gaulois réfractaires qui font des print

Dans tout ça, je me demande si les soutiers collègues de base y retrouveront leurs petits …

Moonchild a écrit:Je n'ai à peu près rien compris, mais je retiens qu'utiliser eval c'est mal !

C'est un assez bon résumé ;-). eval prend une chaine de caractère et l'évalue comme une expression Python ; la fonction exec fait de même mais sait en plus traiter des instructions (on peut donc passer à exec un programme Python complet). Ces fonctions puissantes sont le reflet du caractère très dynamique de Python ; elles ont des utilisations pertinentes (je pense par exemple au module timeit qui permet d'évaluer le temps de calcul d'un programme : on passe le programme sous forme de chaine).

Mais elles sont aussi des portes ouvertes pour des utilisations malfaisantes, ou tout simplement des erreurs de l'utilisateur :
si je fais eval("print(x)"), c'est comme si mon programme contenait print(x) : ça affiche la valeur de x.

Donc si un programme contient l'appel eval(input()), ou, de façon plus subtile, eval(x) avec x une chaine fabriquée maladroitement à partir de saisies de l'utilisateur, ce dernier peut faire faire au programme ce qu'il veut, en entrant dans la chaine évaluée n'importe quelle expres​sion(voire n'importe quel programme, avec un exec(x)).

Ça fournit un vecteur d'attaque trivial : par exemple, si un programme doit recevoir un mot de passe et le vérifier, si on a placé ces fonctions sur-puissantes dans le code, l'utilisateur peut injecter des expressions (ou instructions) qui conduisent le programme à révéler le mot de passe au lieu de le vérifier. C'est analogue au problème des injections SQL rendues possibles par une mauvaise construction des patrons de requêtes SQL.

Bien sûr, on ne fera pas plus de choses avec un eval qu'en saisissant directement des expressions dans la console Python, et donc ce n'est pas dramatique dans ce contexte d'utilisation (mais du coup pas très utile non plus, à mon avis). En revanche "en production", c'est vraiment dangereux si on n'est pas conscient du problème (et même quand on en est conscient).

VinZT a écrit:Tiens, c'est rigolo, en étalant ma pâte à pizza, j'ai consulté les documents trouvables ici. Alors, c'est très joli, vraiment. Et farci de print  
On sent que ces documents ont été faits à l'arrache (plein de coquilles dans les pdf par exemple) et par plusieurs personnes (ce qui est normal, après tout) et relus par des ipéhères entre la poire et le fromage (tiens, je leur conseille pour faire plus vrai cette belle extension LaTeX : coffee).
Visiblement parmi les rédacteurs, il y a (au moins) deux écoles :
— les tenants de la console façon IPython
— les gaulois réfractaires qui font des print

Dans tout ça, je me demande si les soutiers collègues de base y retrouveront leurs petits …

Ch'uis un fou moi tu sais, je peux même te faire un programme avec un "break" en pleine boucle.