Il y a beaucoup de propos intéressants sur cette page ... et beaucoup de langages aussi (Caml, B, ... ca me rappelle l'école). Mais je suis de l'avis de woopla (eux aussi d'ailleurs ;-p http://www.thinkgeek.com/tshirts/sysadmin/6692/):(...)
Le problème se situe entre la chaise et le clavier.
au moins pour 80% des cas! Le langage n'est que secondaire.
** Constatations **
Les langages actuels sont certes insuffisants pour exprimer la richesse du monde mais la source primaire des bugs (AMHA) ce sont les personnes travaillant sur le projet. N'est pas développeur de logiciels qui veut. Si, me direz-vous, avec des outils style VB (malheureusement :-(). Je n'ai rien contre ceux qui travaillent avec VB, j'en fait d'ailleurs occasionnellement partie de par mon travail, mais VB vulgarise un peu trop à mon goût le développement d'applications. Pour qu'un programme soit fiable (sans bug ou presque), il faut de bon concepteurs (c'est-à-dire des gens qui réfléchissent à ce qu'il faut réellement faire et comment le faire), des analystes expérimentés qui proposent des solutions techniques (environnement, langages, ...), de bon pisseurs de lignes (qui codent rigoureusement en commentant leurs sources) et enfin de bons testeurs (en unitaire et en intégration). Ca ne résoud pas 100% des bugs mais devrait déjà faire avancer pas mal le schimilibilibilick.
Allons plus loin, la source de la source, c'est l'argent. Pour être compétent, un développeur/analyste/testeur/pisseur doit avoir étudié la théorie (les maths, le paradigme objet, ...) et doit avoir de l'expérience ... donc va coûter cher à l'entreprise. Et généralement, un DSI préfère prendre un BAC+2 sorti de la fac, le former sur le tas et le payer à coups de bambous, quitte à ce que son boulot ne soit pas « top moumoute » mais qu'il arrive rapidement sur le marché (tant pis, on sortira un service pack ;-)) que de prendre des gens compétents (mais qui vont prendre plus de temps à produire et vont coûter + cher).
[digression philosphique]
Pour aller encore plus loin, la source de la source de la source, c'est l'homme: avide d'argent et de technologie pour le conforter dans sa paresse intellectuelle, il en veut toujours plus et contraint le système à aller vite, trop vite pour bien faire.
[/digression philosphique]
** Conclusion **
A « comment réduire le nombre de bug ? », je répondrais donc « en ayant la volonté de le faire ! ».
** Conclusion : la vraie **
Non je déconne, le problème n'est pas aussi simple. Il est vrai qu'il y a encore beaucoup de travail pour améliorer les langages actuels : l'absence de typage strict des variables en PHP ou Javascript, la possibilité d'omettre la déclaration des variables en VB, le non typage des Objects d'un tableau en Java pre-1.5, l'absence d'assertions natives dans de nombreux langages.
A ce titre, je proposerai un nouveau langage à la liste déjà longue évoquée ici: Eiffel (et son compilo GNU http://smalleiffel.loria.fr/).(...) On y trouve une implémentation du paradigme objet + poussée qu'en Java, un système de pré et post conditions sur les fonctions, ... des concepts très intéressant permettant une vérification accrue du code à la compil et à son exécution. Pas encore suffisant objecterez-vous, certes mais c'est un petit pas pour l'homme :-)
Pour conclure, tout est affaire de perte acceptable: puis-je me permettre d'aller vite au détriment de la stabilité (pour des raisons commerciales le + souvent) (Mysql 5.0, Tomb Raider 1 à 6) ou est-ce que je dois prendre mon temps et limiter les bugs au maximum (A380)?
Sur ce ...
à non j'oubliais!
la gestion des exceptions (ndr :les contrats)
Les contrats n'ont, sauf erreur de ma part due au temps écoulé depuis mes cours de théorie OO, rien à voir avec les exceptions. Un contrat défini un ensemble de règles qu'un client doit respecter. En Java comme en IDL, c'est décrit par des interfaces qui énumèrent les méthodes que doit implémenter une classe cliente (le contrat qu'elle doit respecter).
# Mon avis de moi
Posté par Jay . En réponse au journal Repenser les langages et le développement logiciel. Évalué à 10.
au moins pour 80% des cas! Le langage n'est que secondaire.
** Constatations **
Les langages actuels sont certes insuffisants pour exprimer la richesse du monde mais la source primaire des bugs (AMHA) ce sont les personnes travaillant sur le projet. N'est pas développeur de logiciels qui veut. Si, me direz-vous, avec des outils style VB (malheureusement :-(). Je n'ai rien contre ceux qui travaillent avec VB, j'en fait d'ailleurs occasionnellement partie de par mon travail, mais VB vulgarise un peu trop à mon goût le développement d'applications. Pour qu'un programme soit fiable (sans bug ou presque), il faut de bon concepteurs (c'est-à-dire des gens qui réfléchissent à ce qu'il faut réellement faire et comment le faire), des analystes expérimentés qui proposent des solutions techniques (environnement, langages, ...), de bon pisseurs de lignes (qui codent rigoureusement en commentant leurs sources) et enfin de bons testeurs (en unitaire et en intégration). Ca ne résoud pas 100% des bugs mais devrait déjà faire avancer pas mal le schimilibilibilick.
Allons plus loin, la source de la source, c'est l'argent. Pour être compétent, un développeur/analyste/testeur/pisseur doit avoir étudié la théorie (les maths, le paradigme objet, ...) et doit avoir de l'expérience ... donc va coûter cher à l'entreprise. Et généralement, un DSI préfère prendre un BAC+2 sorti de la fac, le former sur le tas et le payer à coups de bambous, quitte à ce que son boulot ne soit pas « top moumoute » mais qu'il arrive rapidement sur le marché (tant pis, on sortira un service pack ;-)) que de prendre des gens compétents (mais qui vont prendre plus de temps à produire et vont coûter + cher).
[digression philosphique]
Pour aller encore plus loin, la source de la source de la source, c'est l'homme: avide d'argent et de technologie pour le conforter dans sa paresse intellectuelle, il en veut toujours plus et contraint le système à aller vite, trop vite pour bien faire.
[/digression philosphique]
** Conclusion **
A « comment réduire le nombre de bug ? », je répondrais donc « en ayant la volonté de le faire ! ».
** Conclusion : la vraie **
Non je déconne, le problème n'est pas aussi simple. Il est vrai qu'il y a encore beaucoup de travail pour améliorer les langages actuels : l'absence de typage strict des variables en PHP ou Javascript, la possibilité d'omettre la déclaration des variables en VB, le non typage des Objects d'un tableau en Java pre-1.5, l'absence d'assertions natives dans de nombreux langages.
A ce titre, je proposerai un nouveau langage à la liste déjà longue évoquée ici: Eiffel (et son compilo GNU http://smalleiffel.loria.fr/).(...) On y trouve une implémentation du paradigme objet + poussée qu'en Java, un système de pré et post conditions sur les fonctions, ... des concepts très intéressant permettant une vérification accrue du code à la compil et à son exécution. Pas encore suffisant objecterez-vous, certes mais c'est un petit pas pour l'homme :-)
Pour conclure, tout est affaire de perte acceptable: puis-je me permettre d'aller vite au détriment de la stabilité (pour des raisons commerciales le + souvent) (Mysql 5.0, Tomb Raider 1 à 6) ou est-ce que je dois prendre mon temps et limiter les bugs au maximum (A380)?
Sur ce ...
à non j'oubliais!
la gestion des exceptions (ndr :les contrats)
Les contrats n'ont, sauf erreur de ma part due au temps écoulé depuis mes cours de théorie OO, rien à voir avec les exceptions. Un contrat défini un ensemble de règles qu'un client doit respecter. En Java comme en IDL, c'est décrit par des interfaces qui énumèrent les méthodes que doit implémenter une classe cliente (le contrat qu'elle doit respecter).