Bonjour.
Hier soir après une drôle de journée j’ai laissé divaguer mon esprit et peut être par ce que j’étais épuisé j’ai pensé à une notion de variable qui s’use.
Dans le monde matériel tout s’use, y compris nous. Et je me suis dit que dans un programme on peut utiliser autant de fois qu’on veut une variable (ou une propriété ) tant qu’on ne change pas volontairement sa valeur, elle ne change pas. Idem pour une méthode elle ne fatigue pas.
De la même manière on peut créer une boucle infinie, elle ne s’arrêtera pas d’elle même, au contraire d’un balancier.(c’est le hardware qui va casser d’un coup, pas le soft qui tourne dessus).
Or si on veut créer du virtuel qui simule le réel, pour rejoindre l’autre discussion sur les langages qui n’ont pas été inventé, ne faudrait il pas introduire cette notion d’usure ?
Bon je vais bosser .
J’ai envie de te dire Kamoulox !
La notion d’usure (ou plutot simu d’usure) est deja présente (et heureusement !) dans certaines industries qui présentent des risques humain réels : médical, spacial, aviation, automobile…
On fait des estimations d’usure de pièces mécaniques, contraintes de résistance des matériaux et j’en passe
Mais dans d’autre domaines où le virtuel se suffit a lui meme, genre des appli de gestion, ça apporterait un ensemble supplémentaire de difficultés dont on se passe volontiers.
Imagine prendre cela en compte dans des tests unitaires , d’intégration et tout.
Le virtuel amene une non-obsolescence particulièrement bienvenue, quand elle n’a pas l’exigence de Turing.
Tu mentionnes quelque chose de vague mais chaque branche de l’IT connaît bien “l’usure”.
Il y a plein de concepts connus autour de cela, notamment dans les univers de :
-
infra et stockage : les experts en hardware, en RAM et en disques durs en parlent
https://en.wikipedia.org/wiki/Data_degradation -
codeurs : “bit rot”, dette technique, veille technologique…
https://en.wikipedia.org/wiki/Software_rot -
systèmes distribués et perf et autres timing-sensitive stuff. Un exemple très simple :
http://martinfowler.com/bliki/CircuitBreaker.html -
devops : mises à jour permanentes de sécu, c’est pas l’usure mais l’envie d’être à jour ;)
-
humains et management on va parler burnout, formation continue,“bus factor”…
-
business on parlera de TMA, de “run” de fin de vie du projet et prestation de réversibilité
Bref si, le concept est clairement présent, compris, et toute personne qui a un peu de bouteille dans son domaine sait très bien qu’il faut considérer cet aspect de timing, de dégradation et de mise à jour dans la durée à tous niveaux.
La plupart y ont été (douloureusement) confrontés, et plus ton secteur travaille dans la qualité et la pérennité, plus tu y seras confronté. Et même si l’on trouve des gens pour en parler, c’est pas dans les écoles et les agences à projets jetables qu’on y est sensibilisés ;)
Ça veut pas dire que ça existe pas, et ce sont des choses (stressantes mais) passionnantes à apprendre :D
Il existe même des modèles logiques formels intégrant cette idée d’usure, de consommation de ressources: la logique linéaire !
J’aurais tendance à dire qu’effectivement une variable ne change pas automatiquement. Mais sa qualité, elle, aura tendance à se dégrader dans le temps (pour les systèmes où l’usure compte).
Bonjour,
Dans un langage destiné aux grands débutants, MicroAlg, j’ai bridé les boucles Tant_que pour éviter que ça plante si le programmeur n’a pas fait assez attention et a laissé une boucle infinie. Une sorte d’usure de sécurité !
Voici des exemples interactifs et un bout de doc concernant ce mécanisme.
Pour ceux qui veulent parler de ce langage ici, il y a déjà un fil ici.
Les concepts informatiques servent généralement un but prédéfini.
Pourquoi vouloir introduire cette notion d’usure ?
Accessoirement, je ne sais pas si tu sais comment fonctionne un garbage collector, mais on peut considérer qu’il s’agit bien-là d’évaluer l’ancienneté/l’usure d’une variable.
J’avais beaucoup aimé lire cet article sur le sujet : http://thorstenball.com/blog/2014/03/12/watching-understanding-ruby-2.1-garbage-collector/
Je pense qu’il peut être intéressant même sans faire de Ruby, ou bien à défaut, un article similaire doit exister pour ton langage de prédilection.