• [^] # Re: Pascal...

    Posté par (Mastodon) . En réponse au journal Python comme premier langage de programmation ?. Évalué à 3.

    Un enseignant ne doit-il pas être pédagogue ?

    Tout dépend de ce que tu mets dans la pédagogie. Là, on a devant nous des étudiants, pas des enfants, donc ils savent déjà apprendre, notre mission est de leur apprendre à apprendre. Certes il faut un peu de pédagogie mais il faut surtout de la méthode et de l'efficacité.

    Si tu introduis ça au début, pur des personnes qui ne continueront probablement pas à faire de la programmation, tu les dégoutes.

    J'ai devant moi des étudiants scientifiques (qui vont aller après dans des filières diverses : physique, chimie, maths, sciences de l'ingénieur) et quand il néglige les cours d'informatique en L1, je les mets en garde : ils en auront besoin plus tard, quoi qu'il fasse. Et quand je regarde les programmes des différents filières, il y a de la programmation à un moment donné parce que la plupart des sciences utilisent maintenant fortement l'informatique (au même titre que les maths). Donc des scientifiques qui en continueront pas à faire de la programmation, ça n'existe pas. Ils continueront, quoi qu'il arrive. Donc autant commencer sur de bonnes bases.

    Maintenant, j'ai peut-âtre été trop restrictif dans les types de base, et je t'accorde que différencier décimal/entier serait prebablement pertinent. Comme tu parlais de C/C++, j'avais à lesprit la totalité des types C/CPP (int, short , long, float, double, etc ....) qui sont difficiles à appréhender quand tu commences à programmer.

    Il ne faut pas leur apprendre les types de C/C++, il faut leur apprendre les types ! Donc, entiers (de diverses tailles, mais int suffit dans 90% des cas), flottants (double dans 90% des cas), char pour manipuler des caractères ASCII, booléen pour calculer des expressions booléennes. Déjà avec ça, on a du boulot. Parce que choisir le bon type parmi ces 4 familles, c'est parfois compliqué. Surtout char en fait, il est très bien parce qu'il permet d'expliquer qu'on peut représenter un truc abstrait (un caractère) par un entier, suivant une norme qu'on se définit. Et qu'on peut faire pareil après, par exemple pour dire que 1 veut dire oui et 2 veut dire non. C'est aussi important que le code en lui-même et c'est souvent plus difficile d'ailleurs.