Conférence de Bertrand Meyer sur le langage Eiffel

Une présentation passionnante de l’inventeur du langage Eiffel a eu lieu le 09 mai 2012 chez Valtech. Eiffel est un langage OO se basant sur un certain nombre de concepts nouveaux ou méconnus. Ce billet va vous expliquer tout çà.

Qu’est ce qu’Eiffel ?

• Une « méthode » pour reprendre les mots du conférencier. Eiffel supporte en effet de nombreux paradigmes objets. Mais il incite fortement (pour ne pas dire force) à penser ses programmes par contrats. Nous en reparlerons, mais disons qu’un contrat garantit les pré conditions, post conditions et invariants du langage.
• Un langage Orienté Object à typage fort, capable de gérer des exceptions. Il se base sur la méthode et les paradigmes ci-dessus, évidemment.
• Un outil de développement, Eiffel Studio. On l’a peu vu, donc nous avons cru B. Meyer sur parole 🙂

Quelles sont les grandes idées derrière Eiffel ?

Eiffel est portable

La compilation du code Eiffel produit du code MSIL (pour la VM .Net) ou en C. Par conséquent, le code est à la fois portable et rapide. On peut s’interroger sur l’absence de VM, comme C# et Java. Mais la réponse vient d’elle-même : le C est en partie standard, et tourne sur de nombreuses architectures. Il est également connu pour sa rapidité. Enfin, cela épargne le cout d’entretien de la VM pour les équipes de développement.

Eiffel a besoin de peu de librairies spécifiques

Les râleurs et les esprits tatillons trouveront qu’il y a peu de librairies pour Eiffel. Oui, c’est exact. Mais une conséquence de la compilation en C ou MSIL est qu’il devient possible d’utiliser les librairies dans ces langages. Donc, il y aura forcément votre bonheur. D’autre part, il est possible d’interfacer Eiffel avec un autre langage.

Eiffel est « void safe »

Pour le dire dans un langage que tout le monde comprend, on ne peut pas appeler une méthode sur un objet nul. C’est impossible en Eiffel, et le code ne compilera pas si ce peut être le cas. On évite donc la fameuse NullPointerException. Comme B. Stroustrup l’explique si justement dans son dernier livre, plus on détecte d’erreurs à la compilation, meilleur est le compilateur.

Eiffel utilise la conception par contrats

La conception par contrats, c’est un des principaux arguments de vente d’Eiffel. Le principe est le suivant :

• Avant le lancement d’une méthode, des pré-conditions doivent être remplies.
• L’algorithme fonctionne sur des invariants
• A la sortie de la méthode, la méthode garantit un certain nombre de post-conditions.

Ces éléments sont définis de manière formelle dans le code. Ébahissons-nous un moment devant cette idée. Le code Eiffel étant très lisible, on s’épargne des spécifications techniques détaillées. Pas tout, bien sûr, mais les parties un peu critiques. C’est le principe dit du modèle unique. Une même condition est écrite une seule fois, pas dans des fichiers word décorellés de l’évolution du code.  Ensuite, en les incluant ainsi, la détection d’exceptions s’en trouve d’autant facilitée. Par rapport à Java et au mot clé assert, le plus est l’expressivité du langage Eiffel. La mise en place des concepts est en effet intéressante. D’abord car il est possible de définir des prédicats « complexes » en utilisant les champs de l’objet. Ensuite, car ces éléments permettent de séparer le code (implémentation) des contrats que la méthode doit garantir. Le mot clé deferred permet d’ailleurs de séparer la partie contrats de la partie implémentation. La mise en œuvre se fait en utilisant les mots clés : require, ensure, invariant. Respectivement, les pré conditions, post conditions et invariants.

A quoi cela sert il, sinon à em…bêter le développeur ? Excellente question qui prouve à quel point nous n’avons pas l’habitude de ce paradigme. Eiffel pousse l’idée jusqu’à inclure dans Eiffel la génération automatique de tests unitaires pour torturer un peu le code. Tests aux valeurs spéciales, tests sur certaines valeurs prédéfinies sont deux exemples. Le point clé est qu’Eiffel Studio teste de manière automatique les méthodes. En cas d’erreur sur un test, il « se rappelle » du cas et le sauvegarde pour le jouer plus tard. Eiffel travaille également à la minimalisation du cas de test, c’est-à-dire le « plus court code » provoquant la violation d’un invariant, pré ou post condition.

Eiffel offre la programmation par agents

Oui, les agents, comme dans les systèmes multi agents des cours d’intelligence artificielle. Un agentémet un message, qui est lu par un consommateur. En Eiffel, le principe est utilisé pour la programmation par exemple d’interfaces graphiques, un peu comme les événements en .Net (le peu que j’en connais).

Eiffel propose une gestion « simple » du parallélisme

B. Meyer nous a détaillé la librairie Scoop. Son analyse est la suivante : le parallélisme est au point mort conceptuel depuis les années 1970. Or, la vitesse des processeurs commence à stagner, et tout le monde se tourne vers :

• des architectures distribuées
• des processeurs multi core

Eiffel se doit donc de suivre cette tendance et mettre en place un moyen simple de répondre à ces deux problématiques. Eiffel suggère une division du code en régions : une région est gérée par un processus et un seul, sur une machine et une seule. Les régions communiquent et ce qui vient d’une autre région est déclaré separate. Cela permet de poser un sémaphore dessus quand on en a besoin, et d’attendre que les autres le libèrent. Par conséquent, pour deux objets :

• s’ils sont dans la même région, l’appel de l’un à l’autre est synchrone
• sinon, il est asynchrone et a besoin de savoir avec le mot clé separate qu’il vient d’ailleurs.

Eiffel met en avant la notion de reasonability, la faculté d’Eiffel à calculer l’ordonnancement des instructions et d’attendre que les ressources nécessaires soient disponibles.

Quels sont les axes de recherche autour d’Eiffel ?

Les équipes travaillent sur les améliorations suivantes :

• ORM : en natif dans le langage
• Concurrence : pousser Scoop plus loin. Une bourse européenne a été proposée à B. Meyer. 2.5 millions d’euros. Quand même.
• Le cloud : Windows s’y est mis. Eiffel aussi.
• Vérifications de code et preuve : Idée géniale (une de plus) de B. Meyer : la machine qui découvre un bug peut suggérer une amélioration ou une correction. Vous allez me dire que c’est impossible dans le cas général. C’est exact en général, mais une analyse des bugs tracker montre que  les erreurs sont souvent les mêmes, que les corrections sont faciles (quand on sait où corriger). La méthode par contrats facilite le travail de la machine : soit le contrat reste violé, soit il passe. De même, la preuve de code est théoriquement impossible dans le cas général. Bien sûr, mais sur certaines parties du code, elle peut l’être. Et quand elle l’est, Eiffel Studio valide le code.
• Re-engineering : Le code Eiffel peut être compilé en C. Ce que suggère la R&D d’Eiffel, c’est de tenter l’inverse. Retrouver du code Eiffel à partir du C.