Re: "interruption" a l'interieur d'une boucle ?

> Thomas De Contes a écrit :
>
>> [...je coupe un débat trop long pour le reciter en entier...]
>>
>

J’avais, dans des temps que les moins de vingt ans ne peuvent pas 
connaître, publié dans TSI un essai de synthèse sur goto, et j’ai envie 
d’intervenir ici.

Ne pas utiliser goto est une règle pas historiquement contestée (avec 
de bons argument), pas immédiatement  acceptée, et appliquée sans la 
comprendre. En pratique, on s’aperçoit qu’on trouve toujours une 
solution sans goto de simplicité comparable. Et on constate que bien 
peu de programmeurs ont compris cette règle, même s’ils ne se 
hasarderaient pas à la violer.

Un peu d’histoire. Ceux que ça ennuie peuvent passer au spam suivant.

Au commencement était l’organigramme, autrement sit le plat de 
spaghetti. Et la lumière fut, avec les dénommés Böhm et Jacopini 
publiant en 1966 qu’on pouvait tout programmer avec si/alors/sinon, 
tantque et des variables booléennes. Alaluyah! Il en résulta la 
« programmation structurée », appliquée de manière intégriste en 
n’acceptant rien d’autre. Ce fut Pascal, merveille pédagogique et 
nullité industrielle (un peu la faute à ses concepteurs).

Je rappelle pour mémoire le débat entre Dijkstra et Knuth autour de 
goto, débat utile malheureusement gâché par des zélateurs incompétents 
(situation loin d’être unique). Vinrent les transformations de 
programmes, Arsac introduisant les sorties d’itération à plusieurs 
niveaux (numériquement) dont je montrai ultérieurement qu’il était 
préférable de les nommer.

Un article primoavrilesque introduisit aussi l’instruction come from, 
peut être pas si canularesque que ça au bout de la réflexion.

Dans un monde parallèle furent inventées les preuves de programmes, 
assertions, préconditions, postconditions et invariants de tous poil et 
plume, lesquels assuraient (mais on ne le savait pas encore) les 
fondements de bien des choses. La suite est une vision plus personnelle.

La difficulté des preuves n’est pas dans goto : on sait où on est, on 
sait où on va. La difficulté est dans le come from : on aurait surtout 
besoin de savoir d’où on vient quand on a plusieurs chemins d’arrivée. 
La solution proposée est la précondition et la postconditon des 
sous-programmes, et l’invariant de boucle, qui doivent être introduits 
a priori. Mais cette solution est universelle : l’instruction de retour 
de sous-programme est rendue solide par l’existence de la 
postcondiiton, celle de sortie de boucle par l’invariant d’itération. 
Rien n’interdit d’introduire un invariant, non pas de goto mais 
d’étiquette.

Parallèlement, si on introduit dans le débat les mesures de complexité 
de programme, on peut mesurer la complexité apportée par l'introduction 
d’une instruction par rapport à une situation sans elle. La complexité 
additionnelle d’un ensemble de goto vers l’avant est égale à la 
quantité de structures de contrôle dont il faut sortir.  La complexité 
d’un goto unique en arrière est (de mémoire) le double. La complexité 
d'un ensemble de goto dont certains en arrière n’est pas calculable de 
manière générale.

Ceci étant rappelé autour du saut lui-même, j’ai envie de dire que 
l'arrivée d’Ada n'a presque rien changé aux façons de programmer. Quand 
je regarde autour de moi, j'ai l'impression qu'en quarante ans ce qui 
s'est passé dans le monde des fondement de la programmation n'a eu 
aucune influence sur la réalité professionnelle que je constate. Par 
une autre voie, il semble que je rejoigne Dewar et Schonberg dans leur 
défense et illustration de l'enseignement de la programmation.

À trop ignorer l’histoire, on la condamne à se répéter.

Alors... introduire d’autres instructions ? Je n'y crois pas trop. Le 
plus important aurait été à mon avis de réfléchir avant de traduire 
dans les bibliothèque prédéfinies ce qui se faisait avant, au lieu de 
produire des concepts nouveaux conçus à partir d’une abstraction du 
monde et de ce qui devenait possible. Ça, on l’a presque totalement 
raté.

Excusez ces élucubrations d'ancien combattant.

Un proverbe pour finir : l'important dans un programme, ce ne sont pas 
les instructions qui en définissent le fonctionnement, ce sont les 
assertions qui articulent ces instructions.

-----     -----     -----     -----     -----
Michel Gauthier
83, rue d’Isle
87000 Limoges
-----     -----     -----     -----     -----

Il semble possible de faire des OMLTTS sans E.
On peut aussi faire des SUPES sans O.

_______________________________________________
Site WWW de l'association Ada-France: http://www.ada-france.org/
[email protected]
http://www.ada-france.org/mailman/listinfo/ada-france