Edsger Wybe Dijkstra et Niklaus Wirth vont apporter dans les années 1960 une véritable révolution dans l'art de programmer : la quasi-mort de l'instruction GOTO et l'arrivée de la programmation structurée.


Revenons à notre machine de Turing. Elle accomplissait des tâches simples : déplacer la tête de lecture/écriture, lire ou écrire une valeur simple et finalement s'arrêter.

Les ordinateurs ne vont guère en faire plus. Le langage machine va contenir des instructions basiques comme lire des registres, les comparer, effectuer des branchements en fonction du résultat, etc.

Tout ceci, on l'a vu est exprimé uniquement avec des 0 et des 1. Pour que les humains s'y retrouvent, une codification mnémotechnique est apportée par le langage assembleur (MOV AX, 00h, JMP étiquette...).

Outre la difficulté d'écrire les programmes dans ce type de langage, un problème crucial va se poser au moment de sa maintenance.

Si un programme doit être modifié, il va falloir en comprendre tous les mécanismes avant d'intervenir. Si c'est la même équipe qui doit le faire et que le programme est récent, on peut parier que se sera possible. Dans les autres cas, cela risque d'être très compliqué.

Imaginez-vous en train de lire un livre où, à chaque phrase, on vous renvoie à une autre phrase dans une autre page qui elle-même vous demande de consulter un index vous indiquant un renvoi en bas d'une autre page et cela trois ou quatre fois avant de vous demander de faire un effort de mémoire pour revenir juste après le premier renvoi. Au bout d'une page, vous allez sans doute laisser tomber.

Eh bien, c'est cette gymnastique que l'on va demander de faire aux programmeurs chargés de la maintenance d'un gros programme écrit en assembleur. Dans notre langage machine ou dans l'assembleur ce sont des instructions JMP, pour JUMP (sauter), ainsi que d'autres instructions du même type qui vont en rendre difficile la compréhension.

Même si le programme est bien commenté, la tâche ne va pas être facile. Et s'il ne l'est pas, n'en parlons pas...

L'apparition des compilateurs va permettre d'écrire des programmes selon des langages plus accessibles aux humains. Mais cela ne va pas se faire immédiatement. Les premiers langages comme le FORTRAN et plus tard le BASIC vont garder cette structure pleine de sauts vers des étiquettes avec l'instruction GOTO (Aller à).

Edsger Wybe Dijkstra et Niklaus Wirth vont démontrer qu'on peut faire beaucoup mieux en se débarrassant de l'instruction GOTO !

Dijkstra rédige en 1968 un article qu'il nomme "Un Procès contre l'instruction GOTO" ("A Case against the GOTO Statement"). Niklaus Wirth en sera l'éditeur et le rebaptisera "L'Instruction Go To considérée comme nuisible" ("Go To Statement Considered Harmful").

Les conséquences en seront l'arrivée de la programmation structurée que Niklaus Wirth introduira dans une version du langage Algol qu'il appellera Algol-M. C'est sur les bases de ce langage qu'il créera son célèbre "Pascal". La mise en évidence de structures nouvelles en fera un langage clair et didactique.


Jusque-là, les structures d'un programme comprenaient des séquences d'instructions, des étiquettes, des sauts et un arrêt à la fin de la dernière séquence. Cela permettait de faire appel à des sous-programmes, mais c'était à peu près tout.

Avec le Pascal, et d'autres langages par la suite, ces structures vont donc se multiplier. En voilà une liste avec quelques explications sommaires. Certaines se suffisent à elles-mêmes, les principales (la programmation procédurale, les branchements conditionnels et les boucles) seront développées dans les pages qui suivent :

La séquence. Cette structure va rester bien sûr, un programme va toujours contenir des suites d'instructions, mais il sera possible de les segmenter afin de rendre le code plus lisible. C'est ce qu'on verra avec la programmation procédurale et les blocs d'instruction.

