URL: https://linuxfr.org/users/montaigne/journaux/retour-sur-le-isaac-meeting-2008 Title: Retour sur le Isaac Meeting 2008 Authors: Ontologia Date: 2008年12月20日T02:28:25+01:00 Tags: Score: 4 C'est avec quelques mois de retard que je vous propose un rapide petit compte rendu de la réunion du projet Isaac ayant eu lieu du 25 au 28 juillet 2008 à Strasbourg. Environ une quinzaine de personnes étaient présente, dont certains habitués de ces pages. Divers questions y ont été abordé dans la chaleur moite et statique de l'été Strasbourgeois (35 °C, 0 Km/h de vent) Le programme se trouve ici : [http://lisaac.u-strasbg.fr/index.php/R%C3%A9union_25-28_juil(...)](http://lisaac.u-strasbg.fr/index.php/R%C3%A9union_25-28_juillet_2008) Parmi les points fort, on pourra remarquer la présentation de travaux autour de Lisaac : externalisation des optimisations, Programmation par aspect, une GUI automatique, le fantastique binding OpenGL de Damien Bouvarel, le nouvel Isaac OS. Citons aussi, pour ne pas l'oublier, "Raton Parser" une librairie de mapping mémoire. Eurent lieu quelques débats théologiques : Quid de la gestion des erreurs, de la compilation de module, de la gestion de la configuration des librairies, choix cornélien entre GIT et Mercurial, etc... L'externalisation consiste, grâce à un pattern visiteur, de détecter des pattern au sein du graphe de code que traite le compilateur Lisaac, le compilateur travaillant en interne avec un langage minimaliste (une vingtaine d'instruction). Isaac OS, qui n'avait pas bougé depuis 2003, a été entièrement repris par Jérôme Hilbert et Simon Fuhlaber, Jérôme ayant joué les prolongations pour implémenter le multitâche dans le système. GUII, par Johnatan Ponté et Maxime Audrin est un très intéressant système d'adaptation automatique de l'organisation de l'interface afin que celle-ci s'adapte à toute résolution : elle construit un arbre abstrait reprenant l'arbre réel des widgets de l'interface et le transforme en arbre concret pour redessiner l'interface. Outre l'aspect de calcul sur l'arbre, ce projet utilise des possibilités uniquement offertes par Lisaac et plus largement le paradigme objet à prototype. Vous trouverez les slides ici : [http://isaacproject.u-strasbg.fr/download/2008Meeting/](http://isaacproject.u-strasbg.fr/download/2008Meeting/) Lisaac est encore en cours d'évolution et donne toujours lieu à des réflexions diverses sur le génie logiciel, l'expérience que l'on a accumulé avec d'autres langages, les extensions qu'on aimerait avoir. Quelques liens pour illustrer les débats ayant eu lieu : [http://lisaac.u-strasbg.fr/index.php/Aspect_programming](http://lisaac.u-strasbg.fr/index.php/Aspect_programming) Les présentations de Nicolas Boulay rassemblées ici : [http://lisaac.u-strasbg.fr/index.php/Pr%C3%A9paration_r%C3%A(...)](http://lisaac.u-strasbg.fr/index.php/Pr%C3%A9paration_r%C3%A9union_de_Juillet_2008) Les Fallback de Mildred : [http://mildred817.free.fr/2008/LisaacWorkshop/Slides2008/Fal(...)](http://mildred817.free.fr/2008/LisaacWorkshop/Slides2008/Fallback/) Enfin, n'oublions pas l'impressionnant port OpenGL réalisé par Damien Bouvarel (que vous trouverez sur le repo git), qui nous avait déjà gratifié d'un tout aussi impressionnant compilateur Prolog générant du Lisaac. L'ensemble des présentations présentés durant cette session sont maintenant disponible sur C'est le débat sur la gestion des erreurs qui m'a le plus marqué, surtout au vu de mes expériences récentes : j'ai été affecté deux mois sur le travail de test d'un énorme logiciel de gestion commerciale, et largement sensibilisé à la vision fonctionnelle du développement logiciel. Du débat que nous avons eu lors de cette réunion, il ressortait, après étude de tous les systèmes de gestion d'erreurs existant, qu'aucun n'était réellement satisfaisant. Le débat est d'ailleurs né ici même, puisque c'est Nicolas Boulay qui [nous a un jour posé la question](https://linuxfr.org/~nicOnicO/25834.html). Le système par contrat de Lisaac/Eiffel, est gênant pour son approche "le contrat n'est pas respecté pas donc je crash", mais intéressant dans sa capacité à chercher la cause d'une erreur 20km plus loin. Le système à exception de Javouille est intéressant dans sa capacité à faire remonter une erreur, à la capter. Le problème est que c'est un système qui peut vite être très mal utilisé, et pour travailler sur des projets de plusieurs millions de lignes en Java/J2EE, même en environnement très contrôlé, cela devient vite très problématique. Typiquement, Hibernate perd la connexion à la base, il charge des null dans les objets et l'appli part en carafe... Le errno est intéressant, pas de rupture de contexte, pas de mort du signaleur, mais difficile de savoir d'où ça vient. Récemment dans mon entreprise, j'ai beaucoup travaillé avec les fonctionnels, et j'espère d'ailleurs continuer sur cette voie qui permet de prendre un recul très intéressant sur la capacité de l'humain de se représenter ce que doit rendre possible un logiciel, quel service doit-il offrir. Les fonctionnels que j'ai rencontré m'ont expliqué que, selon eux, les langages utilisés dans l'industrie étaient conçu pour faire plaisir aux développeur, mais pas "orienté client". En particulier la gestion des erreurs est un énorme problème : le logiciel doit se comporter de diverses manière en cas d'erreur logiciel survenu quelques part, mais pas forcément de façon bloquante : une souscription à un service sur son téléphone portable doit pouvoir marcher même si la base de données est momentanément hors d'usage, ou fournir le service au client, même si la banque n'a pas encore répondu. Je ne parle même pas des erreurs qui ne remontent pas, ou remontent mal.. C'est pour cela qu'il faudrait se demander si l'invention d'un système d'erreur ne deviendrait pas nécessaire : on pourrait imaginer un système basé sur un moteur de règle, avec un arrière gout Prolog. Cela aurait l'avantage de pouvoir gérer des conjonctions d'erreurs, et au compilateur de déterminer les cas possibles d'interaction pour proposer aux développeurs de prévoir une réponse. Le moteur de règle serait intrinsèquement d'assez haut niveau pour être accessible au fonctionnel, qui pourrait alors faire des choix. Reste qu'il nous manque un modèle, que nous implanterions alors sûrement dans le langage... Quelques liens : [http://lisaac.u-strasbg.fr/index.php/Gestion_d%27erreur](http://lisaac.u-strasbg.fr/index.php/Gestion_d%27erreur) [http://lisaac.u-strasbg.fr/index.php/Reflexion_de_08/2008](http://lisaac.u-strasbg.fr/index.php/Reflexion_de_08/2008) [http://mildred817.free.fr/2008/LisaacWorkshop/Slides2008/Ges(...)](http://mildred817.free.fr/2008/LisaacWorkshop/Slides2008/Gestion%20des%20erreurs/gestion_des_erreurs-1.pdf) [http://mildred817.free.fr/2008/LisaacWorkshop/Slides2008/Ges(...)](http://mildred817.free.fr/2008/LisaacWorkshop/Slides2008/Gestion%20des%20erreurs/)

AltStyle によって変換されたページ (->オリジナル) /