11.5.10 : Conclusions
Comme on a pu le voir, le choix d'un langage de programmation est complexe et ne saurait se résumer à une affirmation dogmatique de la supériorité d'un langage sur tous les autres. La performance n'est qu'une facette du problème, et d'autres contraintes comme l'expressivité, l'ergonomie, la compatibilité avec le code existant éventuel, la facilité de prise en main initiale pour les programmeurs non-spécialistes, la disponibilité d'experts, et la maturité de l'écosystème (langage, bibliothèques, etc), doivent toutes être prises en compte.
Il n'est pas possible de recommander ou même d'imaginer un langage affichant la perfection sur tous ces plans, car plusieurs de ces objectifs de conception entrent en conflit. Le choix d'un langage relèvera donc nécessairement en partie d'un arbitrage informé entre différentes priorités, et notre rôle se bornera à émettre des recommandations pour un petit nombre de situations classiques.
Tout d'abord, une première question à poser est celle du degré d'inertie du projet logiciel dans lequel on œuvre~:
- Dans des projets établis possédant une grande base de code existant, il sera souvent plus pertinent de poursuivre avec la technologie existante, sauf si des défauts rédhibitoires du langage ou du code existant justifient une réécriture totale ou partielle de l'application. Dans ce cas, un changement de langage pourra quand même être envisagé.
- À l'inverse, pour de nouveaux projets peu dépendants d'infrastructures existantes, comme des analyses physiques, l'exploration de nouveaux langages est bien plus aisée, et peut permettre d'échapper à la stagnation des écosystèmes établis.
- Entre ces deux extrêmes, il existe toute une palette de situations où le choix de changer ou non de langage dépendra fortement de la manière dont les développeurs dosent différent critères.
Une autre question qui doit être posée est celle du profil des développeurs~:
- Pour des personnes dont la programmation est le cœur de métier, l'apprentissage de langages complexes mais dotés d'une grande puissance expressive comme C++ ou Rust simplifiera l'écriture de bibliothèques puissantes au code performant.
- Pour des personnes pour qui la programmation est une activité annexe, on privilégiera plutôt des langages conçus pour être faciles à prendre en main comme Go, Python ou Julia.
- Lorsque des personnes dont l'expertise en programmation est très hétérogène doivent collaborer, on aura recours à des langages qui peuvent être utilisés à plusieurs niveaux de maîtrise, comme Julia, ou à des systèmes à deux langages comme la combinaison Python/C++ lorsque l'utilisation d'outils plus établis est nécessaire.
L'échéance du projet jouera aussi un rôle important~:
- Il n'est pas envisageable d'adopter une technologie peu mature, qui nécessitera un nombre important de contributions à l'écosystème du langage, lorsqu'un logiciel doit être livré sous une échéance courte.
- À l'inverse, des échéances longues comme celles de FCC donneront aux développeurs la possibilité d'envisager du travail de fond sur leur code, y compris des migrations technologiques importantes comme un changement de langage.
Et enfin, le contexte technologique pourra aussi influer sur les choix de langages disponibles. Par exemples, certains matériels de calcul comme les FPGAs n'acceptent actuellement d'exécuter que des routines écrites en C ou parfois en C++. Interagir avec ces matériels depuis un code écrit dans un autre langage nécessitera donc une base de code hybride, avec tous les soucis que cela implique. Si ces monopoles de langages disparaissent progressivement aujourd'hui, avec par exemple l'ouverture de Julia à la programmation des GPUs NVidia, tous les projets ne pourront pas se permettre d'attendre que la situation se résolve d'elle-même, ni de contribuer à ces efforts.
Le choix d'un langage de programmation relève d'un compromis difficile, et l'informatique scientifique ne fait pas exception.
Si la combinaison de C++ et de Python, bien établie à l'IN2P3, reste appropriée dans certains cas, de nouveaux langages comme Julia et Rust promettent d'offrir à l'avenir de bien meilleurs compromis entre performance et ergonomie, à la fois pour les physiciens, les informaticiens, et leurs collaborations logicielles.
Face aux défis calculatoires sans précédents auxquels l'IN2P3 fait face, l'exploration et le développement de ces alternatives pourrait donc être une composante importante de la stratégie technologique de long terme de l'Institut.
Si la combinaison de C++ et de Python, bien établie à l'IN2P3, reste appropriée dans certains cas, de nouveaux langages comme Julia et Rust promettent d'offrir à l'avenir de bien meilleurs compromis entre performance et ergonomie, à la fois pour les physiciens, les informaticiens, et leurs collaborations logicielles.
Face aux défis calculatoires sans précédents auxquels l'IN2P3 fait face, l'exploration et le développement de ces alternatives pourrait donc être une composante importante de la stratégie technologique de long terme de l'Institut.