Sauf erreur, Caml est un langage... fonctionnel...
Il n'est donc pas forcément difficile à comprendre que la théorie applicable aux langages procéduraux ne soit pas forcément adaptée
Effectivement...Donc je pense aussi que la théorie est un bon préambule à la pratique, il permet de s'abstraire d'un support, d'éviter de s'attacher à des techniques du langage quand on conçoit un algorithme, d'apprendre rapidement à évaluer s'il va marcher (quand on vous impose de démontrer un algo, en général vous partez pas sur quelque chose qui marchera peut-etre ...)
Pour l'OO, on peut parfaitement suivre un raisonnement similaire, et commencer par expliquer, simplement, les notions qui sont propres à ce paradigme, telles, finalement, que celle qui sont représentables en UML.Pour ce qui est des autres théories liées à la programmation (OO, Typage, Métrique ....) je ne sais pas trop quoi penser. Pour l'OO je pense aussi que de ne partir d'aucun langage peut-etre une bonne idée. Pour les 2 autres que j'ai coté elles sont je crois assez abstraite en soit).
En regroupant une dizaine de potes près à "jouer le jeu", tu peux demander à chacun de jouer le rôle d'une classe particulière et voir si ce que tu as envisagé tient la route
Cela dépend énormément de beaucoup de paramètres, tels que l'intérêt que le prof peu susciter (on retient beaucoup plus facilement ce qui nous fait rire un bon coup ) ou l'intérêt de l'élève pour ce qu'on lui explique...
Mais il faut, aussi, suivre une "courbe d'apprentissage" consistante et cohérente.
Ne parlons pas de fonction ou de classe template, c'est trop "orienté C++", mais parlons plutôt de programmation générique.
Cependant, si on lui montre les possibilités offertes par le langage (pour un mathématicien la puissance de calcul, pour d'autres les jeux vidéos,...) il pourra avoir un attrait. Puis, il faut lui enseigner les clés pour le faire :
Pas forcément: une fois que tu as vu la théroie (par exemple, les différentes boucles), présente lui un exercice, autant que possible en rapport avec ses propres intérêts, dans lequel il devra, effectivement, choisir celle qui convient le mieux.Au début il peu s'agir d'explication théorique comme "une boucle for consiste à... et est utilisée pour..." mais il faudra que rapidement les mettre en pratique sans quoi il oubliera tout et verra son objectif se perdre (et donc sa motivation).
Et fait lui jouer le rôle du processeur pour s'assurer que son algorithme est correct.
Comme il aura été mis "en situation réelle", et qu'il aura sans doute bien ri à la mise en situation, il retiendra très facilement dans quel cas choisir quel type de boucle
Ce qui nous oppose semble principalement être... la manière dont on envisage la "mise en pratique" de ce qu'il apprend.En les mettant en pratique, il pourra vérifier la qualité de son raisonnement (un test véritable est toujours mieux qu'un test "dans la tête" et donne l'impression d'aboutissement). Plus tard, quand le sentiment d'aboutissement ne sera plus nécessaire, que son objectif ne lui paraitra pas inatteignable (ou du moins qu'il comprendra les mécanismes), il pourra faire de la théorie pure.
Si on lui explique ce qu'est un tri a bulle, il n'en comprendra pas vraiment l'intérêt car il n'en n'aura jamais eut besoin.
Il ne sert à rien de lui apprendre "brut de force" ce qu'est un tri à bulle, par contre, tu peux le mettre face à un défi qui l'amènera "naturellement" à présenter un algorithme qui, comme par hasard, s'apparentera à celui-ci.
Il n'y a pas besoin du support d'un langage pour y arriver: il suffit de donner "le bon problème à résoudre".
Une fois qu'il arrive avec son algorithme, qu'il tient la route et que tu l'as incité à le vérifier, tu peux lui dire "tu sais quoi cela s'appelle un tri à bulles" et, comme il l'aura imaginé "de lui-même", il retiendra très facilement non seulement que cela s'appelle un tri à bulles, mais, aussi, la logique de cet algorithme.
Mes cours d'algorithmie tenaient sur une petite quarantaine de pages, et j'ai eu au total près de 200 heures de cours exclusivement dessus (comprend: cours de programmation orientée objet exclu).
Sur ces 200 heures, il y en a peut être 20 qui ont été dédiées aux explications "théoriques" pures.
Le reste a été dédié à des des exercices dans lesquels on était confrontés à des problèmes à résoudre (et à leur vérification).
Chaque exercice nous mettait dans une situation dans laquelle nous réfléchissions nous même à l'algorithme que le prof voulait nous apprendre, et ce n'est qu'une fois que cet algorithme avait été démontré que le prof nous disait de quel type d'algorithme il s'agissait.
La "mise en pratique" peut prendre de nombreuses formes, mais la forme la plus intéressante est celle... qui ne fait appel à aucun langage de programmation.
Le premier algorithme que le prof nous ait demandé d'écrire, juste après nous avoir dit qu'il n'y aurait pas 10% de théorie pour plus de 90 % de pratique (déception, nous qui croyions que "principes de programmation" serait un cours exclusivement théorique ) a été... "Donnez moi les étapes à suivre pour changer une roue si vous crevez sur l'autoroute".
Cela n'avait rien à voir avec la programmation, c'était "simplement" pour nous faire comprendre qu'il faut, comme pour l'écriture d'une recette de cuisine, arriver à séparer clairement les différentes étapes et à les placer "dans l'ordre adéquat".
Je ne vais pas reprendre l'intégralité de son cours ici, mais, par la suite, il nous présentait de temps en temps un concept particulier, mais nous passions le gros de notre temps à... créer des algorithmes et à... les tester oralement.
Partager