--
Car avec beaucoup de science, il y a beaucoup de chagrin ; et celui qui
accroît sa science accroît sa douleur.
[Ecclésiaste, 1-18]
MELMOTH - souffrant
interdit dans le rules guide de programmation de l'US air force par exemple :-)
Tu te rends compte que tu es en train de parler de l'US air force à un débile qui chasse la palombe, et pêche des trucs bizarres dont ils raffolent par là ?
-- -- Ricco
Stephane Legras-Decussy wrote:
Le 11/07/2010 23:19, Ofnuts a écrit :
Quand on commence à causer d'héritage multiple
Evil !
interdit dans le rules guide
de programmation de l'US air force par exemple :-)
Tu te rends compte que tu es en train de parler de l'US air force à un
débile qui chasse la palombe, et pêche des trucs bizarres dont ils raffolent
par là ?
interdit dans le rules guide de programmation de l'US air force par exemple :-)
Tu te rends compte que tu es en train de parler de l'US air force à un débile qui chasse la palombe, et pêche des trucs bizarres dont ils raffolent par là ?
-- -- Ricco
Ofnuts
On 12/07/2010 00:13, Stephane Legras-Decussy wrote:
Le 11/07/2010 23:18, Ofnuts a écrit :
Je ne pense pas non plus que l'architecture de logiciel soit un domaine particulièrement trivial.
+1
c'est clair. une fois le projet découpé en fonctions, le boulot est fini.
taper le code de chaque fonction quand son interface est connue, c'est les vacances...
ensuite t'as monsieur gros boulet qui vient dire qu'il faut changer des interfaces de fonctions... et plouf...
Et c'est la que la programmation objet te permet de le faire en un tournemain...
Maintenant, quand on code pour d'autres, on leur demande d'abord de signer la spec avec leur sang avant décrire une ligne... et s'ils changent d'avis, ça devient très cher.
-- Bertrand
On 12/07/2010 00:13, Stephane Legras-Decussy wrote:
Le 11/07/2010 23:18, Ofnuts a écrit :
Je ne pense pas non plus que l'architecture de logiciel soit un domaine
particulièrement trivial.
+1
c'est clair.
une fois le projet découpé en fonctions,
le boulot est fini.
taper le code de chaque
fonction quand son interface est connue,
c'est les vacances...
ensuite t'as monsieur gros boulet qui vient
dire qu'il faut changer des interfaces de
fonctions... et plouf...
Et c'est la que la programmation objet te permet de le faire en un
tournemain...
Maintenant, quand on code pour d'autres, on leur demande d'abord de
signer la spec avec leur sang avant décrire une ligne... et s'ils
changent d'avis, ça devient très cher.
On 12/07/2010 00:13, Stephane Legras-Decussy wrote:
Le 11/07/2010 23:18, Ofnuts a écrit :
Je ne pense pas non plus que l'architecture de logiciel soit un domaine particulièrement trivial.
+1
c'est clair. une fois le projet découpé en fonctions, le boulot est fini.
taper le code de chaque fonction quand son interface est connue, c'est les vacances...
ensuite t'as monsieur gros boulet qui vient dire qu'il faut changer des interfaces de fonctions... et plouf...
Et c'est la que la programmation objet te permet de le faire en un tournemain...
Maintenant, quand on code pour d'autres, on leur demande d'abord de signer la spec avec leur sang avant décrire une ligne... et s'ils changent d'avis, ça devient très cher.
-- Bertrand
Ofnuts
On 11/07/2010 23:47, YouDontNeedToKnowButItsNoëlle wrote:
Le 11/07/10 23:19, Ofnuts a écrit :
Quand on commence à causer d'héritage multiple et de l'ordre d'éxécution des constructeurs qui va avec, c'est loin d'être trivial. Sinon, oui, les meilleures idées sont les plus simples et la programmation objet ne fait pas exception. Mais ce qui est pompeux dans l'objet ce sont les gourous qui gravitent autour...
Tu penses à quelqu'un en particulier ? Un Bertrand aussi :) assez content de lui, et fort brillant ce le justifie presque mais pas vraiment ?. Sinon les gens de l'objet ne m'ont jamais parus plus pompeux que les autres...Enfin bon je ne sais pas comment c'est dans l'industrie.
Non, je pense à ceux qui vendent comme "méthodologie" une collection de recette de cuisine qu'ils ont pompés sur d'autres, par exemple. -- Bertrand
On 11/07/2010 23:47, YouDontNeedToKnowButItsNoëlle wrote:
Le 11/07/10 23:19, Ofnuts a écrit :
Quand on commence à causer d'héritage multiple et de l'ordre d'éxécution
des constructeurs qui va avec, c'est loin d'être trivial. Sinon, oui,
les meilleures idées sont les plus simples et la programmation objet ne
fait pas exception. Mais ce qui est pompeux dans l'objet ce sont les
gourous qui gravitent autour...
Tu penses à quelqu'un en particulier ? Un Bertrand aussi :) assez
content de lui, et fort brillant ce le justifie presque mais pas
vraiment ?. Sinon les gens de l'objet ne m'ont jamais parus plus pompeux
que les autres...Enfin bon je ne sais pas comment c'est dans l'industrie.
Non, je pense à ceux qui vendent comme "méthodologie" une collection de
recette de cuisine qu'ils ont pompés sur d'autres, par exemple.
--
Bertrand
On 11/07/2010 23:47, YouDontNeedToKnowButItsNoëlle wrote:
Le 11/07/10 23:19, Ofnuts a écrit :
Quand on commence à causer d'héritage multiple et de l'ordre d'éxécution des constructeurs qui va avec, c'est loin d'être trivial. Sinon, oui, les meilleures idées sont les plus simples et la programmation objet ne fait pas exception. Mais ce qui est pompeux dans l'objet ce sont les gourous qui gravitent autour...
Tu penses à quelqu'un en particulier ? Un Bertrand aussi :) assez content de lui, et fort brillant ce le justifie presque mais pas vraiment ?. Sinon les gens de l'objet ne m'ont jamais parus plus pompeux que les autres...Enfin bon je ne sais pas comment c'est dans l'industrie.
Non, je pense à ceux qui vendent comme "méthodologie" une collection de recette de cuisine qu'ils ont pompés sur d'autres, par exemple. -- Bertrand
Ofnuts
On 12/07/2010 00:25, Stephane Legras-Decussy wrote:
Le 11/07/2010 23:19, Ofnuts a écrit :
Quand on commence à causer d'héritage multiple
Evil !
interdit dans le rules guide de programmation de l'US air force par exemple :-)
Pas impossible... c'est aussi pour ça qu'il n'y en a pas en Java. Mais du coup on est amené a faire des trucs encore plus horribles. Par exemple en Java on utilise des interfaces mais ça permet de prendre beaucoup de libertés avec les attributs.
D'un autre côté, je ne travaille pas pour l'USAF(*)
(*) mais pour des clients qui ont des préventions contre les instructions ternaires, les opérateurs composites (+= et consorts) ou l'instruction switch -- Bertrand
On 12/07/2010 00:25, Stephane Legras-Decussy wrote:
Le 11/07/2010 23:19, Ofnuts a écrit :
Quand on commence à causer d'héritage multiple
Evil !
interdit dans le rules guide
de programmation de l'US air force par exemple :-)
Pas impossible... c'est aussi pour ça qu'il n'y en a pas en Java. Mais
du coup on est amené a faire des trucs encore plus horribles. Par
exemple en Java on utilise des interfaces mais ça permet de prendre
beaucoup de libertés avec les attributs.
D'un autre côté, je ne travaille pas pour l'USAF(*)
(*) mais pour des clients qui ont des préventions contre les
instructions ternaires, les opérateurs composites (+= et consorts) ou
l'instruction switch
--
Bertrand
On 12/07/2010 00:25, Stephane Legras-Decussy wrote:
Le 11/07/2010 23:19, Ofnuts a écrit :
Quand on commence à causer d'héritage multiple
Evil !
interdit dans le rules guide de programmation de l'US air force par exemple :-)
Pas impossible... c'est aussi pour ça qu'il n'y en a pas en Java. Mais du coup on est amené a faire des trucs encore plus horribles. Par exemple en Java on utilise des interfaces mais ça permet de prendre beaucoup de libertés avec les attributs.
D'un autre côté, je ne travaille pas pour l'USAF(*)
(*) mais pour des clients qui ont des préventions contre les instructions ternaires, les opérateurs composites (+= et consorts) ou l'instruction switch -- Bertrand
Alban Taraire
On Sun, 11 Jul 2010 13:03:50 +0200, Stephane Legras-Decussy wrote:
Le 11/07/2010 12:09, Alban Taraire a écrit :
Mais ca boot tout seul, c'est le principal !
bah oui ton winPE il a pas besoin d'OS, c'est cool non ?
Ah ouais trop cool, d'ailleurs mon Linux non plus a pas besoin d'OS, mon windows non plus, ni mon MacOSX, ni mon AmigaOS, ni mon PalmOS, ni mon AIX, ni mon Solaris (on continue ?).
En fait le seul OS qui ait besoin d'un OS, ça doit être la VM Java...
Trodlabal !
-- Alban
On Sun, 11 Jul 2010 13:03:50 +0200, Stephane Legras-Decussy wrote:
Le 11/07/2010 12:09, Alban Taraire a écrit :
Mais ca boot tout seul, c'est le principal !
bah oui ton winPE il a pas besoin d'OS, c'est cool non ?
Ah ouais trop cool, d'ailleurs mon Linux non plus a pas besoin d'OS, mon
windows non plus, ni mon MacOSX, ni mon AmigaOS, ni mon PalmOS, ni mon
AIX, ni mon Solaris (on continue ?).
En fait le seul OS qui ait besoin d'un OS, ça doit être la VM Java...
On Sun, 11 Jul 2010 13:03:50 +0200, Stephane Legras-Decussy wrote:
Le 11/07/2010 12:09, Alban Taraire a écrit :
Mais ca boot tout seul, c'est le principal !
bah oui ton winPE il a pas besoin d'OS, c'est cool non ?
Ah ouais trop cool, d'ailleurs mon Linux non plus a pas besoin d'OS, mon windows non plus, ni mon MacOSX, ni mon AmigaOS, ni mon PalmOS, ni mon AIX, ni mon Solaris (on continue ?).
En fait le seul OS qui ait besoin d'un OS, ça doit être la VM Java...
Trodlabal !
-- Alban
Stephane Legras-Decussy
Le 12/07/2010 02:36, Ofnuts a écrit :
(*) mais pour des clients qui ont des préventions contre les instructions ternaires, les opérateurs composites (+= et consorts) ou l'instruction switch
de même dans le document de l'USAF,
le pilote de F15 deteste les écrans bleus de la mort :-)
Le 12/07/2010 02:36, Ofnuts a écrit :
(*) mais pour des clients qui ont des préventions contre les
instructions ternaires, les opérateurs composites (+= et consorts) ou
l'instruction switch
de même dans le document de l'USAF,
le pilote de F15 deteste les écrans bleus de la mort :-)
(*) mais pour des clients qui ont des préventions contre les instructions ternaires, les opérateurs composites (+= et consorts) ou l'instruction switch
de même dans le document de l'USAF,
le pilote de F15 deteste les écrans bleus de la mort :-)
Stephane Legras-Decussy
Le 12/07/2010 02:25, Ofnuts a écrit :
Maintenant, quand on code pour d'autres, on leur demande d'abord de signer la spec avec leur sang avant décrire une ligne... et s'ils changent d'avis, ça devient très cher.
j'avais lu, je ne sais pas si c'est vrai, que 50% des projets informatiques étaient abandonnés après un an de boulot...
le client change d'avis, le besoin a disparu, le chef de projet est nul (ou mort), etc
Le 12/07/2010 02:25, Ofnuts a écrit :
Maintenant, quand on code pour d'autres, on leur demande d'abord de
signer la spec avec leur sang avant décrire une ligne... et s'ils
changent d'avis, ça devient très cher.
j'avais lu, je ne sais pas si c'est vrai, que 50%
des projets informatiques étaient abandonnés après un an
de boulot...
le client change d'avis, le besoin a disparu,
le chef de projet est nul (ou mort), etc
Maintenant, quand on code pour d'autres, on leur demande d'abord de signer la spec avec leur sang avant décrire une ligne... et s'ils changent d'avis, ça devient très cher.
j'avais lu, je ne sais pas si c'est vrai, que 50% des projets informatiques étaient abandonnés après un an de boulot...
le client change d'avis, le besoin a disparu, le chef de projet est nul (ou mort), etc
Ofnuts
On 12/07/2010 13:48, Stephane Legras-Decussy wrote:
Le 12/07/2010 02:25, Ofnuts a écrit :
Maintenant, quand on code pour d'autres, on leur demande d'abord de signer la spec avec leur sang avant décrire une ligne... et s'ils changent d'avis, ça devient très cher.
j'avais lu, je ne sais pas si c'est vrai, que 50% des projets informatiques étaient abandonnés après un an de boulot...
C'est faux.... il faut souvent deux ans :-)
le client change d'avis, le besoin a disparu, le chef de projet est nul (ou mort), etc
Le client s'aperçoit que subitement ce qu'il demande est en fait très cher... Dans mon experience, 90% du coût du projet vient de 10% des specs, et vice-versa.
-- Bertrand
On 12/07/2010 13:48, Stephane Legras-Decussy wrote:
Le 12/07/2010 02:25, Ofnuts a écrit :
Maintenant, quand on code pour d'autres, on leur demande d'abord de
signer la spec avec leur sang avant décrire une ligne... et s'ils
changent d'avis, ça devient très cher.
j'avais lu, je ne sais pas si c'est vrai, que 50%
des projets informatiques étaient abandonnés après un an
de boulot...
C'est faux.... il faut souvent deux ans :-)
le client change d'avis, le besoin a disparu,
le chef de projet est nul (ou mort), etc
Le client s'aperçoit que subitement ce qu'il demande est en fait très
cher... Dans mon experience, 90% du coût du projet vient de 10% des
specs, et vice-versa.
On 12/07/2010 13:48, Stephane Legras-Decussy wrote:
Le 12/07/2010 02:25, Ofnuts a écrit :
Maintenant, quand on code pour d'autres, on leur demande d'abord de signer la spec avec leur sang avant décrire une ligne... et s'ils changent d'avis, ça devient très cher.
j'avais lu, je ne sais pas si c'est vrai, que 50% des projets informatiques étaient abandonnés après un an de boulot...
C'est faux.... il faut souvent deux ans :-)
le client change d'avis, le besoin a disparu, le chef de projet est nul (ou mort), etc
Le client s'aperçoit que subitement ce qu'il demande est en fait très cher... Dans mon experience, 90% du coût du projet vient de 10% des specs, et vice-versa.
-- Bertrand
Ghost-Rider
Le 12/07/2010 13:58, Ofnuts a écrit :
On 12/07/2010 13:48, Stephane Legras-Decussy wrote:
j'avais lu, je ne sais pas si c'est vrai, que 50% des projets informatiques étaient abandonnés après un an de boulot...
C'est faux.... il faut souvent deux ans :-)
Et encore, quand c'est deux ans, ça va encore, mais il arrive que le projet enfin livré, testé, paramétré, débugué, payé avec toutes ses rallonges, ne soit jamais utilisé parce que le monde change et que le personnel n'y comprend rien. J'ai des noms !
le client change d'avis, le besoin a disparu, le chef de projet est nul (ou mort), etc
Le client s'aperçoit que subitement ce qu'il demande est en fait très cher... Dans mon experience, 90% du coût du projet vient de 10% des specs, et vice-versa.
Tout-à-fait. Le client choisit un standard par économie et demande tellement de modifications pour coller à son organisation fautive qu'il se retrouve au bout du compte avec un système plus cher que du sur-mesure et bien moins performant. Du reste, le personnel ne s'y trompe pas et délaisse le monstre. Là encore, j'ai des noms !
-- Ghost Rider
"Aimez-vous les uns les autres". Jésus-Christ
Le 12/07/2010 13:58, Ofnuts a écrit :
On 12/07/2010 13:48, Stephane Legras-Decussy wrote:
j'avais lu, je ne sais pas si c'est vrai, que 50%
des projets informatiques étaient abandonnés après un an
de boulot...
C'est faux.... il faut souvent deux ans :-)
Et encore, quand c'est deux ans, ça va encore, mais il arrive que le
projet enfin livré, testé, paramétré, débugué, payé avec toutes ses
rallonges, ne soit jamais utilisé parce que le monde change et que le
personnel n'y comprend rien.
J'ai des noms !
le client change d'avis, le besoin a disparu,
le chef de projet est nul (ou mort), etc
Le client s'aperçoit que subitement ce qu'il demande est en fait très
cher... Dans mon experience, 90% du coût du projet vient de 10% des
specs, et vice-versa.
Tout-à-fait. Le client choisit un standard par économie et demande
tellement de modifications pour coller à son organisation fautive qu'il
se retrouve au bout du compte avec un système plus cher que du
sur-mesure et bien moins performant.
Du reste, le personnel ne s'y trompe pas et délaisse le monstre.
Là encore, j'ai des noms !
On 12/07/2010 13:48, Stephane Legras-Decussy wrote:
j'avais lu, je ne sais pas si c'est vrai, que 50% des projets informatiques étaient abandonnés après un an de boulot...
C'est faux.... il faut souvent deux ans :-)
Et encore, quand c'est deux ans, ça va encore, mais il arrive que le projet enfin livré, testé, paramétré, débugué, payé avec toutes ses rallonges, ne soit jamais utilisé parce que le monde change et que le personnel n'y comprend rien. J'ai des noms !
le client change d'avis, le besoin a disparu, le chef de projet est nul (ou mort), etc
Le client s'aperçoit que subitement ce qu'il demande est en fait très cher... Dans mon experience, 90% du coût du projet vient de 10% des specs, et vice-versa.
Tout-à-fait. Le client choisit un standard par économie et demande tellement de modifications pour coller à son organisation fautive qu'il se retrouve au bout du compte avec un système plus cher que du sur-mesure et bien moins performant. Du reste, le personnel ne s'y trompe pas et délaisse le monstre. Là encore, j'ai des noms !
-- Ghost Rider
"Aimez-vous les uns les autres". Jésus-Christ
Alban Taraire
On Mon, 12 Jul 2010 13:58:24 +0200, Stephane Legras-Decussy wrote:
sans rire, on décider d'appeller OS n'importe quel logiciel bootable, je trouve juste ça completement con.
Franchement, appeler brique n'importe quel parallelepipède rectangle en terre cuite fait pour construire des murs, je trouve ça complètement con.
Mais on appelle ça une définition, trop dure la vie !
-- Alban
On Mon, 12 Jul 2010 13:58:24 +0200, Stephane Legras-Decussy wrote:
sans rire,
on décider d'appeller OS n'importe quel logiciel bootable, je trouve
juste ça completement con.
Franchement, appeler brique n'importe quel parallelepipède rectangle en
terre cuite fait pour construire des murs, je trouve ça complètement con.
Mais on appelle ça une définition, trop dure la vie !
