Ce 9 Mai, Valtech nous avait invité à rencontrer Bertrand Meyer. Figure emblématique de l’objet à la fin des années 1980 / début des années 1990, j’avoue que je n’avais plus entendu parler de cette sommité depuis de nombreuses années. L’objet s’est effacé du devant de la scène dans la seconde moitié des années 90 tandis que le Web tractait toute l’attention, et le nom du créateur d’Eiffel a disparu des titres.

C’est donc avec grand plaisir que je suis venu l’écouter, entendre parler d’objet à nouveau et en savoir plus sur ses sujets d’investigation d’aujourd’hui.

Un peu de Biographie

Diplomé de Polytechnique (X-Telecom), Bertrand Meyer a rejoint la direction des études d’EDF en 1974. Parti pour un an en Californie, à Santa Barbara, il y restera quatre, entre 1983 et 1986. Il y rencontrera des sommités de l’informatique, tel que Donald Knuth, mais il créera surtout le language Eiffel

Depuis 2001, Bertrand Meyer occupe une chaire de professeur à l’EPFL de Zurich, où il succède à Niklaus Wirth, le créateur du language Pascal.

Parlons maintenant d’Eiffel

Pour débuter, Mr Meyer nous propose de commencer… par évoquer les points négatifs !

Les points négatifs

• Eiffel n’est supporté par aucun acteur majeur de l’industrie. C++ Le fut par AT&T, puis par Sun. Java l’a été par Sun et désormais par Oracle.
• Mais il s’est fait sa place chez certains industriels qui lui sont fidèles.

Il s’agit d’une petite communauté. Toutefois cette communauté n’a jamais cessé d’exister depuis 25 ans. Donc si ce mouvement est discret il est solide.

• De manière assez curieuse, après avoir essuyé les reproches d’être un langage “trop jeune”, Eiffel est presque directement passé au statut de “legacy” !

Pas de phénomène de mode autour du langage. A aucun moment, il n’a eu la réputation d’être le langage “dans le vent”. Absence de composants réutilisables. Ce dernier point est paradoxal, car le langage a été imaginé et créé au départ avec cette finalité en tête.

• Aujourd’hui les librairies existent mais restent peu nombreuses comparées aux standards du marché.
• Mais le langage est simplement interfaçable vers le C et le C++ (le compilateur fonctionne en “C front”). L’interfaçage se fait également sur la machine virtuelle .NET de Microsoft. L’interfaçage vers Java est possible, mais difficile.

Les points négatifs … qui n’en sont pas

• “Cette fonctionnalité finira par arriver dans mon langage favori”. Les ajouts de fonctionnalités après coup dans les langages s’avèrent générallement boiteuses. Par exemple les “code contract” de .net fonctionnent comme des pièces rapportées.
• “Il n’y a pas de programmeur Eiffel”. Eiffel n’est pas une religion. Tout développeur aguerri à l’objet peut se mettre aisément à Eiffel. Il est apte à être pris en main par des débutants, plus qu’il ne s’avère possible avec C++ qui est un langage difficile à maîtriser.
• Pas de covariance pour l’instant. Il s’agit d’un problème avec le système de type sui sera résolu bientôt.
• Pas fait pour le Web. Là aussi il s’agit d’un point en cours de résolution. Le framework EWF adressera cela.

Ce pour quoi Eiffel est fait

• Il ne cible pas les réalisations “quick and dirty”. Les langages orientés script tels que Perl et Python sont mieux ciblés pour cela.
• Il ne cible pas non plus le temps réel: la présence d’un garbage collector est une source d’alea trop importante pour répondre aux exigences du temps contraint

Et les types de développements ?

• Les développements “casual” ne sont pas non plus le coeur de cible du langage (cf le “quick and dirty”)
• Le développement professionnel en entreprise est clairelment la cible du langage. C’est par ailleurs la très grande majorité des développements informatiques.
• Les développements critiques (money critical, life critical) : pas non plus la cible privilégiée du langage, malgré la présence de fonctionnalités adaptées (typage forts, contrats).

Quels sont les argumentaires d’Eiffel ?

Par rapport à sa cible, ce sont les arguments liés à la qualité sur le long terme:

• Extensibilité
• Fiabilité
• Scalabilité
• Portabilité (grâce au compilateur “C front”, il a le niveau de portabilité du C sous-jacent).
• Intégration méthode / langage. Nous reviendrons sur ce point.

