Re: Etude(s) de cas
Sven Luther wrote:
On Thu, Jun 26, 2003 at 06:59:37AM +0200, JusTiCe8 wrote:
C'est pas grave, des que tu trouve un bug, il faut le documenter, sinon,
il passe inapercu. Avec les manieres de developper deficiente que tout
le monde utilise aujourd'hui, les bugs sont forcement present et il n'y
a que cette methode pour les traquer.
Alors là, ça me surprend, cela voudrait il dire que les erreurs sont une
fatalité ?
Tant qu'on n'utilisera pas des methodes de developpement qui permettent
de ne pas faire d'erreurs oui. Utiliser un langage tel caml est deja un
Certe :).
Encore faudra t'il qu'une telle méthode (utopie ?) ne soit pas trop
contraignante au point de n'être suivi par... personne :/.
premier pas, mais le mieux est souvent de partir d'abord de la preuve du
programme, et generer ensuite le code automatiquement. C'est possible en
coq qui peut generer du code ocaml, ou avec B, qui permet de generer
(manuellement si je ne me trompe) du code procedurale. Et B a servi pour
Le soucis de telles méthodes est leur poids non négligeable dans le
processus de développement et surtout, facteur humain, la frustration
qui découle parfois de leur utilisation. Puisque se conformer à une
méthodologie riguoureuse et stricte nécéssite une discipline plus que
militaire. Et bon, souvent, on veut vite se jeter dans le code d'où des
problèmes surgissant rapidement. Je sais ce que c'est et je voudrai
rendre hommage là à toutes les personnes qui ont contribuées, et
continuent de contribuer, de près ou de loin à la création des outils de
dev sous Unix/Linux.
des grands projet, comme l'automatisation de la ligne Meteor a Paris par
exemple, qui a pris 4 ans de developpement, et a ete entierement prouve
en B avant d'etre code. Apres 2 ans de developpement, les commanditaire
du projet (la RATP ?) ont decide qu'ils avait confiance en la methode,
Thompson y à participer il em semble. De plus, une partie du travail a
été réaliser en Ada si je me souviens bien.
et on arrete de faire des tests, apres 2 ans supplementaires, ils ont
lancer meteor pour la premiere fois (a vide bien sur) et tout a bien
marche. Bien sur, il faut rajouter apres du materiel sur, avec des liens
redondant, etc, chose que tu ne verra jamais dans ta machine desktop.
lol, ça c'est clair !!!
Mais bien sur, ce genre de methode est tres loin des pratiques du
logiciel libre, bien qu'il semble que la gestion des fichiers dans le
noyau Linux ai ete prouve en Coq, a ce qu'il parait.
Je sais pertinament que nous ne pouvons TOUT tester sur TOUTES les
configs possible et imaginable mais quand même... :/
La difference de developpement entre le logiciel libre, et le logiciel
conventionnelle, c'est que tout le monde a acces au code, et que donc il
est beaucoup plus facile de tester et de corriger les bugs, et bien sur,
il y a beaucoup plus de developpeurs et de testeurs que meme une boite
comme microsoft peut se permettre de payer. On peut faire une analogie
avec un algo genetique, ou la theorie de Darwin, en logiciel libre, le
code foissonne partout, et le meilleur s'impose apres un temps.
Entierement d'accord avec toi pour la première partie, quant à la
seconde, c'est une analogie plutôt amusante je trouve. Mais le côté
"pervers" si je puis dire de celle ci est l'expression "le code
foissonne partout, et le meilleur s'impose apres un temps.", qui est en
légère contradiction avec tes échanges récents au sujets du dev Debian
(les backports étant des "mutations" chaotiques qui pourraient bien
s'imposer dans l'avenir ;) ) tel que j'ai pu le comprendre en tout cas.
Amicalement,
Sven Luther
A+,
J8.
Reply to: