"Manual investigation into the students' programs suggest that problem understanding and programming logic, and not language features, may be the main hurdles to
learning programming."
Évidemment je n'ai pas testé avec 6000 étudiants mais mon expérience de transition d'enseignement du C⁺⁺ vers Python est plutôt en accord avec cette conclusion. La difficulté tient surtout à l'acquisition de mécaniques de raisonnement nouvelles ; à tel point que l'excellence en mathématiques est souvent annonciatrices de difficultés d'apprentissage en programmation.
Toutefois Python (mais peut-être d'autres facteurs) me semble avoir lissé les résultats. En C⁺⁺, les classes se divisaient globalement entre les gens ayant 2 de moyenne et ceux ayant 16. En Python les notes paraissent plus uniformément distribuées.
Une des difficultés qui peut survenir est que dans les maths, en dehors des méthodes algorithmiques, le temps n'intervient pas. Dans un problème, on va par exemple écrire un certain nombre de formules mathématiques qui sont toutes vraies simultanément, d'un bloc. Alors que transcrites dans un programme, elles vont être exécutées dans le temps, séquentiellement. Parfois un étudiant va alors croire qu'une formule écrite avant une boucle voit sa valeur automatiquement mise à jour quand une variable change dans la boucle.
Certains peuvent aussi écrire B=A au lieu de A=B, croyant que le = en programmation est la même chose qu'en maths. D'où le := en Pascal pour faire la distinction.
Et je ne parle pas des = au lieu des == dans un if en C…
Posté par Tit .
Évalué à 4 (+2/-0).
Dernière modification le 11 décembre 2024 à 10:45.
ce qui présente une certaine difficulté pour moi (qui ne suis pas mathématicien) c'est de comprendre : << il est faux de penser le contraire de "Ça ne représente pas plus une difficulté pour un mathématicien que pour un autre">> … trop d'empilement de négations pour mon esprit limité ;)
l'excellence en mathématiques est souvent annonciatrices de difficultés d'apprentissage en programmation
C’est un comble quand on sait que l’algorithmie est (bon disons était) une branche des mathématiques. Et quand je pense que c’est par des matheux et matheuses que LISP/ALGOL/FORTRAN sont arrivé, ça m’en bouche un coin. :)
Après, j’ai envie de dire que tout dépend de ce que l’on entend par « programmation » ;) Je n’ai vu que des gens bons en maths s’approprier rapidement APL ou Coq ; ou être rapidement productif avec Octave (pour ne pas nommer le pendant privateur) par exemple. J’ai remarqué aussi que les gens qui ont l’esprit plus tourné vers les mathématiques sont plus à l’aise avec OCaml ou Julia qu’avec TypeScript ou Python par exemple.
Ceci dit, apprendre de nouveaux paradigmes n’est pas simple et facile pour tout le monde :
La difficulté tient surtout à l'acquisition de mécaniques de raisonnement nouvelles
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Posté par kantien .
Évalué à 2 (+1/-1).
Dernière modification le 11 décembre 2024 à 09:40.
Oui, cela doit dépendre des langages qu'on leur enseigne et comment l'on s'y prend. J'aimerai bien voir un esprit non matheux faire du Haskell ! Rien que pour faire des entrées-sorties, il faut déjà passer par la monade IO. Heu ? C'est quoi une monade ? C'est simple, c'est juste un monoïde dans la catégorie des enfodoncteurs ! :-D
Sinon, on fait comment pour traduire naturellement les concepts de bases de l'algèbre en OCaml ? C'est simple :
(* un concept mathématique est un type dans les cas des structures, ce sont des modules*)moduletypeGroupe=sigtypetvalzero:tvaladd:t->t->tvalneg:t->tendmoduletypeAnneau=sigincludeGroupevalone:tvalmul:t->t->tend(* maintenant on définit le polynôme `x² + x + 1` *)letpoly(typea)(moduleR:Anneauwithtypet=a)x=let(+),(*)=R.(add,mul)inx*x+x+R.one(* on l'utilise sur différents anneaux *)poly(moduleInt)5;;-:int=31poly(moduleFloat)5.4;;-:float=35.56(* la notion d'anneau produit *)moduleProd(R:Anneau)(S:Anneau):Anneauwithtypet=R.t*S.t=structtypet=R.t*S.tletzero=(R.zero,S.zero)letone=(R.one,S.one)letadd(x,y)(x',y')=(R.addxx',S.addyy')letmul(x,y)(x',y')=(R.mulxx',S.mulyy')letneg(x,y)(x',y')=(R.negxx',S.negyy')end(* utilisation *)poly(moduleProd(Int)(Float))(5,5.4);;-:int*float=(31,35.56)
Bon, la syntaxe est un peu lourde pour définir le polynôme, mais bientôt on pourra se contenter de:
letpoly(R:Anneau)x=...
En Haskell, on passerait par des types classes avec une syntaxe plus légère et il ne serait même pas nécessaire de passer explicitement l'anneau en paramètre lors de l'appel de fonction. En Rust, ce serait avec des Traits avec une syntaxe aussi lourde et sans instantiation explicite de l'anneau.
On peut ensuite continuer la hiérarchie des structures algébriques:
On fait comment dans les autres langages pour formaliser tout ça ? Le premier qui me propose un idiome de POO (comme en C++ ou Python), je l'envoie au piquet et lui demande de retourner étudier l'algèbre ! :-P
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
Et le début résume bien toute la problématique (de l’enseignement et du langage et du public)
Oui, cela doit dépendre des langages qu'on leur enseigne et
Une personne qui travaille dans un domaine où Prolog est bien indiqué assimilera facilement ce langage. Maintenant si on veut lui faire faire les mêmes choses en passant par Python, la marche serait aussi haute et laborieuse qu’une personne ne connaissant que le François et devant se mettre au Mandarin. Dans cet exemple, Lisp serait plus accessible bien que différent ; un peu comme apprendre la langue de Gothe ou de Shakespeare pour notre francophone.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Même au-delà de mon exemple, il y a un point fondamental en mathématique : toutes les valeurs sont immuables et vivent, pour ainsi dire, dans le monde Platonicien des idées. D'où ma référence à Haskell où tout est immuable et qui nécessite la monade IO pour faire des entrées sorties.
Mais de manière générale, la mutabilité est une source d'emmerdes sans nom dont on n'a rarement besoin, si ce n'est pour des raisons de performances en programmation bas niveau. Et dans ce cas, mieux vaut du Rust qui contrôle cela via le borrowing et le lifetime. Raisonner, sans erreur, avec des choses mutables sur une large échelle est une gageure.
Ensuite, mon expérience m'a appris que les programmeurs ne comprennent pas toujours réellement les structures qu'ils manipulent, en particulier avec la POO (qui se représente réellement un objet comme une paire constituée d'une algèbre et d'une valeur de son support ? ce qu'il est pourtant réellement).
Enfin, l'algorithmie est bien une branche des mathématiques. Pour l'anecdote, et en revenir à Platon (cf. le dialogue du Ménon), la première crise des mathématiques remonte à l'antiquité et concernait un problème de non terminaison d'un algorithme. Algorithme qui pour nous termine toujours, les pythagoriciens pensaient qu'il devait aussi en être ainsi mais ils ont trouvé un cas de non terminaison qui les laissa perplexe. Je veux parler de l'algorithme d'Euclide pour le calcul du plus petit diviseur commun. Il s'en servait pour trouver la commune mesure entre deux grandeurs géométriques, jusqu'à ce qu'il l'essaye sur un carré et sa diagonale. La non terminaison signifiant l'irrationalité de racine de 2. ;-)
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
Dans les tâches évaluées, les étudiants n'ont qu'à acquérir la syntaxe de base du langage et à faire preuve de compétences minimales en logique. Ils n'ont même pas besoin de la leçon sur la compilation, puisque celle-ci est rendue transparente par l'IDE. Sur ces critères, je ne m'attends effectivement pas à voir de différence entre C++, Java et Python.
C'est à un niveau un peu supérieur que je m'attendrais à voir une différence, par exemple pour manipuler des types élaborés, pour bien gérer la mémoire, ou pour utiliser l'API intégrée au langage.
Méthodologiquement, je suis intrigué par le passage :
Le programme précisait que le cours était destiné à la fois aux étudiants en informatique et aux non-spécialistes (comprendre : étudiants dans une autre discipline).
Le critère final a été inclus car de nombreux cours Python s'adressent uniquement aux non-spécialistes, et on pourrait donc s'attendre à ce que ces cours demandent aux étudiants de passer plus de temps et d'avoir plus de difficultés sur ces exemples de laboratoires.
Est-ce qu'ils sont en train de dire qu'ils ont ajouté un critère spécifiquement pour avoir des résultats défavorables à Python ?
Est-ce qu'ils sont en train de dire qu'ils ont ajouté un critère spécifiquement pour avoir des résultats défavorables à Python ?
Non, ils disent qu'ils ont cherché à éliminer un biais statistique : vu que Python est célèbre chez les débutants, comparer Python vs Java c'est aussi quelque part comparer débutant vs expérimenté (ce qui n'est pas le but de la recherche).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
C'est aussi inclure un biais. Si Python est si simple à apprendre c'est en partie car on trouve tous les tutoriel (voir les programmes tout fait) sur internet.
C'est un fait, il m'est arrivé de trouver le programme tout cuit en Python alors qu'autrement il fallait se débrouiller : appel à un webservice. Eh bien faire un wget, un parsing json et extraire les infos en C++, même pour moi qui connaît bien c'est largement plus complexe en C++ (et je ne parles pas de C).
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Je crois que la traduction en Français s'est un peu fourvoyée. Le texte original ne parle pas de "spécialistes" et "non-spécialistes", mais de major et minor qui sont une spécificité des universités États-Uniennes.
En gros, ils ont retenu les cours de programmation s'adressant à des étudiants en informatique, mais pas ceux s'adressant uniquement à des étudiants dans un autre domaine, qui auraient tout de même des cours de programmation dans leur cursus. Pour ces derniers, Python est sur-représenté, et donc cela pourrait défavoriser Python, qui est plus volontiers mis entre les mains de personnes qui n'ont pas prévu de devenir informaticiens professionnels et sont peut-être moins intéressés et moins susceptibles de suivre chaque exercice jusqu'au bout.
Celles/ceux-là ne parlent pas des langages un peu plus littéraux comme AppleScript (que je trouve vraiment bien fait) ou COBOL ou autre ?
H.S. chaud… il a fallu plusieurs essais et intuitions pour trouver la bonne formulation…
premier essai qui m’est venu naturellement :
comme [[AppleScript]] (que je trouve vraiment bien fait) ou
dernier essai qui a finalement fonctionné :
comme [[AppleScript]] \(que je trouve vraiment bien fait) ou
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
« programme » est méta… Et la question est un peu la même que « quelle est la différence entre un-e cardiologue et un-e médecin ? »
Plus sérieusement, un langage de scriptage est un langage de programmation interprété…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Ca me semble être une definition discutable de script. Il me semble que dans le language courant, on parle plus de script pour parler de l'automatisation d'une série de commandes.
Et en ce sens la, python n'est pas forcement le plus pratique. Javascript (j'ai bien note qu'il y a "script" dans le nom) convient a la premiere definition, mais pas vraiment a la deuxième.
Dans le sens le plus traditionnel, qui est celui des scripts shell, un script sert principalement à lancer et coordonner l'exécution de programmes.
le sens graphique (ou théâtral)
Dans un sens différent, on appelle aussi langage de script un langage où les éléments visuels sont considérés comme des personnages placés sur une « scène », personnages dont le comportement est défini par un script.
le sens péjoratif (juste avant la section des propriétés)
Le terme langage de script a souvent une connotation négative, on préfère alors parler de langage de programmation dynamique quand c'est possible.
la désignation générique (paragraphe juste avant) que j’ai mentionnée
Le terme « langage de script » désigne parfois n'importe quel langage de programmation interprété. […] On y trouve alors ceux qui sont parfois ou toujours interprétés comme Python, BASIC, PHP, Lisp, JavaScript, etc.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Ce n'est pas la difficulté/le temps pour devenir expert qui compte seulement.
Il y a aussi le temps pour arriver à faire un programme qui fait cf que l'on veut… et de ce point de vue python est imbattable. Vous prenez 2 néophytes et vous leur demandez un programme qui fait un truc basique, en Python ce sera bien plus rapide. On peut se contenter de coller 2-3 tutoriel sur internet… Et on retrouve la même histoire pour un programme un peu plus complexe entre autre car Python dispose de toute les librairies et même si C++ n'en ai pas dépourvu elles sont plus complexe à intégrer et maîtriser.
Ensuite même une fois le language à peu près maîtriser le Python permet de développer bien plus rapidement.
La difficulté en C++ c'est de bien gérer sa mémoire, de comprendre les pointeurs, de débuguer (comprendre les messages d'erreur), d'installer son IDE et de compiler.. difficile de commencer un programme sans.
La difficulté en Python c'est de gérer les dépendances (venv), la portabilité sur d'autres versions de Pythons (docker), les pythonneries, les bibliothèques avancées et optimisées… rien de bien important pour la pluspart des petits projets et pour les gros ça arrive après dans une étape où on a validé le reste…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Il y a aussi le temps pour arriver à faire un programme qui fait cf que l'on veut… et de ce point de vue python est imbattable. Vous prenez 2 néophytes et vous leur demandez un programme qui fait un truc basique, en Python ce sera bien plus rapide. On peut se contenter de coller 2-3 tutoriel sur internet…
Pas forcément. Lorsque j'ai commencé à apprendre Python, j'ai justement été bloqué pendant un temps certain à partir de trucs collés d'internet qui ne marchaient pas.
Le premier souci est que j'avais indenté avec des tabulations et que le bout de code inclus récupéré était indenté avec des espaces. L'interpréteur a refusé d'interpréter avec un message cryptique, et il a fallu du temps pour comprendre ce qui n'allait pas.
Le second est que la syntaxe de la fonction print a changé entre python 2 et python 3 et que j'essayais de faire tourner un programme python 2 genre "Hello world" sur mon environnement qui était en 3.
J'avais vraiment eu moins de problème en C. Les tutos de 1995 compilent toujours…
En son temps, BASIC était imbattable (bien plus simple que Python en prenant les mêmes critères) ; et feu(?) LSE avait toutes les qualités pour apprendre des algos (en dessin ou en texte formel) avec une implémentation directe…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
"Faire un truc" et "bien plus rapide" c'est très relatif.
Si tu fais un truc mais que tu ne le comprends pas, est-ce que tu as appris réellement ?
Par exemple si tu dois faire une intersection entre deux ensembles, en Python tu vas utiliser set, c'est plié en 3 lignes. En C tu vas faire des boucles, c'est beaucoup plus difficile mais à la fin tu aura appris un algo.
Si tu fais un truc mais que tu ne le comprends pas,
A quoi ça te sert de comprendre l'algorithme derrière? Pour un expert, pour des micro optim peut-être. Et encore l'algorithme déjà existant est sûrement plus optimisé que le tiens.
A tu besoin de comprendre aussi le fonctionnement de l'ordinateur à fond?
Clairement si on peut se passer de réinventer la roue.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
On parle d'apprentissage.
Pour ma part le fait d'avoir commencé par apprendre le fonctionnement d'un ordinateur "à fond" en commençant par l'assembleur plus le C m'a énormément simplifié la vie par la suite.
Le réinventage de roue est également un excellent moyen d'apprendre car on peut ensuite regarder comment d'autres ont fait ces mêmes roues.
Pour faire du Python, il faut comprendre le fonctionnement des types implicite (est-ce que c'est une string? est-ce que c'est un entier? comment on convertit entre les 2?), la gestion de la mémoire par références (si on a deux variables qui référencent le même objet, en modifier une va modifier l'autre), les exceptions, …
L'étude compare ces langages en dehors de leur environnement "naturel", dans un IDE web clé en main. Donc toute la partie venv, dépendances, portabilité ne pose pas problème (de la même façon que la compilation, édition de lien, etc en C++ n'est pas mise en jeu).
La conclusion est donc peut-être que le langage Python n'est pas plus simple à apprendre, mais que son environnement (facile à installer, avec des modules pour faire beaucoup de choses disponibles dans pip ou dans la bibliohèque standard) est son point fort qui rend le tout vraiment plus abordable.
Depuis la dernière réforme du lycée, il y a une spécialité NSI (Numérique et sciences informatiques) disponible. Ce n'est pas une option, c'est bien une composante majeure du bac pour ceux qui la choisissent.
En deux ans (première et terminale), de nombreux thèmes sont abordés, et la programmation en est un gros morceau. Les élèves partent souvent d'un niveau : « ils n'ont presque jamais touché un clavier avant ». Pour beaucoup, il leur faut beaucoup de temps pour trouver les parenthèses… Les élèves ont des profils très variés. Certains sont matheux (ils ont aussi la spé maths, et réussissent souvent bien, et sont souvent les plus à l'aise), d'autres ont choisi une autre spécialité moins scientifique (comme art-plastique, ou histoire/géopolitique, … tous les profils sont possibles). Très clairement, les profils matheux sont avantagés pour réussir (mais ce n'est pas rédhibitoire pour les autres ! Il y a des réussites possibles.)
Le choix du langage s'est porté sur Python, pour tout un tas de raisons que je trouve parfaitement valables. Dans le lot, il y avait : interprété, largement utilisé et documenté.
Franchement, si le choix n'avait pas été Python, je n'aurais même pas candidaté pour enseigner NSI. Essayez d'imaginer un tout jeune batailler à comprendre un simple Hello World! en Java ; je n'ose même pas ! Avec Python, le programme permet de faire travailler efficacement les élèves, en deux ans, du début complet jusqu'à la construction de structures arborescentes variées, et le travail sur des graphes, le tout en POO. (Et je rappelle que ce n'est qu'une partie du programme, il y a aussi BDD(SQL), réseau, des projets à réaliser, …) Volume horaire : 4h/semaine en première ; 6h par semaine en terminale.
Les poursuites d'études post BAC, avec NSI en poches, pour les plus sélectives, sont très clairement les prépas MP2I. Pas seulement, mais toujours avec les profils matheux les plus recherchés.
D'après mon expérience, un autre choix que Python aurait conduit les élèves moyens à un échec terrible sur la partie programmation, alors que là, ils peuvent faire de choses honorables.
Pour voir un peu ce sur quoi on les fait travailler, vous pouvez jeter un œil là pour les exercices : https://pratique.forge.apps.education.fr/algo/
(Très grosse base d'exercices en ligne, aide + guide si besoin, aucune installation, RGPD, autonomie, autoévaluation, aucune mesure d'audience, forge logicielle Éducation Nationale…)
# Pas mieux
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 4 (+2/-0).
Évidemment je n'ai pas testé avec 6000 étudiants mais mon expérience de transition d'enseignement du C⁺⁺ vers Python est plutôt en accord avec cette conclusion. La difficulté tient surtout à l'acquisition de mécaniques de raisonnement nouvelles ; à tel point que l'excellence en mathématiques est souvent annonciatrices de difficultés d'apprentissage en programmation.
Toutefois Python (mais peut-être d'autres facteurs) me semble avoir lissé les résultats. En C⁺⁺, les classes se divisaient globalement entre les gens ayant 2 de moyenne et ceux ayant 16. En Python les notes paraissent plus uniformément distribuées.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Pas mieux
Posté par Maderios . Évalué à 4 (+2/-0).
Je garde donc espoir :)
[^] # Re: Pas mieux
Posté par vmagnin (site web personnel) . Évalué à 6 (+4/-0).
Une des difficultés qui peut survenir est que dans les maths, en dehors des méthodes algorithmiques, le temps n'intervient pas. Dans un problème, on va par exemple écrire un certain nombre de formules mathématiques qui sont toutes vraies simultanément, d'un bloc. Alors que transcrites dans un programme, elles vont être exécutées dans le temps, séquentiellement. Parfois un étudiant va alors croire qu'une formule écrite avant une boucle voit sa valeur automatiquement mise à jour quand une variable change dans la boucle.
Certains peuvent aussi écrire
B=Aau lieu deA=B, croyant que le=en programmation est la même chose qu'en maths. D'où le:=en Pascal pour faire la distinction.Et je ne parle pas des
=au lieu des==dans unifen C…[^] # Re: Pas mieux
Posté par abriotde (site web personnel, Mastodon) . Évalué à 2 (+1/-0).
Ça ne représente pas plus une difficulté pour un mathématicien que pour un autre… ce qui je pense est faux, c'est de penser le contraire.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Pas mieux
Posté par Tit . Évalué à 4 (+2/-0). Dernière modification le 11 décembre 2024 à 10:45.
ce qui présente une certaine difficulté pour moi (qui ne suis pas mathématicien) c'est de comprendre : << il est faux de penser le contraire de "Ça ne représente pas plus une difficulté pour un mathématicien que pour un autre">> … trop d'empilement de négations pour mon esprit limité ;)
[^] # Re: Pas mieux
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 6 (+4/-0).
C’est un comble quand on sait que l’algorithmie est (bon disons était) une branche des mathématiques. Et quand je pense que c’est par des matheux et matheuses que LISP/ALGOL/FORTRAN sont arrivé, ça m’en bouche un coin. :)
Après, j’ai envie de dire que tout dépend de ce que l’on entend par « programmation » ;) Je n’ai vu que des gens bons en maths s’approprier rapidement APL ou Coq ; ou être rapidement productif avec Octave (pour ne pas nommer le pendant privateur) par exemple. J’ai remarqué aussi que les gens qui ont l’esprit plus tourné vers les mathématiques sont plus à l’aise avec OCaml ou Julia qu’avec TypeScript ou Python par exemple.
Ceci dit, apprendre de nouveaux paradigmes n’est pas simple et facile pour tout le monde :
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pas mieux
Posté par kantien . Évalué à 2 (+1/-1). Dernière modification le 11 décembre 2024 à 09:40.
Oui, cela doit dépendre des langages qu'on leur enseigne et comment l'on s'y prend. J'aimerai bien voir un esprit non matheux faire du Haskell ! Rien que pour faire des entrées-sorties, il faut déjà passer par la monade IO. Heu ? C'est quoi une monade ? C'est simple, c'est juste un monoïde dans la catégorie des enfodoncteurs ! :-D
Sinon, on fait comment pour traduire naturellement les concepts de bases de l'algèbre en OCaml ? C'est simple :
Bon, la syntaxe est un peu lourde pour définir le polynôme, mais bientôt on pourra se contenter de:
En Haskell, on passerait par des types classes avec une syntaxe plus légère et il ne serait même pas nécessaire de passer explicitement l'anneau en paramètre lors de l'appel de fonction. En Rust, ce serait avec des Traits avec une syntaxe aussi lourde et sans instantiation explicite de l'anneau.
On peut ensuite continuer la hiérarchie des structures algébriques:
On fait comment dans les autres langages pour formaliser tout ça ? Le premier qui me propose un idiome de POO (comme en C++ ou Python), je l'envoie au piquet et lui demande de retourner étudier l'algèbre ! :-P
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Pas mieux
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Fou rire sur la fin :D
Et le début résume bien toute la problématique (de l’enseignement et du langage et du public)
Une personne qui travaille dans un domaine où Prolog est bien indiqué assimilera facilement ce langage. Maintenant si on veut lui faire faire les mêmes choses en passant par Python, la marche serait aussi haute et laborieuse qu’une personne ne connaissant que le François et devant se mettre au Mandarin. Dans cet exemple, Lisp serait plus accessible bien que différent ; un peu comme apprendre la langue de Gothe ou de Shakespeare pour notre francophone.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pas mieux
Posté par kantien . Évalué à 3 (+1/-0).
Même au-delà de mon exemple, il y a un point fondamental en mathématique : toutes les valeurs sont immuables et vivent, pour ainsi dire, dans le monde Platonicien des idées. D'où ma référence à Haskell où tout est immuable et qui nécessite la monade IO pour faire des entrées sorties.
Mais de manière générale, la mutabilité est une source d'emmerdes sans nom dont on n'a rarement besoin, si ce n'est pour des raisons de performances en programmation bas niveau. Et dans ce cas, mieux vaut du Rust qui contrôle cela via le
borrowinget lelifetime. Raisonner, sans erreur, avec des choses mutables sur une large échelle est une gageure.Ensuite, mon expérience m'a appris que les programmeurs ne comprennent pas toujours réellement les structures qu'ils manipulent, en particulier avec la POO (qui se représente réellement un objet comme une paire constituée d'une algèbre et d'une valeur de son support ? ce qu'il est pourtant réellement).
Enfin, l'algorithmie est bien une branche des mathématiques. Pour l'anecdote, et en revenir à Platon (cf. le dialogue du Ménon), la première crise des mathématiques remonte à l'antiquité et concernait un problème de non terminaison d'un algorithme. Algorithme qui pour nous termine toujours, les pythagoriciens pensaient qu'il devait aussi en être ainsi mais ils ont trouvé un cas de non terminaison qui les laissa perplexe. Je veux parler de l'algorithme d'Euclide pour le calcul du plus petit diviseur commun. Il s'en servait pour trouver la commune mesure entre deux grandeurs géométriques, jusqu'à ce qu'il l'essaye sur un carré et sa diagonale. La non terminaison signifiant l'irrationalité de racine de 2. ;-)
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
# my 2 cents
Posté par sobriquet . Évalué à 4 (+3/-0).
Dans les tâches évaluées, les étudiants n'ont qu'à acquérir la syntaxe de base du langage et à faire preuve de compétences minimales en logique. Ils n'ont même pas besoin de la leçon sur la compilation, puisque celle-ci est rendue transparente par l'IDE. Sur ces critères, je ne m'attends effectivement pas à voir de différence entre C++, Java et Python.
C'est à un niveau un peu supérieur que je m'attendrais à voir une différence, par exemple pour manipuler des types élaborés, pour bien gérer la mémoire, ou pour utiliser l'API intégrée au langage.
Méthodologiquement, je suis intrigué par le passage :
Est-ce qu'ils sont en train de dire qu'ils ont ajouté un critère spécifiquement pour avoir des résultats défavorables à Python ?
[^] # Re: my 2 cents
Posté par gUI (Mastodon) . Évalué à 8 (+5/-0).
Non, ils disent qu'ils ont cherché à éliminer un biais statistique : vu que Python est célèbre chez les débutants, comparer Python vs Java c'est aussi quelque part comparer débutant vs expérimenté (ce qui n'est pas le but de la recherche).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: my 2 cents
Posté par abriotde (site web personnel, Mastodon) . Évalué à 3 (+2/-0).
C'est aussi inclure un biais. Si Python est si simple à apprendre c'est en partie car on trouve tous les tutoriel (voir les programmes tout fait) sur internet.
C'est un fait, il m'est arrivé de trouver le programme tout cuit en Python alors qu'autrement il fallait se débrouiller : appel à un webservice. Eh bien faire un wget, un parsing json et extraire les infos en C++, même pour moi qui connaît bien c'est largement plus complexe en C++ (et je ne parles pas de C).
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: my 2 cents
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
Je crois que la traduction en Français s'est un peu fourvoyée. Le texte original ne parle pas de "spécialistes" et "non-spécialistes", mais de major et minor qui sont une spécificité des universités États-Uniennes.
En gros, ils ont retenu les cours de programmation s'adressant à des étudiants en informatique, mais pas ceux s'adressant uniquement à des étudiants dans un autre domaine, qui auraient tout de même des cours de programmation dans leur cursus. Pour ces derniers, Python est sur-représenté, et donc cela pourrait défavoriser Python, qui est plus volontiers mis entre les mains de personnes qui n'ont pas prévu de devenir informaticiens professionnels et sont peut-être moins intéressés et moins susceptibles de suivre chaque exercice jusqu'au bout.
# normal
Posté par devnewton 🍺 (site web personnel) . Évalué à 1 (+4/-6).
Bien qu'on puisse utiliser Python pour de la programmation, c'est d'abord un langage de script.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: normal
Posté par orfenor . Évalué à 2 (+0/-0). Dernière modification le 11 décembre 2024 à 00:48.
Oui, mais c'est surtout un langage de scribes.
[^] # Re: normal
Posté par gwilherm . Évalué à 3 (+3/-0).
C'est une langue de vipère !
[^] # Re: normal
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Oui, ça a perdu son fun quand Monty s’est paré d’un logo rampant.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: normal
Posté par gwilherm . Évalué à 2 (+2/-0).
C'est une langue de vipère !
[^] # Re: normal
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Celles/ceux-là ne parlent pas des langages un peu plus littéraux comme AppleScript (que je trouve vraiment bien fait) ou COBOL ou autre ?
H.S. chaud… il a fallu plusieurs essais et intuitions pour trouver la bonne formulation…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: normal
Posté par BAud (site web personnel) . Évalué à 3 (+1/-0).
moui, il faut échapper à la regexp du Markdown :p une virgule aurait suffit
[^] # Re: normal
Posté par Tit . Évalué à 4 (+2/-0).
C'est quoi la différence entre un script et un programme ?
[^] # Re: normal
Posté par gwilherm . Évalué à 2 (+2/-0).
Personnellement je le vois comme ça : Un script est un programme mais un programme n'est pas nécessairement un script
[^] # Re: normal
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+1/-1).
« programme » est méta… Et la question est un peu la même que « quelle est la différence entre un-e cardiologue et un-e médecin ? »
Plus sérieusement, un langage de scriptage est un langage de programmation interprété…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: normal
Posté par flagos . Évalué à 2 (+0/-0).
Ca me semble être une definition discutable de script. Il me semble que dans le language courant, on parle plus de script pour parler de l'automatisation d'une série de commandes.
Et en ce sens la, python n'est pas forcement le plus pratique. Javascript (j'ai bien note qu'il y a "script" dans le nom) convient a la premiere definition, mais pas vraiment a la deuxième.
[^] # Re: normal
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Suivre le lien… Il y a
le sens historique (de langage de « batch »)
le sens graphique (ou théâtral)
le sens péjoratif (juste avant la section des propriétés)
la désignation générique (paragraphe juste avant) que j’ai mentionnée
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: normal
Posté par Benoît Sibaud (site web personnel) . Évalué à 4 (+1/-0).
Le script, aussi appelé écriture script, écriture scripte ou aussi écriture imprimée
ça couvre du coup les autres sens de script, ça devient rare les scripts manuels écrits à la main en cursive.
[^] # Re: normal
Posté par BAud (site web personnel) . Évalué à 3 (+1/-0).
les recettes de cuisine ? :D
# il n'y a pas que ça
Posté par abriotde (site web personnel, Mastodon) . Évalué à 5 (+4/-0).
Ce n'est pas la difficulté/le temps pour devenir expert qui compte seulement.
Il y a aussi le temps pour arriver à faire un programme qui fait cf que l'on veut… et de ce point de vue python est imbattable. Vous prenez 2 néophytes et vous leur demandez un programme qui fait un truc basique, en Python ce sera bien plus rapide. On peut se contenter de coller 2-3 tutoriel sur internet… Et on retrouve la même histoire pour un programme un peu plus complexe entre autre car Python dispose de toute les librairies et même si C++ n'en ai pas dépourvu elles sont plus complexe à intégrer et maîtriser.
Ensuite même une fois le language à peu près maîtriser le Python permet de développer bien plus rapidement.
La difficulté en C++ c'est de bien gérer sa mémoire, de comprendre les pointeurs, de débuguer (comprendre les messages d'erreur), d'installer son IDE et de compiler.. difficile de commencer un programme sans.
La difficulté en Python c'est de gérer les dépendances (venv), la portabilité sur d'autres versions de Pythons (docker), les pythonneries, les bibliothèques avancées et optimisées… rien de bien important pour la pluspart des petits projets et pour les gros ça arrive après dans une étape où on a validé le reste…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: il n'y a pas que ça
Posté par harlock974 . Évalué à 2 (+2/-1).
Pas forcément. Lorsque j'ai commencé à apprendre Python, j'ai justement été bloqué pendant un temps certain à partir de trucs collés d'internet qui ne marchaient pas.
Le premier souci est que j'avais indenté avec des tabulations et que le bout de code inclus récupéré était indenté avec des espaces. L'interpréteur a refusé d'interpréter avec un message cryptique, et il a fallu du temps pour comprendre ce qui n'allait pas.
Le second est que la syntaxe de la fonction print a changé entre python 2 et python 3 et que j'essayais de faire tourner un programme python 2 genre "Hello world" sur mon environnement qui était en 3.
J'avais vraiment eu moins de problème en C. Les tutos de 1995 compilent toujours…
[^] # Re: il n'y a pas que ça
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
En son temps, BASIC était imbattable (bien plus simple que Python en prenant les mêmes critères) ; et feu(?) LSE avait toutes les qualités pour apprendre des algos (en dessin ou en texte formel) avec une implémentation directe…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: il n'y a pas que ça
Posté par wilk . Évalué à 2 (+0/-0).
"Faire un truc" et "bien plus rapide" c'est très relatif.
Si tu fais un truc mais que tu ne le comprends pas, est-ce que tu as appris réellement ?
Par exemple si tu dois faire une intersection entre deux ensembles, en Python tu vas utiliser set, c'est plié en 3 lignes. En C tu vas faire des boucles, c'est beaucoup plus difficile mais à la fin tu aura appris un algo.
[^] # Re: il n'y a pas que ça
Posté par flagos . Évalué à 2 (+0/-0).
Tu peux aussi faire ta boucle for en python, et utiliser des Set en C++ en utilisant la STL.
Bon après en C++, tu obtiens vite ce genre de trucs qui sont vite penible, et a la fin, la syntaxe en python est tout de meme plus simple.
[^] # Re: il n'y a pas que ça
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1 (+0/-0).
A quoi ça te sert de comprendre l'algorithme derrière? Pour un expert, pour des micro optim peut-être. Et encore l'algorithme déjà existant est sûrement plus optimisé que le tiens.
A tu besoin de comprendre aussi le fonctionnement de l'ordinateur à fond?
Clairement si on peut se passer de réinventer la roue.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: il n'y a pas que ça
Posté par BAud (site web personnel) . Évalué à 3 (+1/-0).
on parle bien de développeurs non ?
t'utilises des bibliothèques et c'est marre, mais mieux vaut en comprendre leur utilisation (à défaut de leur implémentation)…
[^] # Re: il n'y a pas que ça
Posté par wilk . Évalué à 2 (+0/-0).
On parle d'apprentissage.
Pour ma part le fait d'avoir commencé par apprendre le fonctionnement d'un ordinateur "à fond" en commençant par l'assembleur plus le C m'a énormément simplifié la vie par la suite.
Le réinventage de roue est également un excellent moyen d'apprendre car on peut ensuite regarder comment d'autres ont fait ces mêmes roues.
[^] # Re: il n'y a pas que ça
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Pour faire du Python, il faut comprendre le fonctionnement des types implicite (est-ce que c'est une string? est-ce que c'est un entier? comment on convertit entre les 2?), la gestion de la mémoire par références (si on a deux variables qui référencent le même objet, en modifier une va modifier l'autre), les exceptions, …
L'étude compare ces langages en dehors de leur environnement "naturel", dans un IDE web clé en main. Donc toute la partie venv, dépendances, portabilité ne pose pas problème (de la même façon que la compilation, édition de lien, etc en C++ n'est pas mise en jeu).
La conclusion est donc peut-être que le langage Python n'est pas plus simple à apprendre, mais que son environnement (facile à installer, avec des modules pour faire beaucoup de choses disponibles dans pip ou dans la bibliohèque standard) est son point fort qui rend le tout vraiment plus abordable.
# Retour de l'enseignement en France au lycée
Posté par Francky (site web personnel) . Évalué à 1 (+0/-0).
Depuis la dernière réforme du lycée, il y a une spécialité NSI (Numérique et sciences informatiques) disponible. Ce n'est pas une option, c'est bien une composante majeure du bac pour ceux qui la choisissent.
En deux ans (première et terminale), de nombreux thèmes sont abordés, et la programmation en est un gros morceau. Les élèves partent souvent d'un niveau : « ils n'ont presque jamais touché un clavier avant ». Pour beaucoup, il leur faut beaucoup de temps pour trouver les parenthèses… Les élèves ont des profils très variés. Certains sont matheux (ils ont aussi la spé maths, et réussissent souvent bien, et sont souvent les plus à l'aise), d'autres ont choisi une autre spécialité moins scientifique (comme art-plastique, ou histoire/géopolitique, … tous les profils sont possibles). Très clairement, les profils matheux sont avantagés pour réussir (mais ce n'est pas rédhibitoire pour les autres ! Il y a des réussites possibles.)
Le choix du langage s'est porté sur Python, pour tout un tas de raisons que je trouve parfaitement valables. Dans le lot, il y avait : interprété, largement utilisé et documenté.
Franchement, si le choix n'avait pas été Python, je n'aurais même pas candidaté pour enseigner NSI. Essayez d'imaginer un tout jeune batailler à comprendre un simple
Hello World!en Java ; je n'ose même pas ! Avec Python, le programme permet de faire travailler efficacement les élèves, en deux ans, du début complet jusqu'à la construction de structures arborescentes variées, et le travail sur des graphes, le tout en POO. (Et je rappelle que ce n'est qu'une partie du programme, il y a aussi BDD(SQL), réseau, des projets à réaliser, …) Volume horaire : 4h/semaine en première ; 6h par semaine en terminale.Les poursuites d'études post BAC, avec NSI en poches, pour les plus sélectives, sont très clairement les prépas MP2I. Pas seulement, mais toujours avec les profils matheux les plus recherchés.
D'après mon expérience, un autre choix que Python aurait conduit les élèves moyens à un échec terrible sur la partie programmation, alors que là, ils peuvent faire de choses honorables.
Pour voir un peu ce sur quoi on les fait travailler, vous pouvez jeter un œil là pour les exercices : https://pratique.forge.apps.education.fr/algo/
(Très grosse base d'exercices en ligne, aide + guide si besoin, aucune installation, RGPD, autonomie, autoévaluation, aucune mesure d'audience, forge logicielle Éducation Nationale…)
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.