Python ou C++ ?

Par ailleurs, pour revenir un peu au point de départ de la discussion, ce qui fait justement que C++ n'est pas si intéressant que ça en remplacement du C pour des projets comme le noyau Linux, c'est bien que les features haut niveau qui font l'intérêt de C++ sont parfaitement inutiles, et donc qu'on est obligé d'utiliser les features bas niveau et se retrouver avec du C with class complètement boiteux. Et c'est bien là qu'est l'erreur de conception de C++ amha.

Donc en fait, si j'ai bien compris, d'apres toi, C++ est mal concu parce qu'il n'est pas le meilleur choix de langage pour coder le noyau linux ?
Perso, je trouve que Python c'est mal concu parce que c'est pas le meilleur choix pour faire de l'embarque. Et puis JavaScript aussi parce que c'est pas tip top pour faire du HPC.

Même sans bibliothèque standard, C++ n'est pas du C with class. Parce qu'il n'y a pas besoin de bibliothèque standard pour exploiter le RAII (et des ressources gérables par RAII, même à très bas level, il y en a un paquet). Et parce qu'il y a toujours les templates pour avoir un truc un peu plus typé que void* ou des MACROs pour écrire des algos génériques. Bref on a deux abstractions très utiles (abstraction de la gestion des ressources et abstraction des types - sans suppression), même à très bas niveau.

Cpp = C with class lors de la première décennie d'existence du C++, qui contient quelques fonctionnalités comme le RAII (le nom de l'expression C with class est plutôt trompeur là dessus, il n'y a pas que les classes en plus). Cela reste bien léger par rapport au C et ne justifie clairement pas une réécriture d'un projet très bas niveau vers ce type d'usage du langage. Non pas que c'est inutile, mais le C peut avoir ce genre de mécanismes (plus manuellement, certes) et le gros avantage du C++ réside justement dans des fonctionnalités plus puissantes qui ne sont pas accessibles.

Bref, le C++ aurait été un choix possible pour le noyau Linux, mais dès le départ. Une réécriture n'est pas pertinente, il y a bien plus à perdre qu'à y gagner ainsi.

Réécriture non clairement, ça n'aurait aucun sens de porter 15 millions de lignes vers un autre langage (même si GCC a été porté de C à C++). Si c'est pour introduire des bugs partout c'est pas la peine. D'autre part pour un OS, l'absence d'ABI standard est toujours la barrière la plus problématique.

Mis à part ça, la création d'un nouveau module en C++ n'aurait pas d'impact sur le reste du code du noyau (en tout cas, si c'est vraiment un module).

même si GCC a été porté de C à C++

Ça c'est faux. GCC reste majoritairement un projet C. Un peu de C++ a été ajouté aux endroits où ça a été jugé nécessaire et parce que GCC avait une grosse dette technique qui a justifié une belle réécriture par endroit. Le portage est loin d'être complet.

Mis à part ça, la création d'un nouveau module en C++ n'aurait pas d'impact sur le reste du code du noyau (en tout cas, si c'est vraiment un module).

Ce n'est pas si simple, l'architecture de Linux est très particulier, Linux exploite énormément les limites de GCC pour produire son binaire. Il n'est pas dit que de faire intervenir du C++ au milieu soit si évident que ça, même pour un module (sauf si tu le compiles séparément bien entendu, je parle du cas d'un module intégré à l'environnement de construction de Linux).

Le problème que je vois à tenter ça est que les développeurs noyaux ont une expertise en C qu'ils n'ont probablement pas en C++, inclure du C++ éloignerait le code des habitudes des développeurs C que ce soit vis à vis des compétences mais aussi du modèle canonique du code d'un module par exemple (il y a de nombreux réflexes à changer dans un tel cadre).

De toute façon ça arrivera pas de si tôt. On peut probablement trouver des raisons de l'introduire mais c'est pas pour ça que ça changera.

Donc en fait, si j'ai bien compris, d'apres toi, C++ est mal concu parce qu'il n'est pas le meilleur choix de langage pour coder le noyau linux ?

Tu as oublié de lire mon message avant d'y répondre, je crois.

Les features haut niveau du C++ sont inutiles dans un projet bas niveau, oui. News at 11.

