Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Euh.. As-tu déjà travaillé dans ce genre de domaine ???Envoyé par TropMDR
Parce que, à part l'armée (où la problématique n'est pas tout à fait celle que tu dis) , j'ai travaillé dans des domaines de ce qu'on appelle des "logiciels critiques", et que ce soit en médecine ou ailleurs, je n'ai jamais vu utiliser de telles méthodes....
Mais je n'ai pas tout vu, bien entendu
Euh.. As-tu déjà travaillé dans ce genre de domaine ???
Parce que, à part l'armée (où la problématique n'est pas tout à fait celle que tu dis
Mais je n'ai pas tout vu, bien entendu
même dans des domaines plus "militaires", je ne vois vraiment pas ce qu'il y a de choquant dans l'analyse tenue par TropMDR... clairement, nous sommes dans un milieu académique avec implications industrielles (pas les mêmes en ce qui nous concerne aussi bien sur la théorie que la valorisation, mais de votre point de vue, ça va sembler proche). de nombreux "systèmes critiques embarqués" ont besoin de ce genre d'expertise, et il n'y a qu'à voir le nombre croissant de thèses CIFRE, de contrats ANR, etc. dans ce domaine pour se convaincre de l'importance que ces "approches sûres" ont prise dans les bureaux d'étude depuis près de dix/quinze ans
je n'ai pas dit que c'était "choquant"..
Je rectifie simplement par rapport à la phrase semblant indiquer que dans les domaines où il y a criticité du logiciel c'est automatiquement utilisé.. *
D'autre part, la grosse différence (et tous ceux ayant travillé de près ou de loin dans des domaines financés par l'armée le savent), c'est que quand l'armée est derrière, il y a des fonds...relativement inépuisables... et la notion de délai n'est pas vraiment à l'ordre du jour...
(j'ai même vu 10 ans de développement de plus de 100 personnes repartir à zéro)
C'est tout ce que je veux dire... Et c'est très bien qu'il y ait l'armée pour financer des thèses CIFRE et autres..
C'est juste qu'entre une utilisation dans ce genre de cadre et une utilisation industrielle massive, il y a une (énorme) marge...
* : avec une note humoristique parce que le but d'un logiciel militaire n'est pas très fréquemment de vouloir "une forte assurance sur le fait qu'on ne tuera personne"
J'ai l'impression que Souviron blaguait sur le fait que le rôle de l'armée, précisément, est de tuer des gens.....même dans des domaines plus "militaires", je ne vois vraiment pas ce qu'il y a de choquant dans l'analyse tenue par TropMDR... clairement, nous sommes dans un milieu académique avec implications industrielles (pas les mêmes en ce qui nous concerne aussi bien sur la théorie que la valorisation, mais de votre point de vue, ça va sembler proche). de nombreux "systèmes critiques embarqués" ont besoin de ce genre d'expertise, et il n'y a qu'à voir le nombre croissant de thèses CIFRE, de contrats ANR, etc. dans ce domaine pour se convaincre de l'importance que ces "approches sûres" ont prise dans les bureaux d'étude depuis près de dix/quinze ans
Celà étant, il est probable que ce genre d'approche méthodique et systémique marche bien. Appliquée par des gens bien formés, sur des sujets spécifiques, et sur des sujets d'ampleur limitée(au vu du cout de vérification). Mon quotidien, c'est de devoir cracher 4 programmes en une matinée pour corriger en urgence un historique rendu faut parceque le batch a tourné hors des dates prévues. D'avoir des specs sybillines au possibles, torchées en vitesse par des gens dont ça n'est pas le métier, et qui en plus ont autre chose à faire. De bosser avec des gens pour qui une "norme de programmation", ça se limite à couper un paragraphe de 3000 lignes linéaires en 4 ou 5 paragraphes(linéaires et executés linéairement) histoire de faire de la "programmation structurée". Et de bosser sur du code de 10 ou 20 ans d'âge(avec une pointe à 36, mais ça reste rare)
Donc, dans mon cas, utiliser des méthodes de ce type, c'est de la science-fiction.
EDIT : grillé.
Oui et non, c'est certain que c'est réservé à des produits circonscrits; mais ça n'enléve pas les deux problèmes :
- Faire une spécification exhaustive
- Faire une vérification exhaustive
Sur un cas dans un produit, oui, maintenant, il faut aussi considérer que la spécification peut être fausse et que la vérification n'est pas exhaustive.
Tout le sujets sensibles dans la qualité des applications actuelles ne trouvent pas de solutions dans une preuve mathématique.
Je répète donc ce que j'ai dit
Donc, en détaillant : si tu es dans un domaine non critique, l'usage des méthodes formelles sera trop couteux. Il n'y a que dans les domaines critique où ça peut être rentable.
Si tu préfères, je dis "not in critical domaine -> no use of formal methode". La contraposé de ça n'a jamais été "in critical domaine -> use of formal methode". Donc merci de ne pas me faire dire ce que je n'ai pas dit.
On peut peut être éventuellement espérer que doucement, les méthodes évoluent. Genre que l'informatique n'est pas une science/technique morte. Non ?
Par exemple, dans l'aéronautique, on est passé de pas d'informatique, à quelques dizaines de milliers de ligne, jusqu'à plus de 500 000 lignes de C pour le système de commande de l'A380 (plus aucun lien mécanique entre le manche et les ailes). Les besoins ne sont plus les mêmes.
C'est pourquoi la majorité de ce code est généré et non plus écrit à la main, et c'est aussi pourquoi ils utilisent le logiciel Astrée (analyse statique) pour garantir l'absence d'erreur à runtime. Ainsi que d'autres vérifications sur le code binaire produit (assurances fines de temps d'exécutions).
Ensuite je considère que le système de commande d'un métro roulant à 80km/h et transportant 500 000 personnes par jour (sans doute bien plus maintenant en fait), rentre dans le domaine du "logiciel critique". Et de telles méthodes ont été utilisé, puisqu'il a été développé en utilisant la méthode B.
Donc oui, c'est utilisé.
Sans doute, je ne te contredis pas, et d'ailleurs j'étais d'accord avec ton post.. Je ne relevais qu'une incongruité...
Maintenant, ayant vu le(s) code(s) de calcul des horaires des trains SNCF (et TGV et Eurostar) aux points de contrôle, que ce soit l'ancienne version ou la nouvelle (pas encore mise en place ce me semble), aucune des deux ne s'en servait...
(et à vrai dire, la nouvelle version "développée par des pros d'aujourd'hui" est à moins avis bien pire point de vue sécurité que l'ancienne , en Fortran IV et développée par des cheminots , ayant appris sur le tard à programmer
Curieux.
Il est (était ? ) tout à fait possible de programmer sans utiliser de pointeur et en laissant le compilateur gérer la mémoire.
Il vaudrait peut-être mieux utiliser au départ un langage strict qui ne permet pas l'intrusion de tels bugs plutôt que devoir utiliser un débogueur de course sur un code laxiste.
C'est clair ! Allons jouer aux légos, on aura moins de problèmes !
Exactement.
Un programme devrait être conçu comme des briques s'emboitant des prémisses au résultat. Je pense que c'est généralement possible ( J'exclus les algos sophistiqués qui relèvent plus des mathématiques que du développement )
Malheureusement beaucoup d'informaticiens préfèrent les jeux de l'ego au jeu de Lego
A priori, il ne s'agit pas que de problèmes de pointeurs, comme le montre le logiciel Astrée
et bien du coup vous parlez d'autre chose, plusieurs pages sont passees depuis mon intervention. ce que je vois dans la discussion c'est que tout le monde parle sans s'ecouter et que chacun cherche les incoerrences de l'autre.
bref moi j'utilise pas de debugeurs car MOI oui MOI je sais pas l'utiliser et j'ai pas envie d'apprendre printf ME oui ME suffit. JE fais comme l'a dit quelqu'un j'ai des modules (.h et .c) separe et teste, quand ca plante je sais ou sais. et comme l'a dit aussi un autre mais quand on mets ensemble parfois le module B tente d'acceder a un pointer qui a ete detruit par le module A alors ca plante aussi et la MOI oui encore MOI meme si c'est parfois penible avec les printf ca marche aussi.
quand au utilisateur de debugeur je vois pas en quoi ils sont debutant, il y a un homme que je respect en programmation mon idole si vous voulez qui utilise et quand dans le passe j'ai voulu commencer a en utiliser un pour faire comme mon model,il m'a dit:et j'ai deja travaille en equipe mais c'etait du php jamais en c ou je programmais souvent dans mon coin j'ai toujours cru avant ce topic que les printf j'etais le seul a les utiliser et que les autres c'etait debugeur.
Code : Sélectionner tout - Visualiser dans une fenêtre à part quand tu fais tes printf tu debug deja et c'est plus efficaces que mon debug car la methode vient de toi et tu es a l'aise avec
mais pour resumer c'est quoi debuger? je pense que c'est chercher des bugs. c'est quoi la methode? il n'en existe pas UNE, utiliser un debugeur est utiliser un outils printf(, echo, display, systeme.print,println, print, writeln...) sont aussi des outils qui peuvent etre utiliser pour la meme chose.
il existe d'autres methode dont par exemple, relire tout le code et trouver le bug,je sais c'est la plus difficile mais c'est tout de meme une methode et pourquoi dirait on que celui qui l'utilise est fou ?
une autre methode que moi meme j'utilise aussi dans les cas de code plutot court c'est la trace avec un stylot et une feuille c'est parfois plus efficace qu'un debugeur ou un printf selon le cas bien sur.
pour conclure je constate que la methode de travaille c'est comme la politique, la religion, les idees... bref l'ego de l'homme ma religion est la meilleur c'est la vrai c'est celle qui rapproche de Dieu, la Democratie c'est ce que nous on utilise et c'est ca qui est bien, le C c'est le meilleur language, ce que j'utilise c'est mieux.
ca fait vraiment pitie mais le monde dans le quel on vie c'est ca, et se defaut s'applique partout. meme ici dans l'informatique. meme dans l'open source ou il y a des belle idees de communaute on trouve aussi des debats futiles sur la methode au lieu de chercher un bon resultat.
pensez que dans un cas ,pour un personne , a un moment donne une methode peu prendre le dessus sur les autres. je l'ai dit j'utilise pas de debugeur car j'ai pas envie d'apprendre a en utiliser un. j'utilise pas EDI car je trouve que ca me rend pareisseux surtout a cause de complement de code (ou je sais pas comment on appel ca, le truc qui complete mes phases) et ca me rend pas moin productif car je fini mon travail dans les temps.
allez la vrai conclusion desole par le discour:
ce sujet n'a aucune utilite sinon de montrer : l'un des plus grands defauts des Hommes a savoir ce que moi je fais,en quoi je crois, ce que j'utilise c'est mieux et tout le monde devrait faire comme moi, s'applique aussi ici, bien que ce soit l'un de nos defaut le plus souvent source de guerre dans le monde.
C'est vrai, mais je ne crois pas que ça rende le sujet de la discussion caduque : en informatique, il n'est pas difficile de démontrer que certaines méthodes sont plus efficaces que d'autres pour une situation donnée. Bien sûr il y a quelques extrémistes, mais il y aussi des posts intelligents, et ce n'est pas juste de les jeter dans ce sac.
En fait dans ceux qui n'utilisent pas de débuggueur il y a :
- Ceux qui ne savent pas s'en servir et qui ont une autre méthode qui leur convient. C'est tout à leur honneur, apprendre à utiliser un débuggueur prend du temps, et on ne peut pas toujours se payer un coût d'apprentissage.
- Ceux pour lesquels l'environnement de travail ne le permet pas : embarqué, langages serveurs, autres mic macs.
Dans ceux qui utilisent un débuggueur, il y a une catégorie de personnes qui le font parce qu'ils savent, peuvent, qu'ils sont plus efficace avec et qu'ils savent pourquoi.
Et enfin il y a quelques extrémistes qui n'en utilisent pas, qui ne l'ont jamais fait mais qui sont persuadés que c'est inutile, [edit, merci lilington] ceux qui pensent qu'il est impensable de s'en passer. Mais on va pas se laisser pourrir le débat par quelques cas isolés n'est ce pas ?
t'as oublie les autres extremistes, ceux qui l'utilise et qui trouve que se qui pensent pouvoir s'en passer sont contre productif. bref preuve (comme si il fallait encore la faire) que l'exces peut nuir a la sante (mentale comme physique hein!)
Ce qui est intéressant de noter, c'est qu'il n'y a pas que Printf et le débugueur pour "circonscrire" les bugs, on découvre qu'il y a des outils très sophistiqués.
EDIT: J'ai eu recours à une autre technique pour débuguer une application: comparer tous les résultats produits par l'ancienne application avec la nouvelle, c'était surprenant.
Exact...
Car un programme peut ne pas avoir de bugs au sens informatique mais néanmoins être faux...
+1000
Je suis entièrement d'accord avec toi...
Quand je vois les religions sur l'OO, UML, sur tel langage ou telle méthode, et autres, ça m'atterre...
C'est effectivement très religieux : si on n'utilise pas tel truc, on est un "mécréant" , et forcément on est nul...
Et faudrait quasiment être banni...
Il faut fournir les preuves que le programme est juste au sens métier.Car un programme peut ne pas avoir de bugs au sens informatique mais néanmoins être faux...
D'où la question, qu'est ce qu'un bug ? Un événement non prévu ...
Répondre avec citation
Partager