C'est brownien
Le mouvement brownien est celui de particules placées dans un gaz ou un liquide. Il est désordonné parce qu'elles sont frappées aléatoirement de tous cotés (à cause de l'agitation thermique) par les molécules qui les environnent. Plus les particules sont petites, moins il y a statistiquement un équilibre entre les forces qui s'y appliquent à un instant donné. Le résultat est qu'elles peuvent alors se déplacer sur une trajectoire discontinue, au hasard.
En informatique, un programme est constitué d'un nombre restreint de termes prédéfinis par le vocabulaire et la grammaire du langage employé mais qui peuvent être agencés selon une infinité de combinaisons (elles ne seraient limitées que par les capacités de la machine ou du compilateur utilisés, à condition que l'informaticien travaille comme une fourmi). A l'époque héroïque, avant que l'on ne se préoccupe de programmation structurée, l'instruction goto (aller à) était omniprésente. Elle permet, en se trouvant à un endroit du programme, de se déplacer à un autre sans se préoccuper de l'organisation. En fait c'est une traduction directe des sauts conditionnels ou inconditionnels qui font partie des opérations de base du microprocesseur.
Comme elle donne la possibilité de traiter toute sorte de situations, cela paraît bien pratique. Mais son utilisation systématique et quasiment sans contrôle a posé en fait de gros problèmes. Dès qu'un certain nombre de goto étaient enchevêtrés et comme on pouvait se déplacer vers l'avant aussi bien que vers l'arrière, il devenait quasiment impossible de prévoir sur papier le cheminement dans le programme parce qu'ils étaient souvent dans des portions de code liées à des tests. En cas de bug(s) ou de situations non prévues c'était le déraillement assuré. De plus les anciens langages ne se préoccupaient pas vraiment de placer automatiquement des sécurités telles que des restrictions sur les valeurs des variables ou indices, donc comment évaluer les dégâts causés avant de retrouver une trajectoire "normale" ?
De là l'idée de structurer les programmes en remplaçant au maximum cette instruction de malheur - pour le développeur - par d'autres (ou des notations) qui ont un début et une fin, encadrant une partie du code comme des parenthèses et qui ont un déroulement plus facile à anticiper. Le goto est tout de même encore utile, avec un usage ponctuel, pour simplifier certains cas. Malheureusement, la structuration n'a pas été une solution miracle, seulement un mieux (net). Un bug reste un bug.