C'est pas parce que c'est une évidence que tout le monde semble en prendre compte dans son raisonnement. Typiquement, ce que je critique dans la suite du message (là aussi, lire avant de répondre, c'est toujours utile). Ça sert à rien de le réécrire une deuxième fois, alors je te demande de te contenter de relire puis de considérer à nouveau l'utilité de ta remarque.

Sur le RAII Renault a déjà répondu. C'est pas assez pour justifier toute cette mode de tout réécrire en C++ lorsqu'il s'agit d'un projet bas niveau.

Peux-tu expliciter les termes en gras pour bien comprendre ?

Par ailleurs, pour revenir un peu au point de départ de la discussion, ce qui fait justement que C++ n'est pas si intéressant que ça en remplacement du C pour des projets comme [exemples d'autres types de projets aussi volumineux avec une dependance enorme au choix technologique initial ?] le noyau Linux, c'est bien que les features haut niveau qui font l'intérêt de C++ [lesquelles ? pourquoi la capacite bas niveau du C++ n'est pas un interet du C++ ?] sont parfaitement inutiles [pourquoi ?], et donc qu'on est obligé d'utiliser les features bas niveau [ pourquoi l'obligation d'utiliser des fonctions bas niveau exclus d'utiliser des fonctionnalites haut niveau ?] et se retrouver avec du C with class complètement boiteux. Et c'est bien là qu'est l'erreur de conception de C++ amha.

Typiquement, l'inference de type avec auto est un mecanisme haut niveau qui pourrait parfaitement etre utilise dans du code utilisant des mecanismes bas niveau egalement. Egalement, l'utilisation de template, mecanisme haut niveau, peut permettre factoriser du code sans que cela remette en cause la necessite ou la possibilite d'avoir du code bas niveau.
Je ne vois pas en quoi le fait de disposer de ces mecanismes haut-niveau est inutile.

J'ai parfaitement lu tes messages et je penses juste que c'est un ramassi d'idees preconcues sur le C++, la (pseudo-)opposition haut / bas niveau et le (pseudo-)debat abstraction / performances.

Le choix de l'exemple de Linux pour justifier que C++ est mal concu n'a ni queue ni tete. Deja parce que c'est probablement le seul exemple de projet aussi gigantesque et tres dependant de son environnement de developpement et des choix technologiques initiaux, eux meme guides par l'epoque. Ensuite parce que ce qui est vrai ici pour le C++ est vrai pour tout langage : il n'y a aucun gain suffisant ou interet a recoder un tel projet dans une toute autre technologiem que ce ASM, Erlang ou Basic.

La verite c'est qu'aujourd'hui, si l'on devait coder un projet comme Linux from scratch, je ne vois aucune contrainte particuliere a l'utilisation du C++ moderne a cette fin. D'une part parce que les nouvelles normes du C++ permettent d'ecrire plus rapidemment du code plus robuste, mais aussi parce qu'il permet d'atteindre les pre-requis techniques d'un tel projet, a savoir gerer le bas-niveau.

C'est marrant parce que les template à la place de void* + MACRO (merci pour le auto, je l'avais oublié), ça fait plusieurs fois que je le cite en plus du RAII mais celui-ci n'est pas relevé comme une feature intéressante.

Sinon, je pense qu'effectivement tout le monde est d'accord pour dire que recoder un projet qui fonctionne dans un autre langage, ça n'a jamais d'intérêt à moins que l'on puisse justifier que le coût de maintenance et d'évolution aura recouvert le coût de re-développement en peu de temps.

Je ne vois pas en quoi le fait de disposer de ces mecanismes haut-niveau est inutile.

Personne n'a dit que les mécanismes de C++ étaient inutiles, même pour un noyau. Seulement que de nombreux mécanismes intéressantes du C++ sont absents à cette échelle et que du coup faire une migration totale du code n'a aps un grand intérêt.

Ensuite parce que ce qui est vrai ici pour le C++ est vrai pour tout langage : il n'y a aucun gain suffisant ou interet a recoder un tel projet dans une toute autre technologiem que ce ASM, Erlang ou Basic.

Ça pourrait si la plu valu était énorme ce qui n'est pas le cas ici.

