[Index Software] Coin des développeurs :]

[Ixy]

On est bien d'accord mais je veux dire que parfois un code ne fonctionne pas, on le refait à l'identique (on pense), et il marche. C'est ce que veut dire l'image.

[Tugdual]

En informatique, on ne fait que considérer que ça marche tant que l'on a pas trouvé de bugs.

Ça quand même dépend du domaine, des moyens
qu'on veut se donner, des outils qu'on utilise ...

Dans certains domaines (aérospatial, aéronautique ...)
les leçons (fort chères) du passé ont été tirées, et
aujourd'hui les bugs (erreurs de programmation) ont
disparu, la programmation étant quasi automatisée
à partir des fonctionnalités soigneusement décrites ...

[Ixy]

Tout à fait, c'était en fait le sens de mon message.

[Bubu]

En aéronautique, le code ne suffit pas. S'il n'est pas accompagné de sa preuve, il est inutilisable.

Dans les jeux c'est plus souple. Le back culling est dans le mauvais sens? Bof. Je recompile en changeant le signe du produit vectoriel.
Et on est prêt à toutes les approximations si ça va plus vite.

[Tugdual]

En aéronautique, le code ne suffit pas. S'il n'est pas accompagné de sa preuve, il est inutilisable.

En simplifiant à peine, le code est de fait prouvé
de par sa génération automatique par une chaine
d'outils eux-mêmes prouvés, des spécifications
jusqu'au compilateur final (ou aux circuits) ...

[Benoit]

En plus en logiciel aero, meme s'il y avait des bugs un passager aurait le temps de recompiler le code sur son portable avant qu'il n'arrive.

Ceci etait un troll gratuit sur la perf des hardware embarques.

[Manichéenne]

En informatique, on ne fait que considérer que ça marche tant que l'on a pas trouvé de bugs.

Encore un cas où je vois que je ne suis pas du tout dans le même domaine que vous.
Je considère qu'il y a des bugs, toujours et sur tous les programmes sur lesquels je travaille. Simplement, les plus bloquants restent cachés en attendant le cas limite qu'on n'a pas prévu ou le petit effet de bord d'une modif qui n'avait rien à voir... Les autres bugs sont déjà là mais tout le monde s'en fout. J'aime bien regarder les fichiers de log des applications et réduire le nombre d'erreurs critiques, généralement de quelques milliers par jour.

[Tugdual]

Si ça peut te rassurer, là où j'ai bossé c'était comme toi ...

J'ai l'impression qu'une grande partie des logiciels sont encore
créés à l'ancienne, donc forcément avec des paquets de bugs ...

Seules les industries qui ont payé le prix fort pour de simples bugs
(logiciel ou électronique) ont réagi et donc changé leurs méthodes.

Ce qui est inquiétant est que d'autres industries, telles que
l'automobile (aides à la conduite) ou le médical (pacemakers ...)
semblent n'avoir pas encore réagi, alors que les conséquences
de dysfonctionnements vont grandissant avec le temps qui passe ...

[Manichéenne]

Quand il n'y a pas de conséquences vitales évidentes, j'ai l'impression que les entreprises ont tendance à sous estimer les effets des bugs.
En vrac, et en modifiant très légèrement, j'ai vu des trucs comme :
-données RH : oups, les salariés vont recevoir des cadeaux du CE à Noël pour leurs enfants décédés.
-logistique : dites, on a échangé les adresses des entrepôts, il y a des camions en Espagne alors qu'ils devaient livrer en Belgique.
-achats : ah, on a fait sauter la virgule, tous les prix ont été multipliés par 100.
Pour la finance, les télécoms, les achats en ligne, les conséquences sont plus classiques. Pour les péages, de ce que j'en ai vu c'est remarquablement fiable.
Heureusement pour moi, la plupart du temps je ne sais même pas quelles sont les conséquences réelles des bugs que je corrige.

[Benoit]

Du coup, ca m'etonne moins que le client refuse de payer en fait...

pataper pataper pataper pataper.

[Manichéenne]

vu l'état dans lequel était le système quand je suis partie aujourd'hui, et sachant que personne d'autre que moi ne sait développer sur cette appli puisqu'ils n'ont trouvé personne à embaucher, je me dis que soit l'éditeur va leur louer un consultant à prix d'or, soit ils vont se décider à payer la grosse somme qu'ils doivent à ma boite. Ou alors c'est le moment de négocier une embauche en télétravail, mais s'ils gèrent les salaires de la même manière...

[Bubu]

Je viens de découvrir en Java l'attribut de variable volatile
En gros, ça encapsule une variable dans une section critique.
Seul un thread à la fois peut y avoir accès (tant en lecture qu'en écriture)
C'est assez génial et hyper pratique.

[Benoit]

Il me semble que ça n'est pas conseillé en multithread "critique" (= zéro protection contre les race conditions, ...) :

Extrait de la réponse à :
https://stackoverflow.com/questions/455 ... -threading

Do not assume volatile has special meaning in the memory model. It does not. It is not -- as in some later languages -- a synchronization mechanism. To get synchronization, use atomic, a mutex, or a condition_variable.

[Bubu]

Il me semble que ça n'est pas conseillé en multithread "critique" (= zéro protection contre les race conditions, ...) :

Extrait de la réponse à :
https://stackoverflow.com/questions/455 ... -threading

Do not assume volatile has special meaning in the memory model. It does not. It is not -- as in some later languages -- a synchronization mechanism. To get synchronization, use atomic, a mutex, or a condition_variable.

Il s'agit de C++, en Java, la définition est plus claire :

Code : Tout sélectionner

Essentially, volatile is used to indicate that a variable's value will be modified by different threads.

Declaring a volatile Java variable means:

The value of this variable will never be cached thread-locally: all reads and writes will go straight to "main memory";
Access to the variable acts as though it is enclosed in a synchronized block, synchronized on itself.

mais peut-être devrais-je utiliser l'attibut atomic ?

[Benoit]

Ah oui tiens, en fait c'est l'équivalent d'un mutex en Java 5.

Pour la nécessité de lui mettre des opérations atomiques, ça dépend de ce que tu fais des variables.
(Si la variable varie autour de 100, c'est pas la même chose que de 0 à 1)...

https://stackoverflow.com/questions/974 ... nchronized