les arrêts. Si, évidemment, il y aura un arrêt à la fin du programme (sauf erreur comme le compteur de Bob) d'autres arrêts seront possibles, par exemple pour interrompre une séquence en dehors de son déroulement normal.

Les étiquettes. Si les étiquettes et les GOTO qui vont avec sont conservés dans de nombreux langages, c'est uniquement pour gérer des cas très spécifiques et il est désormais contre-indiqué de les utiliser.

les sauts inconditionnels. Revoici notre GOTO avec son renvoi vers des étiquettes. Ce qu'on vient de dire pour les étiquettes est donc également valable pour les sauts inconditionnels.


Passons maintenant aux nouveautés :

Les blocs d'instruction. Première nouveauté dans notre programmation structurée, on va s'efforcer de découper les programmes en unités de quelques dizaines de lignes maximum. Ces unités, dont on connaîtra souvent la raison d'être en leur donnant des noms explicites, vont largement faciliter la compréhension du code. Par ailleurs, certains d'entre eux pourront être appelés plusieurs fois autant que nécessaire au cours du déroulement du programme.

Ces blocs seront constitutifs de ce qu'on appelle la programmation procédurale, concept que l'on examinera plus à fond dans le prochain thème.

Les branchements conditionnels. Ces branchements (Si... Alors... Sinon...) existaient depuis longtemps, mais leur structure contenait en général un saut (encore notre GOTO) si une condition était remplie et la continuation en séquence dans le cas contraire. C'était peu explicite, surtout en cas de branchements multiples.

La programmation structurée va permettre de représenter des branchements conditionnels complexes de façon beaucoup plus lisible et de développer des blocs d'instructions entre les branchements conditionnels eux-mêmes, ce qui, là aussi, rendra le code beaucoup plus clair. Un prochain thème développera ces notions.

Les boucles. Il arrive souvent qu'un programme doive faire un certain nombre de fois la même chose. Par exemple lire une liste d'éléments et afficher le nom de ceux qui ont une certaine caractéristique. La structure la mieux adaptée à ce genre de tâche est évidemment la boucle.

Il y a beaucoup d'autres cas où cette structure se révèle utile. Cela fera l'objet d'une étude plus approfondie dans quelques pages.

Les exceptions. Au cours du déroulement d'un programme, il peut survenir des erreurs qui ne sont pas des erreurs de programmation (bugs) mais des tâches qui échouent. Par exemple, un programme peut invoquer un fichier qui n'existe peut-être plus.

Les exceptions permettent de tester si un bloc d'instruction provoque une erreur, si c'est le cas, le bloc est ignoré. Par exemple, en Python :
try: instruction ...
except: traitement de l'exception ...
("Try" signifie "Essayer")

Programmation multitâche. Les systèmes d'exploitation actuels (Windows, Linux, Androïd, Mac OS X, IOS...) sont multitâches, c'est en général au système lui-même d'assurer la synchronisation de toute les tâches en cours.

Certains langages comme ADA, Smalltalk et Java intègrent des structures de contrôle permettent d'agir sur des taches concourantes qu'ils ont eux-mêmes générées. D'autres langages (C#, C++, Ruby...) utilisent des extensions permettant de faire appel aux capacités de multithreading (exécution de plusieurs tâches simultanément) du système d'exploitation.

Programmation événementielle. Contrairement à ce qu'il se passait au tout début de l'informatique, de très nombreuses applications sont de nos jours en interaction constante avec l'utilisateur.

Par exemple, cette page Web attend que vous cliquiez sur la souris pour accomplir certaines tâches comme passer à la page suivante. Il doit donc exister des mécanismes tournant en boucle pour surveiller les actions sur la souris.

C'est le rôle de certaines bibliothèques fournies par le système d'exploitation. Les applications y font appel à l'aide d'instructions comme onclick="procédure" en HTML (un des langages du Web).


Comme promis, vous allez successivement retrouver dans les pages qui suivent, la programmation procédurale, les branchements conditionnels et les boucles...