je viens d'installer Mandriva 2007 sur un portable acer TM230
Probleme :
le systeme arrete pour un soucis de temperature critique 77°
Bon je fais un tour sur google et je vois qu'il faut faire un acpi=off
au boot.
Mais là un autre probleme apparait : Kernel Panic
Bon ben je me dis que la migration vers linux commence bien :o(
Non, pas du tout. La détection des erreurs de type se fait à la compil, et c'est très peu informatif. Une erreur de type au runtime, ça par contre c'est informatif.
Les erreurs de type à la compilation sont celles qui se seraient produites à l'exécution, tu sais. Autant les corriger les plus tôt possible. Et en pratique, pour peu qu'on s'en tienne à quelques règles élémentaires de propreté du code, comme le pas réutiliser le même nom de variable pour deux choses différentes dans le même contexte, les erreurs de type sont presque toujours détectables à la compilation.
Surtout si le programme ne plante pas comme une merde et éventuellement fonctionne malgré tout (une erreur de type à l'affichage, par exemple, n'est pas une catastrophe).
Je ne suis pas d'accord du tout. Ce que tu décris, on appelle ça de la programmation défensive. Dans les cas courants, c'est une mauvaise idée : un bug dans un programme, il faut le corriger, on ne peut pas se contenter de croiser les doigts en espérant que le résultat ne sera pas trop faux. Les conversions numériques automatiques à la perl, elles peuvent justement causer un résultat subtilement faux, avec le bon ordre de grandeur, mais une valeur suffisamment fausse pour que le résultat soit inutilisable. Et si on ne s'en rend pas compte tout de suite, les résultats peuvent être catastrophiques.
En plus l'obligation de transtyper et caster dans tous les sens sans arrêt alourdit le code
Tu te trompes. Une vérification statique de types n'implique pas de transtyper dans tous les sens. Un transtypage est quelque chose de fondamentalement exceptionnel, parce que le type, c'est justement ce qu'on peut faire avec un objet. Quand on a une connexion réseau, on peut faire tous les transtypages qu'on voudra, on n'arrivera pas à la faire rentrer dans un produit vectoriel.
Que la vérification soit faite à la compilation n'interdit absolument pas le polymorphisme est les conversions automatiques.
Certains langages sont un peu pénibles de ce point de vue, il est vrai, parce que la combinaison de polymorphisme et de détection automatique de type peut conduire à des cas indécidables, mais la plupart des cas pratiques sont en fait parfaitement triviaux.
Emmanuel Florac , dans le message
<pan.2007.01.04.15.46.00.803241@imaginet.fr>, a écrit :
Non, pas du tout. La détection des erreurs de type se fait à la compil,
et c'est très peu informatif. Une erreur de type au runtime, ça par
contre c'est informatif.
Les erreurs de type à la compilation sont celles qui se seraient produites à
l'exécution, tu sais. Autant les corriger les plus tôt possible. Et en
pratique, pour peu qu'on s'en tienne à quelques règles élémentaires de
propreté du code, comme le pas réutiliser le même nom de variable pour deux
choses différentes dans le même contexte, les erreurs de type sont presque
toujours détectables à la compilation.
Surtout si le programme ne plante pas comme une
merde et éventuellement fonctionne malgré tout (une erreur de type à
l'affichage, par exemple, n'est pas une catastrophe).
Je ne suis pas d'accord du tout. Ce que tu décris, on appelle ça de la
programmation défensive. Dans les cas courants, c'est une mauvaise idée : un
bug dans un programme, il faut le corriger, on ne peut pas se contenter de
croiser les doigts en espérant que le résultat ne sera pas trop faux. Les
conversions numériques automatiques à la perl, elles peuvent justement
causer un résultat subtilement faux, avec le bon ordre de grandeur, mais une
valeur suffisamment fausse pour que le résultat soit inutilisable. Et si on
ne s'en rend pas compte tout de suite, les résultats peuvent être
catastrophiques.
En plus l'obligation de transtyper et caster dans tous les sens sans
arrêt alourdit le code
Tu te trompes. Une vérification statique de types n'implique pas de
transtyper dans tous les sens. Un transtypage est quelque chose de
fondamentalement exceptionnel, parce que le type, c'est justement ce qu'on
peut faire avec un objet. Quand on a une connexion réseau, on peut faire
tous les transtypages qu'on voudra, on n'arrivera pas à la faire rentrer
dans un produit vectoriel.
Que la vérification soit faite à la compilation n'interdit absolument pas le
polymorphisme est les conversions automatiques.
Certains langages sont un peu pénibles de ce point de vue, il est vrai,
parce que la combinaison de polymorphisme et de détection automatique de
type peut conduire à des cas indécidables, mais la plupart des cas pratiques
sont en fait parfaitement triviaux.
Non, pas du tout. La détection des erreurs de type se fait à la compil, et c'est très peu informatif. Une erreur de type au runtime, ça par contre c'est informatif.
Les erreurs de type à la compilation sont celles qui se seraient produites à l'exécution, tu sais. Autant les corriger les plus tôt possible. Et en pratique, pour peu qu'on s'en tienne à quelques règles élémentaires de propreté du code, comme le pas réutiliser le même nom de variable pour deux choses différentes dans le même contexte, les erreurs de type sont presque toujours détectables à la compilation.
Surtout si le programme ne plante pas comme une merde et éventuellement fonctionne malgré tout (une erreur de type à l'affichage, par exemple, n'est pas une catastrophe).
Je ne suis pas d'accord du tout. Ce que tu décris, on appelle ça de la programmation défensive. Dans les cas courants, c'est une mauvaise idée : un bug dans un programme, il faut le corriger, on ne peut pas se contenter de croiser les doigts en espérant que le résultat ne sera pas trop faux. Les conversions numériques automatiques à la perl, elles peuvent justement causer un résultat subtilement faux, avec le bon ordre de grandeur, mais une valeur suffisamment fausse pour que le résultat soit inutilisable. Et si on ne s'en rend pas compte tout de suite, les résultats peuvent être catastrophiques.
En plus l'obligation de transtyper et caster dans tous les sens sans arrêt alourdit le code
Tu te trompes. Une vérification statique de types n'implique pas de transtyper dans tous les sens. Un transtypage est quelque chose de fondamentalement exceptionnel, parce que le type, c'est justement ce qu'on peut faire avec un objet. Quand on a une connexion réseau, on peut faire tous les transtypages qu'on voudra, on n'arrivera pas à la faire rentrer dans un produit vectoriel.
Que la vérification soit faite à la compilation n'interdit absolument pas le polymorphisme est les conversions automatiques.
Certains langages sont un peu pénibles de ce point de vue, il est vrai, parce que la combinaison de polymorphisme et de détection automatique de type peut conduire à des cas indécidables, mais la plupart des cas pratiques sont en fait parfaitement triviaux.
Nicolas George
Emmanuel Florac , dans le message , a écrit :
Effectivement l'obligation de faire des casts et des transtypages dans les langages "statiques"
Comme je le disais dans un autre message, ce n'est pas du tout une nécessité structurelle. Toutes les conversions automatiques qui sont possibles à l'exécution peuvent être mise en place de la même manière à la compilation.
Emmanuel Florac , dans le message
<pan.2007.01.04.15.41.08.277083@imaginet.fr>, a écrit :
Effectivement l'obligation de faire des casts et des transtypages dans les
langages "statiques"
Comme je le disais dans un autre message, ce n'est pas du tout une nécessité
structurelle. Toutes les conversions automatiques qui sont possibles à
l'exécution peuvent être mise en place de la même manière à la compilation.
Effectivement l'obligation de faire des casts et des transtypages dans les langages "statiques"
Comme je le disais dans un autre message, ce n'est pas du tout une nécessité structurelle. Toutes les conversions automatiques qui sont possibles à l'exécution peuvent être mise en place de la même manière à la compilation.
Emmanuel Florac
Le Thu, 04 Jan 2007 17:32:08 +0000, Nicolas George a écrit :
Les erreurs de type à la compilation sont celles qui se seraient produites à l'exécution, tu sais.
Non. Si un utilisateur, ou une base de données, renvoie "AZ" pour un entier, il n'y aura qu'une erreur d'éxécution, pas de compilation.
Je ne suis pas d'accord du tout. Ce que tu décris, on appelle ça de la programmation défensive. Dans les cas courants, c'est une mauvaise idée : un bug dans un programme, il faut le corriger, on ne peut pas se contenter de croiser les doigts en espérant que le résultat ne sera pas trop faux.
Un bug dans le programme doit être corrigé, c'est clair. Et si ton programme très important récupère une string pour un entier et que le bug c'est que tu as oublié d'intercepter l'exception, il va s'arrêter comme une mede alors qu'il aurait pu continuer à tourner peut être sans conséquence. Donc je suis totalement en désaccord avec toi, la programmation défensive est un must.
En plus l'obligation de transtyper et caster dans tous les sens sans arrêt alourdit le code
Tu te trompes. Une vérification statique de types n'implique pas de transtyper dans tous les sens.
Je ne suis pas un as de ces langages, c'est clair, mais dans les codes que j'ai vu les transtypages en tout genre représentent toujours une part très significative du code.
Que la vérification soit faite à la compilation n'interdit absolument pas le polymorphisme est les conversions automatiques.
Le meilleur moyen de se prendre les pieds dans le tapis, surcharger tous les opérateurs, bravo :)
Certains langages sont un peu pénibles de ce point de vue, il est vrai, parce que la combinaison de polymorphisme et de détection automatique de type peut conduire à des cas indécidables, mais la plupart des cas pratiques sont en fait parfaitement triviaux.
En tout cas Java ne fait pas partie de ces langages, il me semble. Ou alors c'est très récent, il est vrai que j'ai décidément cessé de m'y intéresser ces derniers temps.
-- A thing of beauty is a joy forever. J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert! Marcel Bénabou.
Le Thu, 04 Jan 2007 17:32:08 +0000, Nicolas George a écrit :
Les erreurs de type à la compilation sont celles qui se seraient produites à
l'exécution, tu sais.
Non. Si un utilisateur, ou une base de données, renvoie "AZ" pour un
entier, il n'y aura qu'une erreur d'éxécution, pas de compilation.
Je ne suis pas d'accord du tout. Ce que tu décris, on appelle ça de la
programmation défensive. Dans les cas courants, c'est une mauvaise idée : un
bug dans un programme, il faut le corriger, on ne peut pas se contenter de
croiser les doigts en espérant que le résultat ne sera pas trop faux.
Un bug dans le programme doit être corrigé, c'est clair. Et si ton
programme très important récupère une string pour un entier et que le
bug c'est que tu as oublié d'intercepter l'exception, il va s'arrêter
comme une mede alors qu'il aurait pu continuer à tourner peut être sans
conséquence. Donc je suis totalement en désaccord avec toi, la
programmation défensive est un must.
En plus l'obligation de transtyper et caster dans tous les sens sans
arrêt alourdit le code
Tu te trompes. Une vérification statique de types n'implique pas de
transtyper dans tous les sens.
Je ne suis pas un as de ces langages, c'est clair, mais dans les codes
que j'ai vu les transtypages en tout genre représentent toujours une part
très significative du code.
Que la vérification soit faite à la compilation n'interdit absolument pas le
polymorphisme est les conversions automatiques.
Le meilleur moyen de se prendre les pieds dans le tapis, surcharger tous
les opérateurs, bravo :)
Certains langages sont un peu pénibles de ce point de vue, il est vrai,
parce que la combinaison de polymorphisme et de détection automatique
de type peut conduire à des cas indécidables, mais la plupart des cas
pratiques sont en fait parfaitement triviaux.
En tout cas Java ne fait pas partie de ces langages, il me semble. Ou
alors c'est très récent, il est vrai que j'ai décidément cessé de m'y
intéresser ces derniers temps.
--
A thing of beauty is a joy forever.
J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert!
Marcel Bénabou.
Le Thu, 04 Jan 2007 17:32:08 +0000, Nicolas George a écrit :
Les erreurs de type à la compilation sont celles qui se seraient produites à l'exécution, tu sais.
Non. Si un utilisateur, ou une base de données, renvoie "AZ" pour un entier, il n'y aura qu'une erreur d'éxécution, pas de compilation.
Je ne suis pas d'accord du tout. Ce que tu décris, on appelle ça de la programmation défensive. Dans les cas courants, c'est une mauvaise idée : un bug dans un programme, il faut le corriger, on ne peut pas se contenter de croiser les doigts en espérant que le résultat ne sera pas trop faux.
Un bug dans le programme doit être corrigé, c'est clair. Et si ton programme très important récupère une string pour un entier et que le bug c'est que tu as oublié d'intercepter l'exception, il va s'arrêter comme une mede alors qu'il aurait pu continuer à tourner peut être sans conséquence. Donc je suis totalement en désaccord avec toi, la programmation défensive est un must.
En plus l'obligation de transtyper et caster dans tous les sens sans arrêt alourdit le code
Tu te trompes. Une vérification statique de types n'implique pas de transtyper dans tous les sens.
Je ne suis pas un as de ces langages, c'est clair, mais dans les codes que j'ai vu les transtypages en tout genre représentent toujours une part très significative du code.
Que la vérification soit faite à la compilation n'interdit absolument pas le polymorphisme est les conversions automatiques.
Le meilleur moyen de se prendre les pieds dans le tapis, surcharger tous les opérateurs, bravo :)
Certains langages sont un peu pénibles de ce point de vue, il est vrai, parce que la combinaison de polymorphisme et de détection automatique de type peut conduire à des cas indécidables, mais la plupart des cas pratiques sont en fait parfaitement triviaux.
En tout cas Java ne fait pas partie de ces langages, il me semble. Ou alors c'est très récent, il est vrai que j'ai décidément cessé de m'y intéresser ces derniers temps.
-- A thing of beauty is a joy forever. J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert! Marcel Bénabou.
Emmanuel Florac
Le Thu, 04 Jan 2007 18:07:03 +0100, remy a écrit :
peut etre il faut voir le cout est souvent inversement proportionnel a la programmation avancee
Il n'y a pas d'accents ni de ponctuation sur ton clavier? Ton message reste parfaitement obscur à la 3e lecture. Quant aux design patterns, boarf. J'ai lu un blog très rigolo qui expliquait que le "gang of four" avait élaboré une théorie sophistiquée qui montrait comment contourner les limitation du langage qu'ils utilisaient à l'époque (C++, je crois), et comment ils auraient définis les "designs patterns" s'ils avaient ça du temps du COBOL :)
-- Le commissaire : Comment vous appelez-vous? Garance : Moi je ne m'appelle jamais, je suis toujours là. J'ai pas besoin de m'appeler. Mais les autres m'appellent Garance, si ça peut vous intéresser. Prévert,"les enfants du Paradis".
Le Thu, 04 Jan 2007 18:07:03 +0100, remy a écrit :
peut etre il faut voir
le cout est souvent inversement proportionnel
a la programmation avancee
Il n'y a pas d'accents ni de ponctuation sur ton clavier? Ton message
reste parfaitement obscur à la 3e lecture.
Quant aux design patterns, boarf. J'ai lu un blog très rigolo qui
expliquait que le "gang of four" avait élaboré une théorie
sophistiquée qui montrait comment contourner les limitation du langage
qu'ils utilisaient à l'époque (C++, je crois), et comment ils auraient
définis les "designs patterns" s'ils avaient ça du temps du COBOL :)
--
Le commissaire : Comment vous appelez-vous?
Garance : Moi je ne m'appelle jamais, je suis toujours là. J'ai pas
besoin de m'appeler. Mais les autres m'appellent Garance, si ça peut
vous intéresser.
Prévert,"les enfants du Paradis".
Le Thu, 04 Jan 2007 18:07:03 +0100, remy a écrit :
peut etre il faut voir le cout est souvent inversement proportionnel a la programmation avancee
Il n'y a pas d'accents ni de ponctuation sur ton clavier? Ton message reste parfaitement obscur à la 3e lecture. Quant aux design patterns, boarf. J'ai lu un blog très rigolo qui expliquait que le "gang of four" avait élaboré une théorie sophistiquée qui montrait comment contourner les limitation du langage qu'ils utilisaient à l'époque (C++, je crois), et comment ils auraient définis les "designs patterns" s'ils avaient ça du temps du COBOL :)
-- Le commissaire : Comment vous appelez-vous? Garance : Moi je ne m'appelle jamais, je suis toujours là. J'ai pas besoin de m'appeler. Mais les autres m'appellent Garance, si ça peut vous intéresser. Prévert,"les enfants du Paradis".
Nicolas George
Emmanuel Florac , dans le message , a écrit :
Non. Si un utilisateur, ou une base de données, renvoie "AZ" pour un entier, il n'y aura qu'une erreur d'éxécution, pas de compilation.
S'il est possible de passer « AZ », c'est que le type est une chaîne de caractères. Évidemment, à certains endroits il est nécessaire de valider à l'exécution le passage d'un monde à l'autre, d'un type à l'autre. Mais si tu y réfléchis bien, dans un programme correctement conçu, ça se produit très rarement : une fois à l'entrée, une fois à la sortie. Partout ailleurs, les données ont le bon type.
Un bug dans le programme doit être corrigé, c'est clair. Et si ton programme très important récupère une string pour un entier et que le bug c'est que tu as oublié d'intercepter l'exception, il va s'arrêter comme une mede alors qu'il aurait pu continuer à tourner peut être sans conséquence. Donc je suis totalement en désaccord avec toi, la programmation défensive est un must.
Il aurait pu continuer à tourner sans conséquences, il aurait pu continuer à tourner avec des conséquences gravissimes, corruption de données et trou de sécurité au premier rang. Les deux sont possibles, et également plausibles, avec la troisième possibilité qu'il se vautre un peu plus loin.
Je préfère largement qu'un programme s'arrête purement et simplement plutôt qu'il donne un shell root à n'importe qui sur ma machine, ou qu'il me vide mon compte en banque. Mais je préfère encore que le programme n'ai tout simplement pas pu être compilé parce que l'erreur était détectable statiquement. Et pour tout ce qui n'est pas détectable statiquement,vive assert() !
Dans ces conditions, pratiquer la programmation défensive est purement et simplement criminel.
Je ne suis pas un as de ces langages, c'est clair, mais dans les codes que j'ai vu les transtypages en tout genre représentent toujours une part très significative du code.
Ça me paraît bizarre, je soupçonne une très large exagération, ou bien des cas pathologiques montés en épingle.
Le meilleur moyen de se prendre les pieds dans le tapis, surcharger tous les opérateurs, bravo :)
Ce n'est pas de ça que j'ai parlé.
En tout cas Java ne fait pas partie de ces langages, il me semble.
Oui, évidemment. Java est un langage médiocre.
Emmanuel Florac , dans le message
<pan.2007.01.04.21.33.38.172073@imaginet.fr>, a écrit :
Non. Si un utilisateur, ou une base de données, renvoie "AZ" pour un
entier, il n'y aura qu'une erreur d'éxécution, pas de compilation.
S'il est possible de passer « AZ », c'est que le type est une chaîne de
caractères. Évidemment, à certains endroits il est nécessaire de valider à
l'exécution le passage d'un monde à l'autre, d'un type à l'autre. Mais si tu
y réfléchis bien, dans un programme correctement conçu, ça se produit très
rarement : une fois à l'entrée, une fois à la sortie. Partout ailleurs, les
données ont le bon type.
Un bug dans le programme doit être corrigé, c'est clair. Et si ton
programme très important récupère une string pour un entier et que le
bug c'est que tu as oublié d'intercepter l'exception, il va s'arrêter
comme une mede alors qu'il aurait pu continuer à tourner peut être sans
conséquence. Donc je suis totalement en désaccord avec toi, la
programmation défensive est un must.
Il aurait pu continuer à tourner sans conséquences, il aurait pu continuer à
tourner avec des conséquences gravissimes, corruption de données et trou de
sécurité au premier rang. Les deux sont possibles, et également plausibles,
avec la troisième possibilité qu'il se vautre un peu plus loin.
Je préfère largement qu'un programme s'arrête purement et simplement plutôt
qu'il donne un shell root à n'importe qui sur ma machine, ou qu'il me vide
mon compte en banque. Mais je préfère encore que le programme n'ai tout
simplement pas pu être compilé parce que l'erreur était détectable
statiquement. Et pour tout ce qui n'est pas détectable statiquement,vive
assert() !
Dans ces conditions, pratiquer la programmation défensive est purement et
simplement criminel.
Je ne suis pas un as de ces langages, c'est clair, mais dans les codes
que j'ai vu les transtypages en tout genre représentent toujours une part
très significative du code.
Ça me paraît bizarre, je soupçonne une très large exagération, ou bien des
cas pathologiques montés en épingle.
Le meilleur moyen de se prendre les pieds dans le tapis, surcharger tous
les opérateurs, bravo :)
Ce n'est pas de ça que j'ai parlé.
En tout cas Java ne fait pas partie de ces langages, il me semble.
Non. Si un utilisateur, ou une base de données, renvoie "AZ" pour un entier, il n'y aura qu'une erreur d'éxécution, pas de compilation.
S'il est possible de passer « AZ », c'est que le type est une chaîne de caractères. Évidemment, à certains endroits il est nécessaire de valider à l'exécution le passage d'un monde à l'autre, d'un type à l'autre. Mais si tu y réfléchis bien, dans un programme correctement conçu, ça se produit très rarement : une fois à l'entrée, une fois à la sortie. Partout ailleurs, les données ont le bon type.
Un bug dans le programme doit être corrigé, c'est clair. Et si ton programme très important récupère une string pour un entier et que le bug c'est que tu as oublié d'intercepter l'exception, il va s'arrêter comme une mede alors qu'il aurait pu continuer à tourner peut être sans conséquence. Donc je suis totalement en désaccord avec toi, la programmation défensive est un must.
Il aurait pu continuer à tourner sans conséquences, il aurait pu continuer à tourner avec des conséquences gravissimes, corruption de données et trou de sécurité au premier rang. Les deux sont possibles, et également plausibles, avec la troisième possibilité qu'il se vautre un peu plus loin.
Je préfère largement qu'un programme s'arrête purement et simplement plutôt qu'il donne un shell root à n'importe qui sur ma machine, ou qu'il me vide mon compte en banque. Mais je préfère encore que le programme n'ai tout simplement pas pu être compilé parce que l'erreur était détectable statiquement. Et pour tout ce qui n'est pas détectable statiquement,vive assert() !
Dans ces conditions, pratiquer la programmation défensive est purement et simplement criminel.
Je ne suis pas un as de ces langages, c'est clair, mais dans les codes que j'ai vu les transtypages en tout genre représentent toujours une part très significative du code.
Ça me paraît bizarre, je soupçonne une très large exagération, ou bien des cas pathologiques montés en épingle.
Le meilleur moyen de se prendre les pieds dans le tapis, surcharger tous les opérateurs, bravo :)
Ce n'est pas de ça que j'ai parlé.
En tout cas Java ne fait pas partie de ces langages, il me semble.
Oui, évidemment. Java est un langage médiocre.
remy
reste parfaitement obscur à la 3e lecture.
c'est normal je ne comprends pas toujours se que j'écris
Quant aux design patterns, boarf. J'ai lu un blog très rigolo qui expliquait que le "gang of four" avait élaboré une théorie sophistiquée qui montrait comment contourner les limitation du langage qu'ils utilisaient à l'époque (C++, je crois), et comment ils auraient définis les "designs patterns" s'ils avaient ça du temps du COBOL :)
les designs patterns c'est simple même super simple mais il ne faut surtout pas le répéter sinon tout les profs d'info vont faire la gueule
l'idée de base
2*a+3*a+4*a=a*(2+3+4)
en gros tu te démerdes comme tu veux pour éviter la redondance du code à l'arrivée tu retomberas presque toujours sur les mêmes schémas que tu le veuilles ou pas alors autant ne pas le vouloir c'est plus rigolo
dit différemment c'est l'apologie de la fainéantise
mais bon moi tu sais.... j'aime bien la notion du tu sais moi ...:-)
remy
reste parfaitement obscur à la 3e lecture.
c'est normal je ne comprends pas toujours se que j'écris
Quant aux design patterns, boarf. J'ai lu un blog très rigolo qui
expliquait que le "gang of four" avait élaboré une théorie
sophistiquée qui montrait comment contourner les limitation du langage
qu'ils utilisaient à l'époque (C++, je crois), et comment ils auraient
définis les "designs patterns" s'ils avaient ça du temps du COBOL :)
les designs patterns c'est simple même super simple
mais il ne faut surtout pas le répéter sinon tout
les profs d'info vont faire la gueule
l'idée de base
2*a+3*a+4*a=a*(2+3+4)
en gros tu te démerdes comme tu veux pour éviter la redondance du code
à l'arrivée tu retomberas presque toujours sur les mêmes schémas
que tu le veuilles ou pas alors autant ne pas le vouloir
c'est plus rigolo
dit différemment c'est l'apologie de la fainéantise
mais bon moi tu sais....
j'aime bien la notion du tu sais moi ...:-)
c'est normal je ne comprends pas toujours se que j'écris
Quant aux design patterns, boarf. J'ai lu un blog très rigolo qui expliquait que le "gang of four" avait élaboré une théorie sophistiquée qui montrait comment contourner les limitation du langage qu'ils utilisaient à l'époque (C++, je crois), et comment ils auraient définis les "designs patterns" s'ils avaient ça du temps du COBOL :)
les designs patterns c'est simple même super simple mais il ne faut surtout pas le répéter sinon tout les profs d'info vont faire la gueule
l'idée de base
2*a+3*a+4*a=a*(2+3+4)
en gros tu te démerdes comme tu veux pour éviter la redondance du code à l'arrivée tu retomberas presque toujours sur les mêmes schémas que tu le veuilles ou pas alors autant ne pas le vouloir c'est plus rigolo
dit différemment c'est l'apologie de la fainéantise
mais bon moi tu sais.... j'aime bien la notion du tu sais moi ...:-)
remy
Emmanuel Florac
Le Fri, 05 Jan 2007 00:26:42 +0000, Nicolas George a écrit :
Oui, évidemment. Java est un langage médiocre.
Là au moins on est d'accord :)
-- Le travail est la malédiction des classes qui boivent. O. Wilde.
Le Fri, 05 Jan 2007 00:26:42 +0000, Nicolas George a écrit :
Oui, évidemment. Java est un langage médiocre.
Là au moins on est d'accord :)
--
Le travail est la malédiction des classes qui boivent.
O. Wilde.
-- J'ai pu constater avec les commandes "C-h v Tab" et "C-h f Tab" que emacs (version 20.7.1 de la SuSE 7.3) disposait de 1.660 variables et de 3.420 fonctions ! ----------------------------------Bloatware PowAAA----------------------
On 2007-01-03, remy <remy@fctpas.fr> wrote:
le déploiement pour les service web aussi ?
l'integration des jars aussi ?
le débogage aussi ?
etc...
--
J'ai pu constater avec les commandes "C-h v Tab" et "C-h f Tab" que
emacs (version 20.7.1 de la SuSE 7.3) disposait de 1.660 variables et de
3.420 fonctions !
----------------------------------Bloatware PowAAA----------------------
-- J'ai pu constater avec les commandes "C-h v Tab" et "C-h f Tab" que emacs (version 20.7.1 de la SuSE 7.3) disposait de 1.660 variables et de 3.420 fonctions ! ----------------------------------Bloatware PowAAA----------------------
C'est mal d'avoir un /etc/passwd codé en dur dans son /bin/passwd.
Ouais, bon, fatigue, toussa :) Mais l'idée était là. Si vous saviez toutes les conneries que j'ai essayé comme login-shell !...
--
Le format dans lequel OpenOffice (et KOffice) enregistre votre travail personnel vient d'être _normalisé_ par l'ISO "Un petit pas pour l'homme, mais un grand pas pour la numeralité !"
--{ Ker2x, philosophe de la numéricité }--
On 2007-01-06, Khanh-Dang <khanh-dang@w.fr.invalid> wrote:
C'est mal d'avoir un /etc/passwd codé en dur dans son /bin/passwd.
Ouais, bon, fatigue, toussa :) Mais l'idée était là.
Si vous saviez toutes les conneries que j'ai essayé comme
login-shell !...
--
Le format dans lequel OpenOffice (et KOffice) enregistre votre travail
personnel vient d'être _normalisé_ par l'ISO
"Un petit pas pour l'homme, mais un grand pas pour la numeralité !"
C'est mal d'avoir un /etc/passwd codé en dur dans son /bin/passwd.
Ouais, bon, fatigue, toussa :) Mais l'idée était là. Si vous saviez toutes les conneries que j'ai essayé comme login-shell !...
--
Le format dans lequel OpenOffice (et KOffice) enregistre votre travail personnel vient d'être _normalisé_ par l'ISO "Un petit pas pour l'homme, mais un grand pas pour la numeralité !"
