Re: Rien de nouveau

Vas expliquer à un étudiant qui a passé des heures sur un projet et dont le code fonctionne (pour lui) qu'il va se prendre une taule.

Si tu expliques les critères de notation avant, je ne vois pas le problème.
Théoriquement un élève futur ingénieur ou détenteur d'un master en informatique doit comprendre qu'un code qui marche n'est pas la seule chose qu'on attend de lui, et en entreprise ça sera également vrai.

Si ça fait effectivement partie clairement de la notation, il va peut-être le faire « pour faire plaisir au prof » et pour avoir une bonne note mais il n'aura rien compris.

Ça c'est de la réflexion niveau collège/lycée (je parle bien d'un étudiant qui pense ainsi, pas ta réflexion). Je sais qu'il y a des étudiants qui procèdent ainsi, mais un étudiant dans le supérieur quelque soit sa section peut interroger les profs pour expliciter la notation, la comprendre et l'appliquer en sachant que ça a un sens réel. Pour moi les étudiants qui cherchent juste à avoir une bonne note pour faire plaisir au prof et à papa et maman manquent clairement de maturité pour évoluer dans le système éducatif supérieur. Malheureusement je sais que ça existe.

C'est un peu comme des cours de programmation fonctionnelle (en lisp de préférence). En tant qu'enseignant, je pense qu'un informaticien qui connaît plusieurs paradigmes de programmation est un meilleur programmeur. Sauf que les étudiants considèrent tous que le cours de lisp, c'est de la merde inutile et après avoir validé le module, ils s'empressent de tout oublier.

Je ne te jettera pas la pierre, mais tu as expliqué l'intérêt de la chose avant ?
Car dans mon établissement il y a des matières ou l'intérêt n'est pas toujours évident au premier abord mais dont les profs n'essayent même pas d'expliquer l'intérêt. L'élève doit c'est vrai se documenter seul (on n'est plus au primaire) mais je pense qu'un bref rappel avant de se lancer n'est pas de trop.

C'est avec ce genre de traumatisme qu'on apprend l'intérêt de règles qui semblent arbitraires. De ce point de vue, lire « Go To Statement Considered Harmful » de Dijkstra et les réponses de qui ont été faites, notamment par Knuth est très instructif. Ne pas utiliser de goto, c'est arbitraire. Certaines personnes très intelligentes n'ont jamais vu l'intérêt de se restreindre comme ça. Sauf que bon, c'est quand même pas plus mal d'éviter d'utiliser trop de goto.

Mon but est d'être pédagogique, pas d'être arbitraire. Je préfère mille fois une personne qui utilise du goto proprement qu'une personne qui n'en met pas car il considère comme interdit et doit le simuler avec du code plus crade. Quand tu as un critère de notation, notamment sur du code source, il faut fixer des règles mais surtout les expliquer. Si tu n'expliques pas ça ne sert en effet à rien et si tu laisses faire, ils n'apprendront jamais à part ceux qui le font par eux-même.

Il y a une chose que je n'ai jamais osé faire quand j'en ai eu l'occasion mais qui serait très formateur, c'est de faire un projet à étages. Je m'explique. On prend un projet avec 3 étapes claires comme un compilo (analyse syntaxique, création de l'arbre de 1/3 de semestre, chaque groupe laisse son code et continue avec le code d'un autre groupe. L'exemple du compilo est mauvais parce que c'est trop difficile à traiter comme ça en un semestre mais je pense que les étudiants apprendraient beaucoup de choses.

On a eu un projet comme ça mais pas dans le sens ou tu l'entends. C'était un projet découpé en deux ou quatre sections et chaque groupe devait en faire une partie. Comme c'était une chaine, il fallait que les groupes se mettent d'accord sur des spécifications sur les entrées/sorties histoire que le toute fonctionne bien. Une horreur. Déjà les sections qui fonctionnaient individuellement se faisaient rares et en plus les groupes ont mal fait ou mal respecté les spécifications et du coup ça a donné n'importe quoi. Et e doute que les étudiants aient beaucoup appris vu les commentaires après recettes qui se content de rejeter la faute sur le groupe voisin…