Cet argumentaire qualité passe hélas peu. Il est pourtant très aligné sur les principes sous-jacents à l’agilité au niveau du code, selon l’analyse qu’en fait Bertrand Meyer, suite à sa formation “Scrum Master”.

Alors quels sont les projets classiquement dévolus à Eiffel ?

• Ceux pour lesquels tout le reste n’a pas marché !
• Ceux qui sont soumis à des évolutions fréquentes.
• Ceux pour lesquels il y a un “champion local” supportant ce choix.

Et justement, ces développeurs à quoi ressemblent-ils ?

• Ce sont tout autant des concepteurs que des codeurs … et certainement pas de simples codeurs: comme dans tout langage objet, les principes de conception sont liés au langage, mais pour Bertrand Meyer, c’est encore plus le cas avec Eiffel !
• Ce sont des développeurs dont la volonté de se perfectionner est plus importante que celle de suivre le plus grand nombre.
• Il semblerait aussi que la pratique d’Eiffel rende beau et donne un charme irrésistible auprès des femmes ! Et voilà : Bertrand Meyer nous a pris par surprise, car sous une apparence disons classique, le créateur d’Eiffel a un sens de l’humour tout à fait aiguisé, et il nous délivre ses traits sous un air pince sans rire redoutablement efficace !

La réalité d’Eiffel aujourd’hui

Eiffel est à la fois une méthode, un langage et un environnement.

En tant que méthode

Eiffel suit les principes de la conception orientée objet, tels du moins que son auteur les a décrits dans son ouvrage disponible dans toutes les bonnnes librairies.

Eiffel suit le principe du “single model”, c’est à dire que le code du langage porte le code d’exécution, mais aussi des informations d’analyse, comme celles concernant les pré/post conditions et les invariants.

L’approche orientée obets est l’axe principal (unique ?) de l’approche d’Eiffel, la méthode (et le langage) supportent donc le paradigme des types abstraits de données, ce qui signifie :

• Une description abstraite des propriétés des opérations.
• Une organisation des types en hiérarchies supportant le polymorphisme (principe de substitution de Liskow).

En tant que language…

Eiffel a été normalisé par l’ISO en 2006. L’implémentation du compilateur est donc ouvert à la concurrence, du moins en principe.

La classe est le seule mécanisme de modularisation. Pas de “package”, de “namespace” ou de “module” !

Par ailleurs, Eiffel est un des rares langage qui supporte l’héritage multiple, position que Bertrand Meyer défend avec ardeur. Si je le suis sur ce terrain, l’exemple qu’il nous a présenté ne m’a pas paru terriblement percutant: le cas du vélo qui hérite de “véhicule” et de “Liste” me semble boiteux, car ces deux abstractions sont de niveaux très différents. Ainsi la liste devrait être un simple élément d’implémentation dans le vélo…

Eiffel supporte aussi depuis le départ la notion de générique. Contrairement à C++ et surtout par rapport à Java, cette fonctionalité n’est pas une pièce rapportée … surtout quand elle est aussi faible que le “type erasure” de Java !

… Toujours vivant !

Le langage est désormais “void safe”. Cet ajout arrivé il y a 6 ans interdit le déréférencement de pointeurs pouvant être nuls ! Et ceci est même vérifié à la compilation.

Les agents. Il permet de construire des clases qui sont des “observer” du pattern MVC. D’autres classes pouvant évidemment publier des évènements. C’est le MVC intégré dans le langage !

En tant qu’environnement

Eiffel Studio est le standard “de facto” du langage. Il intègre 2 compilateurs:

• 1 compilateur “C front” qui est le compilateur historique d’Eiffel. Ce passage par le C est le couche qui assure au langage sa portabilité, comme je l’ai évoqué précédemment.
• Un compilateur sur la machine virtuelle .NET de Microsoft.

Le compilateur utilise la technique dite de “la glace fondue”, en fait une compilation incrémentale qui rend les temps de compilation non pas dépendants de la taille du projet, mais de l’importance des changements depuis la dernière compilation.

Design by contracts

L’un des apports originaux (repris depuis par d’autres langages) est la notion de contrats. Ceux-ci sont intégrés au code selon le principe du “modèle unique” que nous avons évoqué plus haut. L’environnement dispose quand à lui d’outils pour extraire ces informations à différents niveaux (modèle, documentation, tests…). Il y a 3 types de contrats:

• Les préconditions : Il s’agit des conditions que l’apellant doit respecter avant l’appel à la méthode.
• Les postconditions : Il s’agit des conditions que l’apellé doit respecter avant de rendre la main.
• Les invariants: Ils doivent être respectés à tout moments..

