A regarder les offres d'emploi, PYPL me paraît plus proche de la réalité.
Après, de la à dire qu'un de ces classement est pertinent...
Non.
Mais mon argument est différent de la moyenne. Tout le monde dit, "un langage est plus efficace dans un domaine précis". Pour moi, c'est faux.
Moi, je pense plutôt que "un paradigme est plus efficace dans un domaine précis".
Après le paradigme, le point le plus important (selon moi) et presque toujours oublié, les gens citent d'autres arguments, que je trouve invalides, pour comparer les langages:
1: la philosophie du langage: Java et C++ sont très différents, par exemple, l'un activant par défaut la virtualité des méthodes, par exemple, un autre exemple est l'usage de la RAII contre les GC.
Mais un bon développeur C++ ou Java saura contourner les problèmes causés par ce point (les performances d'un code polymorphe sont moindres). Pour le coup, ça n'influence pas tant que ça l'efficacité du langage dans un domaine.
Idem pour le garbage collector ou la RAII de C++: quand on sait s'en servir, on en fait ce qu'on veut (pour la RAII, je suis sûr, pour le GC, je suppose, je ne maîtrise pas assez Java pour l'affirmer catégoriquement).
2: les bibliothèques standard: si on reprends l'exemple C++ vs Java, C++ à une lib standard très limitée, contrairement à Java. Sauf qu'il y a à disposition une quantité non négligeable de lib tierces qui font que l'on pourra faire la même chose.
Il faut les choisir et les installer, c'est vrai, mais Java à le problème inverse: il y a des fonctionnalité de la librairie standard qui sont obsolète, notamment au niveau des framework graphiques (Je me souviens plus du nom... AWT? Ou pas, je sais plus)
Bref, encore une fois, le point n'a pas grande importance pour des langages aussi répandus: la base de code disponible est suffisante.
Pour des langages neufs, ou peu populaires, en revanche, c'est nettement plus problématique, mais dans ce cas, il ne s'agit que d'un investissement au tout début du projet, on code, et on conserve pour usage futur.
Pour reprendre un exemple cité:
J'ai noté un truc tout con: pour programmer un µcontroleur, je peux utiliser C++, C, ASM (l'un des, il n'y en a pas qu'un), et sûrement quelques autres langages.Citation:
Pour ma part je me vois mal programmer un microcontrôleur 8 bits en C#, et je me vois mal programmer un logiciel de gestion sous Windows en C. Si donc on me demande de choisir un "meilleur" langage, encore faut-il me donner le contexte exact et ensuite ne pas reprendre ma réponse dans un tableau "général" qui n'a aucune signification.
Pour programmer un logiciel de gestion, C++ me paraît toujours adapté, bien qu'il va alors y avoir besoin du renfort de SQL.
Qu'est-ce qui fait la force de C++ dans cette histoire? Sans vouloir troller, c'est juste qu'il supporte nativement plusieurs paradigmes:
_ pour le micro-contrôleur , on va utiliser le paradigme impératif (quoique, ça ne me gênerait pas d'utiliser quelques classes, rien que pour la RAII, donc je mixerai les deux)
_ pour le logiciel de gestion, la programmation orientée objet sera un vrai plus, mais il manque le paradigme déclaratif, d'où l'intérêt du SQL.
_ pour écrire une bibliothèque, je vais utiliser le paradigme générique, sûrement combiné à l'objet ou l'impératif, en fonction du rôle de cette lib.
Dans les 3 situations, j'utilise plusieurs paradigmes, au final (dans le 1er cas, les développeurs C ont aussi une approche objet, avec les structures qui ont leurs jeux de fonctions spécialisées pour allouer, nettoyer, bouger, etc).
Après, le multi-paradigme à les défauts de ses avantages: C++ à une courbe d'apprentissage importante pour le maîtriser à 100%, car il faut maîtriser 3 paradigmes (parce que la façon de penser change à chaque fois), au moins.
C, PHP, Java, C#... n'ont pas ce problème, il ont moins de paradigmes à supporter (pas un seul, juste moins... le seul qui n'en a qu'un, c'est le C: PHP à la POO et l'impératif, Java et C# ont la POO et un peu de support du générique, mais moins poussé que mon favoris :P)
Bon, cette courbe vient aussi du fait que le C++ est une évolution d'un langage pour y ajouter l'objet, puis le générique, plutôt qu'avoir créé un langage de 0, conçu les avoir tous les trois.
Le pire, c'est qu'il manque encore plusieurs paradigmes à ce langage:
_ fonctionnel *
_ prog. par contrat *
_ déclaratif
_ ...
*: support partiel en fait, grâce à l'attribut const pour le fonctionnel, et pour la prog par contrat, utiliser const, throw(), static et consort permet d'avoir une bonne indication des pré-conditions, post-conditions et invariants. Mais le langage ne favorise pas tant que ça un bon usage de ces façons de coder. Dommage, pour moi.
HORS SUJET:
Quant au troll classique de la lenteur de C++ contre C, avec des exemples bidon dans ce genre:
write(1,"Hello World", 11); vs std::cout << "Hello World"; il faut se souvenir que les deux sont du code C++ valide. Raté, donc.
A savoir d'ailleurs, que j'utilise toujours abondamment les printf/scanf, et que je n'aime pas du tout les flux, qui, je trouve, rendent le code peu esthétique (lignes super longues, entres autres).
Mais il faut admettre qu'ils ont un grand intérêt quand on en vient à la manipulations de chaînes dont on ne connaît pas la longueur à l'avance. M'enfin, j'avoue, j'ai mon petit ensemble de classes pour gérer la situation, et elles ne sont pas basées sur les flux :aie:
Pour les erreurs de compilations super longues de C++, c'est vrai, mais elles ne sont pas liées au langage lui-même, plutôt au fait que les lib standard de templates ne vérifient pas assez les assertions (voire pas du tout), ce qui engendre des expériences très pénibles.
Bon, sur ce point, il faut aussi admettre que le dernier standard devrait améliorer les choses, au fur et à mesure.
Toujours est-il qu'avec les 3 compilos (g++, clang++ et visual C++ 2008) que j'ai utilisés, la lisibilité de ces erreurs varie très fortement... Et parfois, compiler avec plusieurs compilos le même code permet de cadrer plus vite le problème réel.
