Plus de productivité avec ce langage, mythe ou réalité ?

Bonjour,

J'entends souvent dire que Python est un langage qui divise les temps de développement de 2 à 3 fois (voir même 5 récemment). Pour ma part je pense que Python reste un langage comme un autre, on peut lancer un IDE et coder en Python, créer des frameworks en Python, faire des builds … tout ce qu'il y a déjà dans tous les langages modernes en somme. La seule différence que je vois, c'est le langage lui-même, l'impression qui se dégage en moi est la suivante : je suis plus productif parce que mon code est plus "court". Un algo Python est toujours plus court dans un autre langage… un mythe ou une réalité ?

Objectif : Proposez un algorithme en Python, que vous considérez plus court (et donc plus rapide à produire) que dans tout autre langage (nous éviterons juste les langages Brainf*ck-like).

But : Obtenir un code aussi court (à ~10% près) qu'en Python avec n'importe quel autre langage et prouver si le mythe est bien réel.

Remarque : Tous les langages ne proposent pas les mêmes features (cf: yield/async dans les version récentes de Python par exemple), donc ce qui compte ici c'est d'avoir pour le code Python et l'autre langage la même entrée et la même sortie peu importe l'algorithme utilisé.

Contraintes :

• Le code devra être opérationnel, testé sous un site tel que ideone.com
• Pour Python : Ne pas abuser du fait qu'il soit possible de déclarer ses attributs directement dans le constructeur
• Pour les autres langages : Ne pas mettre plus d'une instruction sur une ligne (cf : instruction1; instruction2; instructionN; // une ligne).

Bonus pour les autres langages :

• Les accolades ne seront pas comptabilisés ({ ou } => -1 ligne)
• Certains langages comme Java ou C# requièrent la création d'au moins une classe pour que le code fonctionne car les fonctions globales n'existent pas (class GlobalClass{ … } => -2 lignes).
• Certains langages requièrent la présence d'une fonction main(). Les lignes de la fonction main() ne seront pas comptabilisées (main(){ ... } => -2 lignes).
• Rendre ses attributs private ou protected n'est pas obligatoire, vous pouvez tout mettre en public comme en Python (we're all consenting adults here ). PS: Vous remarquerez que les bonus pour les autres langages se sont pas si abusés que ça.

Nous pourrions même réaliser des microbenchmarks avec les codes. Vos exemples seront listés ici.

C'est à vous

Pour moi le postulat de base n'est pas bon : la productivité n'est pas directement liée à la taille du code. Un exemple extrême : APL.

Justement j'ai précisé que nous éviterions les langages qui sortent du commun (cf : les Brainf*ck-like).

Même argument avec Perl alors

Deux choses me semble incomparables :

1. La taille de la "bibliothèque standard" : pour prendre des extrèmes, la libc contient le strict nécessaire (et encore) tandis que les import de python contiennent extrêmement beaucoup de choses, probablement codées par des gens compétant de manière efficace, là ou écrire un algo "maison" serait probablement moins optimisé. Du coup, une partie de la taille d'un algo sera réduite parce que la fonction n'est pas à recoder. La remarque tient aussi en C quand on utilise des librairies ultra optimisées telles que numa, BLAS ou ATLAS.
2. Même si nos ordinateurs modernes permettent de moins en moins de faire la différence, on ne compare pas de l'interpreté et du compilé. Et que celui qui parle de compiler python commence par mesurer l'overhead induit par le fait de devoir charger python quand c'est compilé malgré que ça le soit.

Dans tout les cas, ce site va te permettre de répondre à beaucoup de tes questions.

Ne pas abuser du fait qu'il soit possible de déclarer ses attributs directement dans le constructeur

Qu'est-ce que tu veux dire par là ? Ne pas utiliser le langage comme il devrait l'être ?

Mais comme le dit SpaceFox, la longueur du code n'est qu'un détail parmi tous les autres : le tout objet (sans forcément faire de la POO), le typage dynamique, de nombreux types standard, une gestion simple des exceptions, une syntaxe facile à lire et un niveau d'abstraction élevé…

Et quand on combine ce tout avec une très grande bibliothèque standard et une facilité d'interfaçage avec des langages de bas niveau (comme le langage C pour des algorithmes plus critiques en terme de performance), on se retrouve avec un langage polyvalent, rapide à apprendre et surtout facile à manipuler.

