lothoaheur a écrit :



Un langage simple à prendre en main mais avec des perfs proches du C je prends direct ! Dans le domaine scientifique c’est carrément un plus!



Je passe pas mal de temps à coder, dont une simulation axée sur les performances et je m’arrache souvent les cheveux en C++. Ce langage devient vite ultra complexe dès que l’on s’attarde à “bien coder” et à chercher les performances, sans compter les casse-tête qu’on a à la compilation !







C’est une plaisanterie ?



C/C++ est certainement l’un des langages qui permet de garder un style de programmation le plus propre quand on veut un minimum de performances. Comparativement à d’autres langages, il minimise grandement le coût de l’abstraction.



Quand à la compilation, il n’y a rien de spécialement compliqué en C/C++. Mais comme tout langage, le C/C++ a ses spécificités et son style qui doit être appris et compris.



Pour le reste, quand on veut des performances, on est toujours obligé de sortir des styles de programmation “académiques”. Et cela n’a rien à voir avec le langage de programmation utilisé.



Le “bien coder” appris dans les écoles n’est pas orienté performances…





Un langage qui associerait simplicité et flexibilité de Python avec les performances du C me simplifierait tellement la vie pour ma thèse … Il manque juste les libraries scientifiques au Go …





En même temps, il ne faut pas rêver. Pour avoir des performances, il faut taper à bas niveau. Tout le contraire de ce qu’un langage “simplifié” permet…

gokudomatic a écrit :



Mais c’est là qu’apparaît un paradoxe. Avec un code pragmatique mais sale, tu obtiens une certaine performance. Avec un code académique et lisible, il est possible que tu voies une amélioration possible dans le principe de l’algorithme. Et vu que c’est lisible et propre, la modification peut se faire facilement. Et du coup, il se peut que tu puisses grandement améliorer les performances. Avec un code sale, par contre, vu que c’est peu lisible, c’est aussi difficile de voir un problème dans l’algorithme, et aussi de faire une modification. Du coup, tu es un peu bloqué dans tes choix initiaux.



Maintenant, la différence entre le sale code et le code bas niveau, c’est que le code bas niveau peut être bien pensé. Mais il reste tout aussi peu lisible et coûteux à maintenir/modifier. Tu tombes donc un peu dans la même impasse.







D’une manière générale, quand on écrit du code de bas niveau, c’est parce qu’on écrit un logiciel (ou une portion de code) ou les performances s’avèrent importantes… et que le gain(qui peut s’avérer colossal dans certains cas) en vaut la chandelle.



Mais il va de soi qu’il faut soigneusement étudier l’algorithme au préalable pour être raisonnablement sûr d’avoir épuisé toutes les possibilités de ce côté la.



En pratique il est rare d’utiliser ce style de programmation pour un programme dans son ensemble. D’où l’utilité de langages qui permettent aussi bien de faire du bas niveau que de l’abstraction.

Pazns a écrit :



Merci de ne pas me faire dire ce que je n’ai pas dit :-)

Je suis toujours ravi d’entendre des trucs à propos de Go, mais il faut quand même qu’un tel article ait un intérêt. Ici c’est assez limité, franchement, pour se retrouver dans la ligne éditoriale de NextINpact, vis à vis de ce à quoi on est habitué.

Ceci dit, ce n’est pas la première fois que je sens une certaine orientation dans des articles sur des technos ; je le comprends tout à fait (on a tous des centres d’intérêts, les rédacteurs aussi), cependant j’ai bien le droit de le faire remarquer.



Vous ne vous servez peut-être pas de PHP, mais quand même, faire un article sur cette “mise à jour” de Go aussi long ou presque que la mise à jour majeure PHP7, réellement importante dans l’industrie du web, et de l’informatique en générale à cause de l’utilisation massive de PHP, je trouve ça un peu costaud.

Le jour où Go aura également une màj majeure, je serai ravi de lire un article, peu importe sa longueur.

J’ai pris l’exemple de PHP car il m’avait marqué, mais c’est valable avec d’autres articles dans le coin, j’imagine.

Si on me demande le souci selon moi, je répondrais que l’article sur PHP était trop court. Pas que celui-ci sur Go est trop long.







Je suis d’accord avec toi.



La base d’utilisateurs de ce langage GO doit être relativement faible à l’heure actuelle.

saladiste a écrit :



Si on crée un langage qui se positionne dans le même segment que le C++, on va juste réinventer le C++.







Des langages qui visent d’autres segments, il y en a une foultitude… et c’est en augmentation constante…



Le segment du C/C++ est le seul segment ou le même langage domine depuis aussi longtemps. Et ça n’est visiblement pas prêt de changer.





Les gens à qui le C++ pose problème ont en général des lacunes en théorie informatique et algorithmique, car on peut très bien faire de la POO en C struct obj; obj_alloc(struct obj); obj_init(struct obj, args); ret_t obj_method(obj*, args); etc….



Globalement, la programmation générique en C++ manque encore de souplesse et de puissance et donne un arrière gout de “beta” prometteuse et puissante, mais mal finie…



Et d’une manière générale, beaucoup de spécialistes du C reprochent aux mécanismes du C++ de faire trop de choses dans le dos du programmeur et de laisser trop de liberté au compilateur d’implémenter des choses de manière peu standardisée. Il est vrai que l’esprit du C aurait pu être mieux respecté.

Tout cela sans compter la norme qui n’évolue pas toujours dans le bon sens (voir la déprecation du mot clé “inline”).



Ma conclusions personnelle, c’est que C++ est un langage fabuleux, indispensable et sans concurrence. Mais le concept dispose encore d’une marge de progression non négligeable…



Dommage que tous les créateurs de langages se battent aujourd’hui pour la palme du langage le plus facile, sécurisé, infantilisant et peu performant.