Discussion :

[OuftiBoy]

d_d_v

Dans ce cas, les entreprises du logiciel peuvent fermer boutique en France, car à te lire, on a des singes qui programment

Je n'ai pas dis ça, j'ai dis que le niveau de compétence des développeurs d'une équipe n'est pas uniforme. Et Uther a bien raison quand il dit que même le plus doué des développeurs peut aussi commettre des erreurs. Si un langage permet d'éviter des soucis, et si c'est possible (toutes les bases de code n'ont pas été commencées en Rust), ce serait idiot de s'en passer. Surtout en entreprise.

Et les singes n'ont rien à faire ici. Un développeur peut être excellent avec un outil qu'il connait depuis longtemps, mais être un mauvais développeur dans un autre domaine, là où il doit utiliser des langages/concepts/outils qu'il ne maîtrise pas. Un bon dévellopeur Web aura sûrement très difficile de faire du code de bas niveau, et l'inverse est vrai également. On ne peut pas connaître et être à l'aise avec tous les langages et/ou leur librairie.

Donc, si les fuites et dépassement mémoire sont "sécurisés", ça ne va pas empêcher les singes de continuer à faire n'importe quoi, comme utiliser une liste chaînée plutôt qu'une table binaire, et on va se retrouver avec des logiciels 1000 fois plus lents que ce qu'ils devraient être

Je n'ai pas dis ça non plus. Oui, "Rust" permet de sécuriser plus facilement et d'éviter les fuites mémoire. C'est déjà une bonne chose, non ?

Après, employer la bonne structure de donnée, pour un problème donné, ça n'a rien a voir avec le langage. C'est un problème très différent. Et ça suppose de connaître les différentes structures de données, ainsi que leurs avantages et inconvénients.

Que tu fasse un tri de type "Bubble Sort" en 'Rust', en 'C++', en 'C' ou en 'Pascal', la lenteur se fera vite ressentir dès que la taille de ce qu'il faut trier augmentera. Là aussi, c'est un problème de formation.

Les vieux développeurs ont fait leur gammes sur des machines avec peu de ressources, et sont donc sensibilisés à la question. Ce n'est plus forcément le cas des générations suivantes, et c'est bien dommage.

D'ailleurs, de ma longue expérience professionnelle, j'ai en réalité assez peu vu des problèmes de mémoire imputés au code interne. C'était plutôt des fuites mémoires liées à des composants externes, comme des objets COM (Windows), des librairies open ou close source, ou bien une catastrophique gestion du partage de données entre threads, ou bien l'utilisation de conteneurs pas adaptés à l'utilisation souhaitée. On fait quoi dans ce cas ?

Là encore, ce sont des problèmes qui ne sont pas liés à un langage en particulier, même si certains langages rendent plus facile telle ou telle chose.

Si c'est de l'open-source, avec ta compétence, tu peux corriger le soucis, et partager ton savoir et ta correction avec la communauté

Si c'est du close-source, tu peux en avertir le vendeur. Dans ma boîte, on a plusieurs fois eu des problèmes avec (par exemple) du code C mal compilé. On a aussi déjà trouvé des bugs "hardware" dans des µControlleurs, et fait remonter le problème au vendeur. C'est pour ce genre de soucis qu'on est très conservateur, qu'on ne change pas de version de compilateur juste parce qu'elle vient de sortir.

On peut le déplorer, mais c'est ainsi.

@ Pierre Louis Chevalier : D'autant que Python est certes interprété mais quand tu utilises une API pour Python qui est écrite en C, C++ ou Rust à partir de Python du coup le problème de perfs n'existe simplement parfois pas. Donc tu peux avoir à la fois langage facile à utiliser, API riches, et performances.

C'est effectivement une des forces de "Python". Le langage est facilement lisible, avec des types de bases (list, dict) faciles a utiliser. Et la facilité de faire un "Wrapper" autour d'une libraire écrite en C, C++, Rust, permet bien souvent d'obtenir des vitesses plus qu'acceptables. C'est pour son éco-système, et sa communauté que l'on choisit souvent Python. C'est pour ça que pour le moment, j'utilise 'C', j'utiliserai le 'Rust' sur mes nouveaux projets (en évitant soigneusement le C++), et je m'en tiendrais à Python pour le reste.

On ne peut pas être spécialiste de tout

BàV et Peace & Love.

[Pyramidev]

D'ailleurs, de ma longue expérience professionnelle, j'ai en réalité assez peu vu des problèmes de mémoire imputés au code interne. C'était plutôt des fuites mémoires liées à des composants externes, comme des objets COM (Windows), des librairies open ou close source, ou bien une catastrophique gestion du partage de données entre threads, ou bien l'utilisation de conteneurs pas adaptés à l'utilisation souhaitée. On fait quoi dans ce cas ?

Quand on code en Rust, les dépendances externes sont majoritairement codées en Rust, ce qui réduit beacoup les risques de fuites de mémoire et d'accès concurrent.

[OuftiBoy]

Oui, c'est UNE panne, une seule !
Moi, de ce que je vois, c'est qu'une bonne partie du développement logiciel (en France en tout cas) est au niveau de l'amateurisme et du bordélisme. Et pour moi, ce n'est pas forcément à cause du code mais aussi de l'absence de documentation et de specs.

Généralement, la documentation n'est pas à jour avec le logiciel, c'est très chronophage, et ces documentions pourrissent dans les archives. La spécification, si elle est faites en collaboration entre le "chef de projet" et "l'équipe de développement" est un document qui vit, évolue avec les besoins et changements, et peut servir de "documentation".

Pour le code, il faut qu'il soit le plus lisible possible, correctement architecturé, et ne pas utiliser trop d'abstractions sur abstractions. On lit plus souvent un code qu'on ne l'écrit, d'où l'importance d'écrire du code simple et lisible.

En ce moment, je suis sur du code legacy et c'est le pompon: aucune doc technique, aucune commentaire dans le code (aucun !), aucun test unitaire, aucune spec, des classes qui instancient des trucs dans tous les sens, aucune notion de précondition - on fait des "if null" partout. Peut-être que ça peut marcher, mais vu qu'il n'y aucune doc, et aucune volonté de prendre du temps pour documenter, forcément, il y a des risques concernant la mémoire. Mais supposons, qu'il n'y ait que des allocations sécurisées, je suis certain qu'il y aurait d'autres problèmes, car quand c'est le bordel, ça ne peut pas marcher correctement. Bon, j'imagine que tous les développeurs bordéliques vont encore me mettre un pouce rouge (ceux qui ne documentent jamais rien).

On a tous eu un jour ce genre de code legacy de m..... Je compatis, mais le langage n'est pas en cause, c'est plus un soucis de mauvaise architecture et de mauvaises pratiques. Les commentaires ne doivent pas polluer le code. Normalement, le meilleur commentaire, c'est le code lui-même, obtenu en s'en tenant à des principes simples. Je suis un adepte du "Less Is More" et du "Kiss". Je dis souvent que la POO a remplacé le "code spaghetti" par du code "en lasagne". Moi, ma préférence và aux "Ravioles" (modules). Il faut toujour préférer la composition à l'héritage, éviter l'héritage multiple, limiter les couches et les abstractions 'au cas ou', et écrire pour des interfaces, pas pour des types "concrêts".

Pour comparaison, j'ai aussi travaillé un peu dans le secteur industriel: cycle en V, plusieurs dizaines de pages de specs/cahiers des charges, interdiction de l'usage des exceptions, les fonctions utilisateur retournent des codes d'erreur qui sont référencés dans un dossier à part. Un cahier de tests était aussi destiné à l'"opérateur de tests" qui, pour telle action dans telle condition, s'attendait à avoir tel code de retour et pas un autre. Je peux vous dire que ce mode de fonction est bien plus sécurisé, quel que soit le langage.

C'est exactement ce que je dis, ce n'est pas qu'une question de langages. Le langage permet d'éviter certains problèmes, et une certaine rigueur indépendante du langage permet d'éviter d'autres genres de soucis. Il n'y a pas incompatibilité entre les 2 mondes.

Il y a plusieurs "méthodes" (Scrum, Développement en Cycle, etc), mais il faut en choisir une, s'y tenir, mais surtout faciliter le dialogue entre les intervenants au projets, du client au développeur, en passant par toutes les couches (utiles ou pas, on a rarement prise là dessus).

BàT et Peace & Love.

[jpouly]

C'est marrant de voir Fortran a gagné 7 places, comme Rust, et personne n'en parle . Par contre Rust, là c'est la demie-molle assurée

Y aurait il pas du dogme dans l'air

Pour moi, cet indice ne veut pas dire grand chose, mais il a le mérite d'exister. De mon point de vu, il reflète plus les projets du moment.

A ce sujet, je trouve bizarre que Java soit aussi haut, avec la politique commerciale désastreuse d'Oracle (qui demande maintenant aux entreprises de payer le support de la JRE ).

Après le "parc" est tellement important qu'il va falloir du temps pour que les applications écrites en Java soient remplacées un jour.

Si elles le sont, parce que quand on voit que VB est dans le top 10, ça laisse rêveur .

[Pierre Louis Chevalier]

A ce sujet, je trouve bizarre que Java soit aussi haut, avec la politique commerciale désastreuse d'Oracle (qui demande maintenant aux entreprises de payer le support de la JRE ).

En théorie tu n'as pas tord, mais dans la pratique Java évolue bien et il suffit d'utiliser l'Open JDK pour ne rien payer
De toute façon la version Java en prod est toujours loin voir très loin derrière la dernière sortie récente, donc ça pose aucun souci d'utiliser l'Open JDK.

[Uther]

Moi, de ce que je vois, c'est qu'une bonne partie du développement logiciel (en France en tout cas) est au niveau de l'amateurisme et du bordélisme. Et pour moi, ce n'est pas forcément à cause du code mais aussi de l'absence de documentation et de specs.
En ce moment, je suis sur du code legacy et c'est le pompon: aucune doc technique, aucune commentaire dans le code (aucun !), aucun test unitaire, aucune spec, des classes qui instancient des trucs dans tous les sens, aucune notion de précondition - on fait des "if null" partout. Peut-être que ça peut marcher, mais vu qu'il n'y aucune doc, et aucune volonté de prendre du temps pour documenter, forcément, il y a des risques concernant la mémoire. Mais supposons, qu'il n'y ait que des allocations sécurisées, je suis certain qu'il y aurait d'autres problèmes, car quand c'est le bordel, ça ne peut pas marcher correctement.

Alors pour le coup ça n'a rien a voir avec le langage, j'ai vu des projets bien ou mal documentés quelque soient les langages. Je dirais même que dans les langages modernes où les tests unitaires et la documentation du code sont intégrés dans les outils de base, c'est quand même plus naturel de mettre ça bien en place.
De plus les types contenant en eux même pas mal d'information en Rust, notamment sur le traitement des erreurs, je dirais qu'un code dans ce langage t’aurais simplifié les choses, même sans documentation.

Bon, j'imagine que tous les développeurs bordéliques vont encore me mettre un pouce rouge (ceux qui ne documentent jamais rien).

Je ne m'estime pas un développeur bordélique mais je suis content d'avoir un outils qui impose un formalisme minimum, a moi qui sais que je fais parfois des erreurs, et a ceux qui seraient moins compétents, en les aidant à apprendre à bien faire au passage.

C'est marrant de voir Fortran a gagné 7 places, comme Rust, et personne n'en parle . Par contre Rust, là c'est la demie-molle assurée

J'ai beau apprécier le Rust, je n'ai certainement pas une demi-mole. Je trouvais ce classement débile et le trouve toujours autant : le but d'un langage n'est pas de gagner un concours de beauté mais de permettre de produire un programme de la manière la plus efficace possible. Ce classement ne veut rien dire de concret pour l’utilisabilité d'un langage.
Quand bien même le nombre de requêtes sur les moteurs de recherches serait pertinent, classer des langages hors contexte d'utilisation n'a pas de sens. Le Basic, le SQL et le Fortran, n'ont clairement rien a faire ensemble. Même les langage qui peuvent être utilisés dans plusieurs domaines n'ont pas la même pertinence dans tous les domaines.

[Fagus]

Moi, de ce que je vois, c'est qu'une bonne partie du développement logiciel (en France en tout cas) est au niveau de l'amateurisme et du bordélisme. Et pour moi, ce n'est pas forcément à cause du code mais aussi de l'absence de documentation et de specs. [...]
Pour comparaison, j'ai aussi travaillé un peu dans le secteur industriel: cycle en V, plusieurs dizaines de pages de specs/cahiers des charges,[...]

ça a peut être un rapport avec le fait que l'industrie veut un logiciel fiable, alors que les sociétés qui produisent des logiciels ordinaires pour divers clients ont souvent un modèle basé sur la vente de mises à jour ou de nouvelles options (qui ne sont compatibles qu'avec la dernière mise à jour).

