Genèse de O+ par Maxime Daniel

Maxime Daniel, le père du Langage
Maxime Daniel, le père du Langage

Au tout début de l’été 1991, le projet AGL89, qui ne s’appelle pas encore PAC/CS, est à la recherche d’un langage de programmation adapté aux systèmes d’exploitation des micro-ordinateurs, et en particulier aux interfaces homme-machine multi-fenêtres, portables entre différentes plates-formes, et assez structurant pour aider nos clients à capitaliser leur parc applicatif au fil des années, dans la grande tradition PACBASE.

Nous disposons alors sur les micros d’un générateur de langages dédiés, qui a fait ses preuves à travers le langage de script de la station de travail Pacbench.

Il présente cependant deux défauts majeurs dans le contexte d’AGL89 :

– c’est un langage fonctionnel pur ; Marc Boullé, moi-même et d’autres collègues pensons que le passage à la programmation orientée objet ne peut pas être différée, et qu’il nous faut un langage orienté objet ; l’expérience des équipes micro de CGI ne fait que renforcer cette conviction, même si les langages orientés objet de l’époque peuvent parfois présenter des caractéristiques peu enviables (l’un d’entre eux utilise le préprocesseur C pour générer à la volée du C qui simule une syntaxe à objets, et présente le curieux défaut que certaines parenthèses des fichiers sources ne doivent pas balancer !) ;

– c’est un langage interprété, ce qui a toujours présenté un certain déficit en termes de performances, à une époque où les performances des systèmes sont très significativement inférieures à celles dont nous disposerons vingt ans plus tard.

Benoît Gloanec décide donc que nous devons développer un langage orienté objet compilé, dont le nom de code sera L89 (pour Langage d’AGL89).

Je me lance dans les spécifications à Saint-Marc, en m’inspirant très fortement de Eiffel. Marc Boullé et d’autres collègues participent très activement à l’élaboration d’icelles, tant en ajouts et affinages qu’en éliminations !

Thibault Le Paul me rejoint et nous commençons allègrement le codage.

Les classes de base algorithmiques (collections, accès au système d’exploitation, etc.), CBA de leur petit nom, sont développées par Bruno Guillon à Paris.

La diversité des systèmes cibles est grande, et la disponibilité de bibliothèques réutilisables portées pour différents systèmes est vue comme un complément absolument nécessaire aux générateurs de code.

Nous nous servons bien entendu de L89 et des CBAs pour écrire le compilateur, empruntant encore à la tradition, qui veut que chez CGI, nous écrivions nos produits avec nos produits à chaque fois que possible.

La plate-forme prioritaire est OS2, le compilateur génère du langage C, vu ici comme « assembleur portable », et le projet avance.

Le 27 février 1992, pris de sérieux doutes, je rencontre Pascal Garrigue rue du Château des Rentiers pour lui exposer que, selon moi, nous n’avons pas les moyens de mener l’aventure à bien (même pas peur !).

AGL89 a besoin de toutes les forces de l’équipe, et mon point de vue est qu’en distraire une partie à élaborer un langage de programmation n’est pas une bonne opération. Je souhaite plutôt que nous mettions en œuvre un langage existant du marché, ce qui aurait l’avantage supplémentaire de doter immédiatement le projet d’un langage complet et équipé de tous les outils et bibliothèques nécessaires.

Compte tenu de leurs caractéristiques respectives, et de notre public, ma préférence va à Eiffel, conçu avec un très grand souci de l’ingénierie du logiciel. (Je juge C++ trop difficile, en particulier pour la gestion de la mémoire, et Smalltalk trop permissif – thèmes que je reprends quelques années plus tard contre ces candidats quand nos clients viennent en formation.En ajoutant toujours « il y aurait bien eu Eiffel, mais… »).

Pascal me « passe un savon » en m’expliquant qu’il faut être fier de ce que l’on fait (ce en quoi il avait parfaitement raison, il faut s’y tenir à chaque fois que c’est possible !), et je rentre à Saint-Marc continuer l’aventure.

L’équipe s’étoffe et le produit grandit et embellit. Nous sommes en 1995 huit personnes à Saint-Marc pour programmer le langage, maintenant appelé O+, ses classes de base graphiques et algorithmiques et son environnement d’exécution.

O+ tourne sur cinq plates-formes (AIX, OS 1.3 et 2.0, Windows 3.11 et DOS 5.0). PAC/CS est codé en O+, qui s’interface aux langages C et C++ pour accéder aux couches les plus basses des systèmes. O+ dispose d’un compilateur, d’un outil de formatage, d’outils variés pour faciliter la détermination des problèmes, par exemple les fuites mémoire.

Nous commençons à rêver de l’intégrer au dictionnaire de façon structurée, abandonnant le format fichier et facilitant au passage l’intégration au modèle de PAC/CS et la conception des générateurs.

