Analyse très technique (trop pour moi) mais j'aimerais répondre sur certains points et avoir quelques précisions sur d'autres. En tout cas, visiblement il me reste encore beaucoup à apprendre !
Avez-vous deja essaye de programmer avec Xcas ?
Pour être honnête, très peu. J'avais regardé Xcas et Scilab au tout début de l'arrivée de l'algorithmique mais mon choix s'était porté sur Algobox car j'avais peur que ces langages soient rebutants à cause de la syntaxe. Ils m'avaient intéressé, mais vu que dans la pratique je ne l'aurais pas utilisé avec mes élèves et que j'étais en début de carrière d'enseignant (c'était ma 2ème année à l'époque), mes efforts se sont portés sur d'autres choses. Et puis récemment, j'ai pu voir l'engouement pour Python, donc il y a presque deux ans maintenant, j'ai acheté quelques bouquins et je m'y suis mis. Mais ce n'est que de l'autoformation, malheureusement, je n'ai trouvé aucune formation proposée par l'EN pour avoir de bonnes bases théoriques.
Je rejetterai un oeil sur Xcas quand même, par curiosité.
De mon cote, j'ai observe des collegues, utilisant Python avec leurs eleves, bloquer sur leur propre code Python (en preparant des TP ecrits a la fois en langage Xcas et Python), je ne crois pas que ca aide pour debloquer les eleves (sauf si on a fait la meme erreur bien sur).
En fait, je n'ai pas trop eu de problèmes à ce niveau là pour le moment, mais peut-être parce qu'en seconde les programmes restent simples. Et les erreurs des élèves sont souvent les mêmes : oubli des :, problème d'indentation, on écrit une fonction mais on ne l'appelle jamais... mais j'avoue que je crains voir arriver bientôt le jour où je ne saurai pas résoudre le problème ! Mais pour l'instant, le shell m'explique bien le problème donc je m'en sors. Croisons les doigts pour que ça continue !
utilisation de ** pour ^, division de 2 entiers / renvoyant un flottant
Dès le début j'explique que / renvoie un float et // renvoie un entier, et en général ils comprennent vite. Donc ça va franchement. Je suis presque plus gêné par la fonction input qui renvoie une chaîne systématiquement. Au début, les élèves ne perçoivent pas bien la différence entre 5 et "5". C'est seulement quand j'écris 3+5 et "3"+"5" qu'ils visualisent un peu. Et ça, je reconnais que c'est gênant.
on a un type entier, mais l'utilisation des rationnels n'est pas tres naturelle.
C'est vrai. En 1ère S cette année, j'ai du coup utilisé le module fractions pour l'algorithme qui détermine la mesure principale d'un angle. Ca m'a sauvé la vie.
pas de type vecteur ou matrice (ainsi + sur 2 listes concatene 2 listes)
Je n'ai pas tout compris... là, on atteint mes limites ! ^^
pas d'expression symboliques (ni d'equations).
Avec le module sympy on peut non ? J'ai réussi par exemple à récupérer d'un champ de saisie (du module tkinter) une expression de f(x) et la faire évaluer avec la fonction eval pour une valeur donnée.
Consequence: pour faire une dichotomie generale, il faut passer une fonction en argument a une autre fonction, ce qui exige un certain niveau d'abstraction (certains etudiants ont deja du mal avec des arguments normaux pour une fonction).
Je ne sais pas ce qu'est la dichotomie "générale". Moi au lycée, je traite la dichotomie de façon très simple. Je définis une fonction, et j'utilise l'algorithme classique avec le test f(a) x f(m) >0. Il suffit de vérifier les conditions du TVI. Peut-être ne vais-je pas assez loin.
Faire une representation graphique necessite aussi plus de travail qu'avec un CAS ou une calculatrice formelle et risque de passer pour une suite d'instructions difficiles a comprendre sans meme parler de la creer.
Là dessus, je suis complètement d'accord. C'est pour moi le point faible. C'est la raison pour laquelle j'espère vraiment que Casio réussisse à créer une interactivité entre les menus. Ainsi, la création de points depuis Python pour les afficher dans le menu graph deviendra un jeu d'enfants.
Pour les complexes, utilisation de j et de la multiplication implicite alors que partout ailleurs on utilise la multiplication explicite
Pour j je comprends la remarque, mais au final ça ne concerne que les terminales, donc ils ne sont pas freinés par si peu. Au pire, dans le module sympy, il me semble que le i complexe est un I (i majuscule). Quant à la multiplication implicite, j'avoue que je ne l'avais pas remarqué ! C'est vrai que ça peut dérouter.
Pour la programmation en elle-meme : l'affectation par = peut engendrer des confusions avec les equations en mathematiques
J'avais déjà entendu cet argument, mais j'avoue ne l'avoir jamais constaté. Le fait est que dans l'algorithmique on utilise une flèche et qu'ils commencent pas ça. Donc le concept de l'affectation est normalement ancré avant l'introduction du symbole = non ? Et puis quand je tape, je ne dis jamais égal, je dis toujours "prend la valeur". C'est un réflexe quasi-pavlovien.
je n'aime pas devoir utiliser des objets compliques pour faire des choses simples, or c'est precisement ce qui se passe pour la boucle for en Python.
Je ne comprends pas trop. C'est de l'informatique pur j'imagine non ?
les listes sont passees par reference, alors que les autres types sont passes par valeur, ca peut etonner
Ca je crois peut-être comprendre : c'est ce qui explique que si je fais ceci :
a = [1, 3, 5]
b = a
a.remove(1)
print(b)
Ca m'affichera [3, 5] car a et b pointent vers le même objet ? Ou alors ça n'a rien à voir et je n'ai rien compris...
Mais est-ce que ça ne devient pas trop "technique" pour des élèves ? Je veux dire, je sais bien qu'on ne leur parlera jamais de ça, mais seront-ils réellement confrontés au problème ?
l'indentation pour structurer les fins de blocs a de mon point de vue un gros inconvenient: si on copie-colle un bloc dans une autre structure on ne peut pas le reindenter automatiquement contrairement aux autres langages. Ca peut etre difficile de savoir ou est la fin de bloc s'il y a changement de page dans un code imprime. On le voit aussi dans les echanges sur forum (probablement aussi certains lecteurs de mail) ou les debutants inserent leur code sans precaution et ou l'indentation est perdue. Et c'est sans doute plus difficile pour des deficients visuels.
Je comprends, mais moi qui suis visuel par exemple, cette organisation m'aide vraiment du point de vue algorithmique. Par exemple, les accolades en java, que certains mettent en début de ligne seule, en début de ligne suivie d'une première instruction, à la fin d'une condition ou de la définition d'une fonction... je ne m'y retrouve pas. Alors qu'en Python, c'est clair, c'est net, et je trouve ça bien organisé. Mais j'avoue que c'est très personnel.
les variables locales sont implicites dans les fonctions Python. Cela peut etre source d'erreur en cas de faute de frappe.
C'est vrai. Pour l'instant je n'ai pas encore été confronté au problème, mais il faut en tenir compte, je le reconnais.
Pour toutes ces raisons, je considere Python comme un choix possible parmi d'autres langages, mais il ne faut absolument pas l'imposer. S'il est vraiment meilleur que les autres, il s'imposera de lui-meme, encore faut-il que la concurrence ne soit pas faussee!
La concurrence est faussée par l'ipr, il est vrai. Peut-être auraient-ils dû communiquer sur les raisons du choix. Ils auraient peut-être convaincu. Après, je reste sur ma position : j'y vois des avantages et des inconvénients à vouloir imposer un langage. Donc on verra ce qu'il en sera par la suite. Mais je ferai quand même l'effort de mon côté d'aller regarder du côté de Xcas.
by 
