Python ou C++ ?

Ou alors c'est le seul qui a l'honnêteté de dire ce qu'il pense plutôt que de suivre une mauvaise mode juste pour faire genre qu'il est à la page.

Si il reste des dev perl vivant quand elle finit par sortir…

C'est vrai qu'il faut bien du courage ! Pour mon cas personnel, je ne suis le développement de Perl6 que depuis 6 mois environ, donc ça va. Larry a annoncé en début d'année qu'une version de développement devrait sortir pour son anniversaire, le 27 septembre. Une version de production devrait quand à elle sortir pour Noël. Au vu des dernières avancées, Perl6 pour Noël, j'y crois ! Sinon, il y a pas mal de nouveautés intéressantes, qui pourrait (je l'espère), redonner un nouveau souffle à Perl.

Ou alors c'est le seul qui a l'honnêteté de dire ce qu'il pense plutôt que de suivre une mauvaise mode juste pour faire genre qu'il est à la page.

En toute subjectivité, je trouve que c'est un très bon langage. Il a les qualités de ses défauts.

Quand je dis "mauvaise mode", c'est celle de recoder des applis C en C++, ou plus largement la mode du "tout objet" qui fait qu'on se traine des tonnes de langages tous plus ou moins identiques qui reflètent des visions légèrement différentes de ce que doit être la POO (sans pour autant en enlever les défauts fondamentaux ).

En toute subjectivité, je trouve que c'est un très bon langage. Il a les qualités de ses défauts.

Après, il faut se remettre dans le contexte. Dans le cadre de développement noyau, tu as besoin d'utiliser des mécanismes bas niveaux à foison (ce qui est plutôt contraire au C++ dit moderne qui tend à éviter ce cas là) mais aussi comme tu n'as pas vraiment de LibC ou Libcpp, tu n'as le droit qu'à un petit sous ensemble du langage. Le C++ serait grandement diminué de ses avantages sur le C d'un point de vue abstraction. En fait le C++ exploitable à ce stade serait assez proche d'un C with class ce qui est plutôt sans intérêt majeur.

Si tu lisais le code du noyau Linux par exemple, tout comme d'un programme C avec GTK+, le C résultat a une approche objet très poussé, c'est vraiment une POO mais à base de C. Ce n'est pas aussi agréable que le C++ pour gérer ce concept mais au moins ça permet d'en tirer les avantages.

Autant je suis d'accord avec toi sur la profusion des langages oo sans réel avantages, autant je le trouve peu adapté au C++. Déjà parce qu'on peut pas dire que ce soit un langage nouveau mais surtout parce que le C++ à assez peu de concurrence à savoir un langage permettant pas mal d.abstraction tout en assurant un contrôle du bas niveau au besoin. Ça le rend compliqué comme langage mais il a peu de concurrence à part rust peut être mais qui n'est pas encore assez mature et réservé à des personnes qui on une certaines compréhension des caractéristiques bas niveau.

J'ai rien contre C++ en particulier (même si je reste persuadé que si un langage est trop difficile à apprendre et surtout à utiliser correctement, c'est qu'il y a un problème de conception quelque part, mais c'est subjectif). Ce sont plutôt les arguments du genre "on recode des applis en C avec C++ histoire d'avoir du vrai objet et profiter des abstractions offertes par le C++" lorsque ça n'a strictement aucun intérêt (comme dans le cas d'un kernel ou de git) juste histoire de dire qu'on fait du C++ et qu'on n'est pas un dinosaure accro au C que je trouve stupides.

J'ai rien contre C++ en particulier (même si je reste persuadé que si un langage est trop difficile à apprendre et surtout à utiliser correctement, c'est qu'il y a un problème de conception quelque part, mais c'est subjectif).