Il lui manque en revanche, et pour toujours, des facilités disponibles depuis longtemps pour d’autres langages, comme un débogueur symbolique, et à venir dans les prochaines années comme le complément automatique des noms de classes, méthodes, variables etc. dans les éditeurs de code, la compilation incrémentale et le signalement des erreurs à la volée, et bien d’autres.

S’il faut parler de leçons de modestie, j’évoquerai une bataille homérique entre Marc Boullé et moi sur la pertinence de nous lancer dans la création d’un allocateur de mémoire maison. En 1993, les performances d’AGL89 laissent à désirer, et Marc est convaincu qu’améliorer l’allocateur serait un facteur de gain décisif. Je lui résiste âprement au motif que l’allocateur C, que nous utilisons inchangé, a fait ses preuves, et que rien ne permet de supposer que nous ferons mieux.

Marc code un sous-allocateur chez lui pendant un week-end, et me montre ainsi que j’avais spectaculairement tort. Son prototype met en évidence que, compte tenu de la distribution typique en temps et en taille des allocations et libérations de mémoire d’un langage à objets (allocations et libérations très fréquentes, petites tailles de fragments mémoires radicalement sur-représentées dans l’échantillon), l’allocateur standard du langage C, prévu pour des allocations moins fréquentes et distribuées plus largement, est complètement inadapté. Le prototype transforme les minutes en secondes, sans autre changement.

Thibault Le Paul se lance immédiatement dans la programmation d’un allocateur robuste inspiré des travaux de Marc, que nous étendrons ensuite en ajoutant la détection des débordements et fuites mémoire, des outils statistiques, etc., qui donne un second souffle à toutes les applications écrites en L89, et à AGL89 en premier.

S’il faut parler des moments d’héroïsme, j’évoquerai ce moment tragique fin 1994 où nous réalisons soudainement que Windows 3.11, dont le support est exigé par certains de nos clients, ne supporte pas les segments de données privés.

(Parenthèse pour les gourmands de détails : à cette époque, les DLLs ont des segments de code, où résident les programmes, et des segments de données, où résident les variables ; OS2 permet de distinguer les segments de données partagés, dans lesquels il convient de ranger les constantes, par exemple, des segments de données privés, dans lesquels chaque invocation de la DLL peut ranger, en particulier, ses propres variables ; nous nous retrouvons tout à coup face à une très mauvaise surprise : toutes les copies actives d’une DLL sur un même ordinateur Windows 3.11 partagent leurs variables, les différents programmes modifiant allègrement les données des autres ; inacceptable !)

Les coûts des solutions évidentes sont prohibitifs. Si nous renonçons aux bibliothèques dynamiques, nous allons saturer la mémoire des systèmes, et ne pourrons pas cibler les machines disponibles sur le marché. Si nous devons prendre explicitement des copies différentes des objets par programme, tous les générateurs de PAC/CS (qui génèrent du O+ à partir du modèle et du code spécifique, lui aussi en O+) doivent être réécrits, alors même que nos clients commencent sérieusement à s’intéresser aux versions alpha de PAC/CS.

Bertrand Fayn a alors une idée lumineuse : Windows 3.11 ne supporte peut-être pas les segments de données privées, mais le tout récent processeur 386 d’Intel supporte la segmentation au niveau physique, lui.

Si nous pouvons nous « glisser sous Windows » et piloter la segmentation du processeur à chaque changement de programme appelant pour une DLL, nous sommes peut-être sauvés ! Bertrand commence le travail tout seul et, alors que la piste s’avère en même temps prometteuse et ardue, je lui prête la main.

Nos six mois-homme d’efforts aboutissent à une bonne centaine de lignes de C, et autant d’assembleur, qui constituent le l89swapper, véritable intermédiaire entre Windows et le processeur, qui fait danser les segments physiques pour les DLLs.

Chères lignes, mais PAC/CS tourne comme une horloge sur Windows 3.11, et aucun bogue ne sera rapporté sur ce code critique en neuf mois que durera son existence !

En janvier 1996, nous savons déjà que le développement de PAC/CS est interrompu, et nous n’allons pas tarder à apprendre que, contrairement à ce qui a été annoncé un mois plus tôt, sa commercialisation n’est plus à l’ordre du jour.

Pascal Garrigue m’appelle à Toronto, où je fais mes premiers pas dans la grande famille des laboratoires de développement IBM dans le cadre d’un projet de collaboration, et me confie qu’O+ a été avancé comme l’un des éléments déterminants de la décision d’IBM.

Ce n’est pas un mauvais langage.

Mais c’est un langage propriétaire, que nous n’avons pas les moyens de développer assez largement, ni en fonctions, ni en termes d’adoption sur le marché. Pascal me pose à contre-temps la question rhétorique suivante : combien cela pourrait-il prendre de temps de porter PAC/CS dans un langage qui pourrait recevoir l’agrément d’IBM si l’équipe PAC/CS était restée en ordre de bataille ?

Je réponds un an, peut-être…

La vraie réponse nous échappera toujours.

 

Laisser un commentaire