[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Etude(s) de cas



On Thu, Jun 26, 2003 at 10:24:29AM +0200, JusTiCe8 wrote:
> 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 :/.

Sur, mais c'est plus une question d'habitude qu'autre chose.

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

Oui, mais si tu contrebalance ce cout avec celui de la recherche de
bugs, de maintenance, et de service apres vente, le choix est vite fait.
C'est sur que les firmes informatique s'en foute totalement et
produisent en general des produits a la qualite si douteuse que
n'importe qui d'autre serait deja en prison pour les memes choses.

> 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 

Oui, bien sur, je comprend, mais le choix du langage aide. Tu ne peut
pas avoir de runtime error par exemple avec un langage statiquement type
comme ocaml.

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

Oui.

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

Oui, B, c'est uniquement le mecanisme de preuve, apres tu genere du code
Ada ou autre, mais d'une maniere controlle et formelle. J'ai eu une
conference avec Jean-Raymond ABRIAL sur B en 2000, le mecanisme qui est
derriere est vraiment fascinant.

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

Mmm, non, les backport sont des impasses de l'evolution ammener a
disparaitre. Ils essaye de remonter le temps, en adaptant des logiciels
recents a des environements anciens et deja depasse par l'evolution :)))

Amicalement,

Sven Luther



Reply to: