Le Wed, 01 Jun 2005 08:34:35 +0200, Richard Delorme a écrit :
Le langage importe peu, me semble t'il, aucune technique, aucune langage, aucun progrès technique n'a toujours pas permis un gain de productivité *mesurable* depuis 1968.
Ce n'est même pas un troll, c'est une plaisanterie.
Ce principe énoncé dans «The Mythical Man-Month» par Fred. Brooks Puis, en 1987, Robert Solow énonça un paradoxe, connu depuis sous le nom de « paradoxe de la productivité », ou « paradoxe de Solow », selon lequel « l'ordinateur est partout, sauf dans les statistiques de productivité ».
Faut peut etre pas mélanger les deux productivités - celle du programmeur en changeant de langage - celle du travailleur avec ou sans ordinateur
Parce que si vous avez des stats qui vous montrent qu'un programmeur travaille aussi vite sans ordinateur qu'avec, j'en veux aussi !
MB -- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
jul <saponific@ti0n.net> writes:
Le Wed, 01 Jun 2005 08:34:35 +0200, Richard Delorme a écrit :
Le langage importe peu, me semble t'il, aucune
technique, aucune langage, aucun progrès technique n'a toujours pas
permis un gain de productivité *mesurable* depuis 1968.
Ce n'est même pas un troll, c'est une plaisanterie.
Ce principe énoncé dans «The Mythical Man-Month» par Fred. Brooks Puis,
en 1987, Robert Solow énonça un paradoxe, connu depuis sous le nom de «
paradoxe de la productivité », ou « paradoxe de Solow », selon lequel
« l'ordinateur est partout, sauf dans les statistiques de productivité
».
Faut peut etre pas mélanger les deux productivités
- celle du programmeur en changeant de langage
- celle du travailleur avec ou sans ordinateur
Parce que si vous avez des stats qui vous montrent qu'un programmeur
travaille aussi vite sans ordinateur qu'avec, j'en veux aussi !
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
Le Wed, 01 Jun 2005 08:34:35 +0200, Richard Delorme a écrit :
Le langage importe peu, me semble t'il, aucune technique, aucune langage, aucun progrès technique n'a toujours pas permis un gain de productivité *mesurable* depuis 1968.
Ce n'est même pas un troll, c'est une plaisanterie.
Ce principe énoncé dans «The Mythical Man-Month» par Fred. Brooks Puis, en 1987, Robert Solow énonça un paradoxe, connu depuis sous le nom de « paradoxe de la productivité », ou « paradoxe de Solow », selon lequel « l'ordinateur est partout, sauf dans les statistiques de productivité ».
Faut peut etre pas mélanger les deux productivités - celle du programmeur en changeant de langage - celle du travailleur avec ou sans ordinateur
Parce que si vous avez des stats qui vous montrent qu'un programmeur travaille aussi vite sans ordinateur qu'avec, j'en veux aussi !
MB -- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
billaud
jul writes:
Le Wed, 01 Jun 2005 16:34:19 +0200, Richard Delorme a écrit :
A mon avis, cet article est obsolète. Juste quelques dates : 1986 : publication l'article 1991 : sortie de Python 1.0. 1995 : sortie de Java 1.0. 1996 : sortie de Ruby 1.0. 1999 : publication d'Extreme Programming Explained
Ah !
Complete Code de Steve Mc Connell ne dit pas autrement que Fred Brooks pourtant (j'ai la deuxième édition qui date d'après 2000). Il y donne bien des recettes, et il conseille notamment d'employer les langages les plus concis en général (perl, python étant égaux sur ce critère), mais ces langages permettent-ils de gagner un ordre de grandeur en productivité ?
Pourquoi les langages et XP changeraient l'informatique ? Influent-ils sur l'essence de la programmation (la créativité) ou sur l'aspect accidentel (managérial et technique) ?
Les langages qui facilitent la définition et la réutilisation de composants font gagner en productivité.
Enfin ça dépend ce qu'on compte. C'est pas facile de calculer la productivité à partir du nombre de lignes de codes qu'on n'a pas eu besoin d'écrire.
Le logiciel libre est-il tellement différent de ce qui est dit par Mc Connell et Brooks ?
Un peu mon neveu. On évite de redévelopper ce qui est récupérable.
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
jul <saponific@ti0n.net> writes:
Le Wed, 01 Jun 2005 16:34:19 +0200, Richard Delorme a écrit :
A mon avis, cet article est obsolète. Juste quelques dates :
1986 : publication l'article
1991 : sortie de Python 1.0.
1995 : sortie de Java 1.0.
1996 : sortie de Ruby 1.0.
1999 : publication d'Extreme Programming Explained
Ah !
Complete Code de Steve Mc Connell ne dit pas autrement que Fred Brooks
pourtant (j'ai la deuxième édition qui date d'après 2000). Il y donne
bien des recettes, et il conseille notamment d'employer les langages les
plus concis en général (perl, python étant égaux sur ce critère),
mais ces langages permettent-ils de gagner un ordre de grandeur en
productivité ?
Pourquoi les langages et XP changeraient l'informatique ? Influent-ils sur
l'essence de la programmation (la créativité) ou sur l'aspect accidentel
(managérial et technique) ?
Les langages qui facilitent la définition et la réutilisation de composants
font gagner en productivité.
Enfin ça dépend ce qu'on compte. C'est pas facile de calculer la productivité
à partir du nombre de lignes de codes qu'on n'a pas eu besoin d'écrire.
Le logiciel libre est-il tellement différent de ce qui est dit par Mc
Connell et Brooks ?
Un peu mon neveu. On évite de redévelopper ce qui est récupérable.
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
Le Wed, 01 Jun 2005 16:34:19 +0200, Richard Delorme a écrit :
A mon avis, cet article est obsolète. Juste quelques dates : 1986 : publication l'article 1991 : sortie de Python 1.0. 1995 : sortie de Java 1.0. 1996 : sortie de Ruby 1.0. 1999 : publication d'Extreme Programming Explained
Ah !
Complete Code de Steve Mc Connell ne dit pas autrement que Fred Brooks pourtant (j'ai la deuxième édition qui date d'après 2000). Il y donne bien des recettes, et il conseille notamment d'employer les langages les plus concis en général (perl, python étant égaux sur ce critère), mais ces langages permettent-ils de gagner un ordre de grandeur en productivité ?
Pourquoi les langages et XP changeraient l'informatique ? Influent-ils sur l'essence de la programmation (la créativité) ou sur l'aspect accidentel (managérial et technique) ?
Les langages qui facilitent la définition et la réutilisation de composants font gagner en productivité.
Enfin ça dépend ce qu'on compte. C'est pas facile de calculer la productivité à partir du nombre de lignes de codes qu'on n'a pas eu besoin d'écrire.
Le logiciel libre est-il tellement différent de ce qui est dit par Mc Connell et Brooks ?
Un peu mon neveu. On évite de redévelopper ce qui est récupérable.
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
Denis Beauregard
Le 02 Jun 2005 18:04:08 +0200, écrivait dans fr.comp.os.linux.debats:
Parce que si vous avez des stats qui vous montrent qu'un programmeur travaille aussi vite sans ordinateur qu'avec, j'en veux aussi !
Euh, quand j'ai appris l'informatique (1975), on programmait sans ordinateur. On écrivait tout le code sur des cartes. Chez nous, on avait tout de même un ordinateur rapide: le lecteur de cartes était dans la salle voisine. Mais une fois, un groupe d'étudiants (niveau classe terminale je dirais) avait visité notre installation universitaire et s'émerveillait devant la rapidité de notre ordinateur. En effet, ils devaient expédier les boîtes avec les cartes dans une autre ville pour avoir la sortie de l'ordinateur. Donc, c'est au moins possible de programmer sans ordinateur.
Quant à la vitesse, je pense que si on travaille dans ces conditions, on prend l'habitude d'écrire du code qui marche la première fois...
Denis
Le 02 Jun 2005 18:04:08 +0200, billaud@labri.u-bordeaux.fr écrivait
dans fr.comp.os.linux.debats:
Parce que si vous avez des stats qui vous montrent qu'un programmeur
travaille aussi vite sans ordinateur qu'avec, j'en veux aussi !
Euh, quand j'ai appris l'informatique (1975), on programmait sans
ordinateur. On écrivait tout le code sur des cartes. Chez nous, on
avait tout de même un ordinateur rapide: le lecteur de cartes était
dans la salle voisine. Mais une fois, un groupe d'étudiants (niveau
classe terminale je dirais) avait visité notre installation
universitaire et s'émerveillait devant la rapidité de notre
ordinateur. En effet, ils devaient expédier les boîtes avec les
cartes dans une autre ville pour avoir la sortie de l'ordinateur.
Donc, c'est au moins possible de programmer sans ordinateur.
Quant à la vitesse, je pense que si on travaille dans ces conditions,
on prend l'habitude d'écrire du code qui marche la première fois...
Le 02 Jun 2005 18:04:08 +0200, écrivait dans fr.comp.os.linux.debats:
Parce que si vous avez des stats qui vous montrent qu'un programmeur travaille aussi vite sans ordinateur qu'avec, j'en veux aussi !
Euh, quand j'ai appris l'informatique (1975), on programmait sans ordinateur. On écrivait tout le code sur des cartes. Chez nous, on avait tout de même un ordinateur rapide: le lecteur de cartes était dans la salle voisine. Mais une fois, un groupe d'étudiants (niveau classe terminale je dirais) avait visité notre installation universitaire et s'émerveillait devant la rapidité de notre ordinateur. En effet, ils devaient expédier les boîtes avec les cartes dans une autre ville pour avoir la sortie de l'ordinateur. Donc, c'est au moins possible de programmer sans ordinateur.
Quant à la vitesse, je pense que si on travaille dans ces conditions, on prend l'habitude d'écrire du code qui marche la première fois...
Denis
Emmanuel Florac
Le Thu, 02 Jun 2005 09:59:48 +0200, Sébastien BALLET a écrit :
Je ne t'ai pas attendu pour me méfier des logiciels propriétaires .....et non-propriétaires. Le risque principal d'un logiciel propriétaire, c'est d'être abandonné par son concepteur et le risque principal du logiciel non-propriétaire....
Personnellement, ce que je trouve dommage, c'est qu'une partie de la communauté Linux rejète Java sans même réfléchir, uniquement parce que java n'est pas _libre_ alors que dans le fond, Linux et Java ont la liberté comme point commun : de choix pour linux, de choix du système sur lequel ont développe pour Java.
Tant d'inanité dans un seul message, je n'ai pas même la force de répondre.
-- Il y a toujours un bug de plus. Loi de Lubarsky.
Le Thu, 02 Jun 2005 09:59:48 +0200, Sébastien BALLET a écrit :
Je ne t'ai pas attendu pour me méfier des logiciels propriétaires .....et
non-propriétaires. Le risque principal d'un logiciel propriétaire, c'est
d'être abandonné par son concepteur et le risque principal du logiciel
non-propriétaire....
Personnellement, ce que je trouve dommage, c'est qu'une partie de la
communauté Linux rejète Java sans même réfléchir, uniquement parce que java
n'est pas _libre_ alors que dans le fond, Linux et Java ont la liberté comme
point commun : de choix pour linux, de choix du système sur lequel ont
développe pour Java.
Le Thu, 02 Jun 2005 09:59:48 +0200, Sébastien BALLET a écrit :
Je ne t'ai pas attendu pour me méfier des logiciels propriétaires .....et non-propriétaires. Le risque principal d'un logiciel propriétaire, c'est d'être abandonné par son concepteur et le risque principal du logiciel non-propriétaire....
Personnellement, ce que je trouve dommage, c'est qu'une partie de la communauté Linux rejète Java sans même réfléchir, uniquement parce que java n'est pas _libre_ alors que dans le fond, Linux et Java ont la liberté comme point commun : de choix pour linux, de choix du système sur lequel ont développe pour Java.
Tant d'inanité dans un seul message, je n'ai pas même la force de répondre.
-- Il y a toujours un bug de plus. Loi de Lubarsky.
Emmanuel Florac
Le Thu, 02 Jun 2005 11:03:58 +0000, Nicolas George a écrit :
À condition de ne pas vouloir utiliser de clôtures récursives, quand même.
OUi mais on peut faire du fonctionnel de base. On peut même pousser plus loin, il y a un module "AI::Prolog" pour ceux qui veulent essayer la programmation logique pure et dure...
-- Quidquid latine dictum sit, altum sonatur
Le Thu, 02 Jun 2005 11:03:58 +0000, Nicolas George a écrit :
À condition de ne pas vouloir utiliser de clôtures récursives, quand même.
OUi mais on peut faire du fonctionnel de base. On peut même pousser plus
loin, il y a un module "AI::Prolog" pour ceux qui veulent essayer la
programmation logique pure et dure...
Le Thu, 02 Jun 2005 11:03:58 +0000, Nicolas George a écrit :
À condition de ne pas vouloir utiliser de clôtures récursives, quand même.
OUi mais on peut faire du fonctionnel de base. On peut même pousser plus loin, il y a un module "AI::Prolog" pour ceux qui veulent essayer la programmation logique pure et dure...
-- Quidquid latine dictum sit, altum sonatur
Emmanuel Florac
Le Thu, 02 Jun 2005 18:08:19 +0200, billaud a écrit :
Un peu mon neveu. On évite de redévelopper ce qui est récupérable.
Et même quand on ne récupère pas directement, la possibilité de se référer (de lire, de tester, de jouer avec) à du code de grande qualité facilement disponible est inestimable. Il faut se rappeler qu'il n'y a pas si longtemps on commençait à programmer sans quasiment avoir jamais vu du "vrai" code (du bon code de production fait pas de bons programmeurs) mais seulement les exemples qui sont dans les bouquins, qui ne sont pas des applications complètes et qui sont en général nettement défectueux. Bref aujourd'hui on peut parfaitement apprendre à bien programmer tout seul ou presque, avec les sources libres, les docs libres et les newsgroups et forums.
-- on passe la moitié de son temps à refaire ce que l'on n'a pas eu le temps de faire correctement. Loi de Myers.
Le Thu, 02 Jun 2005 18:08:19 +0200, billaud a écrit :
Un peu mon neveu. On évite de redévelopper ce qui est récupérable.
Et même quand on ne récupère pas directement, la possibilité de se
référer (de lire, de tester, de jouer avec) à du code de grande
qualité facilement disponible est inestimable.
Il faut se rappeler qu'il n'y a pas si longtemps on commençait à
programmer sans quasiment avoir jamais vu du "vrai" code (du bon code de
production fait pas de bons programmeurs) mais seulement les exemples qui
sont dans les bouquins, qui ne sont pas des applications complètes et qui
sont en général nettement défectueux.
Bref aujourd'hui on peut parfaitement apprendre à bien programmer tout
seul ou presque, avec les sources libres, les docs libres et les
newsgroups et forums.
--
on passe la moitié de son temps à refaire ce que l'on n'a pas eu le
temps de faire correctement.
Loi de Myers.
Le Thu, 02 Jun 2005 18:08:19 +0200, billaud a écrit :
Un peu mon neveu. On évite de redévelopper ce qui est récupérable.
Et même quand on ne récupère pas directement, la possibilité de se référer (de lire, de tester, de jouer avec) à du code de grande qualité facilement disponible est inestimable. Il faut se rappeler qu'il n'y a pas si longtemps on commençait à programmer sans quasiment avoir jamais vu du "vrai" code (du bon code de production fait pas de bons programmeurs) mais seulement les exemples qui sont dans les bouquins, qui ne sont pas des applications complètes et qui sont en général nettement défectueux. Bref aujourd'hui on peut parfaitement apprendre à bien programmer tout seul ou presque, avec les sources libres, les docs libres et les newsgroups et forums.
-- on passe la moitié de son temps à refaire ce que l'on n'a pas eu le temps de faire correctement. Loi de Myers.
Sébastien BALLET
"Emmanuel Florac" a écrit dans le message de news:
Je ne t'ai pas attendu pour me méfier des logiciels propriétaires .....et non-propriétaires. Le risque principal d'un logiciel propriétaire, c'est d'être abandonné par son concepteur et le risque principal du logiciel non-propriétaire....
Personnellement, ce que je trouve dommage, c'est qu'une partie de la communauté Linux rejète Java sans même réfléchir, uniquement parce que java n'est pas _libre_ alors que dans le fond, Linux et Java ont la liberté comme point commun : de choix pour linux, de choix du système sur lequel ont développe pour Java.
Tant d'inanité dans un seul message, je n'ai pas même la force de répondre.
et bien alors pourquoi avoir répondu ???
"Emmanuel Florac" <eflorac@imaginet.fr> a écrit dans le message de news:
pan.2005.06.02.20.14.51.105399@imaginet.fr...
Je ne t'ai pas attendu pour me méfier des logiciels propriétaires .....et
non-propriétaires. Le risque principal d'un logiciel propriétaire, c'est
d'être abandonné par son concepteur et le risque principal du logiciel
non-propriétaire....
Personnellement, ce que je trouve dommage, c'est qu'une partie de la
communauté Linux rejète Java sans même réfléchir, uniquement parce que
java
n'est pas _libre_ alors que dans le fond, Linux et Java ont la liberté
comme
point commun : de choix pour linux, de choix du système sur lequel ont
développe pour Java.
"Emmanuel Florac" a écrit dans le message de news:
Je ne t'ai pas attendu pour me méfier des logiciels propriétaires .....et non-propriétaires. Le risque principal d'un logiciel propriétaire, c'est d'être abandonné par son concepteur et le risque principal du logiciel non-propriétaire....
Personnellement, ce que je trouve dommage, c'est qu'une partie de la communauté Linux rejète Java sans même réfléchir, uniquement parce que java n'est pas _libre_ alors que dans le fond, Linux et Java ont la liberté comme point commun : de choix pour linux, de choix du système sur lequel ont développe pour Java.
Le risque principal d'un logiciel propriétaire, c'est d'être abandonné par son concepteur
Mais sans possibilité de le reprendre.
tout dépend de l'intérêt que celui-ci sucite. S'il existe une communauté d'utilisateur substantiel, le dit logiciel pourra être repris par une autre entreprise.
et le risque principal du logiciel non-propriétaire....ben c'est d'être abandonné par son concepteur.
Mais lui je peux mettre les mains à la poche et le reprendre là ou il s'est arreté.
Tout dépends de la qualité du logiciel, est-il bien écrit, bien documenté ?? si je te file un source d'une taille conséquente sans aucun commentaire, tu crois vraiment que le jeu en vaudra la chandelle ?? Certes il y a du bon et même du très bon code dans le LL, mais il y a aussi de très nombreux projet dont le source est mal voir pas du tout documenté (regarde donc du côté des drivers alsa).
"Rakotomandimby (R12y) Mihamina" <mihamina.rakotomandimby@etu.univ-orleans.fr> wrote in message news:<pan.2005.06.02.10.40.47.803396@etu.univ-orleans.fr>...
Le risque principal d'un logiciel
propriétaire, c'est d'être abandonné par son concepteur
Mais sans possibilité de le reprendre.
tout dépend de l'intérêt que celui-ci sucite. S'il existe une
communauté d'utilisateur substantiel, le dit logiciel pourra être
repris par une autre entreprise.
et le risque
principal du logiciel non-propriétaire....ben c'est d'être abandonné
par son concepteur.
Mais lui je peux mettre les mains à la poche et le reprendre là ou il
s'est arreté.
Tout dépends de la qualité du logiciel, est-il bien écrit, bien
documenté ?? si je te file un source d'une taille conséquente sans
aucun commentaire, tu crois vraiment que le jeu en vaudra la chandelle
?? Certes il y a du bon et même du très bon code dans le LL, mais il y
a aussi de très nombreux projet dont le source est mal voir pas du
tout documenté (regarde donc du côté des drivers alsa).
Le risque principal d'un logiciel propriétaire, c'est d'être abandonné par son concepteur
Mais sans possibilité de le reprendre.
tout dépend de l'intérêt que celui-ci sucite. S'il existe une communauté d'utilisateur substantiel, le dit logiciel pourra être repris par une autre entreprise.
et le risque principal du logiciel non-propriétaire....ben c'est d'être abandonné par son concepteur.
Mais lui je peux mettre les mains à la poche et le reprendre là ou il s'est arreté.
Tout dépends de la qualité du logiciel, est-il bien écrit, bien documenté ?? si je te file un source d'une taille conséquente sans aucun commentaire, tu crois vraiment que le jeu en vaudra la chandelle ?? Certes il y a du bon et même du très bon code dans le LL, mais il y a aussi de très nombreux projet dont le source est mal voir pas du tout documenté (regarde donc du côté des drivers alsa).
Sébastien BALLET
"Khanh-Dang" a écrit dans le message de news: 42a00ef3$0$879$
dans le fond, Linux et Java ont la liberté comme point commun : de choix pour linux, de choix du système sur lequel ont développe pour Java.
Oui, bien sûr. Et l'oiseau est libre parce qu'il peut gambader librement dans la toisième dimension, là où l'homme est naturellement lié au sol.
au lieu d'utiliser de jolies paraboles, essaies d'argumenter réellement.
"Khanh-Dang" <kd@fr.invalid> a écrit dans le message de news:
42a00ef3$0$879$8fcfb975@news.wanadoo.fr...
dans le fond, Linux et Java ont la
liberté comme point commun : de choix pour linux, de choix du système
sur lequel ont développe pour Java.
Oui, bien sûr. Et l'oiseau est libre parce qu'il peut gambader librement
dans la toisième dimension, là où l'homme est naturellement lié au sol.
au lieu d'utiliser de jolies paraboles, essaies d'argumenter réellement.