si l'on devait coder un projet comme Linux from scratch, je ne vois aucune contrainte particuliere a l'utilisation du C++ moderne a cette fin.

Personne n'a dit le contraire sur le fait de partir d'un noyau de 0 en C++. De nombreuses personnes l'ont fait (je crois que Windows est dans ce cas là) et je en trouve pas cette décision stupide techniquement loin de là. On ne parle que dans le cadre d'une réécriture (c'était le sujet de la discussion, non ?).

ça fait plusieurs fois que je le cite en plus du RAII mais celui-ci n'est pas relevé comme une feature intéressante.

Intéressant ne signifie pas que ça vaut le coup de tout recoder. Je n'ai jamais dit que ces mécanismes ne servaient à rien.

Le choix de l'exemple de Linux pour justifier que C++ est mal concu

Quand je lis ce genre de phrases, je me dis que tu as lu en perdant le fil de discussion en route et en ajoutant un a priori sur ce que je dis. C'est tellement à côté de la plaque comme remarque et sans rapport avec ce que je raconte que ça donne vraiment pas envie de répondre et discuter… Fin bref, partons du principe que tu essayes de discuter honnêtement, et je vais me contenter d'ignorer cette partie.

projets comme

CPython ou GSL par exemple. Cela dit, en cherchant sur Google, on peut en trouver à la pelle des gros projets en C qu'il serait parfaitement inutile de réécrire dans un quelconque langage.

features haut niveau qui font l'intérêt de C++ [lesquelles ? pourquoi la capacite bas niveau du C++ n'est pas un interet du C++ ?]

À peu près tout ce qui est apporté par la STL et Boost (ce n'est pas intrinsèque au langage, mais ce sont des bibliothèques indispensables dès que tu dois coder quelque chose qui est un minimum consistant sans avoir besoin de réinventer la roue), plus intrinsèquement RAII, RTTI, la gestion des exceptions.

Les features haut niveau sont le principal avantage de C++ par rapport à C. Les features bas niveau sont déjà supportées par C, si c'est pour utiliser les features bas niveau, ça ne sert à rien d'utiliser du C++, on fera juste du C with class (avec un peu de RAII éventuellement…).

sont parfaitement inutiles [pourquoi ?]

Voir la citation de Gwenn:

Les features haut niveau du C++ sont inutiles dans un projet bas niveau, oui. News at 11.

et donc qu'on est obligé d'utiliser les features bas niveau [ pourquoi l'obligation d'utiliser des fonctions bas niveau exclus d'utiliser des fonctionnalites haut niveau ?]

Je sais pas comment tu arrives à me faire dire ce qu'il y a dans tes crochets quand ce que je dis est le raisonement "réciproque" : les fonctionnalités haut niveau sont inutilisables, donc (je l'ai utilisé pourtant ce mot) on est obligé de se rabattre sur les fonctionnalités bas niveau.

La verite c'est qu'aujourd'hui, si l'on devait coder un projet comme Linux from scratch, je ne vois aucune contrainte particuliere a l'utilisation du C++ moderne a cette fin.

Je ne crois pas avoir dit nulle part le contraire. Cela dit, je ne vois aucune contrainte à utiliser le C non plus. Par contre, une contrainte possible au C++ est peut être le fait qu'il y a peu de dev C++ compétents (entendre qui codent effectivement en C++ moderne (C++14 étant à peine supporté par les compilos, il me semble raisonnable de penser que le nombre de gens qui y sont formé correctement est relativement faible) mais qui sont tout de même capable de gérer les problématiques de bas niveau lorsque c'est nécessaire) comparativement au C ?

Franchement, si quand j'écris du C je pouvais juste remplacer mes goto par du RAII, je serai sur un petit nuage. Allez, soyons fou, même un finally m'irait.

Pour les justification du C++ dans des mondes hypers restreints, vous pouvez aussi chercher les articles écrits par Dan Saks (pour embedded.com, IIRC). Même, l'encapsulation est intéressante (même si on peut y parvenir avec de l'abstraction/data-hiding (cf FILE*)

En ce qui me concerne j'ai appris les langages que j'ai le plus pratiqué depuis 2008 dans l'ordre suivant : C++ (3 ans), C (1 an), PHP (3 ans), Java (3-4 ans), JavaScript (1 an) et Python (1 mois)

