Il ne faut pas chercher loin. Si quelqu’un te dit : "Tu programmes en C++/PHP/etc. Pfff, c’est vraiment stupide..." tu auras des raisons de trouver que ton interlocuteur manque carrément de tact et de subtilité et qu’il te prend pour un con,
Oui mais tu oublies quelque chose de vraiment important : on ne dit pas juste « c'est stupide », mais « c'est stupide : <argument> ». Le fait qu'il y ait une argumentation construite, même si c'est « juste » pour dire « C/C++ est bien meilleur que Perl, car Perl est interprété » explique pourquoi la personne pense que c'est stupide. Et comme il y a un argument, on peut y répondre : « Non ce n'est pas stupide : tout un tas de modules en Perl font appel à des bibliothèques écrites en C ou C++ et sont donc déjà compilées, et du coup je n'ai presque pas d'overhead quand je les utilise. De plus, si j'ai vraiment besoin de plus de performances pour lire ou écrire des fichiers par exemple, Perl a une interface presque directe avec read(2) en utilisant sysread qui enrobe l'interface C. Il y a beaucoup d'autres appels de ce genre. Comme au final les E/S prennent bien plus de temps que le reste du traitement, Perl convient pour 90% des trucs que j'ai à programmer. Et j'aurais mis beaucoup moins de temps à écrire mon programme qu'en C/C++ au final. » Note bien que le mec imaginaire qui dit qu'utiliser Perl en général juste parce qu'il est interprété, a tout simplement fait montre d'ignorance de la réalité du monde de la programmation.
Mais on pourrait inverser les arguments et qui utilise « stupide » :
« Moi j'utilise jamais de langage interprété, car les langages compilés de type C/C++ sont bien plus rapides que Perl ou Python par exemple. » À ceci, quelqu'un pourrait répondre « Ne jamais utiliser un langage interprété juste parce qu'ils sont plus lents en général que les langages compilés est stupide : tout un tas de modules en Perl font appel à des bibliothèques écrites en C ou C++ et sont donc déjà compilées, et du coup je n'ai presque pas d'overhead quand je les utilise. De plus, si j'ai vraiment besoin de plus de performances pour lire ou écrire des fichiers par exemple, Perl a une interface presque directe avec read(2) en utilisant sysread qui enrobe l'interface C. Il y a beaucoup d'autres appels de ce genre. Comme au final les E/S prennent bien plus de temps que le reste du traitement, Perl convient pour 90% des trucs que j'ai à programmer. Et j'aurais mis beaucoup moins de temps à écrire mon programme qu'en C/C++ au final. »
J'ai tendance à considérer qu'on peut utiliser des mots « forts » (« stupide », « idiot », etc.) lorsqu'on a des arguments béton, et que l'argument auquel on répond est simpliste (et souvent fourni avec aplomb). C'est un peu comme l'humour noir : plus l'humour est noir, plus le sujet est difficile, et plus il faut faire preuve de finesse dans la façon dont on l'aborde. Similairement, plus l'argumentation à laquelle on répond est complexe et raisonnée (i.e. il y a un raisonnement logique, qui part peut-être de prémisses fausses, mais qui néanmoins peut être suivi), moins on peut employer de mots « forts » en réponse — ou alors la contre-argumentation qui suit doit être limpide et imparable.
[^] # Re: Une communauté ?
Posté par lasher . En réponse au journal Pourquoi LinuxFr sent-il le vitriol?. Évalué à 4.
Oui mais tu oublies quelque chose de vraiment important : on ne dit pas juste « c'est stupide », mais « c'est stupide : <argument> ». Le fait qu'il y ait une argumentation construite, même si c'est « juste » pour dire « C/C++ est bien meilleur que Perl, car Perl est interprété » explique pourquoi la personne pense que c'est stupide. Et comme il y a un argument, on peut y répondre : « Non ce n'est pas stupide : tout un tas de modules en Perl font appel à des bibliothèques écrites en C ou C++ et sont donc déjà compilées, et du coup je n'ai presque pas d'overhead quand je les utilise. De plus, si j'ai vraiment besoin de plus de performances pour lire ou écrire des fichiers par exemple, Perl a une interface presque directe avec
read(2)en utilisantsysreadqui enrobe l'interface C. Il y a beaucoup d'autres appels de ce genre. Comme au final les E/S prennent bien plus de temps que le reste du traitement, Perl convient pour 90% des trucs que j'ai à programmer. Et j'aurais mis beaucoup moins de temps à écrire mon programme qu'en C/C++ au final. » Note bien que le mec imaginaire qui dit qu'utiliser Perl en général juste parce qu'il est interprété, a tout simplement fait montre d'ignorance de la réalité du monde de la programmation.Mais on pourrait inverser les arguments et qui utilise « stupide » :
« Moi j'utilise jamais de langage interprété, car les langages compilés de type C/C++ sont bien plus rapides que Perl ou Python par exemple. » À ceci, quelqu'un pourrait répondre « Ne jamais utiliser un langage interprété juste parce qu'ils sont plus lents en général que les langages compilés est stupide : tout un tas de modules en Perl font appel à des bibliothèques écrites en C ou C++ et sont donc déjà compilées, et du coup je n'ai presque pas d'overhead quand je les utilise. De plus, si j'ai vraiment besoin de plus de performances pour lire ou écrire des fichiers par exemple, Perl a une interface presque directe avec
read(2)en utilisantsysreadqui enrobe l'interface C. Il y a beaucoup d'autres appels de ce genre. Comme au final les E/S prennent bien plus de temps que le reste du traitement, Perl convient pour 90% des trucs que j'ai à programmer. Et j'aurais mis beaucoup moins de temps à écrire mon programme qu'en C/C++ au final. »J'ai tendance à considérer qu'on peut utiliser des mots « forts » (« stupide », « idiot », etc.) lorsqu'on a des arguments béton, et que l'argument auquel on répond est simpliste (et souvent fourni avec aplomb). C'est un peu comme l'humour noir : plus l'humour est noir, plus le sujet est difficile, et plus il faut faire preuve de finesse dans la façon dont on l'aborde. Similairement, plus l'argumentation à laquelle on répond est complexe et raisonnée (i.e. il y a un raisonnement logique, qui part peut-être de prémisses fausses, mais qui néanmoins peut être suivi), moins on peut employer de mots « forts » en réponse — ou alors la contre-argumentation qui suit doit être limpide et imparable.