Bunuel66 a écrit:Vous n'avez pas compris mon point. Si vous faites une boucle for j in range(1,n),
Mais si, je l'ai parfaitement compris. Je n'envisage pas que vous n'ayez pas vu qu'il s'agit là d'un itérateur. Là où je vous suis c'est pour dire que cette syntaxe est un peu éloignée de la boucle FOR usuelle.
D'apres mon experience d'enseignement, la structure la plus simple a mettre en oeuvre pour un debutant est la boucle for usuelle. Le test if vient ensuite, et la boucle tantque apres.
Philosophiquement cela à tout son sens si l'on considère que la boucle parcourt un ensemble quelconque et non plus uniquement les entiers. Pour ce qui est de l'occupation mémoire deux petites remarques:
-d'une part la mémoire ne manque pas sur les machines actuelles, on parle de gigagoctets de mémoire quand un itérateur, même sur des millions, occupe un millième de celle-ci.
'd'autre part, si la mémoire est un problème, on peut parfaitement factoriser les boucles, remplacer une boucle simple sur un million par deux boucles imbriquées sur 1000.
Je ne trouve pas ca convaincant du tout, d'autant que en langage compile en tout cas il peut arriver qu'on fasse un milliard d'iterations (et meme a un million gacher de la memoire pour rien n'est pas une bonne habitude a prendre). Je ne comprends d'ailleurs pas pourquoi les concepteurs de Python veulent a ce point empecher la boucle for usuelle.
Il s'agit de montrer du doigt aux eleves de prepas la difference entre interprete et compile pour comprendre les biais d'un interpreteur.
Je ne suis pas certain que le doigt soit suffisant....Qui plus est la situation actuelle est un rien plus compliquée avec les notions de machine virtuelle et Just In Time. La problématique compilation/interprétation me semble une question du deuxième ordre lorsqu'on est dans l'apprentissage de l'algorithmie. Pour beaucoup d'élèves cela reste de l'ordre de la procédure de mise en oeuvre. Il faudrait que les élèves aient une compréhension plus fine de la machine pour en comprendre la réelle différence.
On parle ici d'eleves de classe prepas, censes etre l'elite scientifique de la nation, a qui on va faire ingurgiter des notions d'analyse ou d'algebre assez fines (par exemple la convergence uniforme de series de fonction), a cote de cela on les laisse ignorer les fondementaux de la programmation qu'on ne peut pas apprendre avec un langage interprete qui masque les subtilites avec des types comme les listes de taille dynamique...
Mais cela serait impossible si Python est impose d'en haut, et reciproquement si Julia est impose comme seul langage, alors il serait impossible d'enseigner le Python.
Et alors? Je n'ai jamais dit qu'il fallait imposer un seul langage dans toute la vie des élèves, surtout dans le supérieur. J'ai simplement dit qu'il fallait un langage commun, python ou autre, plutôt que JavaScool. Python me semble un bon compromis. Julia est d'ailleurs quasiment une version JIT de Python.
Je ne suis pas d'accord avec un langage informatique unique pour le lycee, je situe le langage commun au niveau du langage algorithmique, avec pour le lycee en plus de la notion de boucle et de test deja presents, la notion de fonction. Un eleve de lycee doit pouvoir ecrire un algorithme dans ce langage, sans contrainte de syntaxe tres precise. D'ailleurs le passage de ce langage vers un langage informatique precis ou la traduction de l'un vers l'autre parmi les langages cites se fait sans grandes difficultes.
Il se trouve que je n'émarge effectivement pas auprès du grand ministère. Je travaille dans l'industrie. Cependant, je vois d'une part une foultitude d'élèves dans mon entourage qui viennent chercher de l'aide et d'autre part j'ai effectivement enseigné dans des écoles d'ingénieurs et encadré pas mal de stages ou travaux de fin d'études pour voir le résultat de l'enseignement actuel. Excusez moi de ne pas avoir la pureté de l'universitaire.
Il ne s'agit pas de purete, il s'agit d'experience d'enseignement, vous n'en avez donc aucune au niveau du lycee, rien ne vous permet d'affirmer que Xcas ne peut pas etre utilise pour les debutants a ce niveau. Et Xcas est d'ailleurs utilise par certains enseignants, meme si la plupart utilisent algobox (et pas javascool) ou les calculatrices.
ensuite parce qu'ils permettent d'evaluer une expression.
Sans vouloir être très lourd, un terminal Python fait ça très bien.
Mais que je sache, je n'ai jamais dit le contraire, Python est un langage interprete, il se trouve donc dans la classe des langages enseignables au lycee a mon avis, au meme titre que d'autres, dont javascript, Xcas, TI-Basic, HP-Basic, etc. que j'avais cites precedemment.
Le resultat de mes observations c'est que le TI-Basic sur TI92 et Voyage 200 est facile a prendre en main (c'est moins le cas sur ti-nspire, mais peut-etre a cause d'un biais de ma part). J'ai essaye de faire un langage du meme type sur Xcas avec un certain succes de mon point de vue,
A ce compte, pourquoi ne pas généraliser l'usage d'émulateurs de ces machines sur PC/Tablette. Pour développer des programmes un peu conséquents un bon clavier est plus agréable.
Si on fait un cours de maths avec un exercice d'algorithmique, on ne va pas se deplacer en salle info juste pour ca. C'est la raison pour laquelle les calculatrices sont utilisees par pas mal de collegues du secondaire. Je suis en train de developper une interface de Xcas utilisable sur smartphone et tablette (http://www-fourier.ujf-grenoble.fr/~parisse/xcasfr.html) mais l'absence de mode examen risque d'handicaper son utilisation, car les eleves n'y auront pas acces le jour du bac.
l'interet de Xcas c'est comme sur une calculatrice de pouvoir faire a la fois des maths et de l'algorithmique
Ce qui me plait bien dans Xcas c'est plutôt l'aspect symbolique. Malheureusement il n'est pas du tout répandu dans l'industrie et je n'ai pas été convaincu par l'ergonomie. Par ailleurs ce genre de logiciel mélange un peu les genres et risque d'installer une certaine confusion dans l'esprit des élèves.
C'est normal que Xcas ne soit pas utilise dans l'industrie qui a principalement besoin de calcul numerique. Et dans l'industrie comme ailleurs, l'inertie joue aussi, Xcas est encore jeune. Je ne comprends pas ce que vous entendez par melange des genres.
Oui, merci, les flottants aussi, les tableaux etc....Je me suis mal fait comprendre, je voulais dire que ces objets mathématiques se prêtaient bien à une implémentation objet ce qui permettait d'introduire cette notion assez intuitivement. Pour ce qui est des expressions symboliques tout dépend ce que l'on entend par là, si il s'agit de traiter des chaînes avec des expressions régulières ou de les parser beaucoup de langages le permettent, si il s'agit de les transformer au sens large, genre intègration ou dérivation symbolique, il y a fort peu de langages standards qui le permettent sans utiliser de librairie externe.
Par gestion de fonction et expression, je ne demande pas un langage capable de faire de l'integration ou derivation symbolique, mais un langage permettant de faire entrer en ligne de commande ou par un saisir/afficher une expression ou une fonction qui soit ensuite evaluable en un point, afin de pouvoir coder un programme de dichotomie ou de point fixe ou de recherche de valeur approchee d'integrale par la methode des rectangles. N'importe quelle calculatrice graphique le permet, les langages interpretes le permettent en general aussi, mais dans un langage comme C/C++ c'est beaucoup plus difficile.
C'est aussi pour cela qu'il y a une commande debug permettant l'execution en mode pas a pas, qui est de mon point de vue la maniere la plus efficace de corriger des erreurs de runtime.
Il est possible de travailler en pas à pas avec Python, il y a des outils de trace pour cela.
Par contre, le debug pas à pas donne une fausse sécurité à l'étudiant. Cela marche sur des cas simples, sur des cas compliqués, genre ça plante à la trente millième itération le debug pas à pas n'est pas très efficace. A titre personnel je préfère créer un log de trace qui donne la trajectoire des appels et essayer de coder au maximum des fonctions simples que l'on peut valider pas à pas.
Xcas ne dispose pas d'un outil de debuggage aussi puissant que gdb, mais avec de tels outils il est possible d'ignorer un breakpoint pendant un nombre determine de fois et de s'arreter a ce moment-la, puis de continuer en live l'execution, en regardant evoluer la valeur des variables (eventuellement meme en modifiant les variables). C'est ce que je fais tout le temps pour mettre au point giac/xcas, et c'est bien plus efficace que de mettre des logs (je dois malheureusement recourir a ce genre d'expedients sur certaines plateformes et c'est bien deux ordres de grandeur moins efficace). Peut-etre que j'ajouterai cette fonctionnalite au debuggueur de Xcas un jour, mais le champ d'application de Xcas ne necessite pour le moment pas cette fonctionnalite.
En plus cela force l'étudiant à réfléchir à ce qu'il veut voir, plutôt que de se dire, je m'en sortirai toujours en pas à pas.
?? Si on a des outils puissants pour mettre au point un programme, je ne vois pas pourquoi il faudrait imposer l'utilisation d'outils rudimentaires.
Maintenant, pour que cela soit très clair, je ne suis pas un évangéliste de Python. Si j'avais vraiment à faire un choix en la matière pour l'enseignement, je choisirais le TurboPascal dans son implémentation actuelle: FreePascal, et je commencerais par une version simplifiée
tournant en interprété (le Pascal original tournait sur un interpréteur de PCode). Mais comme le Pascal n'a pas vraiment percé dans l'industrie cela reste un choix un peu intellectuel.
Cordialement.
Mais la question du choix n'a pas lieu d'etre, heureusement, puisque les programmes du lycee autorisent la diversite.
