On Tue, 31 May 2005 09:29:59 -0400, Denis Beauregard wrote:
1) vu la diversité des personnes qui trainent dans ce fora (moi même j'ai passé l'age de raison) il est bon d'accompagner les mots "à l'époque" d'une référence temporelle [a] qui permette de se situer [b]
Dans les années 1970 dans mon cas. Plus précisément: j'ai d'abord appris l'APL en 1973, puis le Basic en 1974
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)
Antonio Bravo <tonio_fuckspam@portalen.no> writes:
On Tue, 31 May 2005 09:29:59 -0400, Denis Beauregard wrote:
1) vu la diversité des personnes qui trainent dans ce fora (moi
même j'ai passé l'age de raison) il est bon d'accompagner les
mots "à l'époque" d'une référence temporelle [a] qui permette
de se situer [b]
Dans les années 1970 dans mon cas. Plus précisément:
j'ai d'abord appris l'APL en 1973, puis le Basic en 1974
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)
On Tue, 31 May 2005 09:29:59 -0400, Denis Beauregard wrote:
1) vu la diversité des personnes qui trainent dans ce fora (moi même j'ai passé l'age de raison) il est bon d'accompagner les mots "à l'époque" d'une référence temporelle [a] qui permette de se situer [b]
Dans les années 1970 dans mon cas. Plus précisément: j'ai d'abord appris l'APL en 1973, puis le Basic en 1974
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
Le Wed, 01 Jun 2005 13:18:07 +0200, Richard Delorme a écrit :
Ça n'a rien à voir. Le paradoxe de Solow concerne l'apport de l'informatique dans l'économie générale, or ici on discutait de l'apport d'un langage dans la productivité du programmeur. Que taper sur une machine à écrire soit aussi efficace que sur un ordinateur bureautique; que rechercher une fiche dans une armoire soit aussi rapide que faire une requête isolé sur une base de donnée, pourquoi pas ? Mais quel rapport avec un programmeur qui écrit une application en assembleur x86, et un autre une application similaire en Python ?
But, as we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity. In this article, I shall try to show why, by examining both the nature of the software problem and the properties of the bullets proposed. http://www.virtualschool.edu/mon/SoftwareEngineering/BrooksNoSilverBullet.html
Je résume l'article : l'idée est que les langages informatiques (comme d'autres techniques) ne représentent en eux même pas la promesse d'un gain de productivité d'un ordre de grandeur car les problèmes informatiques sont traités selon l'angle accidentelle (technique) et qu'ils ne s'attaquent pas à l'essence même de l'ingénierie logicielle qui reste que c'est une oeuvre de l'esprit basée sur la créativité.
-- "A belief is not true because it is useful." [Henri Frederic Amiel]
Le Wed, 01 Jun 2005 13:18:07 +0200, Richard Delorme a écrit :
Ça n'a rien à voir. Le paradoxe de Solow concerne l'apport de
l'informatique dans l'économie générale, or ici on discutait de l'apport
d'un langage dans la productivité du programmeur. Que taper sur une
machine à écrire soit aussi efficace que sur un ordinateur bureautique;
que rechercher une fiche dans une armoire soit aussi rapide que faire
une requête isolé sur une base de donnée, pourquoi pas ? Mais quel
rapport avec un programmeur qui écrit une application en assembleur x86,
et un autre une application similaire en Python ?
But, as we look to the horizon of a decade hence, we see no silver bullet.
There is no single development, in either technology or in management
technique, that by itself promises even one order-of-magnitude improvement
in productivity, in reliability, in simplicity. In this article, I shall
try to show why, by examining both the nature of the software problem and
the properties of the bullets proposed.
http://www.virtualschool.edu/mon/SoftwareEngineering/BrooksNoSilverBullet.html
Je résume l'article : l'idée est que les langages informatiques (comme
d'autres techniques) ne représentent en eux même pas la promesse d'un
gain de productivité d'un ordre de grandeur car les problèmes
informatiques sont traités selon l'angle accidentelle (technique) et
qu'ils ne s'attaquent pas à l'essence même de l'ingénierie logicielle
qui reste que c'est une oeuvre de l'esprit basée sur la créativité.
--
"A belief is not true because it is useful."
[Henri Frederic Amiel]
Le Wed, 01 Jun 2005 13:18:07 +0200, Richard Delorme a écrit :
Ça n'a rien à voir. Le paradoxe de Solow concerne l'apport de l'informatique dans l'économie générale, or ici on discutait de l'apport d'un langage dans la productivité du programmeur. Que taper sur une machine à écrire soit aussi efficace que sur un ordinateur bureautique; que rechercher une fiche dans une armoire soit aussi rapide que faire une requête isolé sur une base de donnée, pourquoi pas ? Mais quel rapport avec un programmeur qui écrit une application en assembleur x86, et un autre une application similaire en Python ?
But, as we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity. In this article, I shall try to show why, by examining both the nature of the software problem and the properties of the bullets proposed. http://www.virtualschool.edu/mon/SoftwareEngineering/BrooksNoSilverBullet.html
Je résume l'article : l'idée est que les langages informatiques (comme d'autres techniques) ne représentent en eux même pas la promesse d'un gain de productivité d'un ordre de grandeur car les problèmes informatiques sont traités selon l'angle accidentelle (technique) et qu'ils ne s'attaquent pas à l'essence même de l'ingénierie logicielle qui reste que c'est une oeuvre de l'esprit basée sur la créativité.
-- "A belief is not true because it is useful." [Henri Frederic Amiel]
remy
"Thierry Boudet" a écrit dans le message de news:
On 2005-05-30, Eric Jacoboni wrote:
Je ne trouve pas QT plus beau que Gnome, hein... Les bureaux sous Unix
Bon, QT et Gnome, ce n'est pas trop au même niveau. QT est un toulequite graphique, et Gnome le fondement d'un potentiel desquetaupe multi-système.
m'ont toujours fait gerber et je ne les ait jamais utilisé.
Bah, un de ces jours, un allumé° arrivera à inveter un "bureau"
ah ça c'est bien vrai comme dise la mere Denis cela manque serieusement d'imagination les bureaux
remplace les repertoires par des onglets de differentes couleurs et mettre a la place de l'arbre des icones qui changent en fct du type de fichier selectionne pour choisir son programme de retouche d'image par exemple cela changerait un peu
mais si tatie ginette attend que je reouvre un bouquin sur les toolkit elle risque d'attendre longtemps et tatie ginette elle est sous winsdows XP alors ...
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception remy
"Thierry Boudet" <tth@zouh.org> a écrit dans le message de
news:slrnd9ok0j.k73.tth@zouh.org...
On 2005-05-30, Eric Jacoboni <jaco@neottia.net> wrote:
Je ne trouve pas QT plus beau que Gnome, hein... Les bureaux sous Unix
Bon, QT et Gnome, ce n'est pas trop au même niveau. QT est
un toulequite graphique, et Gnome le fondement d'un potentiel
desquetaupe multi-système.
m'ont toujours fait gerber et je ne les ait jamais utilisé.
Bah, un de ces jours, un allumé° arrivera à inveter un "bureau"
ah ça c'est bien vrai comme dise la mere Denis
cela manque serieusement d'imagination les bureaux
remplace les repertoires par des onglets de differentes couleurs
et mettre a la place de l'arbre des icones qui changent en fct
du type de fichier selectionne pour choisir son programme
de retouche d'image
par exemple cela changerait un peu
mais si tatie ginette attend que je reouvre un bouquin
sur les toolkit elle risque d'attendre longtemps
et tatie ginette elle est sous winsdows XP
alors ...
--
des conneries j'en ai dites oui oui je vous assure...
mais elles n'engagent que votre perception
remy
Je ne trouve pas QT plus beau que Gnome, hein... Les bureaux sous Unix
Bon, QT et Gnome, ce n'est pas trop au même niveau. QT est un toulequite graphique, et Gnome le fondement d'un potentiel desquetaupe multi-système.
m'ont toujours fait gerber et je ne les ait jamais utilisé.
Bah, un de ces jours, un allumé° arrivera à inveter un "bureau"
ah ça c'est bien vrai comme dise la mere Denis cela manque serieusement d'imagination les bureaux
remplace les repertoires par des onglets de differentes couleurs et mettre a la place de l'arbre des icones qui changent en fct du type de fichier selectionne pour choisir son programme de retouche d'image par exemple cela changerait un peu
mais si tatie ginette attend que je reouvre un bouquin sur les toolkit elle risque d'attendre longtemps et tatie ginette elle est sous winsdows XP alors ...
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception remy
Je résume l'article : l'idée est que les langages informatiques (comme d'autres techniques) ne représentent en eux même pas la promesse d'un gain de productivité d'un ordre de grandeur car les problèmes informatiques sont traités selon l'angle accidentelle (technique) et qu'ils ne s'attaquent pas à l'essence même de l'ingénierie logicielle qui reste que c'est une oeuvre de l'esprit basée sur la créativité.
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
Bref, un certain nombre de langages et techniques de programmation clairement conçus avec l'idée d'améliorer la productivité sont postérieurs à cet article.
Je résume l'article : l'idée est que les langages informatiques (comme
d'autres techniques) ne représentent en eux même pas la promesse d'un
gain de productivité d'un ordre de grandeur car les problèmes
informatiques sont traités selon l'angle accidentelle (technique) et
qu'ils ne s'attaquent pas à l'essence même de l'ingénierie logicielle
qui reste que c'est une oeuvre de l'esprit basée sur la créativité.
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
Bref, un certain nombre de langages et techniques de programmation
clairement conçus avec l'idée d'améliorer la productivité sont
postérieurs à cet article.
Je résume l'article : l'idée est que les langages informatiques (comme d'autres techniques) ne représentent en eux même pas la promesse d'un gain de productivité d'un ordre de grandeur car les problèmes informatiques sont traités selon l'angle accidentelle (technique) et qu'ils ne s'attaquent pas à l'essence même de l'ingénierie logicielle qui reste que c'est une oeuvre de l'esprit basée sur la créativité.
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
Bref, un certain nombre de langages et techniques de programmation clairement conçus avec l'idée d'améliorer la productivité sont postérieurs à cet article.
-- Richard
remy
"jul" a écrit dans le message de news:
[suit une argumentation pleine de pragmatisme]
... Sauf qu'apprendre à programmer avec des langages de script de type shell, c'est un coup à prendre de mauvaises habitudes de programmation...
La seule mauvaise habitude que l'on peut prendre c'est de se faire chier quand on code. Le langage importe peu, me semble t'il. Aucune technique, aucun langage n'a pas montré permettre un gain de productivité *mesurable* depuis au moins 30 ans. Ce qui importe c'est d'être et de rester créatif à mon avis.
conclusion il faut banir ou faire un survol rapide les dissing Patent et autres approches uml qui a pu survivre a la lecture d'un de ses bouquins
je m'y suis essaye mais ils m'ont eu .... au 3/4 du bouquin depuis il hante les entrailles de ma bibliotheque
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception remy
"jul" <saponific@ti0n.net> a écrit dans le message de
news:pan.2005.06.01.01.47.41.48063@ti0n.net...
[suit une argumentation pleine de pragmatisme]
... Sauf qu'apprendre à programmer avec des langages de script de type
shell, c'est un coup à prendre de mauvaises habitudes de
programmation...
La seule mauvaise habitude que l'on peut prendre c'est de se faire chier
quand on code. Le langage importe peu, me semble t'il. Aucune
technique, aucun langage n'a pas montré permettre un gain de
productivité *mesurable* depuis au moins 30 ans. Ce qui importe c'est
d'être et de rester créatif à mon avis.
conclusion il faut banir ou faire un survol rapide
les dissing Patent et autres approches uml
qui a pu survivre a la lecture d'un de ses bouquins
je m'y suis essaye mais ils m'ont eu ....
au 3/4 du bouquin
depuis il hante les entrailles de ma bibliotheque
--
des conneries j'en ai dites oui oui je vous assure...
mais elles n'engagent que votre perception
remy
... Sauf qu'apprendre à programmer avec des langages de script de type shell, c'est un coup à prendre de mauvaises habitudes de programmation...
La seule mauvaise habitude que l'on peut prendre c'est de se faire chier quand on code. Le langage importe peu, me semble t'il. Aucune technique, aucun langage n'a pas montré permettre un gain de productivité *mesurable* depuis au moins 30 ans. Ce qui importe c'est d'être et de rester créatif à mon avis.
conclusion il faut banir ou faire un survol rapide les dissing Patent et autres approches uml qui a pu survivre a la lecture d'un de ses bouquins
je m'y suis essaye mais ils m'ont eu .... au 3/4 du bouquin depuis il hante les entrailles de ma bibliotheque
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception remy
jul
Le Wed, 01 Jun 2005 11:19:58 +0000, Nicolas George a écrit :
jul , dans le message , a écrit :
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é ». En effet, la croissance annuelle de la productivité apparente du travail et du progrès technique a considérablement ralenti à partir de 1973 (c'est-à-dire alors que l'ordinateur se diffusait dans l'économie), ains.
Une coïncidence de temps n'est pas la peuve d'une cause dans un certain sens.
De même que c'est une coincidence que quand on lache une pomme elle
tombe. mmouarf !)
La physique est alors un acte de (mauvaise) foi, qui marche plutôt bien :)
En outre, des évaluations plus fines ont été menées : l'informatique augmente la productivité quand son introduction est accompagnée d'une formation adaptée, la diminue sinon.
http://www.insee.fr/fr/ffc/docs_ffc/ES339E.pdf
L'augmentation n'est pas impressionante (moins de quelque pourcent), et l'étude dit que les changement ne sont constatés que si et seulement si un accompagnement est fait. Personnellement, je demanderais bien si l'accompagnement humain et les réorganisations du travail (indépendemment de l'outil informatique) ne peuvent pas à elle même expliquer les gains de productivité constaté.
Si on lit bêtement le paradoxe de Solow on pourrait penser que le but des informaticiens c'est de se générer une activité économique inutile : bref ce sont des shadocks.
-- "Good health" is merely the slowest rate at which one can die.
Le Wed, 01 Jun 2005 11:19:58 +0000, Nicolas George a écrit :
jul , dans le message <pan.2005.06.01.09.31.58.99495@ti0n.net>, a
écrit :
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é
». En effet, la croissance annuelle de la productivité apparente du
travail et du progrès technique a considérablement ralenti à partir de
1973 (c'est-à-dire alors que l'ordinateur se diffusait dans l'économie),
ains.
Une coïncidence de temps n'est pas la peuve d'une cause dans un certain
sens.
De même que c'est une coincidence que quand on lache une pomme elle
tombe. mmouarf !)
La physique est alors un acte de (mauvaise) foi, qui marche plutôt bien :)
En outre, des évaluations plus fines ont été menées : l'informatique
augmente la productivité quand son introduction est accompagnée d'une
formation adaptée, la diminue sinon.
http://www.insee.fr/fr/ffc/docs_ffc/ES339E.pdf
L'augmentation n'est pas impressionante (moins de quelque pourcent), et
l'étude dit que les changement ne sont constatés que si et seulement si
un accompagnement est fait. Personnellement, je demanderais bien si
l'accompagnement humain et les réorganisations du travail
(indépendemment de l'outil informatique) ne peuvent pas à elle même
expliquer les gains de productivité constaté.
Si on lit bêtement le paradoxe de Solow on pourrait penser que le but des
informaticiens c'est de se générer une activité économique inutile :
bref ce sont des shadocks.
--
"Good health" is merely the slowest rate at which one can die.
Le Wed, 01 Jun 2005 11:19:58 +0000, Nicolas George a écrit :
jul , dans le message , a écrit :
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é ». En effet, la croissance annuelle de la productivité apparente du travail et du progrès technique a considérablement ralenti à partir de 1973 (c'est-à-dire alors que l'ordinateur se diffusait dans l'économie), ains.
Une coïncidence de temps n'est pas la peuve d'une cause dans un certain sens.
De même que c'est une coincidence que quand on lache une pomme elle
tombe. mmouarf !)
La physique est alors un acte de (mauvaise) foi, qui marche plutôt bien :)
En outre, des évaluations plus fines ont été menées : l'informatique augmente la productivité quand son introduction est accompagnée d'une formation adaptée, la diminue sinon.
http://www.insee.fr/fr/ffc/docs_ffc/ES339E.pdf
L'augmentation n'est pas impressionante (moins de quelque pourcent), et l'étude dit que les changement ne sont constatés que si et seulement si un accompagnement est fait. Personnellement, je demanderais bien si l'accompagnement humain et les réorganisations du travail (indépendemment de l'outil informatique) ne peuvent pas à elle même expliquer les gains de productivité constaté.
Si on lit bêtement le paradoxe de Solow on pourrait penser que le but des informaticiens c'est de se générer une activité économique inutile : bref ce sont des shadocks.
-- "Good health" is merely the slowest rate at which one can die.
jul
Le Wed, 01 Jun 2005 16:34:19 +0200, Richard Delorme a écrit :
...
Je résume l'article : l'idée est que les langages informatiques (comme d'autres techniques) ne représentent en eux même pas la promesse d'un gain de productivité d'un ordre de grandeur car les problèmes informatiques sont traités selon l'angle accidentelle (technique) et qu'ils ne s'attaquent pas à l'essence même de l'ingénierie logicielle qui reste que c'est une oeuvre de l'esprit basée sur la créativité.
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) ?
Steve Mc Connell commence *tous* ses livres par le rappel de la dépendance au talent de codeurs, et rappelle d'abord que réussir un projet c'est employer les bonnes ressources humaines avant de s'intéresser à la technique (lire notamment rapid development)
Le logiciel libre est-il tellement différent de ce qui est dit par Mc Connell et Brooks ? Unix est un concept vieux de 30 ans et pourtant il finit par tenir face à toutes les soit disant innovations qui menacent de changer le monde (les jvm, le .net, les thins client, les systèmes réticulaires). Dans le libre a-ton le meilleur compilo C ? A-t'on les meilleures implémentations des normes (ANSI C,IEEE xxx, Radius, SQL ...) les «meilleurs langages» ?
Non, on a probablement juste de bons codeurs si vous considérez linux et BSD (basé sur des vieux concepts et langages, et normes). Ou oui, si vous regardez la réussite qu'est hurd : un changement paradigmatique et technique en tout point.
Enfin, moi je préfère linux à Hurd.
-- Human beings were created by water to transport it uphill.
Le Wed, 01 Jun 2005 16:34:19 +0200, Richard Delorme a écrit :
...
Je résume l'article : l'idée est que les langages informatiques
(comme d'autres techniques) ne représentent en eux même pas la
promesse d'un gain de productivité d'un ordre de grandeur car les
problèmes informatiques sont traités selon l'angle accidentelle
(technique) et qu'ils ne s'attaquent pas à l'essence même de
l'ingénierie logicielle qui reste que c'est une oeuvre de l'esprit
basée sur la créativité.
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) ?
Steve Mc Connell commence *tous* ses livres par le rappel de la
dépendance au talent de codeurs, et rappelle d'abord que réussir un
projet c'est employer les bonnes ressources humaines avant de
s'intéresser à la technique (lire notamment rapid development)
Le logiciel libre est-il tellement différent de ce qui est dit par Mc
Connell et Brooks ? Unix est un concept vieux de 30 ans et pourtant il
finit par tenir face à toutes les soit disant innovations qui menacent de
changer le monde (les jvm, le .net, les thins client, les systèmes
réticulaires). Dans le libre a-ton le meilleur compilo C ? A-t'on les
meilleures implémentations des normes (ANSI C,IEEE xxx, Radius, SQL ...)
les «meilleurs langages» ?
Non, on a probablement juste de bons codeurs si vous considérez linux et
BSD (basé sur des vieux concepts et langages, et normes). Ou oui, si vous
regardez la réussite qu'est hurd : un changement paradigmatique et
technique en tout point.
Enfin, moi je préfère linux à Hurd.
--
Human beings were created by water to transport it uphill.
Le Wed, 01 Jun 2005 16:34:19 +0200, Richard Delorme a écrit :
...
Je résume l'article : l'idée est que les langages informatiques (comme d'autres techniques) ne représentent en eux même pas la promesse d'un gain de productivité d'un ordre de grandeur car les problèmes informatiques sont traités selon l'angle accidentelle (technique) et qu'ils ne s'attaquent pas à l'essence même de l'ingénierie logicielle qui reste que c'est une oeuvre de l'esprit basée sur la créativité.
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) ?
Steve Mc Connell commence *tous* ses livres par le rappel de la dépendance au talent de codeurs, et rappelle d'abord que réussir un projet c'est employer les bonnes ressources humaines avant de s'intéresser à la technique (lire notamment rapid development)
Le logiciel libre est-il tellement différent de ce qui est dit par Mc Connell et Brooks ? Unix est un concept vieux de 30 ans et pourtant il finit par tenir face à toutes les soit disant innovations qui menacent de changer le monde (les jvm, le .net, les thins client, les systèmes réticulaires). Dans le libre a-ton le meilleur compilo C ? A-t'on les meilleures implémentations des normes (ANSI C,IEEE xxx, Radius, SQL ...) les «meilleurs langages» ?
Non, on a probablement juste de bons codeurs si vous considérez linux et BSD (basé sur des vieux concepts et langages, et normes). Ou oui, si vous regardez la réussite qu'est hurd : un changement paradigmatique et technique en tout point.
Enfin, moi je préfère linux à Hurd.
-- Human beings were created by water to transport it uphill.
Nicolas George
jul , dans le message , a écrit :
La seule mauvaise habitude que l'on peut prendre c'est de se faire chier quand on code.
Bullshit. Il y a énormément de mauvais réflexes qu'on peut facilement prendre si on n'y prend pas garde (et si le langage les facilite), et qui rendent ensuite la maintenance des programmes un vrai cauchemar. Parmi ces réflexes, les premiers qui viennent à l'esprit sont un mauvais nommage des variables, une utilisation intensive des variables globales, une mauvaise indentation, l'utilisation de structures de données inadaptées, l'utilisation de constructions qui ne marchent pas dans les cas limites, etc.
jul , dans le message <pan.2005.06.01.01.47.41.48063@ti0n.net>, a
écrit :
La seule mauvaise habitude que l'on peut prendre c'est de se faire chier
quand on code.
Bullshit. Il y a énormément de mauvais réflexes qu'on peut facilement
prendre si on n'y prend pas garde (et si le langage les facilite), et qui
rendent ensuite la maintenance des programmes un vrai cauchemar. Parmi ces
réflexes, les premiers qui viennent à l'esprit sont un mauvais nommage des
variables, une utilisation intensive des variables globales, une mauvaise
indentation, l'utilisation de structures de données inadaptées,
l'utilisation de constructions qui ne marchent pas dans les cas limites,
etc.
La seule mauvaise habitude que l'on peut prendre c'est de se faire chier quand on code.
Bullshit. Il y a énormément de mauvais réflexes qu'on peut facilement prendre si on n'y prend pas garde (et si le langage les facilite), et qui rendent ensuite la maintenance des programmes un vrai cauchemar. Parmi ces réflexes, les premiers qui viennent à l'esprit sont un mauvais nommage des variables, une utilisation intensive des variables globales, une mauvaise indentation, l'utilisation de structures de données inadaptées, l'utilisation de constructions qui ne marchent pas dans les cas limites, etc.
l'indien
On Wed, 01 Jun 2005 16:27:07 +0000, Nicolas George wrote:
jul , dans le message , a écrit :
La seule mauvaise habitude que l'on peut prendre c'est de se faire chier quand on code.
Bullshit. Il y a énormément de mauvais réflexes qu'on peut facilement prendre si on n'y prend pas garde (et si le langage les facilite), et qui rendent ensuite la maintenance des programmes un vrai cauchemar. Parmi ces réflexes, les premiers qui viennent à l'esprit sont un mauvais nommage des variables, une utilisation intensive des variables globales, une mauvaise indentation, l'utilisation de structures de données inadaptées, l'utilisation de constructions qui ne marchent pas dans les cas limites, etc.
Tout dépend du contexte. Quand tu dois executer du code dans un secteur de boot ou dans une petite SRAM, il est souvent indispensable d'utiliser des variables globales dans des registres pour diminuer la taille du code compilé, c'est un grand classique ;-)
Une autre faute à éviter: se baser sur des comportements du compilateurs (ou de l'interpréteur, le cas échéant) qui ne sont pas définis dans la norme (même s'ils sont communément acceptés comme valides par la plupart des programmeurs)... Sinon, grosse prise de têtes en perspective quand on change d'outils ou d'environnement....
On Wed, 01 Jun 2005 16:27:07 +0000, Nicolas George wrote:
jul , dans le message <pan.2005.06.01.01.47.41.48063@ti0n.net>, a
écrit :
La seule mauvaise habitude que l'on peut prendre c'est de se faire chier
quand on code.
Bullshit. Il y a énormément de mauvais réflexes qu'on peut facilement
prendre si on n'y prend pas garde (et si le langage les facilite), et qui
rendent ensuite la maintenance des programmes un vrai cauchemar. Parmi ces
réflexes, les premiers qui viennent à l'esprit sont un mauvais nommage des
variables, une utilisation intensive des variables globales, une mauvaise
indentation, l'utilisation de structures de données inadaptées,
l'utilisation de constructions qui ne marchent pas dans les cas limites,
etc.
Tout dépend du contexte.
Quand tu dois executer du code dans un secteur de boot ou dans une petite
SRAM, il est souvent indispensable d'utiliser des variables globales dans
des registres pour diminuer la taille du code compilé, c'est un grand
classique ;-)
Une autre faute à éviter: se baser sur des comportements du compilateurs
(ou de l'interpréteur, le cas échéant) qui ne sont pas définis dans la
norme (même s'ils sont communément acceptés comme valides par la
plupart des programmeurs)...
Sinon, grosse prise de têtes en perspective quand on change d'outils ou
d'environnement....
On Wed, 01 Jun 2005 16:27:07 +0000, Nicolas George wrote:
jul , dans le message , a écrit :
La seule mauvaise habitude que l'on peut prendre c'est de se faire chier quand on code.
Bullshit. Il y a énormément de mauvais réflexes qu'on peut facilement prendre si on n'y prend pas garde (et si le langage les facilite), et qui rendent ensuite la maintenance des programmes un vrai cauchemar. Parmi ces réflexes, les premiers qui viennent à l'esprit sont un mauvais nommage des variables, une utilisation intensive des variables globales, une mauvaise indentation, l'utilisation de structures de données inadaptées, l'utilisation de constructions qui ne marchent pas dans les cas limites, etc.
Tout dépend du contexte. Quand tu dois executer du code dans un secteur de boot ou dans une petite SRAM, il est souvent indispensable d'utiliser des variables globales dans des registres pour diminuer la taille du code compilé, c'est un grand classique ;-)
Une autre faute à éviter: se baser sur des comportements du compilateurs (ou de l'interpréteur, le cas échéant) qui ne sont pas définis dans la norme (même s'ils sont communément acceptés comme valides par la plupart des programmeurs)... Sinon, grosse prise de têtes en perspective quand on change d'outils ou d'environnement....
nicolas vigier
On 2005-06-01, Sébastien BALLET wrote:
relis ce que j'ai écrit et peut être que dans 10 ou 15 ans tu auras compris ce que j'ai dis.
Et bien continues d'utiliser tes logiciels proprietaires et peut etre que dans 10 ou 15 ans tu auras compris pourquoi il faut s'en mefier.
