Je ne suis pas partisan pour croire que le temps de développement sera divisé par 5 (!) parce qu'on utilise un langage sans accolade
De façon purement empirique, ces 8 dernières années, entre des projets en C++ et leur version Python, ce facteur 5 est exactement l'ordre de grandeur que j'ai mesuré. Pour plusieurs raisons :
- Le langage est plus simple (ex: y'a pas 5 types de casts ou 4 types de pointeurs différents à manipuler, tout est passé par référence).
- Le caractère dynamique de Python efface la distinction entre programmation et méta-programmation (là où on a 2 syntaxes, 2 paradigmes totalement différents en C++).
- La bibliothèque standard fait tout, et ce qu'elle ne fait pas, les paquets du Pypi le font. Il n'y a rien à récrire 9 fois sur 10, juste à coller les morceaux ensemble.
- Qui dit moins de code à écrire dit moins de code à valider, à corriger, à débugger, à stabiliser (parce que l'écriture du code en lui-même, c'est vraiment peanuts dans le temps de développement).
Avant de se lancer dans un projet de synthèse à l'université, la première chose qu'on nous apprend c'est de réaliser des benchmarks sur les technologies qu'on utilise par rapport au besoin.
Je vais utiliser un argument qui va pas te plaire parce que c'est quelque part un argument d'autorité, mais attends d'avoir quitté l'université et d'avoir bossé sur des projets réels pendant plusieurs années avant de revoir ta position sur cette question. En particulier, va voir un peu dans une startup où tout est à faire pour hier si tu as le temps de séparer le prototype du produit fini en prod (i.e. de récrire la version prod après prototypage), si tu as le temps de faire des benches avant de devoir coder un truc qui marche, etc. Clairement, si tu commences ton projet par des benchmarks de technos, alors c'est que tu as des deadlines vachement souples. La priorité #1 d'un projet (mais c'est vrai qu'à l'université mes cours ne le mentionnaient pas, par contre mes cours de génie logiciel du CNAM quelques temps auparavant, oui), c'est le fonctionnel. Le client, il veut que tu lui montres un truc qui tourne, et qui marche correctement quitte à l'améliorer plus tard. Donc le parti pris le plus pragmatique est d'abord d'assembler des briques logicielles qui font le job, à haut niveau d'abstraction, et de ne penser performances qu'ensuite, parce que, breaking news, l'optimisation, c'est un processus itératif et continu qui ne s'effectue que par mesures et corrections successives.
C'est exactement cela qu'on nous apprend, on nous apprend ne pas choisir une techno "avant de mesurer les performances et déterminer précisément quels sont les goulots d'étranglement" par rapport au besoin.
Alors on t'apprend exactement ce qui est la racine de tous les maux de la terre selon Donald Knuth. Les benchmarks de technos réalisés par des gens qui se touchent la nouille pour savoir si un pgcd se calcule plus vite en C++ ou en Scala sont clairement trop loins de la réalité pour être exploitables dans la vie réelle. Évidemment, le choix d'une techno cohérente a priori est important, tu ne vas pas te lancer dans un projet de calcul massivement parallèle sur GPU en Javascript, mais tu l'as dit toi-même, les performances ça se mesure : comment comptes-tu mesurer les performances de ton soft et déterminer ses goulots d'étranglement sans avoir codé a minima un prototype fonctionnel ?
Les goulots d'étranglement, tu ne peux pas les déterminer par simple calcul : ils dépendent de la techno employée, c'est vrai, mais bien souvent son influence est négligeable par rapport à celle des algorithmes que tu mets en oeuvre, de l'architecture du projet, du système sur lequel ils tournent et de ses caractéristiques, des données que tu traites, de leur source, de leur volume, de leur nature. Autrement dit, parler de performances avant de se lancer dans un projet est à la fois une perte de temps (tu vas perdre du temps à optimiser a priori des sous-systèmes qui n'en ont absolument pas besoin) et prématuré. Le seul bench qui compte dans un projet, c'est celui qui compare des technos sur le métier de ce projet. Autrement dit avant de bencher, faut prototyper, et pour prototyper, cf. plus haut, il faut un langage qui minimise le temps de conception et de développement initial.
). Pour le moment je ne vois qu'une question de "goût".