Lorsqu'on apprend la programmation, on est confronté en général à deux domaines de compétences très distincts :
-
savoir mettre en place de façon très codifiée un enchaînement d'actions compréhensibles par la machine (l'algorithme) ;
-
apprendre à traduire cet algorithme dans un langage existant et à l'exécuter.
Trois grands types de difficultés surviennent rapidement. Tout d'abord se pose la question de savoir comment créer l'algorithme à partir de "rien", c'est-à-dire comment inventer la suite des actions à exécuter. Ensuite vient la partie codification. Classiquement la rédaction se fait dans un "vrai langage", prévu pour un ordinateur, avec une syntaxe non naturelle et non agréable, qui utilise des symboles qu'on ne manipule pas d'habitude, comme les accolades {, les crochets [ et le double égal ==, ce qui fait qu'il est difficile de se relire et de se corriger soi-même. Enfin reste la partie exécution et validation avec la rigueur/stupidité de l'ordinateur où une seule lettre, un seul point-virgule manquant fait que rien ne fonctionne du premier coup et qu'on a souvent du mal à trouver d'où vient l'erreur.
Pour pallier ces difficultés, nous sommes convaincus qu'il faut recourir à un langage algorithmique simplifié en français couplé à un analyseur et un exécuteur «intelligent» d'algorithmes qui écrit ses messages en français :
-
Avec un langage en français, la débutante et le débutant comprennent plus facilement les actions à faire exécuter par la machine.
Si on restreint le vocabulaire à moins d'une dizaine de verbes (CALCULER, TESTER, BOUCLER...), alors il suffit de se demander par quel mot on doit débuter la phrase, comme s'il s'agissait d'une langue étrangère, pour savoir par où commencer l'algorithme. Utiliser des mots français est plus "rassurant", l'apprenant maitrise sans doute plus facilement BOUCLER que WHILE.
-
Avec un langage simplifié, la syntaxe est lisible.
Imaginons par exemple qu'on doive accorder un point au score d'évaluation d'un questionnaire si la réponse de l'utilisateur est OUI et zéro point pour les autres réponses. Voici un algorithme possible en français simplifié :
TESTER si reponse="OUI"
alors AFFECTER score <-- 1 # sous-entendu : 1 point
sinon AFFECTER score <-- 0 # ici, 0 point
finsi
Avec un langage informatique classique, comme C ou PHP, la traduction n'a que peu de rapport avec le français et comporte de nombreuses idiosyncrasies telles que le double égal et la construction avec ? et : illustrées dans le code suivant qui réalise la même action que l'algorithme :
$score = ($reponse=="OUI") ? 1 : 0 ; // unité : le point
Il est clair que cette "traduction" est très peu accessible au débutant(e) car elle est très éloignée du code en français.
-
Via un analyseur qui indique les «fautes d'orthographe» et les erreurs de syntaxe, il est plus aisé de se corriger soi-même.
Imaginons qu'on oublie d'indiquer la fin de si dans l'algorithme (ou son équivalent, l'accolade fermante dans un code C ou PHP). Si l'analyseur indique fin de si manquante détectée en ligne 8, il est relativement facile de savoir de quel type d'erreur il s'agit (et sans doute à peu près où se situe la faute). En comparaison, un message traditionnel comme syntax error, unexpected end of file line 44 n'explique pas d'où vient le problème mais dit que le fichier ne devrait pas finir ainsi, ce qui est juste du point de vue informatique car on ne peut pas ouvrir une accolade sans la fermer, mais ce n'est pas très explicite ni compréhensible par un(e) débutant(e).
Si on utilise un langage simplifié prévu pour un être humain, de nombreux pièges classiques sont évités. Ainsi, pour réaliser l'action algorithmique proposée, une autre syntaxe en PHP est possible, qui "colle" plus aux mots SI, ALORS, SINON indiquée ci-dessous :
if ($reponse=="OUI") {
$score = 1 # point
} else {
$score = 0 ; # point
} ; # fin si
Malheureusement, seuls une programmeuse ou un programmeur expérimentés verront de suite que l'analyse de ce texte aboutira au message incompréhensible au débutant syntax error, unexpected '}' vu que ce message dit qu'il ne faut pas d'accolade fermante ! En fait, bien sûr, il manque un point-virgule à l'affectation qui précéde cette accolade, ce qui la rend inacceptable, mais il est clair que cette subtilité échappe toujours quand on débute dans un "vrai" langage. Utiliser un langage sans point-virgule (et c'est bien sûr possible) nous semble être incontournable.
-
Via un exécuteur qui indique si "on a bon", il est possible de valider son travail et de s'auto-évaluer.
Lorsqu'un algorithme ou un programme s'exécute sans erreur, cela ne prouve pas que l'algorithme est juste, qu'il calcule exactement ce qu'il faut. Cela indique seulement qu'il s'exécute, qu'il produit des résultats. C'est une étape nécessaire mais non suffisante pour "prouver" que le problème a été résolu. Avec le temps, les programmeuses et programmeurs savent prévoir les cas simples et triviaux, les erreurs faciles à tester et construisent des exemples de situations à vérifier, pour être convaincu(e) que l'algorithme est à la fois correct et robuste, c'est-à-dire qu'il calcule juste et bien dans tous les bons cas de figure. Par exemple on peut imaginer que le programme s'exécute correctement avec des nombres positifs mais qu'il est incorrect avec des nombres négatifs. L'algorithme est juste mais la résolution sera incomplète.
Il faut donc en plus d'un éditeur et d'un analyseur d'algorithmes un exécuteur qui connaisse les bonnes réponses pour des entrées bien choisies afin de pouvoir indiquer si le code écrit correspond bien à la résolution exhaustive du problème. Dans de nombreux cas, même en initiation, un problème peut demander de nombreux jeux d'essais différents afin de couvrir tous les cas possibles. Apprendre à programmer, c'est aussi apprendre à "tout prévoir" et à "tout tester". Avoir un système automatisé qui fournit des problèmes et qui "connait" tous les cas à tester permet d'indiquer à l'utilisateur les cas qu'il a couverts et ceux qui ne sont pas encore pris en compte par son algorithme.
Enfin, pour savoir "si on sait programmer", il faut passer par de nombreux exercices, souvent de difficulté croissante. Ce n'est pas à l'apprenant de choisir ces exercices ni leur progression. C'est bien à une équipe pédagogique qu'il revient de construire ces séries d'exercices, parfois de même nature car nous pensons qu'apprendre à programmer, c'est comme apprendre à parler une langue : seule une pratique assidue vérifiée et validée peut permettre de considérer que les compétences sont acquises. Seul un environnement automatisé permet de laisser l'apprenant essayer et ré-essayer encore, jusqu'à tant qu'il ou elle réussisse un exercice avant de passer au suivant et, au final, disposer d'un certificat qui atteste de ses efforts et de sa compétence via une pratique jugée suffisante par une équipe pédagogique.
Un exemple d'une telle progression est présentée dans la séquence didactique nommée PMG (Petit Moyen Grand) qui consiste, étant données 3 variables d'entrée a,b,c non nécessairement numériques, à écrire au moins 5 algorithmes avec des contraintes différentes pour réussir à mettre dans les 3 variables de sortie p,g,m respectivement la plus petite valeur, la plus grande et celle du milieu. La page liée à ce problème algorithmique est ici.
|
Retour à la page principale de
(gH)