Dans le cas du polymorphisme, les préconditions appartenant à l’abstraction sus-jacente doivent être respectées au moment de la liaison tardive entre appelant et apellé.

Les contrats permettent de vérifier les domaines de validité des paramètres en entrée, de valeurs de retour en sortie et les conditions de stabilité des objets. Dans le cas de l’explosion d’Ariane 5, la vérification du domine de validité des paramètres d’entrée aurait suffit à prévenir l’explosion de la fusée !

En développement, la violation de contrat nous emmène directement dans le debugger, celui-ci précisant la nature du contrat non respecté et le contexte.

Eiffel et les tests unitaires

Bertrand Meyer s’inscrit dans la logique de mise en place des tests unitaire instillée par les pratiques agiles et plus particulièrement TDD ! Cependant il juge que ceux-ci souffrent encore de points faibles, parfois simplement passés sous silence dans la littérature:

• Génération des tests unitaires: les tests passants et surtout les tests non-passants.
• L’enrichissement des tests unitaires sur la base des échecs d’exécution.
• La minimisation des tests afin d’en optimiser l’exécution.

L’environnement Eiffel propose un outil à cet effet nommé Autotest qui permet la génération des tests à partir de contrats, mais égallement leur enrichissement sur la base des échecs d’exécution. Bertrand Meyer n’a rien dit sur le volet de la minimisation, j’imagine donc que c’est toujours un sujet en cours de travail.

Le parallélisme avec SCOOP

Il s’agit d’une nouvelle extension d’Eiffel : Simple Concurrent OO Programming. Il s’agit bien d’une extension car au moins un nouveau mot-clé (separate) est introduit dans le langage avec SCOOP. Le problème de la concurence n’est pas nouveau et nous savons tous qu’il n’est pas simple à adresser. Son importance augmente pourtant de manière importante, avec la progression des processeurs “multi-coeurs”.

SCOOP met en avant les notions d’action, d’asynchronisme et surtout de “région”. SCOOP prend en charge les mécanismes de synchronisation de bas niveau afin de permettre ce que Bertrand Meyer juge important : pouvoir raisonner sur les programmes.

Le principe de base de SCOOP est le “wait rule”: une action ne démarre pas tant que toutes les ressources nécessaires ne sont pas disponibles.

Les développements en cours

Depuis qu’il a repris en 2001 la chaire de professeur de Niklaus Wirth, Bertrand Meyer poursuit ses travaux autour d’Eiffel:

• La notion de “preuve” formelle, et de vérification statiques ou dynamiques des programmes.
• La persistence
• Le “cloud based developpement”. Dans cet environnement, le VCS (ou même le DVCS à la Git) disparait. Les changements se font et sont répercutés en temps réel, à la Google doc.
• EVE: une évolution de l’environnement Eiffel permettant la vérification des programmes minute par minute.
• Autofix, qui l’étape suivant d’Autotest: l’idée ici est de proposer des corrections automatiques des programmes pour les cas simples. Actuellement le ratio de succès de cet outil est de 2/3, testé sur les correctifs apportés au fil du temps sur les librairies Eiffel elle-mêmes.

En conclusion

Eiffel existe, il est toujours en cours d’évolution. Mais il ne deviendra jamais “mainstream”. L’auteur l’avoue et s’en accommode. Certaines choses qui sont acquises dans des langages modernes : la covariance, la présence de frameworks Web sont encore très récentes ici ou en cours de développement. Le langage reste ancré sur ses choix initiaux : purement objet, sans mécanisme de modularité à grande échelle ni intégration de paradigme tiers comme la programmation fonctionnelle. Ces choix ont nécessairement un impact pour rendre le langage attrayant pour le plus grand nombre, mais c’est une bataille que Bertrand Meyer ne cherche plus à mener.

Paradoxalement, cette position de niche lui confère certains avantage, comme la possibilité de ne pas rester fixé sur la stricte compatibilité ascendante lors des évolutions du langage. Et si la communauté est petite, elle est très fidèle à Eiffel. Car le langage reste remarquable, certes doté d’un ecosystème de librairies sans commune mesure avec Java, mais avec un design de base qui n’a rien à lui envier, bien au contraire !

Si vous voulez aller de l’avant avec Eiffel, vous pouvez rejoindre le Groupe des Eiffelistes Francophones (la page Google Group est ici). Merci à Jocelyn Batton de l’avoir créé !