Désolé d'y revenir, mais les commentaires de M. Parisse étant intéressants c'est un véritable plaisir que d'y répondre. Encore une fois, croyez bien que je suis tout à fait admiratif devant l'écriture d'un moteur symbolique.
Inutile d'etre agressif. Je veux dire par la qu'on peut avoir envie de copier-coller le code d'une fonction dans un email, sur un forum, dans un texte, et que les logiciels dedies a ces taches peuvent ne pas respecter les espacements.
Soit, cela doit exister. Mais cela arrive aussi en fonction de l'encodage des caractères et autres facéties. Ceci étant, il y a quand même assez peu de logiciels manipulant du texte qui ne reconnaissent pas le 'tab'.
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. 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.
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.
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 serais curieux de connaitre l'experience d'enseignement de Bunuel66 puisqu'il nous dit ne pas sevir dans l'education nationale.
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.
ensuite parce qu'ils permettent d'evaluer une expression.
Sans vouloir être très lourd, un terminal Python fait ça très bien.
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.
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.
ouvoir manipuler des vecteurs et des matrices n'est pas suffisant pour cela, il faut aussi gerer les fonctions ou a minima les expressions symboliques,
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.
C'est pour cela par exemple que dans Xcas, la non-declaration de variables locales entraine un warning,
C'est un bon sujet. Mais la question est elle la portée des variables ou la détection des erreurs de frappe? Pour ce qui est de la portée des variables Python utilise une convention assez standard qui est que les variables déclarées dans une fonction sont locales à celle-ci. On peut forcer la globalité d'une variable dans une fonction, mais ce n'est pas recommandé....Pour ce qui est de la détection d'erreur de frappe, le cas potentiellement non détecté est celui où on affecte une variable en se trompant, la variable est alors créée sans rien dire, et le résultat est rarement celui attendu. Le problème est inhérent à tous les langages dynamiques. La seule solution est la déclaration statique typée.
On pourrait ergoter que cela relève de l'approche qualité et qu'il convient de ne pas faire n'importe quoi, si on se trompe de variable dans un algorithme ou que les noms sont suffisamment confus et sans règle d'écriture le résultat sera le même. Je vous suis néanmoins sur ce point. Ceci dit en Python il est possible d'extraire la liste des variables globales et locales d'un module, il est donc assez facile de repérer des variables sauvages....Mais encore une fois, la seule 'bonne' solution est la déclaration préalable.
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.
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 Python a reellement de telles qualites pedagogiques pour l'apprentissage (malgre les defauts que je lui trouve), alors il s'imposera de lui-meme en TP, inutile de l'imposer d'en haut avec tous les inconvenients que j'ai indiques precedemment.
Mais je l'espère bien
Encore une fois je m'élevais surtout contre la situation actuelle...
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.