Enseigner Ada, pourquoi ?, à qui ?, comment ? Choisir un langage : entre le tentant et le raisonnable !


précédentsommairesuivant

VII. Conclusion

Arrivé à ce stade, le lecteur (convaincu de l'intérêt d'Ada ?) se posera certainement quelques questions :

Pourquoi Ada n'est-il pas plus répandu ?

On pensait, au début (vers 1980), que Ada remplacerait rapidement les langages alors principalement utilisés : Fortran, Pascal et, dans une moindre mesure, Cobol. Or si le langage Ada s'est bien introduit dans les domaines sensibles (aéronautique, aviation, domaine militaire, nucléaire, contrôle de processus), sa diffusion est restée modeste dans les domaines de la programmation dite traditionnelle : scientifique, gestion, programmation système, alors qu'on assistait à une montée en force du langage C, et plus tard (depuis 1990) de C++ et maintenant et récemment Java (sans parler des langages de script).

Pourtant, toutes les mesures effectuées sur des projets réels ont montré que les bénéfices que l'on pouvait espérer d'Ada étaient obtenus ou dépassés : meilleure qualité de la conception, réutilisation, augmentation de la productivité des programmeurs, infléchissement de la courbe des coûts en fonction de la taille des logiciels, effondrement du taux d'erreurs résiduelles et des coûts d'intégration, efficacité du code produit ; et ceci, quel que soit le domaine d'application concerné

Mais le choix d'un langage de programmation fait intervenir de nombreux éléments, qui touchent plus à la psychologie qu'à l'économie.

