Le choix d’un langage de programmation pour un projet se fait rarement sur la base de critères techniques. La plupart du temps ce choix est régit par des critères économiques ou pratiques tel que :
- L’équipe de développement maîtrise déjà tel ou tel langage.
- L’entreprise est sous contrat avec un éditeur de logiciels.
- Le projet doit s’intégrer avec un système d’exploitation ou un logiciel existant.
- Le personnel de maintenance n’est pas capable de supporter un nouvel environnement d’éxécution lors de la mise en production finale.
Idéalement il faut prendre cette décision sur des critères plus technique tel que :
- Temps d’exécution. Le logiciel final sera ainsi plus efficace. Moins de temps CPU siginifie que sur la même machine d’autre programmes peuvent être exécuter en parallèle.
- Le framework de base du langage. Un framework complet et testé évite le développement de fonctionnalités de base, diminuant ainsi les sources d’erreurs et le paradoxe de la « ré-invention de la roue ».
- La taille mémoire utilisée lors de l’exécution. Même sur les machines actuelles un programme prenant une plus petite taille mémoire permet de rentabiliser la plate-forme. Sur un même serveur on pourra faire tourner d’autres applications.
A la lecture de ses quelques points, il semble évident que le choix d’un langage ne peut se faire sans démarches préalables.
Des outils pour faire le bon choix
Le projet shootout hébergé dans l’environnement Alioth supporté par la communauté Debian tente d’amener quelques outils afin de prendre cette décision. Le but est simple : plutôt que de comparer des langages sur des critères politiques, commerciaux ou complètement ésotériques pourquoi ne pas les comparer en fonctionnement ?
L’idée est de comparer chaque langages dans des implémentations d’algorithmes fondamentaux. Parmi les algorithmes choisi on notera quelques classiques tel que :
- Le fractal de Mandelbrot.
- La manipulation d’arbres binaires.
- La lecture d’un ADN et le calcul de son complément inverse.
Faire partie de la compétition
Les résultats de ce projet sont rassemblés dans une interface claire, graphique à l’appui. De plus, si le code proposé pour un des algorithmes dans un langage que vous maîtrisez ne vous plaît pas, postez votre version. Cette compétition inter-language permet de mettre en évidence les défauts et les qualités et surtout de provoquer de longues réflexions…
Les mirobenchmarks à la « shootout » ne reflète qu’une facette d’un langage.
Pour la plus part des applications le temps d’exécution n’est pas critique, la bonne question à se poser est plutôt :
» Quel est le meilleur outil (langage) qui répond à ma problématique ».
De plus ce genre de microbenchmark est à mon sens biaisé car :
* N’utilise pas le langage dans le cadre de son utilisation.
* Des personnes investissent énormément de temps sur certains langages afin de mettre en œuvre toutes les techniques pour grappiller quelques microsecondes. D’autres langages, moins utilisés, ne bénéficient pas d’un tel traitement.
* Aucun des tests n’est axé sur la mémoire, par exemple pour le Java, la JVM prend beaucoup de place, même pour un tout petit programme alors que sa taille est constante et deviendra insignifiante pour un programme plus grand.
Dans le cadre d’une application de calculs bruts ou à forte charge alors oui on peut s’aider de ce genre de benchmark.
Merci pour ce commentaire constructif. Comme spécifié en introduction le choix d’un langage est bien trop souvent biaisé par d’autre critères qui vont au-delà des contraintes techniques. je te rejoins donc sur tous les points énoncés.
Pour ce qui est de grappiller quelques secondes pour mettre son langage favori en tête de classement, j’avoue ne pas y avoir pensé. On devrait ajouté une métrique de qualité de code en terme industriel (lisibilité, réutilisation, etc…)
Dans tous les cas, ce que j’aime bien dans shootout c’est les débats qu’il provoque…