Quel est alors l'intérêt d'avoir un logiciel parfait d'emblée ? ça prend du temps d'avoir un produit fiable et de maintenir des docs et de travailler avec les clients pour avoir un produit qui colle à leurs besoins, alors qu'on pourra vendre une mise à jour. Ce modèle n'existe pas qu'en France...

Et puis comme ça a été dit, tout le monde n'est pas super-compétent et même les gens compétents se trompent parfois (cf l'historique des bugs dans le noyau linux). Si le langage incite à utiliser par défaut un système de mémoire qui fuit moins, le bon algorithme de tri, ça diminue le potentiel d'erreurs.

Oui, c'est UNE panne, une seule !

Quand Ariane 5 a explosé à cause d'un integer overflow, c'était l'industrie avec ses précautions d'usage. Sachant qu'en général, il n'y a pas les ressources pour toutes les bonnes pratiques, ce n'est sans doute pas un hasard si la plupart des langages courants pour applications non-critiques gèrent la mémoire.

[floyer]

Enfin, les logiciels buggés ont les supporte car on ne souhaite pas payer leur équivalent fiable à 6 fois le prix (facteur pris de seL4… 4 h.an pour le développement même, 20 h.an supplémentaires pour la preuve formelle).

Maintenant, si des techniques peu onéreuses voire gratuites améliore la fiabilité, il ne faudrait pas s’en priver.

NB : Pour Ariane, une exception à cause d’un integer overflow est typique d’Ada… dans la plupart des autres langages, les entiers s’additionnent sans vérification, pour le meilleur ou pour le pire. (Ok, Python supporte les bignum nativement).