Tout d'abord, l'expansion de C est liée au développement du système UNIX. Il est de tradition de fournir gratuitement le compilateur C avec les outils standard d'UNIX. Pourquoi alors acquérir un autre langage ? D'autant plus que C a pour lui une extrême simplicité (d'aucuns disent même pauvreté) de concepts. Remarquons au passage que ces arguments ne s'appliquent plus à C++ : des compilateurs sont payants, et le langage est devenu bien plus compliqué ! Historiquement, UNIX a été développé par un petit nombre d'individus, sans souci de politique d'ouverture commerciale. Les interfaces ont donc été pensées uniquement en fonction des particularités du C ; c'est ainsi qu'une fonction peut retourner par exemple soit un pointeur, soit la valeur False (c'est à dire en fait zéro, qui est également le pointeur nul !). De telles violations de typage sont incompatibles avec la plupart des langages évolués, mais fréquentes avec C. Il en résulte des difficultés à faire des interfaces abstraites, propres, pour beaucoup de fonctionnalités UNIX, ce qui accentue le retard, en particulier au niveau de la standardisation, des autres langages par rapport à C. Et puis la « sagesse populaire » affirme que l'on doit programmer en C sous UNIX, sans plus d'explication. En dehors de ces considérations pratiques, l'attirance du programmeur moyen pour C, et la peur instinctive qu'il éprouve vis à vis d'Ada, plongent leurs racines bien plus profondément. Beaucoup de programmeurs encore peut être en fonction ont été formés à une époque où l'assembleur était roi. Nous avons connu des centres de calcul où les « nobles » (ceux qui étaient capables d'écrire tous leurs programmes en langage machine) regardaient de haut les novices qui n'étaient bons qu'à programmer en Fortran. Avec le temps, la programmation en assembleur tend à disparaître, car les problèmes de fiabilité, de maintenabilité et de portabilité sont vraiment devenus trop importants. Que sont devenus ces programmeurs ? Eh bien ils ont fait et font sûrement encore du C. Ils ont trouvé un langage qui n'est en fait, selon la définition de ses auteurs, qu'un assembleur portable. Comme nous l'avons vu, il permet de faire (presque) tout ce que l'on pouvait faire en langage machine et n'implique aucune remise en cause ni des méthodes ni de la façon de programmer. Inversement, Ada a été spécifiquement conçu pour obliger les programmeurs à modifier leurs habitudes ! En particulier, la programmation Ada s'accompagne d'une description plus abstraite des traitements. Outre que ceci nécessite un effort de réflexion plus important, le programmeur tend à perdre le contact direct avec la machine. Il doit faire confiance au compilateur pour la génération de code efficace, et ne doit plus se préoccuper du parcours exact du programme. Il n'est guère étonnant que l'inertie naturelle ne rende pas Ada très attrayant a priori au programmeur qui n'a pas saisi (car il n'a jamais essayé) les bénéfices d'une approche de plus haut niveau. Mais bien sûr, l'attirance naturelle du programmeur ne saurait être un critère pour un choix technologique dont dépendra tout le projet ! De façon plus imagée :C++ ressemble à un énorme gâteau à la crème, ruisselant de sucreries ; Ada ressemble plus à un poisson poché /pommes vapeur. Les questions intéressantes sont :1) quel est le meilleur pour votre santé

2) qu'est ce que les gens ont tendance à choisir spontanément ?

Les compilateurs Ada ont eu aussi mauvaise réputation. Les premières années (vers 1985), l'effort des fabricants s'est plus porté sur la conformité à la norme, vérifiée par l'incontournable suite de validations, que sur l'efficacité pour laquelle il n'y avait aucune obligation légale. Des compilateurs sont maintenant disponibles sur quasiment toutes les machines du marché, et des mesures objectives ont montré qu'ils étaient au moins aussi performants et fiables que les compilateurs C. Il n'en reste pas moins que le langage continue à traîner quelques vieilles « casseroles », d'autant qu'il est difficile de supprimer de la littérature les comptes rendus des premières expériences.

Un langage ne peut se répandre que s'il est enseigné.

Force est de reconnaître qu'Ada n'a pas réussi à séduire tous les universitaires. A cela au moins trois raisons.

Au début (1985) le prix des compilateurs, justifié en milieu industriel par le gain de productivité apporté, a été un obstacle certain. C'est ce qui a conduit le DOD, plus tard, à financer GNAT, pour mettre à la disposition de tous un compilateur Ada 95 gratuit.

En dehors du coup, chercheurs et enseignants ont, aussi, généralement, des contraintes différentes des industriels : leurs logiciels n'ont que rarement à être maintenus, et doivent, souvent, être développés très rapidement. Même si leurs cours d'informatique prônent le génie logiciel et l'importance de favoriser la maintenance au détriment de la facilité de développement, les universitaires appliquent rarement ces bons principes à eux mêmes ! Inversement, les langages orientés objet sont à la mode et semblent offrir des facilités supplémentaires (mais cet argument n'a plus lieu d'être avec Ada 95 qui les propose aussi).

Enfin, le fait que le DOD ait financé le développement d'Ada lui a créé, sûrement, une certaine antipathie dans les milieux universitaires, traditionnellement antimilitaristes.

Paradoxalement, les promoteurs du langage ont pu lui faire du tort par excès de purisme en exigeant de faire du 100% Ada.

Le langage a tout prévu pour permettre d'écrire des modules en d'autres langages (C, Fortran, Cobol) si c'était plus commode ; il autorise même l'écriture de modules en assembleur. Si ces éléments sont alors non portables, ce n'est pas trop grave dans la mesure où le mécanisme d'empaquetage garantit que ces non portabilités sont répertoriées, aisément identifiées, et sans effet sur les utilisateurs des paquetages. Il n'y a donc pas de honte à écrire un corps de module en assembleur ou en C si, par exemple, il n'y a pas d'autre moyen d'obtenir les performances requises. En exigeant le « tout Ada » au delà du raisonnable, on risque de se heurter à des problèmes tout à fait localisés, mais dont la publicité risque de discréditer le langage tout entier.

Enfin, il est remarquable de constater que les plus virulents adversaires d'Ada ... ne l'ont jamais vraiment pratiqué !

Peut être ont ils juste fait quelques essais, sans formation appropriée, en traduisant « littéralement » des bouts de code d'autres langages avec lesquels ils étaient familiers. Au bout de quelques erreurs de compilation, ils ont décidé que le langage était difficile, et n'ont pas poursuivi. Inversement, ce n'est qu'à l'usage que l'on en apprécie tous les avantages : typage fort, exceptions, parallélisme, paquetages hiérarchiques, etc. Il est certain que pour tirer tout le bénéfice d'Ada, il ne suffit pas d'apprendre la syntaxe ; il faut assimiler l'état d'esprit, c'est à dire « la façon de faire » qui va avec. Il faut admettre qu'un langage comme Ada joue un rôle différent dans le processus du développement du logiciel et que, comme on l'a vu, le choix du langage de codage n'est pas neutre : précisément parce qu'il peut être beaucoup plus qu'un simple outil de codage. Comme le remarquait G. Booch en 1991 : « Donnez une perceuse électrique à un charpentier qui n'a jamais entendu parler de l'électricité, et il l'utilisera comme marteau. Il tordra des clous et se tapera sur les doigts, car une perceuse fait un très mauvais marteau ».

Si les mauvaises nouvelles courent vite, il est plus difficile de répandre les bonnes.

Ada n'a pas toujours su « faire sa pub ». Qui, en dehors des convaincus, sait qu'Ada a été utilisé (il y a longtemps et avec succès) dans de nombreux programmes de gestion, dont un projet de 2,5 millions de lignes de code qui a pu être développé avec la moitié du coût initialement prévu Qu'un logiciel qui n'arrivait pas à tenir ses contraintes temps réel a été réécrit en Ada avec des performances satisfaisantes. Qu'une entreprise gère plusieurs projets totalisant un million de lignes de code en n'employant qu'une seule personne à la maintenance. Soyons honnête cependant : au début les utilisateurs d'Ada 83 ont pu rencontrer des difficultés objectives, même si la plupart ont appris à « vivre avec ». On notait en particulier le manque de support des méthodes par classification, de trop nombreuses re-compilations dans les grands projets, des difficultés d'interfaçage avec d'autres langages ou des bibliothèques... et le manque de fiabilité des premiers compilateurs et des environnements de programmation, la prolifération des tâches pour de simples synchronisations (car il n'y avait qu'un concept de synchronisation, le rendez-vous). Ces problèmes ont disparu depuis plus de dix ans, ou, ont été résolus par Ada 95 et peuvent être maintenant considérés comme sans objet par exemple grâce à l'excellent choix de l'objet protégé dans les synchronisations. Il faut, quand c'est possible, abandonner le rendez-vous pour traiter la synchronisation et ne le garder que pour les appels conditionnels ou temporisés ou pour initialiser des données propres à une tâche (autrement dit, on utilise le rendez-vous quand on ne peut pas traiter le problème avec un objet protégé).


précédentsommairesuivant

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

  

Copyright © 2003 Daniel Feneuille Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.