C'est ridicule: il est notoire que les codes les plus courts possibles sont très souvent en perl, et personne ne pense pour autant que perl est le langage le plus productif du monde…

Ensuite, ce n'est pas seulement une question d'algorithme, mais surtout l'architecture d'un projet qui va coûter de l'investissement en temps de développement.

Sinon, le plupart de tes bonus sont biaisés justement: chaque langage a ses idiomes… Ne pas faire attention à la const-correcteness en C++, ou la visibilité des attributs/méthodes en Java sont de très mauvaises pratiques.

Pour moi, ce qui fait que python est spécialement productif est son expressivité, le duck-typing (qui peut se retourner assez vite contre le programmeur, ceci dit) et la richesse de sa lib standard. Bien évidement, des features (qui ne sont pas uniques à python mais qui sont indispensables pour la productivité) telle que le ramasse-miettes, les lambdas, les regexp, sont également présentes.

D'ailleurs, si tu veux un bon exemple (AMHA), je te conseille de regarder comment implémenter / utiliser des itérateurs en java et de comparer avec la même chose en python… D'autres exemples qui me viennent: traiter un fichier json/xml en Java, utiliser des regexp en C++, faire de la POO en C, du calcul scientifique en PHP, du traitement de texte en JS, etc. Tu vas vite t'apercevoir que python est ultra-polyvalent et permet de faire tout ça facilement et rapidement.

Après, bien sûr, je ne dis pas que python est adapté à tout.

NB: au passage, on peut mettre plusieurs instructions sur une ligne en python aussi, c'est juste déconseillé.

Le truc qui m'intéresse vachement dans ton sujet serait de prendre un problème commun sorti du quotidien d'un développeur (filtrer une collection de données, manipuler une un fichier, serializer des données, …) et de voir un petit bout de code qui le fait dans tel ou tel langage.

Ça prend 10s à écrire pour un connaisseur du langage, c'est instructif pour les autres et même si ça ne permet pas de mesurer la productivité, ça permet de se dire tout à fait subjectivement "ah tiens c'est élégant" ou "j'aime pas c'est moche".

PS pour les diabétiques : ce genre de petits exemples permettent souvent de mesurer la quantité de sucre syntaxique d'un langage et si le sucre en question est digeste ou pas.

Pour ça il y a Rosetta Code même si souvent leur code est pas super joli (certains de leurs codes OCaml sont horribles si je me souviens bien)

bon, je vais rejoindre les autres sur l'impossibilité de se baser sur le nombre de lignes de code.

La question, ici, pose le concept de "productivité". Donc il faut avoir une définition de ce terme pour pouvoir discuter.