En ce qui me concerne j'ai eu de gros problèmes avec les pointeurs, et ce jusqu'au jour où j'en ai vraiment eu besoin, leur nécessité m'est apparue d'un coup et j'ai fini par comprendre. Par la suite l'OO m'a posé pas mal de problèmes, mais je crois que c'est inhérent au concept (pas tant au langage) qui nécessite pas mal de temps pour être compris.
Après, comme c'est le langage avec lequel j'ai appris à programmer, mon avis est sûrement pas objectif. Son apprentissage me paraît pas aussi pathologique, avec un peu de pratique je pense que ça reste parfaitement abordable (pour le coup je trouve le C plus complexe et plus fourbe, la pente d'apprentissage est plus ardue au début).

En revanche par la suite des langages comme Python m'ont donné pas mal de soucis à cause des références implicites un peu partout, la distinction entre objet mutable et non mutable, etc…
Encore aujourd'hui, je ne comprends ce que je fais en Python que si dans ma tête je m'imagine manipuler un pointeur pour chaque variable, j'ai du mal à me passer de la vision bas-niveau (ce qui est assez paradoxal pour un langage qui se veut haut-niveau).
Et je ne parle pas du fait que Haskell après C++, c'est une vrai torture, mais c'est là un autre débat.

Pardon, j'aurais du préciser. Difficile à apprendre correctement (par rapport à d'autres langages). Autrement dit, sans avoir besoin de pointeurs par exemple. Après, les pointeurs et l'OO, ce sont quand même des concepts relativement simples, c'est pas vraiment ça qui rend l'apprentissage de C++ difficile (tout au plus, c'est juste une question de temps pour les comprendre ou trouver une explication de qualité ). Il y a déjà le biais de "peu de cours de qualité", mais aussi le problème ihnérent au C++ lui même qui propose toujours 15000 façons de coder un truc, dont au minimum 90% seront dégueulasse et inutilement compliquées, avec si possible des pointeurs dans tout les sens (et potentiellement des classes là où il n'y en a pas du tout besoin ). Difficile dans ces conditions d'écrire un code de qualité. À contrario, en Haskell par exemple, tu es un peu obligé par le langage à coder proprement (pas forcément efficacement ni le plus proprement possible, c'est relatif évidemment) parce que faire un truc vraiment sale sera bien plus compliqué pour le débutant qu'en C++.

Personnellement, j'ai arrêté de croire au Perl Noël.

Que le C++ soit globalement très mal enseigné n'est pas un problème du langage, c'est un problème d'évolutions des pratiques des enseignants (et je parle au sens très large, ça inclut les mauvais livres et les mauvais cours sur internet). Par exemple :

Avec un cours correct, les pointeurs, tu en as besoin pour la première fois quand tu utilises le polymorphisme d'inclusion et ce sera avec des pointeurs intelligents. Retire les mots-clés new, delete et la notation [] pour la déclaration de tableaux à un débutants, tu vas voir comme il lui sera bien plus difficile d'écrire du code complètement dégueulasse.

Quant à faire de l'inutilement compliqué, c'est le propre des débutants quel que soit le langage, un débutant procède par tâtonnement et n'ira pas de lui même à la solution la plus simple.

Et C++ n'est pas un langage OO. Truc tout con, si on prend la bibliothèque algorithm qui est certainement la plus utile de toute la SL, c'est 0% OO.

Même sans lib standard, C++ n'est pas du C avec des classes. Il reste le RAII et la programmation générique (qui ne nécessitent pas de bibliothèque standard) et qui sont déjà des features ultra intéressantes même à très bas niveau. Le typage un poil plus fort du C++ sera globalement bien utile même si dans les moments où l'on doit virer le typage à bas niveau on alourdira un peu le code.

Fixed.

Accessoirement, la comparaison est complètement hors de propos. L'un permet d'avoir du contrôle sur ce qu'on fait quand c'est nécessaire, pas l'autre.

On n'a rien sans rien.

Fixed

Non non, je ne parlais pas de performances.

Je sais mais je n'ai pas pu m'empêcher de lâcher un petit troll au passage .

Même sans lib standard, C++ n'est pas du C avec des classes. Il reste le RAII et la programmation générique (qui ne nécessitent pas de bibliothèque standard) et qui sont déjà des features ultra intéressantes même à très bas niveau. Le typage un poil plus fort du C++ sera globalement bien utile même si dans les moments où l'on doit virer le typage à bas niveau on alourdira un peu le code.

Tu n'es quand même pas loin du C with class, tu perds une grosse partie de l'attirail du C++ qui le rend pertinent dans la plupart des cas. Il y a des noyaux en C++ aujourd'hui, mais migrer Linux vers le C++ n'a aucun intérêt car le C employé est très enrichi avec des concepts de POO et que la base de code est délirante. Il aurait fallu faire ça dès le début en fait.

Que le C++ soit globalement très mal enseigné n'est pas un problème du langage

Bah si. Un bon langage ne devrait pas pouvoir être aussi mal enseigné que le C++. Que les cours aient évolué moins vite que le C++ ne devrait même pas être un problème si C++ avait été conçu correctement au départ.

Dès le démarrage de C++, les classes avaient un constructeur et un destructeur, donc dès le démarrage de C++ on pouvait coder sans gérer manuellement la mémoire (et de manière générale toute ressource). On avait un besoin très léger de manipulation de pointeurs. Bref, dès les débuts de C++ on pouvait écrire proprement.

Avoir accès aux moyens d'écrire du code plus bas niveau ne veut pas dire avoir l'obligation de le faire. Le truc c'est que C++ est compatible avec une large partie de C, et encore c'est très utile, mais ça ne veut pas dire qu'il faut le faire quand on en a pas besoin.

Et donc là où l'enseignement a péché c'est qu'il a pris son cours de C (déjà très mal enseigné à l'époque et encore mal enseigné aujourd'hui) et a appelé ça C++ (d'ailleurs il avait déjà pris son cours de Fortran, avait réécrit les exemples et avait appelé ça C). On a présenté les classes comme des structures un peu plus avancées (coucou les cours de n'importe quel autre langage OO qui font la même ânerie). Et on a fait du C avec des classes.

Cela n'a rien à voir avec la conception du langage. Si demain je prends un cours de C, que je traduit en OCaml et que j'appelle ça Ocaml, je pourrais réécrire tous les exemples, ce sera odieusement compliqué et pas adapté.

Le fait qu'il y ait énormément de features dans C++ n'est pas un défaut de conception, c'est simplement l'idée que si tu as besoin d'une forme très précise pour tes données et ton programme, tu dois pouvoir l'écrire.

Avoir accès aux moyens d'écrire du code plus bas niveau ne veut pas dire avoir l'obligation de le faire. Le truc c'est que C++ est compatible avec une large partie de C, et encore c'est très utile, mais ça ne veut pas dire qu'il faut le faire quand on en a pas besoin.

Le fait qu'il y ait énormément de features dans C++ n'est pas un défaut de conception, c'est simplement l'idée que si tu as besoin d'une forme très précise pour tes données et ton programme, tu dois pouvoir l'écrire.

Et donc, on en revient exactement à ce que je disais au départ.

même si je reste persuadé que si un langage est trop difficile à apprendre et surtout à utiliser correctement, c'est qu'il y a un problème de conception quelque part, mais c'est subjectif

Du coup, je comprends pas exactement où tu veux en venir.

Là où je veux en venir c'est qu'il est parfaitement possible d'apprendre et de coder en C++ avec les features de plus haut niveau qui sont plus propres, plus simples à prendre en main et qui permettent d'écrire du code robuste sans se prendre la tête.

On n'est pas obligé de tout montrer de tout le langage dès le début, on peut tout à fait débuter avec C++ et n'apprendre que la partie de C++ qui est facile. Mais ça, c'est à l'enseignement du langage de l'apporter, cette partie simple qui suffit à pas mal de développeurs. Ce n'est pas un défaut de conception de C++ si l'enseignement commence par montrer les fonctionnalités avancées du langage avant de montrer ce qui est facile, c'est un défaut de conception du cours.

Par exemple pas, en C si tu veux écrire du code robuste, il faut d'entrée de jeu montrer le fonctionnement des pointeurs et surtout tout le traitement des erreurs nécessaires pour écrire un programme C correct. Ce qui en fait un langage vraiment difficile pour débuter parce qu'entrée tu attaques ce qui est lourd et compliqué.

Ensuite, quand on maîtrise ce qu'on appris de C++ dans ce qu'il a de plus simple, on peut s'attaquer à la partie compliquée mais qui fait qu'on peut être très précis sur le comportement qu'on attend du programme.

Là où je veux en venir c'est qu'il est parfaitement possible d'apprendre et de coder en C++ avec les features de plus haut niveau qui sont plus propres, plus simples à prendre en main et qui permettent d'écrire du code robuste sans se prendre la tête.

Difficile n'a rien à voir avec impossible… Par ailleurs, pour revenir un peu au point de départ de la discussion, ce qui fait justement que C++ n'est pas si intéressant que ça en remplacement du C pour des projets comme le noyau Linux, c'est bien que les features haut niveau qui font l'intérêt de C++ sont parfaitement inutiles, et donc qu'on est obligé d'utiliser les features bas niveau et se retrouver avec du C with class complètement boiteux. Et c'est bien là qu'est l'erreur de conception de C++ amha. Il est censé pouvoir être prévu pour gérer des codes qui ont besoin d'une faible abstraction, mais en pratique il n'apporte rien de plus au C pour cela. Mais cela n'empêchant pas certain fanboys de vanter les mérites haut niveau de C++ qui sont alors totalement hors sujet, je peux comprendre l'énervement de Linus à l'égard du C++ et de ses devs…

PS:

Ce qui en fait un langage vraiment difficile pour débuter parce qu'entrée tu attaques ce qui est lourd et compliqué.

Faudrait peut être voir aussi à pas me faire dire n'importe quoi au passage… Je n'ai jamais parlé de C ou de C++ comme un premier langage. Les "débutants" dont je parle sont les gens qui apprennent le langage, pas des débutants en programmation (sinon, j'aurais employé le terme "débutant en programmation", pas "débutant en C++").

Même sans bibliothèque standard, C++ n'est pas du C with class. Parce qu'il n'y a pas besoin de bibliothèque standard pour exploiter le RAII (et des ressources gérables par RAII, même à très bas level, il y en a un paquet). Et parce qu'il y a toujours les templates pour avoir un truc un peu plus typé que void* ou des MACROs pour écrire des algos génériques. Bref on a deux abstractions très utiles (abstraction de la gestion des ressources et abstraction des types - sans suppression), même à très bas niveau.

La raison pour laquelle amha, C++ n'est pas encore le choix qu'on peut faire sans trop réfléchir pour le bas niveau c'est l'absence d'ABI standard. Pour le reste, il apporte plus qu'il ne prend.

(Par contre, je ne suis pas convaincu que balancer des -1 sans argumenter soit pertinent).