Programmation par contrainte (Constraint Programming)
| Auteur | Message |
|---|---|
|
La programmation par contrainte, est une manière de décrire un programme par une spécification plutôt que par une implémentation. L’implémentation n’existe pas toujours explicitement, et les contraintes peuvent être résolues automatiquement par un solveur, qui peut être un logiciel ou une librairie logicielle spécialisée.
Cet notion de l’informatique fondamentale, existe depuis les années 1980 environ, et a connu en pratique, principalement des solveurs en Prolog. Il existe un site ou un blog dédié à la standardisation de cette approche du logiciel. Cette standardisation a été souhaitée, car bien que étant une approche pertinente et ayant beaucoup à apporter à l’informatique, la programmation par contrainte n’a jamais percé dans l’industrie ou chez les éditeurs de logiciels. Comme souvent, c’est l’absence de standard qui en fut la cause, et c’est à cela que souhaite remédier cette initiative déjà bien avancée. Le second lien redirige vers le premier, mais il est donné tout‑de‑même, parce que plus canonique. Il est possible que dans le futur, ce site ne soit plus sous Wordpress, et qu’il faille se référer au second lien plutôt qu’au premier. Un aboutissement important de ce projet de standardisation, est la standardisation d’une API Java pour la programmation par contrainte. Ce standard se nomme JSR331. Une API Java souffre probablement des défauts de Java, c’est à dire au moins comparé à Ada, l’impossibilité de donner des spécifications précises aux types numériques, ce qui est sûrement une lacune importante dans le domaine de la résolution de contraintes numériques. Mais je ne connais pas d’autre standard pour la programmation par contrainte, autre que cette API Java, pour l’instant. Je ne connais pas de format de fichier ou de langage pour l’écriture des spécifications de contraintes, pour l’instant. |
|
|
Proche de la programmation orientée contrainte, il y a la programmation orientée contrat. Bertrand Meyer (français, mais c’est juste une anecdote) a été l’un des plus connus des « disciples » et aussi « apôtres » de cette approche assez formelle, même si elle n’est jamais parvenue à l’être entièrement. Et Bertrand Meyer est l’auteur d’un langage mettant l’accent sur cette méthode, le langage Eiffel, qui est bien bon, pour en parler en l’ayant connu il y a longtemps, à la fin des années 1990. Ce langage n’a pas connu la popularité qu’il aurait put mérité mais n’est pas tombé dans l’oubli pour autant. En cela, il a connu le sort de SML, Ada, Z, VDM et peut‑être d’autres encore. Une des mises en œuvre parmi les plus connues était SmallEiffel, devenu SmartEiffel ensuite, du LORIA (Laboratoire Lorrain de Recherche en Informatique et ses Applications). Mais ont aussi existé des mise en œuvres commerciales (aucune idée des tarifs), ce qui n’est pas une surprise, comme Bertrand Meyer était ouvert aux logicielles commerciaux et voulait même améliorer leur fiabilité, dans divers domaines, dont l’aérospatiale, mais pas seulement. De mémoire, l’une des mise en œuvre commerciale s’appelait Visual Eiffel ; en fait, une autre encore était EiffelStudio. SmallEiffel, SmartEiffel, Visual Eiffel, sont disparus depuis longtemps, mais EiffelStudio (eiffel.com) existe toujours.
Le langage Eiffel est défini par un standard de l’ECMA : Eiffel: Analysis, design and programming language — ECMA-367 (ecma-international.org), Juin 2006. |
