Python ou C++ ?

La question est dans le titre.

a marqué ce sujet comme résolu.

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.

+6 -0

@nohar, Pourquoi prendre le C++ comme exemple ? C'est un peu trop facile. Je pense que les gens savent déjà que c'est un langage complexe dont la librairie standard n'offre pas grand chose.

Pour moi Python reste un langage de haut niveau comme un autre, et je ne vois toujours pas en quoi ce dernier serait plus productif qu'un autre langage (de haut niveau aussi) comme Java ou C# par exemple. J'ai créé un sujet ici qui ne fait pas l'unanimité, pourtant l'idée c'était de faire démontrer aux gens si ce qu'ils disent est vrai, pas qu'ils se contentent d'un "oui" Python est plus productif et on s'en sort très bien avec because I'm Batman ( hein artragis ;) ). Pour le moment je ne vois qu'une question de "goût".

Je suis d'accord avec toi en ce qui concerne certains protocoles idéalistes et strictes enseignés à l'université. Cependant tu prends n'importe quel professeur en informatique (enfin peut-être pas n'importe lequel, celle de mon université en tout cas, dont un qui est aussi ingénieur), il ne sera absolument pas d'accord avec toi concernant ton dernier paragraphe. Ce qu'il te demandera dans ce cas c'est justement d'entrer en contact avec le client pour connaitre la nature/volume/périmètre de ses données (tu insistes jusqu'à les obtenir s'il le faut) et mocker ces données pour évaluer les goulots d'étranglements, pas de te lancer à l'aveugle. Mais sinon je suis d'accord avec toi, dans la vie réel on n'a pas toujours ce qu'il nous faut pour évaluer les besoins…

+0 -0

i, pas qu'ils se contentent d'un "oui" Python est plus productif et on s'en sort très bien avec because I'm Batman ( hein artragis ;) )

Le problème avec ton argumentaire c'est que tu dis "je trouve que" alors que spacefoxn nohar et moi nous donnos des ordres de grandeurs sur des choses quantifiables et quantifiées par notre expérience (bien que je sois le moins expérimenté).

J'ai déjà eu l'occasion de prototyper en C#, notamment des GUI car WPF ou même WinForm sont extrêmement plus simples à manipuler que les autres éditeurs que ça soit en mode "glissé déposé" ou avec un code "à la main". Surtout en terme de prévisibilité.

Pourtant, dès que mon prototype n'a pas besoin d'UI (traitement de données, tâche en background, ou même page web) python me permet de coder 2 à 3 fois plus rapidement qu'en C# (console/ASP.NET MVC selon les besoin). La principale raison : je n'ai casi jamais besoin de configurer quoi que ce soit (bien que MVC soit vraiment bon à ce jeu) et qu'en plus j'ai accès aux virtualenvs (donc je ne vais pas me faire polluer par mes autres projets que je ne polluerai pas non plus).

Et quand je mets ce facteur, je le dis montre en main (avec de vraies expériences à l'appui et des log redmine/jira selon les outils des entreprises pour qui j'ai réalisé les projets pour démontrer mes assertions).

Je ne mettrai pas python partout (d'ailleurs j'ai déjà fait une exception pour les GUI, tu as vu?), mais globalement, on a dans les faits un vrai gain de productivité, et quand on parle à des gens comme nohar ou spacefox qui ont dépassé le stade de débutant (professionnellement parlant, je suis "jeune diplômé") je ne doute pas qu'ils arrivent avec des facteurs encore plus élevés car ils ont en plus de cela des réflex conceptuels qui leur permettent de vraiment utiliser la puissance des langages tels que python pour le prototypage.

Ensuite, oui, ils prennent l'exemple de C++ car le sujet s'appelle… "python ou C++".

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte