[Info] Quel langage pour enseigner ?

Je me demande bien pourquoi le langage Python a été préféré pour le Lycée ???
En effet, tous les étudiants Post-BAC utilisent exclusivement le langage C, C+, C++ comme en IUT info, IUT GEii, Licence maths-info,...
Pourquoi ne pas apprendre aux élèves de 2nde, 1ere et Tale à "penser" en algorithmique et à créer des programmes "utiles" pour le supérieur ???

marc027 a écrit:Je me demande bien pourquoi le langage Python a été préféré pour le Lycée ???
En effet, tous les étudiants Post-BAC utilisent exclusivement le langage C, C+, C++ comme en IUT info, IUT GEii, Licence maths-info,...
Pourquoi ne pas apprendre aux élèves de 2nde, 1ere et Tale à "penser" en algorithmique et à créer des programmes "utiles" pour le supérieur ???

On s'est posé la question, et je pense que python est avantagé car c'est un langage qui ne nécessite pas de comprendre les phases de compilations (utile pour l'élève ou les profs), qui est pas forcement typé (pas besoin de savoir les différents types primitifs et comment ils sont gérés en mémoire) puis une syntaxe principalement basée sur l'identation et des {}et des ;

Et effectivement dans les IUT, le python n'est pas le premier choix...

Après, en regardant les formations (en maths/info), je vois que seul le python est abordé...

Je comprend bien ce point de vue, mais apprendre le prototypage et l'indentation dès le Lycée serait un plus !
Personnellement, je préfère 100 fois créer un programme en C ou C+ plutôt qu'en langage Python.
Je trouve la syntaxe plus logique et naturelle.

marc027 a écrit:Je comprend bien ce point de vue, mais apprendre le prototypage et l'indentation dès le Lycée serait un plus !
Personnellement, je préfère 100 fois créer un programme en C ou C+ plutôt qu'en langage Python.
Je trouve la syntaxe plus logique et naturelle.

Je n'osais presque pas le dire tant Python semble LA référence, mais cela me fait plaisir de le voir écrit. Je n'arrive pas à voir une logique ou une idée conductrice claire dans la syntaxe Python, cela traduit peut-être mon âge.

Binary a écrit:Je comprends votre point de vue. Je viens des sociétés de dev (cela ne fait que 3ans que je suis prof), et je trouve juste ce programme un peu éloigné des compétences attendues par ces sociétés.

Il s'agit d'un enseignement scientifique en lycée général, pas d'un enseignement technique ni de LP. D'ailleurs le programme précise explicitement qu'il n'a pas d'objectif professionnalisant : on ne forme pas des développeurs ; on ne forme à aucun métier. Pas plus que l'enseignement de la physique ou des math en lycée général, et on ne dit pas : "Ce programme de math/physique/whatever est un peu éloigné des compétences attendues par les sociétés de ceci ou de cela". Enfin si, des gens le disent, mais franchement…

Concernant la syntaxe Python, c'est vrai que l'indentation signifiante est à double tranchant : certains élèves (même en prépa) ont du mal. Est-ce que ça aurait été plus clair pour eux avec des accolades ? Rien n'est moins sûr. Mais au moins les élèves apprennent à indenter !

L'inconvénient que je vois à Python c'est que certaines opérations standard s'utilisent sous la forme de méthodes, ce qui pose des difficultés dans la mesure où on n'enseigne pas la programmation par objets : cette notation apparait comme ésotérique. Mais c'est bien peu de choses à côté des incantations qu'il faut écrire pour commencer à programmer en C++ ou pire en Java. Une autre critique qu'on pourrait faire est le double rôle des crochets : pour signaler la définition d'une nouvelle liste (et alors entre les crochets se trouve le contenu de la liste), et pour accéder à un terme de liste avec son indice (et alors les crochets entourent l'indice, et ne réfèrent pas le contenu). Mais c'est tellement répandu…

Il a aussi des avantages, notamment le fait que les affectations sont des instructions et non des expressions, ce qui a pour conséquence qu'un = au lieu de == dans une condition d'alternative ou de boucle provoque une erreur de syntaxe et non une exécution non souhaitée. On peut également citer la protection des accès aux tableaux (même si tout le monde ne sera pas d'accord là-dessus), et plus généralement tout ce qui relève de la gestion automatique de la mémoire.

La présence d'une REPL en Python a sans doute joué dans le choix (qui est aussi la continuation du choix fait en 2013 pour les CPGE, en lien avec les écoles d'ingénieurs).

C'est sûr qu'on a une perception différente quand on est habitué à un autre langage (je pense que c'est pour cette raison que des licences math-info travaillent encore en C comme premier langage ; dans d'autres on a très longtemps continué de faire du Lisp et on connait quelques endroits où Prolog, qui a certes une élégance, a été employé surtout parce que c'était le langage préféré du collègue en charge du cours). Ce n'est pas non plus mon langage préféré, en raison du typage dynamique.

Balthazaard a écrit:

marc027 a écrit:Je comprend bien ce point de vue, mais apprendre le prototypage et l'indentation dès le Lycée serait un plus !
Personnellement, je préfère 100 fois créer un programme en C ou C+ plutôt qu'en langage Python.
Je trouve la syntaxe plus logique et naturelle.

Je n'osais presque pas le dire tant Python semble LA référence, mais cela me fait plaisir de le voir écrit. Je n'arrive pas à voir une logique ou une idée conductrice claire dans la syntaxe Python, cela traduit peut-être mon âge.

Pareil. Je programmais déjà en C à 13/14 ans. J'ai toujours eu à me coltiner par la suite des langages divers et variés sans être vraiment convaincu. Mais bon.

e1654d a écrit:

Binary a écrit:Je comprends votre point de vue. Je viens des sociétés de dev (cela ne fait que 3ans que je suis prof), et je trouve juste ce programme un peu éloigné des compétences attendues par ces sociétés.

Il s'agit d'un enseignement scientifique en lycée général, pas d'un enseignement technique ni de LP. D'ailleurs le programme précise explicitement qu'il n'a pas d'objectif professionnalisant : on ne forme pas des développeurs ; on ne forme à aucun métier. Pas plus que l'enseignement de la physique ou des math en lycée général, et on ne dit pas : "Ce programme de math/physique/whatever est un peu éloigné des compétences attendues par les sociétés de ceci ou de cela". Enfin si, des gens le disent, mais franchement…

Concernant la syntaxe Python, c'est vrai que l'indentation signifiante est à double tranchant : certains élèves (même en prépa) ont du mal. Est-ce que ça aurait été plus clair pour eux avec des accolades ? Rien n'est moins sûr. Mais au moins les élèves apprennent à indenter !

L'inconvénient que je vois à Python c'est que certaines opérations standard s'utilisent sous la forme de méthodes, ce qui pose des difficultés dans la mesure où on n'enseigne pas la programmation par objets : cette notation apparait comme ésotérique. Mais c'est bien peu de choses à côté des incantations qu'il faut écrire pour commencer à programmer en C++ ou pire en Java. Une autre critique qu'on pourrait faire est le double rôle des crochets : pour signaler la définition d'une nouvelle liste (et alors entre les crochets se trouve le contenu de la liste), et pour accéder à un terme de liste avec son indice (et alors les crochets entourent l'indice, et ne réfèrent pas le contenu). Mais c'est tellement répandu…

Il a aussi des avantages, notamment le fait que les affectations sont des instructions et non des expressions, ce qui a pour conséquence qu'un = au lieu de == dans une condition d'alternative ou de boucle provoque une erreur de syntaxe et non une exécution non souhaitée. On peut également citer la protection des accès aux tableaux (même si tout le monde ne sera pas d'accord là-dessus), et plus généralement tout ce qui relève de la gestion automatique de la mémoire.

La présence d'une REPL en Python a sans doute joué dans le choix (qui est aussi la continuation du choix fait en 2013 pour les CPGE, en lien avec les écoles d'ingénieurs).

C'est sûr qu'on a une perception différente quand on est habitué à un autre langage (je pense que c'est pour cette raison que des licences math-info travaillent encore en C comme premier langage ; dans d'autres on a très longtemps continué de faire du Lisp et on connait quelques endroits où Prolog, qui a certes une élégance, a été employé surtout parce que c'était le langage préféré du collègue en charge du cours). Ce n'est pas non plus mon langage préféré, en raison du typage dynamique.

Bonjour, sans animosité, je souligne seulement pour référencer!
L'argument sur la prétendue facilité n'est jamais déterminant, bien difficile de voir ce qui est facile ou pas à appréhender, mon expérience de C ou je java et ma petite expérience de Python me laisse penser qu'oublier une accolade rend souvent la terminaison d'un bloc foireux et bloque la compil (si l'éditeur ne l'a pas signalé avant), une faute d'indentation peut décaler l'instruction suivante dans le bloc et ne pas bloquer le programme...est-ce un avantage?
Du reste parler de "facilité alors que certains sujets ici parlent de formation pour préparer le post bac et de "compétences" me semble inapproprié, l'adaptabilité (et combien cela compte dans une matière comme l'info par rapport à un domaine sécurisant comme les maths) est justement primordiale.

L'argument se retourne mais cette fois contre/pour Python dans l'exemple que tu cites pour les tests

Je trouve que a=b=2 est très cohérent en C, Python permet l'affectation multiple mais où est la cohérence puisqu'il me semble comme tu le dis que b=2 n'a pas de valeur en tant que tel (mais je connais peut-être trop mal Python et comme je l'ai dit mon expérience est réduite)

x,y =3,4 pourquoi pas (x,y)=(3,4) ? ça marche avec ou sans la parenthèse j'ai l'impression, mais quel est le statut de x,y? La parenthèse est facultative, ok mais tout est loin d'être facultatif dans le langage. Je n'aime pas trop ce choix obligatoire/facultatif sans que l'on sache exactement qui guide quoi et sans qu'une logique interne (comme en C) permette de décider ce qui est permis sans avoir le manuel de référence sous les yeux.

avis perso bien sur, si Python a du succès ce n'est pas sans raison.

Je suis assez d'accord concernant le problème de l'indentation. Ça présente un avantage visuel (mais qu'on a aussi dans les autres langages si on a pris la peine d'indenter correctement), ça permet aussi de changer facilement le niveau d'imbrication d'un bout de code, mais ça pose en effet les difficultés soulignées : on risque plus de désindenter incorrectement que de mal placer une accolade fermante, je pense.

Il y a en effet une règle spéciale dans la syntaxe Python pour permettre l'affectation multiple, alors que dans C cela découle en partie de la sémantique. Mais ça me parait complètement anecdotique : ça ne sert à rien d'écrire des affectations multiples ; si je fais un reproche à Python en la matière, c'est de les autoriser ! C'est de toutes façon un petit prix à payer pour le bénéfice que j'ai cité plus haut : l'oubli d'un = dans une comparaison ne passe pas (alors qu'en C on voit des recommandations de prendre l'habitude d'écrire if (0 == x) de façon à ce que le jour où on fait une faute de frappe ce soit détecté par le compilo…). Il y a par ailleurs une règle semblable pour la comparaison x < y < z, alors que ça pourrait (devrait) se parser comme des expressions booléennes imbriquées.

Idem pour (x, y) = (3, 4) qui n'a aucun intérêt. En revanche, cette construction est intéressante pour échanger les valeurs de deux variables ou faire des mises à jour croisées. C'est vrai que la syntaxe aurait été plus régulière (mais plus contraignante) si on avait imposé les parenthèses partout, les cas où elles le sont étant en effet un peu particuliers (mais logiques finalement : il s'agit de lever des ambigüités). Mais encore une fois, il suffit de toujours écrire les parenthèses et on est débarrassé du problème. Ce qui me parait un peu plus pénible, c'est que pour créer un tuple avec une seule valeur, on doit impérativement écrire (x,) et non (x), alors que dans tous les autres cas la virgule finale est facultative. Mais c'est un compromis : ça aurait été bizarre d'imposer d'écrire (x,y,).

Par contre je ne vois en quoi la syntaxe de C a plus de logique interne que celle de Python (le do-while suivi d'un point virgule, on en parle ?). C'est juste une question d'habitude. Il y a quelques trucs critiquables, notamment l'emploi des mots-clés for, if et in dans plusieurs constructions différentes où ils n'expriment pas la même chose (mais chaque cas reste sensé), et la parfois trop grande souplesse dans l'exécution (notamment la convertibilité implicite de la plupart des valeurs en un booléen et le fait une définition de classe en Python a autant de valeur qu'un accord avec le parti socialiste : il peut se passer complètement le contraire dans la réalité puisque n'importe quel bout de code qui a un objet entre les mains peut en modifier les méthodes !).

Mais ceci relève de la sémantique de Python (et de son typage dynamique), pas de sa syntaxe. Et si on commence à parler de la sémantique de C…

Puisqu'on parle de cohérence d'un langage de programmation, je trouve que rien n'a jamais égalé tcl-tk.

Binary a écrit:On s'est posé la question, et je pense que python est avantagé car c'est un langage qui ne nécessite pas de comprendre les phases de compilations (utile pour l'élève ou les profs), qui est pas forcement typé (pas besoin de savoir les différents types primitifs et comment ils sont gérés en mémoire) puis une syntaxe principalement basée sur l'identation et des {}et des ;

Je connais un autre langage qui ne nécessite pas de compilateur, qui n'est (presque) pas typé, et qui n'a ni {} ni point-virgule: l'assembleur.

e1654d a écrit:C'est de toutes façon un petit prix à payer pour le bénéfice que j'ai cité plus haut : l'oubli d'un = dans une comparaison ne passe pas (alors qu'en C on voit des recommandations de prendre l'habitude d'écrire if (0 == x) de façon à ce que le jour où on fait une faute de frappe ce soit détecté par le compilo…).

Un bon compilateur donne un avertissement intelligible lorsqu'on écrit == au lieu de =. Voilà ce que j'obtiens avec clang 7.0:

Code:

$ clang test.c
test.c:4:7: warning: using the result of an assignment as a condition without parentheses [-Wparentheses]
        if (a=2)
            ~^~
test.c:4:7: note: place parentheses around the assignment to silence this warning
        if (a=2)
             ^
            (  )
test.c:4:7: note: use '==' to turn this assignment into an equality comparison
        if (a=2)
             ^
             ==
1 warning generated.

(gcc 8.2.1 donne aussi un avertissement, mais seulement avec -Wall et ne donne pas la suggestion de remplacer = par ==).

e1654d a écrit:Il y a par ailleurs une règle semblable pour la comparaison x < y < z, alors que ça pourrait (devrait) se parser comme des expressions booléennes imbriquées.

Difficile de procéder ainsi lorsque x < y est convertible en entier.

Au début je pensais que l’indentation serait un point fort, mais finalement je me dis que les {} permettent de vraiment bien délimiter les blocs.

Et python a quand même beaucoup de mot clef "magiques". Je préfère le php et le javascript (qui couplé au html/css sont quand même vachement plus utiles).

Mais oui, on préfère souvent un langage par habitude.

Mathador a écrit:Je connais un autre langage qui ne nécessite pas de compilateur, qui n'est (presque) pas typé, et qui n'a ni {} ni point-virgule: l'assembleur.

Le mot assembleur est un raccourci pour parler du langage d'assemblage, alors qu'à la base c'est en fait le programme qui traduit le langage d'assemblage en langage machine et qui regroupe plusieurs fonctionnalités : préprocesseur (gestion des macro...), compilateur et édition des liens.

Un des problèmes de l'"assembleur" c'est que sa syntaxe n'est pas standard et peut varier d'un assembleur à l'autre. Par exemple, les outils GNU qu'on trouve sous Linux, utilisent la syntaxe ATT (mnémonique source, destination) là où d'autres utilisent la syntaxe Intel (mnémonique destination,source) pour du x86...

On rencontre des accolades en assembleur ARM :  PUSH {r1, r2}

L'assembleur GNU AS autorise le point-virgurle pour séparer plusieurs instructions écrites sur une même ligne.

Personnellement, j'ai commencé l'"assembleur" sans logiciel, en calculant à la main les distances relatives pour les sauts et en codant en hexadécimal les mnémoniques, pour faire des PEEK et POKE en basic et exécuter le programme ; parce que je ne disposait pas d'assembleur... Je me vois mal conseiller cette approche, assez masochiste, aux élèves d'aujourd'hui.

Si je devais conseiller la programmation en "assembleur" je proposerais probablement du Motorola 68000 avec un logiciel comme Easy68k.

Promis, la prochaine fois je réfléchirai davantage avant de troller.

Call_BB5A a écrit:Un des problèmes de l'"assembleur" c'est que sa syntaxe n'est pas standard et peut varier d'un assembleur à l'autre. Par exemple, les outils GNU qu'on trouve sous Linux, utilisent la syntaxe ATT (mnémonique source, destination) là où d'autres utilisent la syntaxe Intel (mnémonique destination,source) pour du x86...

D'un autre côté, le x86 n'est pas un choix souhaitable, ne serait-ce qu'à cause des modes d'adressage sibyllins et irréguliers du jeu d'instructions du processeur. Les opérandes mémoires en RISC sont autrement plus simples…
La variabilité importante de la syntaxe se retrouve-t-elle aussi dans l'assembleur des autres architectures ?

Call_BB5A a écrit:On rencontre des accolades en assembleur ARM :  PUSH {r1, r2}

Je suis allé voir, et c'est une instruction assez surprenante… ça me rappelle d'ailleurs que j'utilise assez peu mes Raspberry Pi, à part un qui sert de serveur MPD et DNS.

Call_BB5A a écrit:L'assembleur GNU AS autorise le point-virgule pour séparer plusieurs instructions écrites sur une même ligne.

J'aurais dû m'en rappeler, ayant déjà vu cette écriture.

Call_BB5A a écrit:Si je devais conseiller la programmation en "assembleur" je proposerais probablement du Motorola 68000 avec un logiciel comme Easy68k.

Là où j'ai étudié, on utilisait MIPS lorsqu'il était important d'avoir une ISA intelligible. Actuellement, je me demande s'il ne serait pas préférable d'utiliser l'ISA ARM si l'on veut une ISA répandue, ou RISC-V sinon.

Matheod a écrit:Et python a quand même beaucoup de mot clef "magiques".

Lesquels par exemple ?

Je préfère le php et le javascript (qui couplé au html/css sont quand même vachement plus utiles).

Javascript est un langage épouvantable ; même les gens qui le pratiquent (y compris à contrecœur) le reconnaissent. Pour rester dans le vocabulaire magique, plusieurs de ses aspects basiques relèvent de la magie noire ! On peut voir ce très bref exposé humoristique de tératologie. Il parait que PHP s'est amélioré ces dernières années (ça fait longtemps que je n'ai plus pratiqué).

Ça fait un peu plaisanteries de geeks mais j'adore...
https://www.scriptol.fr/programmation/citations.php

Balthazaard a écrit:Ça faut un peut plaisanteries de geeks mais j'adore...
https://www.scriptol.fr/programmation/citations.php

Il y en a d'excellentes:

"Perl est le seul language qui paraît le même avant et après le chiffrement RSA."
Keith Bostic

"Si Java avait un vrai garbage collector (collecteur de déchets, ndt), la plupart des programmes se supprimeraient eux-mêmes lors de l'exécution."
Robert Sewell.

(Pour les non-programmeurs, le garbage collector est un système utilisé par certains langages de programmation pour libérer de la mémoire devenue inutilisée.)

Ce sont mes deux préférées.... avec

"PHP est un mal mineur fait et créé par des amateurs incompétents, alors que Perl est un grand et insidieux mal, perpétrés par des professionnels qualifiés, mais pervertis."
Jon Ribbens. Programmeur.

Je me permets d'intervenir, car il me semble dommage de laisser des contrevérités sur le langage Python sans réponse.

marc027 a écrit:En effet, tous les étudiants Post-BAC utilisent exclusivement le langage C, C+, C++ comme en IUT info, IUT GEii, Licence maths-info,...

C'est juste totalement faux, je passe sur le C+ (???), mais Python est un langage très utilisé dans le monde de l'entreprise, le monde académique, de la "programmation amateur" et dans l'enseignement supérieur. Cela partout dans le monde.

Il y a de nombreux exemples d'IUT ou de licence maths-info qui commencent avec Python: on peut par exemple citer le DUT informatique d'Orsay ou la licence MIPI de Paris 6 (Sorbonne maintenant..). Python est aussi utilisé dans les classes préparatoires. Sachant que cette prédominance de Python dans une partie de l'enseignement supérieur vient des grandes facs américaines, on est loin de quelque chose de limité à la France.

Maintenant, je suis d'accord, Python ne prédomine pas tout à fait dans les formations "d'informatique pour informaticien", il prédomine surtout comme langage de programmation pour les scientifiques, il est devenu la lingua franca des gens programmant sans être purement développeur.

Par ailleurs une des principales raisons de l'adoption de Python pour les maths en lycée, c'est la présence d'un REPL. L'idée de la modification du programme de l'an dernier était de se débarrasser des "saisir"/"lire"/"afficher"/"input"/"print" qui ne permettaient pas vraiment de comprendre comment les algos/programmes interagissaient entre eux. De plus, ce ne sont pas des notions algorithmiques, on utilise donc à la place la notion de fonction beaucoup plus algorithmique.  
Dans ce contexte, un REPL est donc indispensable pour pouvoir "interagir" avec la machine.

Et globalement, Python est beaucoup plus proche de l'algorithmique/pseudo-code que tout les autres "grands" langages.

Sur la syntaxe de Python, j'ai du mal à voir ce que vous lui reprochez, et surtout pourquoi vous l'opposez au C, Python est très très profondément inspiré le C.

Je trouve que a=b=2 est très cohérent en C,

notamment le fait que les affectations sont des instructions et non des expressions

C'est plus un élément de critique fort vis à vis du C qu'un point positif pour moi, même si j'aime beaucoup le C par ailleurs.