Ce qui m'emmerde le plus dans ce genre de test, c'est que la comparaison des langages se fait par mesure... de vitesse d'exécution. Quelle connerie!
Le temps de développement est à considérer, par exemple: entre passer trois semaines pour écrire un truc super-rapide en assembleur et une minute à faire un shell script, il n'y a pas d'hésitation:
* si c'est pour obtenir un résultat qui ne sert qu'une fois et qui ne prendra que deux minutes à calculer par la voie lente, on choisit le script;
* si c'est une routine qui va être utilisée des millions de fois dans un programme qui va bien servir, on choisit l'assembleur.
La facilité de relecture est aussi à considérer: si vous savez que vous allez traîner un bout de code pendant une bonne décennie, et que les gens qui vont s'en occuper vont tourner (dans une SSII par exemple), il y a quand même un peu intérêt à ce que ce soit facile de s'y mettre, c'est pas grave si du coup il est un peu plus lent à exécuter ou écrire. Ca met dehors les langages genre assembleur, C et C++ (quoiqu'évidemment, avec dix lignes de commentaire pour chaque ligne de code, ça puisse être jouable).
Autre exemple de point à considérer: les garanties. Dans la plupart des langages, faire de la vérification de concordance entre ce que fait le code et ce que veulent les specs est une vraie galère, et basé sur des hacks (les "assertions"). Le seul langage que je connaisse qui fasse ça bien, c'est eiffel, avec ses pre-conditions, post-condition, son invariant. Car il y a des cas où on veut être sûr de son code: avion, pompe médicale, ...
Bref, vouloir "comparer" des langages rien qu'avec des "benchmarks" (et en plus, ici, "micro-" !), c'est d'un ridicule assez puissant.
# Re: Comparaison de neuf langages sur un micro-benchmark
Posté par Snark_Boojum . En réponse à la dépêche Comparaison de neuf langages sur un micro-benchmark. Évalué à 10.
Le temps de développement est à considérer, par exemple: entre passer trois semaines pour écrire un truc super-rapide en assembleur et une minute à faire un shell script, il n'y a pas d'hésitation:
* si c'est pour obtenir un résultat qui ne sert qu'une fois et qui ne prendra que deux minutes à calculer par la voie lente, on choisit le script;
* si c'est une routine qui va être utilisée des millions de fois dans un programme qui va bien servir, on choisit l'assembleur.
La facilité de relecture est aussi à considérer: si vous savez que vous allez traîner un bout de code pendant une bonne décennie, et que les gens qui vont s'en occuper vont tourner (dans une SSII par exemple), il y a quand même un peu intérêt à ce que ce soit facile de s'y mettre, c'est pas grave si du coup il est un peu plus lent à exécuter ou écrire. Ca met dehors les langages genre assembleur, C et C++ (quoiqu'évidemment, avec dix lignes de commentaire pour chaque ligne de code, ça puisse être jouable).
Autre exemple de point à considérer: les garanties. Dans la plupart des langages, faire de la vérification de concordance entre ce que fait le code et ce que veulent les specs est une vraie galère, et basé sur des hacks (les "assertions"). Le seul langage que je connaisse qui fasse ça bien, c'est eiffel, avec ses pre-conditions, post-condition, son invariant. Car il y a des cas où on veut être sûr de son code: avion, pompe médicale, ...
Bref, vouloir "comparer" des langages rien qu'avec des "benchmarks" (et en plus, ici, "micro-" !), c'est d'un ridicule assez puissant.
Snark