PS: J'ai omis de préciser d'autres langages comme SQL, PL/pgSQL, PL/SQL, T-SQL car on s'éloigne un peu des langages les plus "communs", ou C#, VB.NET ou COBOL car je n'ai pas passé plus d'un mois dessus.

Si je pouvais te conseiller un premier langage parmi ceux je t'ai cité, je dirais Python.

Ce langage est parfait pour le débutant :

• Environnement très simple à mettre en place (Installation et la pratique via la console Python).
• Du code bien indenté (cf: propre) et pensé pour faire du code "plus court" que ses concurrents grâce à l'absence d'accolades.
• La non-obligation de faire de la POO (programmation orienté objet).
• Absence de "pointeur" explicite et système de ramasse-miette intégré pour une gestion automatique de la mémoire.

Sans oublier sa popularité :

• Grande communauté (qui apprécie fortement son langage)
• Bonne documentation officielle, nombreux tutoriels sur internet
• Nombreux projets en Python (ne serait-ce que pour citer les API Google ou le dév Raspberry Pi)
• Intégré à l'éducation nationale, ce qui appuie encore plus la popularité du langage en France
• Python est un "+" pour ton profil professionnel (ps: c'est qui m'a poussé à me lancer dans l'apprentissage de ce langage)

Et dernière chose concernant les jeux vidéos : Si tu veux faire un jeu simple, pas de souci, j'ai un ami qui m'a montré un jeu qu'il a créé grâce à un binding SFML, on peut faire de belles choses.

En ce qui me concerne je n'aime pas particulièrement Python :

• Du fait qu'il ne soit pas explicitement typé (même si un PEP récent intègre l'utilisation d'annotation), ou le fait qu'on puisse changer l'affinité d'une variable quand on veut.
• Ayant déjà pas mal de connaissance avec les différents langages que j'ai cité, j'ai eu l'impression de perdre mon temps à réapprendre la même chose (tu prends un langage, tu changes le nom des méthodes et tu ingurgites en fermant le nez et en ouvrant grand la bouche). Je dirais que ce point n'est à prendre en compte que si on connait déjà au moins 5 langages.
• Performances brutes : Python n'est pas un langage aussi "puissant" qu'on le prétend (ça je le lis n'importe où !), j'ai vu de nombreux benchmark classant ce dernier en bas de la liste avec PHP (exemple de benchmark). Donc quand je vois certaines personnes dire que C ou C++ complète Python pour les performances ou qu'on préfère utiliser un "for in range" au lieu d'un "while" ça me choque un peu.

Ayant déjà pas mal de connaissance avec les différents langages que j'ai cité, j'ai eu l'impression de perdre mon temps à réapprendre la même chose (tu prends un langage, tu changes le nom des méthodes et tu ingurgites en fermant le nez et en ouvrant grand la bouche). Je dirais que ce point n'est à prendre en compte que si on connait déjà au moins 5 langages.

Mouais, pour moi le langage c'est autre chose que d'apprendre seulement des noms de fonctions de la bibliothèque standard qui diffèrent. C'est souvent une autre manière d’architecturer l'ensemble.

Performances brutes : Python n'est pas un langage aussi "puissant" qu'on le prétend (ça je le lis n'importe où !), j'ai vu de nombreux benchmark classant ce dernier en bas de la liste avec PHP (exemple de benchmark). Donc quand je vois certaines personnes dire que C ou C++ complète Python pour les performances ou qu'on préfère utiliser un "for in range" au lieu d'un "while" ça me choque un peu.

Pour moi la puissance d'un langage n'a rien à voir avec ses performances, mais plutôt sur la facilité d'expression et la flexibilité dans les différentes situations où on souhaite l’utiliser.

Je sais bien qu'apprendre un nouveau langage ne se résume pas juste à remplacer des noms de fonctions d'une API, cependant c'est l'une des parties où on passe du temps. Par exemple en informatique on utilise souvent le mot-clé "trim" pour enlever des espaces à gauche et à droite d'une chaine, en Python son nom est "strip"… et parmi toutes les autres syntaxe du langage, malgré le fait que je ne me suis pas encore lancé dans yield ou async/await, je n'ai vu aucun concept "différent" ou "mieux".

Et bien justement pour avoir tâté du JNI en Java, je trouve que le fait d'intégrer du code bas niveau dans un langage haut niveau fait qu'on perd au niveau de cette facilité d'expression/flexibilité. Je veux bien comprendre qu'on mette en place ce type de wrapper pour des appels systèmes (accès aux registres du matériel etc), mais dès que ça touche au niveau performance j'ai juste envie de dire erreur stratégique, change de langage.

Bonjour à tous,

J'ai commencé la programmation il y a déjà longtemps, mais je n'ai que très récemment osé plonger dans python sérieusement en commençant un premier projet il y a 2 semaines à peine. J'ai fait et je fais toujours du Java, du C++, du PHP, du JavaScript, du SQL, du lua…

J'ai commencé le C++ en 1999 et à l'époque je ne comprenais rien aux pointeurs (bon j'ai une excuse, ja'vais 11 ans). Eh oui, encore un bouqin où les pointeurs étaient avant le chapitre 10. Ensuite je suis surtout passé à Java (dès 2001, coucou les applets), puis JavaScript (dès 2003, j'ai vu les débuts d'AJAX) ensuite PHP (dès 2005) parce que c'était clairement plus facile. Aujourd'hui je suis pas mal revenu à C++ quand je ne fais pas du web parce que, pour certaines choses en tout cas, les inconvénients de Java me pesaient.

En python, cette obligation d'indenter dès le départ un code m'a longtemps rebuté. Personnellement je trouve que la présentation du code devrait toujours être gérée automatiquement sans qu'on ait à s'en soucier. Or en python c'est impossible, et ça me gêne de devoir penser à indenter correctement mon code en même temps que je réfléchis à ce qu'il doit faire (le code doit d'abord marcher correctement avant d'être beau à voir).

Par contre, passé cet apriori négatif, je dois dire que je suis impressionné. J'ai codé en quelques jours un début d'application qui m'aurait sûrement pris la tête pendant 5 fois plus de temps en C++. Et je me dis que j'ai été con de m'y refuser pendant si longtemps juste à cause, finalement, d'un petit détail. En tout cas, j'accroche totalement aux listes/dictionnaires/ensembles par compréhension, et par extension aux générateurs. Parser un fichier ini en 2 lignes, on a rarement fait mieux… J'aime bien aussi la distinction string vs bytes. Les mecs qui ont conçu python 3 ont tout compris aux problèmes récurrents des encodages qui empoisonnent la vie de pas mal de gens. J'accroche moins au duck typing, mais bon, ça, c'est un peu comme en PHP donc je ne me sens pas trop désorienté, à ceci près qu'en python c'est quand même nettement mieux pensé (on peut faire moins de choses et c'est sans doute mieux, on peut surtout faire moins n'importe quoi). La seule chose qui m'a un peu surpris en la matière, c'est la non conversion implicite vers str (p.ex. "a"+1 qui déclenche une erreur).

Un truc chiant quand on aborde un nouveau langage alors qu'on en connaît déjà plusieurs autres, c'est de parcourir la doc pour voir ce que la bibliothèque standard propose. ET effectivement, le coup de trim renommé en strip parmi d'autres m'a fait chercher inutilement pendant un certain temps, un moment donné je me suis même demandé comment était-ce possible qu'ils l'aient oublié. Heureusement, la liste des modules sur docs.python.org est pas mal bien faite, et help et dir dans l'interpréteur rendent bien service.

Un avantage certain du pyton quand on débute avec, c'est qu'on a déjà plein de choses inclus dans la boîte, alors qu'en C++ on doit chercher une lib externe pour à peu près tout. Tu veux parser/générer du XML ou du JSON ? En C++, galère,; compresser/décompresser du zip ? pareil; requêter un webservice ou communiquer en réseau avec des protocoles de couche 4-7; encore mieux… il y a toujours forcément 36000 libs qui existent qui font toutes à peu près pareil mais pas exactement et jamais tout à fait comme tu veux.

En bonus, j'ai l'impression que le python est plus en vogue sur le marché du travail que le C++ en ce moment. Donc moi aussi je voterais pour que tu commences par python. Tu disais que tu voulais faire des jeux. Eh bien, en python tu as pygame, un port de la SDL, c'est déjà pas mal pour commencer il me semble; à moins de vouloir faire un jeu 3D tu peux déjà t'amuser un moment.

Donc utiliser un langage qui divise par 5 le temps de développement initial, avant de mesurer les performances et déterminer précisément quels sont les goulots d'étranglement est une erreur stratégique ?

C'est parler des "performances brutes" de Python, l'erreur, à mon avis.

• D'abord parce que dans la plupart des programmes, seuls 10% du code vont généralement être réellement critiques en termes de performances, et que sacrifier l'expressivité, la souplesse et la maintenabilité de toute une application pour ces 10% de code, en codant l'appli complète dans un langage natif et complexe comme C++ est une perte sèche de temps.
• Ensuite parce que je ne connais pas d'application en Python qui n'utilise aucune bibliothèque, et qu'il suffit la plupart du temps d'importer la bonne bibliothèque (binding à une lib native) pour bénéficier à la fois du niveau d'abstraction et d'expressivité de Python, et des performances qui vont bien sur la partie métier du code.

Donc quand je vois certaines personnes dire que C ou C++ complète Python pour les performances ou qu'on préfère utiliser un "for in range" au lieu d'un "while" ça me choque un peu.

La première partie de la phrase est pourtant la stricte vérité. Se laisser la possibilité d'accélérer une application en réimplémentant un de ses modules métier en C ou C++ (ou avec Cython), c'est le chemin de moindre coût en termes de temps ingénieur. Et encore, à titre personnel, je n'ai que très rarement eu besoin d'aller jusque là dans mon boulot.

La seconde partie (for vs. while) n'a presque rien à voir avec les performances. Il s'agit d'idiomatismes : itérer sur une séquence, c'est avec un for et basta. La seule considération sur les performances concernant les boucles est que l'on peut gagner pas mal de temps en utilisant une list/dict/set-comprehension ou une generator expression quand elle suffit à exprimer une boucle explicite, parce que l'itération dans ce cas n'est pas exprimée en bytecode Python mais réalisée nativement dans l'interpréteur, qui peut se permettre de prendre des raccourcis.

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. Le développement "initial" ce n'est rien, ce qui prend du temps c'est la reprise d'un projet (et encore plus si c'est celui de quelqu'un d'autre), le gain de temps c'est quand ton IDE t'indique le maximum d'erreur avant de lancer une compilation. Ouvre ton IDE pour Java/C#, même si ton projet est (malheureusement) peu documenté, tu vas t'y retrouver car tu sais ce que tu manipules, en sera-t-il de même avec un projet JavaScript, PHP, Python etc ? 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. 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. Tu ne peux pas débarquer et dire je vais utiliser <insérer nom du langage ici> parce que j'aime bien et s'il y a un problème au niveau des perfs on s'arrangera avec le gars qui se débrouille bien avec les pointeurs pour nous pondre un ptit code en C.

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.

outre l'exagération évidente de la division par 5 (on est plutôt dans une division par deux, parfois trois) ce n'est clairement pas les accolades qui sont en jeu.

L'API standard, la rapidité de prototypage, la souplesse des outils (environnement virtuels par exemple), le gestionnaire de paquage (que le cpp est un des rares langages à ne pas avoir…) la conception des différentes API (consistance, expressivité…) ainsi que tout un tas de sucre syntaxiques qui permettent un développement sécurisé (ressources, structures de données maîtrisées, API d'asynchronisme…).

n. Ouvre ton IDE pour Java/C#, même si ton projet est (malheureusement) peu documenté, tu vas t'y retrouver car tu sais ce que tu manipules, en sera-t-il de même avec un projet JavaScript, PHP, Python etc ?

oui

. Tu ne peux pas débarquer et dire je vais utiliser <insérer nom du langage ici> parce que j'aime bien et s'il y a un problème au niveau des perfs on s'arrangera avec le gars qui se débrouille bien avec les pointeurs pour nous pondre un ptit code en C.

Bah en fait… si. C'est exactement ce qu'il y a de mieux à faire. Sauf qu'au lieu de parler du "goût" on préfèrera parler des compétences de l'équipe.

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.