Le nombre de lignes de code par heure n'est pas un indicateur de productivité, car la quantité de lignes produite dépend de moins en moins du temps : les IDE te permettent de faire un "refactoring" complet qui te permet de réduire d'un coup le nombre de lignes de code (extraire une fonction d'un texte sélectionné par exemple, pour éviter les copier/coller) et que d'un autre côté, écrire une ligne de code, en soit c'est très rapide et ça l'est d'autant plus qu'avec les gist et autre pastebin, on a accès à des codes déjà créés en un rien de temps.

Plutôt que de nombre de ligne de code, on va parler de nombre de fonctionnalité à la minute (ou à l'heure).

Et là on va commencer à pouvoir parler car qui dit "fonctionnalité" dit :

• besoin d'une expressivité la plus proche possible de l'esprit humain. "envoyer un mail" est un besoin proche de l'humain. Si un langage arrive à dire de lui même alors il est productif
• à la fin on a un truc utile
• a priori on ne sait pas combien de ligne ça va prendre
• a priori le fonctionnement de la fonctionnalité n'est pas corellé au nombre de lignes, seule la maintenabilité l'est

1
2

mail_a_envoyer = construire_le_mail(from, to, copy, bcc, sujet, texte)
envoyer_le_main(mail_a_envoyer)

En python, cela se fait comment?

1
2
3
4
5
6

from email.mime.text import MIMEText
from smtplib import SMTP

email = MIMEText("Salut la compagnie", Subject="Le sujet", From="me@mail.com", To="your@self.com")
server = SMTP("mx.self.com", 25)
server.sendmail(email.as_string(), email["From"], [email["To"]])

En C# on fait comment?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

using System.Net.Mail;

MailMessage mail = new MailMessage("me@mail.com", "your@self.com");
SmtpClient client = new SmtpClient();
client.Port = 25;
client.DeliveryMethod = SmtpDeliveryMethod.Network;
client.UseDefaultCredentials = false;
client.Host = "mx.self.com";
mail.Subject = "Le sujet";
mail.Body = "Salut la compagnie!";
client.Send(mail);

Sauf que voilà, en C#, la méthode montrée sur SO n'est pas la plus idiomatique, on préfèrera:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

MailMessage mail = new MailMessage("me@mail.com", "your@self.com")
{   
    Subject = "Le sujet",
    Body = "Salut la compagnie!"
};
SmtpClient client = new SmtpClient{
    Port = 25,
    DeliveryMethod, SmtpDeliveryMethod.Network,
    UseDefaultCredentials = false,
    Host = "mx.self.com"
};
client.Send(mail);

Mais du coup, entre le jeu avec intellisense pour trouver les attribut et les imports à boucler, j'ai mis un poil plus de temps qu'avec python, je suis donc moins productif.

Maintenant, réfléchit deux secondes : cet envoie de mail (la fonctionnalité que je viens de développer), elle doit s'ajouter au programme de base d'accord.

Voici comment je fais en python :

1. clic droit, nouveau fichier, mail_utils.py,
2. coller le code, sélectionner,
3. clic droit "extraire une fonction".
4. et là où j'en ai besoin from mail_utils import envoyer_le_mail suivi, à l'endroit idoine de envoyer_le_main(from, to)

si j'étais chiant je dirais que l'objet SMTP doit être utilisé dans un with pour le fermer proprement même en cas d'exception

En C#.

1. click droit dans la vue solution, ajouter une classe, donner un nom à la classe
2. mettre public à la classe
3. créer une méthode, en prenant soin d'y mettre public et static
4. coller le code
5. dans le fichier où j'en ai besoin using monassembly.MaClassDeMail
6. puis là où j'en ai besoin MaClassDeMail.envoyer_le_mail(from, to)

si j'étais chiant je dirais que :

1. mon collègue veut que l'envoi soit une méthode d'instance et donc je vais devoir implémenter toute l'interface Disposable pour que mon collègue puisse faire
2. `using(MaClasseDeMail mail_sender MaClasseDeMail(des_parametres)){mail_sender.send(from, to); / et autres /}

Qui est le plus productif?

J'ai pris la doc Microsoft (qui est sortie en premier lors de ma recherche), le code basique ressemble (ils poussent l'usage de la classe mail) à ça:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

MailMessage mail = new MailMessage("me@mail.com", "your@self.com")
{   
    Subject = "Le sujet",
    Body = "Salut la compagnie!"
};

SmtpClient client = new SmtpClient{
    Port = 25,
    Host = "mx.self.com"
};
client.Send(mail);

Là tu as le même comportement en donnant les mêmes informations. Et du coup on est d'accord que les deux se valent.

Pour le reste de ton message, tu regardes l'efficacité de ton IDE, pas de ton langage. On a ici deux langages aussi moderne l'un que l'autre, aussi mature l'un que l'autre, prévus pour faire globalement la même chose, les deux vont permettre la même productivité. Le reste, ce sont des préférences personnelles et une architecture cible (runtime python d'un coté, runtime .NET de l'autre) et de querelle de clocher.

Bref, oui, le langage qui divise le temps de dev par un entier strictement supérieur à 1 par rapport à un autre langage adapté à la tâche, c'est un mythe infondé.

Bonjour,

Du coup j'ai le sentiment que cette impression de productivité dépend avant tout :

• Des compétences de l'auteur: forcément, on est plus productif si on connaît le langage et ses bibliothèques et si on n'a pas besoin d'aller tout le temps chercher dans la doc
• De la qualité de la doc: si on a besoin d'aller chercher dans la doc, on perdra moins de temps si elle est intuitive, pratique et complète que si c'est un foutoir
• De la richesse de la bibliothèque standard: pour reprendre l'exemple, on fait quoi si il n'y a pas de bibliothèque toute faite pour envoyer un mail ? ON cherche sur Google, sur un gestionnaire de packages, qu'importe. et après vu qu'il existe évidemment des dizaines de bibliothèques plus ou moins connues, de plus ou moins bonne qualité, qui ont toutes plus ou moins de fonctionalités et de limitations, qui font à première vue toutes à peu près la même chose, il faut analyser si ça correspond à ce qu'on cherche vraiment / laquelle est la plus intéressante/adaptée, lire la doc, essayer, tester, confirmer que ça fait bien ce qu'on veut que ça fasse…

Du coup si on se base sur ces critères :

• Python, Java et C# sont des langages très productifs car ils on les trois d'excellentes doc et des bibliothèques standard très complètes. Python et C# peut-être même un peu plus que Java en fait (En Java, je constate qu'à priori il n'y a pas de bibliothèque standard pour parser/générer du JSON, pour le mail et le FTP simplement par exemple, même si ça se trouve en 5 minutes sur Google). Par contre pas de différence vraiment notoire entre les trois.
• PHP ne se défend pas mal non plus si on regarde bien; par contre la doc officielle est quand même beaucoup plus pourrie et on a hérité d'un certain nombre de vieilleries incohérentes. Il est quand même clairement un cran en-dessous.
• A l'opposé le C et le C++ sont totalement inproductifs, car à elles seules les bibliothèques standard respectives ne font pas grand chose; et de plus il n'existe pas de doc officielle et ce qu'on peut trouver est au mieux passablement fragmentaire. Mais ça on savait déjà.

JE ne vais pas juger pour ruby, perl, rust, JavaScript côté serveur via Nodes ou je ne sais quoi d'autre, vu que mes connaissances dans ces langages ou leurs environnements est proche de zéro.

Par contre si on prend en compte les frameworks usuels utilisés conjointement aux langages, i.e. faire comme si le contenu de ces frameworks faisaient partie de la bibliothèque standard, ça change pas mal la donne notamment pour Java et C++. Par exemple si on adjoint Boost et WXWidgets ou QT à C++, on a quelque chose de très complet et de plutôt bien documenté pour faire des applications GUI natives. Pareil pour JavaScript si on adjoint JQuery. Donc à voir aussi où on pose le curseur à ce niveau-là.

EDIT: supprimé mes commentaires à propos de JavaScript côté client. Après relecture ça me paraît HS.

Outre la bibliothèque standard, la qualité et la quantité de bibliothèques tierces (sous licence acceptable pour le projet), ainsi que leur facilité d'intégration, joue énormément sur la productivité d'un langage. Parce que ça permet de se concentrer sur le code propre au projet au lieu de passer du temps à réinventer la roue.

Ça explique pourquoi un langage très récent ou exotique, bien que présentant énormément de qualités intrinsèques, est rarement un bon choix s'il ne dispose pas d'une killer feature qui rend son utilisation pertinente pour le projet.

s'il ne dispose pas d'une killer feature qui rend son utilisation pertinente pour le projet

Ou s'il ne permet pas de tirer profit de bibliothèques existantes

La seule différence que je vois, c'est le langage lui-même, l'impression qui se dégage en moi est la suivante : je suis plus productif parce que mon code est plus "court". Un algo Python est toujours plus court dans un autre langage… un mythe ou une réalité ?

Peut-être que c'est ce que tu penses, mais c'est loin d'en être la philosophie du langage… Il suffit de revoir les quelques principes de base de ce langage (zen de python) pour comprendre qu'en python, la seule vraie envie de l'auteur est de rendre un code extrêmement lisible, au dépend même certaines fois de l'efficacité si le besoin ne s'en fait pas ressentir.

Il ne faut pas oublier qu'à sa première conception, son but était de créer rapidement un code test afin de pouvoir vérifier le fonctionnement d'un algorithme en un temps record, non pas court, mais créer très rapidement grâce à ses modules dont l'intérêt premier est d'éviter de réinventer la roue (tiens un autre principe du langage).

Les accolades ne seront pas comptabilisés ({ ou } => -1 ligne)

Tu ne comptabiliseras pas, dans la même logique, les deux-points concernant le langage python

Certains langages comme Java ou C# requièrent la création d'au moins une classe pour que le code fonctionne car les fonctions globales n'existent pas (class GlobalClass{ … } => -2 lignes). Certains langages requièrent la présence d'une fonction main(). Les lignes de la fonction main() ne seront pas comptabilisées (main(){ … } => -2 lignes).

C'est là où la discussion devrait être centrée, concrètement quand tu écris dans ces langages, tu les tapes vraiment ces lignes, ça allonge le code, ça le rend moins lisible, et des fois tu en vois coder sans indenter.

Un algo Python est toujours plus court ? un autre langage… un mythe ou une réalité ?

C'est souvent réel malgré que se soit un mythe !

Les principes sont les mêmes pour tous, la qualité d'un code ne s'exprime pas par son nombre de lignes…

C'est moi qui ai annoncé le facteur 5 entre Python et C++. Voilà un exemple rigolo de truc facile et lisible à faire en Python et relou dans la plupart des autres langages cités ici :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

import random

class RandomFactory:
    classes = []

    @classmethod
    def register(cls, rdm_cls):
        cls.classes.append(rdm_cls)
        return rdm_cls

    @classmethod
    def build(cls, *args, **kwargs):
        return random.choice(cls.classes)(*args, **kwargs)

Concrètement, cette classe permet d'enregistrer (statiquement) d'autres classes dans une factory particulière en décorant celles-ci avec le décorateur @RandomFactory.register.

Par la suite, en appelant RandomFactory.build(...) on instancie une de ces classes au hasard, avec les mêmes arguments que ceux passés à la méthode build.

Si on a besoin de créer plusieurs factories distinctes il suffit de déclarer une classe fille de cette classe par factory dont on a besoin avec son attribut classes = [] à elle, sans rien faire d'autre.

10 lignes utiles en Python. Ça m'a pris 10 minutes sur mon smartphone.

Pour info, ce genre de chose est tout à fait faisable avec des templates en C++. J'en ai eu besoin pour implémenter un algo de machine learning il y a plusieurs années. J'y avais mis la journée.

Parce que oui, c'est en rendant complètement triviale l'implémentation de ce style de patterns "OVNI" que Python nous fait gagner du temps : c'est facile à faire, donc on le fait, donc tout le reste du code en bénéficie, donc il nous fait gagner encore plus de temps chaque fois qu'on l'utilise.

Edit : remplacement du set par une liste.

Pour compléter mon post précédent : c'est évidemment la nature dynamique du langage qui est le plus gros facteur de gain de temps. Je parle bien de nature dynamique, pas uniquement de typage.

C'est elle qui permet de manipuler des classes dans du code en Python comme on manipule n'importe quoi d'autre. Typiquement si je voulais rendre le pattern de mon précédent post accessible et viable dans un projet, j'aurais simplement à déclarer la création de cette classe dans une fonction mk_random_factory et les gens pourraient l'utiliser dans un projet comme ceci :

1
2
3
4
5
6
7
8
9

MyFactory = mk_random_factory()

@MyFactory.register
class Foo:
    pass

@MyFactory.register
class Bar:
    pass

Et le top là dedans, c'est que maintenant que mon pattern est abstrait derrière une fonction, je peux le réimplementer demain à coups de Cython et/ou d'API C si je m'aperçois qu'il est trop gourmand en CPU (educated remark: dans cet exemple précis, y'a 99% de chances pour que cette factory soit le dernier truc à optimiser dans un projet quelconque) sans risquer de casser le code qui l'utilise. Donc non seulement j'ai gagné du temps ingénieur à l'implémentation, mais en plus je n'en perdrai pas à l'optimisation.

Cette "nature dynamique", c'est fondamentalement d'elle que l'on parle quand on dit qu'en Python "tout est objet". C'est à mes yeux (avec la cohérence et l'esprit pragmatique avec lesquels le langage est designé) la plus grande qualité de Python.

PS : Ça vaut aussi pour Ruby, hein, mais Ruby n'a clairement pas un écosystème aussi riche que son grand frère.

salut Nohar.

c'est moi qui ai mis un -1 sur ton précédent message car je trouve que là on arrive exactement dans les limites à partir desquelles le terme de "productivité" est surtout lié à ton expérience et non au langage lui même.

J'ai eu ce même genre de cas hier : je vais des tests d'intégration sur des corpus documentaires. A priori, tout ce que j'ai à savoir c'est :

• la liste de mes documents
• le résultat attendu
• lancer le test et vérifier le résultat attendu

Quand tu fais du java, ou du php (avec atoum) tu passes alors par des "tests paramétrés". Ce qui est "proche de la manière de penser la chose a priori".

Python lui n'a pas ça car il possède une fonctionnalité qui détonne : la métaprogrammation.

Maintenant que j'ai un peu d'expérience, et avec l'aide de mon collègue, ça a été rapide (~10min) de générer un ensemble de tests sans faire de copier/coller et très facilement évolutif.

Mais est-ce vraiment quelque chose d'évident? il faut être familier avec la notion de métaprogrammation, connaître la syntaxe (qui pour le coup est contrintuitive) puis se lancer dans la rédaction.

Si je n'avais pas cette habitude avec python (et un collègue à côté de moi), les 10minutes auraient été 30 et le facteur aurait presque été inversé par rapport aux tests paramétrés avec JUnit ou les tests avec datafeeder de Atoum (encore plus intuitif pour le coup !)

L'auto-registering est ce qu'elle est et la syntaxe de C++ est lourde mais c'est pas non plus la mort des petits lapins (ce qui prend le plus de place c'est la déclaration des éléments static en fait) :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

#include <random>
#include <set>
#include <boost/non_copyable.hpp>

template<class T>
class RandomFactory : private boost::non_copyable{
  using creator_t = typename T::creator_t;

public:
  RandomFactory() = default;

  void register_function(creator_t creator){
    factories.insert(creator);
  }

  template<class ...Types>
  auto build(Types ...args){
    static std::default_random_engine engine{};
    auto it = factories.begin();
    std::uniform_int_distribution<std::size_t> dist{0, factories.size()-1};
    std::advance(it, dist(engine));
    return (*it)(args...);
  }

  std::set<creator_t> factories;
};

template<class T>
class StaticOne : private boost::non_copyable{
public:
  template<class U> struct AutoRegister : private boost::non_copyable{
    AutoRegister(){ factory().register_function(U::build); }
  };

  static auto& factory(){ 
    static RandomFactory<T> facto;
    return facto; 
  }  
};

class A{
public:
  static A* build(int, char){ return new A{}; }
  using creator_t = decltype(&build);

private:
  static StaticOne<A>::AutoRegister<A> reg;  
};
decltype(A::reg) A::reg;

class B : public A{
public:
  static A* build(int, char){ return new B{}; }

private:
  static StaticOne<A>::AutoRegister<B> reg;  
};
decltype(B::reg) B::reg;

Fais en 30 minutes sachant que je n'utilise plus C++ que pour le plaisir et pas pour de gros projets donc autant dire que je suis loin d'être un expert. Alors bon, on est pas de l'ordre de la journée de travail quand même …

@artragis : Tu n'as pas tort quand tu dis qu'il faut pas mal d'expérience pour penser à ce genre de patterns, mais est-ce que c'est la faute du langage si son utilisateur n'est pas habitué à penser outside of the box ?

Après même si je trouve plutôt injuste de mettre les compétences du développeur là-dedans, il faut également inscrire le langage dans une continuité. Admettons que tu perdes une fois du temps à pondre un register-pattern comme celui de mon exemple, parce que tu ne l'avais jamais vu avant : ce décorateur register je ne l'ai pas montré au hasard, il y a vraiment des tonnes de situatuons où il est applicable et où il peut simplifier la vie des devs, et chaque fois que tu les croiseras, tu y penseras, tu taperas tes 5-6 lignes machinalement pour adapter le pattern à ton cas précis et créer le décorateur qui va bien, et basta, problem solved.

D'une façon générale, la conception (le fait de trouver des designs sexy et intelligents) est affaire d'expérience : tu te creuses une fois la tête quand tu croises une situation inédite, mais tu sauras identifier et répondre à toutes les situations analogues, sans même avoir besoin de réfléchir, tout le reste de ta carrière.

@Ksass`Peuk: à l'époque, on en était pas au même standard du C++ : les typelists il fallait les créer à la main ou utiliser Loki. Mais je suis agréablement surpris de voir que C++ a fait beaucoup de progrès depuis.

Là on commence à comprarer C++ et Python, ce n'est plus la même chose que de comparer Python et C#. Ces deux derniers sont des langages prévus pour tourner sur un framework (Python ou .NET), C++ est fait pour pouvoir s'en passer, et ça implique d'ajouter dans le programme l'information qu'on veut utiliser des mécanismes qu'on utilise tout le temps en python.

Chaque langage fait des choix. Ce choix peut être de toujours procéder avec la méthode A, ou toujours avec la B, ou de demander de préciser la méthode dans le code. Parfois vous faites des programmes qui ont besoin de la méthode A, parfois de la B, parfois des 2, suivant l'endroit ou vos êtes dans le code. Choisissez votre langage en conséquence. Et choisissez votre langage en fonction des personnes qui vont devoir contribuer au projet.