Discussion :

[Mingolito]

La gestion de la mémoire en c++ est sécurisée, il suffit de connaître un minimum son métier en passant par les conteneurs de la stl, par unique_ptr, shared_ptr, et de documenter son code de de faire des test unitaires pour les portions de code critiques. Après, si les développeurs font n'importe quoi, c'est un problème de compétence et de gestion de projet.
Pour le c, c'est pareil; si les développeurs font n'importe quoi et que leurs code a été validé, c'est qu'il y a un problème de management et de personnel.

Si tu pars du fait que les gens sont compétents et font bien leur job alors tu es bien naïf. Voila ce qui se passe quand on fais confiance aux employés : Une panne chez Microsoft provoquée par une mise à jour logicielle de CrowdStrike a des répercussions mondiales.

C'est moins dangereux de faire développer une appli en Rust qu'en C, et c'est plus facile de lire et de débuguer un code en Rust qu'en C, c'est factuel. C'est un facteur critique quand tu as à faire a des gens incompétents et qui n'en ont rien à foutre des conséquences de leur nullité, la nullité des gens ça aussi c'est factuel.

C'est pas parce que tu es compétent et consciencieux que tes collègues le sont. Dans les faits une équipe est constituée de très peu de bons, parfois un seul, ou aucun, de pas mal de médiocres qui font à peu près illusion, et de quelques baltringues, et ces dernier ont un pouvoir de nuisance énorme dans une entreprise, et je rappelle qu'en France à pas le droit de les virer. On ne peut pas non plus mieux payer le seul employé compétent de l'équipe sinon le cout des charges vont exploser et si ça se sait (et ça se saura par ce que le service comptable va bien sur se faire une joie du diffuser cette information confidentielle pendant l'une des innombrables pauses café) les autre baltringues vont faire grève pour demander d'avoir le même salaire que la star de l'équipe.

[d_d_v]

Si tu pars du fait que les gens sont compétents et font bien leur job alors tu es bien naïf. Voila ce qui se passe quand on fais confiance aux employés : Une panne chez Microsoft provoquée par une mise à jour logicielle de CrowdStrike a des répercussions mondiales.

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.
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).

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.

[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 .

[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).