Bon, autant je suis un grand grand fan du langage C, mais dire que « tout ce que Python fait, je sais le faire "mieux" et plus maintenable pour le futur en C/C++ » me semble très présomptueux.
Même en utilisant les bibliothèques C qui vont bien, il faut bien avouer que les langage dits de 4è génération (Python, Ruby, Perl, et dans une moindre mesure - car orienté web uniquement - PHP) permettent de développer bien plus rapidement quelque chose de fonctionnel qu'en C. De plus très souvent, si on veut tout refaire « depuis zéro » (parce qu'on aime réinventer la roue, parce qu'on a le syndrôme du « Not Invented Here », ou tout bêtement parce qu'une vraie bonne raison le requiert), ces langages proposent nativement tout un tas de trucs (tables de hachage, augmentation dynamique et implicite de la taille des tableaux, etc). En C, je n'en parle même pas. En C++, certes, il y a la STL, mais il y a tout de même de gros écueils à éviter, et des subtilités parfois très euh ... subtiles. Un exemple tout bête :
for (i = <un_certain_type_d_iterateur;<condition>; i++) {
// quelque chose à faire
}
Bon, ben si l'opérateur '++' a été surchargé, on se retrouve avec deux évaluations de l'objet i, ce qui d'un point de vue perfs est pas génial. On me dira que oui mais bon, quand on surcharge un opérateur, il faut faire gaffe, mais c'est un exemple relativement simple de pourquoi C++ est loin d'être le meilleur langage « universel ». Je préfère 100 fois un programme Perl ou Python. S'il y a besoin d'aller vite, évidemment, alors il faut commencer à fureter du côté de C ou C++. Et même là, parfois on a des surprises.
Sinon, le fait est que malgré l'ascension de Python et Ruby (et avant eux de PHP), Perl reste encore très utilisé (peut-être plus par les admins que par des dévs purs et durs, je te l'accorde). Perl date de 1987 d'après wikipedia. Il a été utilisé (et l'est encore) depuis vingt ans, je trouve que c'est déjà pas mal du tout. Certes, C est plus vieux, mais il lui manque une bibliothèque standard aussi fournie que celle de Java ou au moins C++ (oui, il y a la glibc, mais tout le monde ne veut/peut pas l'utiliser -- vu que c'est pas standard, justement).
Enfin, si on parle de C++, le principal problème à mon avis est le fait que malgré l'existence d'une norme, l'implémentation de celle-ci est partielle au mieux [1] (je pense à C++98 notamment). Je ne parle même pas de la compatibilité entre compilateurs, ou des classes qui existent désormais dans la STL, mais qui sont redondantes avec celles mises au point par de gros frameworks (genre Qt) à l'époque où aucun standard n'existait, mais évidemment avec des différences de comportement, d'API, etc.
Tout ça pour dire quoi ? Affirmer qu'on fait mieux et plus maintenable que Python (ou un langage du genre) peut être vrai, mais je doute très fortement que ce soit réalisé dans les mêmes délais (après, faire du code crade, quel que soit le langage, c'est possible, bien sûr).
[1] Et même en C, C99 n'est pas implémenté intégralement, même par GCC, à cause de fonctionnalités « avancées » voulues par le comité de normalisation mais qui sont fichtrement difficiles à mettre en oeuvre.
[^] # Re: Grandiose
Posté par lasher . En réponse au journal Linuxfr en J2EE. Évalué à 4.
Même en utilisant les bibliothèques C qui vont bien, il faut bien avouer que les langage dits de 4è génération (Python, Ruby, Perl, et dans une moindre mesure - car orienté web uniquement - PHP) permettent de développer bien plus rapidement quelque chose de fonctionnel qu'en C. De plus très souvent, si on veut tout refaire « depuis zéro » (parce qu'on aime réinventer la roue, parce qu'on a le syndrôme du « Not Invented Here », ou tout bêtement parce qu'une vraie bonne raison le requiert), ces langages proposent nativement tout un tas de trucs (tables de hachage, augmentation dynamique et implicite de la taille des tableaux, etc). En C, je n'en parle même pas. En C++, certes, il y a la STL, mais il y a tout de même de gros écueils à éviter, et des subtilités parfois très euh ... subtiles. Un exemple tout bête :
for (i = <un_certain_type_d_iterateur;<condition>; i++) {
// quelque chose à faire
}
Bon, ben si l'opérateur '++' a été surchargé, on se retrouve avec deux évaluations de l'objet i, ce qui d'un point de vue perfs est pas génial. On me dira que oui mais bon, quand on surcharge un opérateur, il faut faire gaffe, mais c'est un exemple relativement simple de pourquoi C++ est loin d'être le meilleur langage « universel ». Je préfère 100 fois un programme Perl ou Python. S'il y a besoin d'aller vite, évidemment, alors il faut commencer à fureter du côté de C ou C++. Et même là, parfois on a des surprises.
Sinon, le fait est que malgré l'ascension de Python et Ruby (et avant eux de PHP), Perl reste encore très utilisé (peut-être plus par les admins que par des dévs purs et durs, je te l'accorde). Perl date de 1987 d'après wikipedia. Il a été utilisé (et l'est encore) depuis vingt ans, je trouve que c'est déjà pas mal du tout. Certes, C est plus vieux, mais il lui manque une bibliothèque standard aussi fournie que celle de Java ou au moins C++ (oui, il y a la glibc, mais tout le monde ne veut/peut pas l'utiliser -- vu que c'est pas standard, justement).
Enfin, si on parle de C++, le principal problème à mon avis est le fait que malgré l'existence d'une norme, l'implémentation de celle-ci est partielle au mieux [1] (je pense à C++98 notamment). Je ne parle même pas de la compatibilité entre compilateurs, ou des classes qui existent désormais dans la STL, mais qui sont redondantes avec celles mises au point par de gros frameworks (genre Qt) à l'époque où aucun standard n'existait, mais évidemment avec des différences de comportement, d'API, etc.
Tout ça pour dire quoi ? Affirmer qu'on fait mieux et plus maintenable que Python (ou un langage du genre) peut être vrai, mais je doute très fortement que ce soit réalisé dans les mêmes délais (après, faire du code crade, quel que soit le langage, c'est possible, bien sûr).
[1] Et même en C, C99 n'est pas implémenté intégralement, même par GCC, à cause de fonctionnalités « avancées » voulues par le comité de normalisation mais qui sont fichtrement difficiles à mettre en oeuvre.