Les questions de codage des noms de fichiers dans un système de
fichiers sont, à la base, indépendantes du contexte "programmation" ou
"pas programmation".
Ne tombez pas dans le piège qui consiste à croire qu'il existe une
frontière entre donnée et programme. Les questions de codage font
intégralement partie des questions de programmation.
Les questions de codage des noms de fichiers dans un système de
fichiers sont, à la base, indépendantes du contexte "programmation" ou
"pas programmation".
Ne tombez pas dans le piège qui consiste à croire qu'il existe une
frontière entre donnée et programme. Les questions de codage font
intégralement partie des questions de programmation.
Les questions de codage des noms de fichiers dans un système de
fichiers sont, à la base, indépendantes du contexte "programmation" ou
"pas programmation".
Ne tombez pas dans le piège qui consiste à croire qu'il existe une
frontière entre donnée et programme. Les questions de codage font
intégralement partie des questions de programmation.
Le 09/01/12 23:58, Paul Gaborit a écrit :
Les questions de codage des noms de fichiers dans un système de
fichiers sont, à la base, indépendantes du contexte "programmation" ou
"pas programmation".
Ne tombez pas dans le piège qui consiste à croire qu'il existe une
frontière entre donnée et programme. Les questions de codage font
intégralement partie des questions de programmation.
Dans ce cas tout est programmation, hein...
Si j'ai une question à poser sur le fonctionnement de "cp", je vais la
poser dans *.programmation, sous prétexte qu'on peut utiliser "cp"
dans un script ??
Ma question récente sur rsync et les mtime FAT, j'aurais dû la poser
dans *.programmation sous prétexte que les mtime sont des données et
qu'il n'y a pas de frontière avec les programmes ?
Le 09/01/12 23:58, Paul Gaborit a écrit :
Les questions de codage des noms de fichiers dans un système de
fichiers sont, à la base, indépendantes du contexte "programmation" ou
"pas programmation".
Ne tombez pas dans le piège qui consiste à croire qu'il existe une
frontière entre donnée et programme. Les questions de codage font
intégralement partie des questions de programmation.
Dans ce cas tout est programmation, hein...
Si j'ai une question à poser sur le fonctionnement de "cp", je vais la
poser dans *.programmation, sous prétexte qu'on peut utiliser "cp"
dans un script ??
Ma question récente sur rsync et les mtime FAT, j'aurais dû la poser
dans *.programmation sous prétexte que les mtime sont des données et
qu'il n'y a pas de frontière avec les programmes ?
Le 09/01/12 23:58, Paul Gaborit a écrit :
Les questions de codage des noms de fichiers dans un système de
fichiers sont, à la base, indépendantes du contexte "programmation" ou
"pas programmation".
Ne tombez pas dans le piège qui consiste à croire qu'il existe une
frontière entre donnée et programme. Les questions de codage font
intégralement partie des questions de programmation.
Dans ce cas tout est programmation, hein...
Si j'ai une question à poser sur le fonctionnement de "cp", je vais la
poser dans *.programmation, sous prétexte qu'on peut utiliser "cp"
dans un script ??
Ma question récente sur rsync et les mtime FAT, j'aurais dû la poser
dans *.programmation sous prétexte que les mtime sont des données et
qu'il n'y a pas de frontière avec les programmes ?
À (at) Tue, 10 Jan 2012 08:12:14 +0100,
pehache écrivait (wrote):Le 09/01/12 23:58, Paul Gaborit a écrit :
Les questions de codage des noms de fichiers dans un système de
fichiers sont, à la base, indépendantes du contexte "programmation" ou
"pas programmation".
Ne tombez pas dans le piège qui consiste à croire qu'il existe une
frontière entre donnée et programme. Les questions de codage font
intégralement partie des questions de programmation.
Dans ce cas tout est programmation, hein...
Franchement qui se préoccupe des questions de codage ? Dans un système
bien conçu, ce ne sont que les développeurs ! Parfois, les problèmes
remontent vers les utilisateurs ou les administrateurs mais c'est loin
de leurs préoccupations et généralement cela les dépasse.
Si j'ai une question à poser sur le fonctionnement de "cp", je vais la
poser dans *.programmation, sous prétexte qu'on peut utiliser "cp"
dans un script ??
Ma question récente sur rsync et les mtime FAT, j'aurais dû la poser
dans *.programmation sous prétexte que les mtime sont des données et
qu'il n'y a pas de frontière avec les programmes ?
Pourquoi pas... Cela dépend de votre point du vue.
Vous avez une vue des choses trop manichéenne : tout doit renter dans
des petites boites et chaque chose se met dans une boite et une seule.
Le seul problème de votre approche (parfaitement illustré par cette
discussion) est que chacun vient avec sa propre idée des boites et que
vous ne pourrez jamais convaincre les autres que vos propres définitions
sont les bonnes.
À (at) Tue, 10 Jan 2012 08:12:14 +0100,
pehache<pehache.7@gmail.com> écrivait (wrote):
Le 09/01/12 23:58, Paul Gaborit a écrit :
Les questions de codage des noms de fichiers dans un système de
fichiers sont, à la base, indépendantes du contexte "programmation" ou
"pas programmation".
Ne tombez pas dans le piège qui consiste à croire qu'il existe une
frontière entre donnée et programme. Les questions de codage font
intégralement partie des questions de programmation.
Dans ce cas tout est programmation, hein...
Franchement qui se préoccupe des questions de codage ? Dans un système
bien conçu, ce ne sont que les développeurs ! Parfois, les problèmes
remontent vers les utilisateurs ou les administrateurs mais c'est loin
de leurs préoccupations et généralement cela les dépasse.
Si j'ai une question à poser sur le fonctionnement de "cp", je vais la
poser dans *.programmation, sous prétexte qu'on peut utiliser "cp"
dans un script ??
Ma question récente sur rsync et les mtime FAT, j'aurais dû la poser
dans *.programmation sous prétexte que les mtime sont des données et
qu'il n'y a pas de frontière avec les programmes ?
Pourquoi pas... Cela dépend de votre point du vue.
Vous avez une vue des choses trop manichéenne : tout doit renter dans
des petites boites et chaque chose se met dans une boite et une seule.
Le seul problème de votre approche (parfaitement illustré par cette
discussion) est que chacun vient avec sa propre idée des boites et que
vous ne pourrez jamais convaincre les autres que vos propres définitions
sont les bonnes.
À (at) Tue, 10 Jan 2012 08:12:14 +0100,
pehache écrivait (wrote):Le 09/01/12 23:58, Paul Gaborit a écrit :
Les questions de codage des noms de fichiers dans un système de
fichiers sont, à la base, indépendantes du contexte "programmation" ou
"pas programmation".
Ne tombez pas dans le piège qui consiste à croire qu'il existe une
frontière entre donnée et programme. Les questions de codage font
intégralement partie des questions de programmation.
Dans ce cas tout est programmation, hein...
Franchement qui se préoccupe des questions de codage ? Dans un système
bien conçu, ce ne sont que les développeurs ! Parfois, les problèmes
remontent vers les utilisateurs ou les administrateurs mais c'est loin
de leurs préoccupations et généralement cela les dépasse.
Si j'ai une question à poser sur le fonctionnement de "cp", je vais la
poser dans *.programmation, sous prétexte qu'on peut utiliser "cp"
dans un script ??
Ma question récente sur rsync et les mtime FAT, j'aurais dû la poser
dans *.programmation sous prétexte que les mtime sont des données et
qu'il n'y a pas de frontière avec les programmes ?
Pourquoi pas... Cela dépend de votre point du vue.
Vous avez une vue des choses trop manichéenne : tout doit renter dans
des petites boites et chaque chose se met dans une boite et une seule.
Le seul problème de votre approche (parfaitement illustré par cette
discussion) est que chacun vient avec sa propre idée des boites et que
vous ne pourrez jamais convaincre les autres que vos propres définitions
sont les bonnes.
Ceci dit je maintiens que le post initial ne parlait absolument pas
d'UTF-8 et de codage.
J'écrivais :Vous avez une vue des choses trop manichéenne : tout doit renter dans
des petites boites et chaque chose se met dans une boite et une seule.
Le seul problème de votre approche (parfaitement illustré par cette
discussion) est que chacun vient avec sa propre idée des boites et que
vous ne pourrez jamais convaincre les autres que vos propres définitions
sont les bonnes.
Le manichéisme serait de dire que tout est soit blanc soit noir, et
que le gris n'existe pas. Ce que je dis ici est qu'il faut éviter de
confondre le blanc avec le noir.
Ceci dit je maintiens que le post initial ne parlait absolument pas
d'UTF-8 et de codage.
J'écrivais :
Vous avez une vue des choses trop manichéenne : tout doit renter dans
des petites boites et chaque chose se met dans une boite et une seule.
Le seul problème de votre approche (parfaitement illustré par cette
discussion) est que chacun vient avec sa propre idée des boites et que
vous ne pourrez jamais convaincre les autres que vos propres définitions
sont les bonnes.
Le manichéisme serait de dire que tout est soit blanc soit noir, et
que le gris n'existe pas. Ce que je dis ici est qu'il faut éviter de
confondre le blanc avec le noir.
Ceci dit je maintiens que le post initial ne parlait absolument pas
d'UTF-8 et de codage.
J'écrivais :Vous avez une vue des choses trop manichéenne : tout doit renter dans
des petites boites et chaque chose se met dans une boite et une seule.
Le seul problème de votre approche (parfaitement illustré par cette
discussion) est que chacun vient avec sa propre idée des boites et que
vous ne pourrez jamais convaincre les autres que vos propres définitions
sont les bonnes.
Le manichéisme serait de dire que tout est soit blanc soit noir, et
que le gris n'existe pas. Ce que je dis ici est qu'il faut éviter de
confondre le blanc avec le noir.
À (at) Wed, 11 Jan 2012 23:57:47 +0100,
pehache écrivait (wrote):Ceci dit je maintiens que le post initial ne parlait absolument pas
d'UTF-8 et de codage.
Celui qui a posté initialement estimait que son sujet concernait la
programmation. Vous avez tout à fait le droit de penser que ce n'était
pas le cas... Mais sa position est tout aussi légitime que la vôtre.
Le manichéisme serait de dire que tout est soit blanc soit noir, et
que le gris n'existe pas. Ce que je dis ici est qu'il faut éviter de
confondre le blanc avec le noir.
Cette dernière phrase illustre parfaitement ce que je dénonce dans votre
approche : vous croyez que tout le monde adopte la même définition du
noir, du blanc et du gris que vous. Or ce n'est évidemment pas le cas.
Que vous indiquiez au posteur que son message entre parfaitement dans
les thématiques d'un groupe dans lequel il n'a pas posté, pourquoi
pas... Vous ne faites que lui monter d'autres points de vue que le sien
et en cela, vous l'aider.
Mais que vous lui refusiez (ainsi qu'à moi) le droit de penser que ça
touche à la programmation ne sert à rien... ou qu'à essayer d'imposer
votre point de vue au risque de déclencher une polémique (petite et
courtoise, heureusement).
La manière dont vous avez amené votre proposition de réorganisation des
forum Mac illustre encore ce que j'essaye de vous dire : votre approche
était inévitablement vouée à l'échec (et là, la polémique n'est restée
ni petite ni courtoise) alors que vos arguments étaient sans doute
justes (de mon point de vue en tous cas).
À (at) Wed, 11 Jan 2012 23:57:47 +0100,
pehache<pehache.7@gmail.com> écrivait (wrote):
Ceci dit je maintiens que le post initial ne parlait absolument pas
d'UTF-8 et de codage.
Celui qui a posté initialement estimait que son sujet concernait la
programmation. Vous avez tout à fait le droit de penser que ce n'était
pas le cas... Mais sa position est tout aussi légitime que la vôtre.
Le manichéisme serait de dire que tout est soit blanc soit noir, et
que le gris n'existe pas. Ce que je dis ici est qu'il faut éviter de
confondre le blanc avec le noir.
Cette dernière phrase illustre parfaitement ce que je dénonce dans votre
approche : vous croyez que tout le monde adopte la même définition du
noir, du blanc et du gris que vous. Or ce n'est évidemment pas le cas.
Que vous indiquiez au posteur que son message entre parfaitement dans
les thématiques d'un groupe dans lequel il n'a pas posté, pourquoi
pas... Vous ne faites que lui monter d'autres points de vue que le sien
et en cela, vous l'aider.
Mais que vous lui refusiez (ainsi qu'à moi) le droit de penser que ça
touche à la programmation ne sert à rien... ou qu'à essayer d'imposer
votre point de vue au risque de déclencher une polémique (petite et
courtoise, heureusement).
La manière dont vous avez amené votre proposition de réorganisation des
forum Mac illustre encore ce que j'essaye de vous dire : votre approche
était inévitablement vouée à l'échec (et là, la polémique n'est restée
ni petite ni courtoise) alors que vos arguments étaient sans doute
justes (de mon point de vue en tous cas).
À (at) Wed, 11 Jan 2012 23:57:47 +0100,
pehache écrivait (wrote):Ceci dit je maintiens que le post initial ne parlait absolument pas
d'UTF-8 et de codage.
Celui qui a posté initialement estimait que son sujet concernait la
programmation. Vous avez tout à fait le droit de penser que ce n'était
pas le cas... Mais sa position est tout aussi légitime que la vôtre.
Le manichéisme serait de dire que tout est soit blanc soit noir, et
que le gris n'existe pas. Ce que je dis ici est qu'il faut éviter de
confondre le blanc avec le noir.
Cette dernière phrase illustre parfaitement ce que je dénonce dans votre
approche : vous croyez que tout le monde adopte la même définition du
noir, du blanc et du gris que vous. Or ce n'est évidemment pas le cas.
Que vous indiquiez au posteur que son message entre parfaitement dans
les thématiques d'un groupe dans lequel il n'a pas posté, pourquoi
pas... Vous ne faites que lui monter d'autres points de vue que le sien
et en cela, vous l'aider.
Mais que vous lui refusiez (ainsi qu'à moi) le droit de penser que ça
touche à la programmation ne sert à rien... ou qu'à essayer d'imposer
votre point de vue au risque de déclencher une polémique (petite et
courtoise, heureusement).
La manière dont vous avez amené votre proposition de réorganisation des
forum Mac illustre encore ce que j'essaye de vous dire : votre approche
était inévitablement vouée à l'échec (et là, la polémique n'est restée
ni petite ni courtoise) alors que vos arguments étaient sans doute
justes (de mon point de vue en tous cas).
Oui enfin bon, le relativisme c'est bien joli, mais sur les questions
techniques ça a quand même quelques limites. Si je viens dire "le C ce
n'est pas de la programmation" est-ce légitime aussi ?
Toi-même dans un autre fil j'ai remarqué que tu avais à plusieurs
reprises refusé les fu2 qu'il mettait et remettait vers fcsmp: sans le
dire explicitement, ça revient à imposer ton point de vue aussi.
Je crois que la seule bonne manière aurait été de pouvoir produire un
certificat que mes ancêtres utilisaient tous un Mac depuis 5
générations :-)
Oui enfin bon, le relativisme c'est bien joli, mais sur les questions
techniques ça a quand même quelques limites. Si je viens dire "le C ce
n'est pas de la programmation" est-ce légitime aussi ?
Toi-même dans un autre fil j'ai remarqué que tu avais à plusieurs
reprises refusé les fu2 qu'il mettait et remettait vers fcsmp: sans le
dire explicitement, ça revient à imposer ton point de vue aussi.
Je crois que la seule bonne manière aurait été de pouvoir produire un
certificat que mes ancêtres utilisaient tous un Mac depuis 5
générations :-)
Oui enfin bon, le relativisme c'est bien joli, mais sur les questions
techniques ça a quand même quelques limites. Si je viens dire "le C ce
n'est pas de la programmation" est-ce légitime aussi ?
Toi-même dans un autre fil j'ai remarqué que tu avais à plusieurs
reprises refusé les fu2 qu'il mettait et remettait vers fcsmp: sans le
dire explicitement, ça revient à imposer ton point de vue aussi.
Je crois que la seule bonne manière aurait été de pouvoir produire un
certificat que mes ancêtres utilisaient tous un Mac depuis 5
générations :-)
À (at) Thu, 12 Jan 2012 07:27:57 +0100,
pehache écrivait (wrote):
> Oui enfin bon, le relativisme c'est bien joli, mais sur les questions
> techniques ça a quand même quelques limites. Si je viens dire "le C ce
> n'est pas de la programmation" est-ce légitime aussi ?
Certains (ils sont quand même de plus en plus rares ;-)) le pensent et
ne jurent que par l'assembleur, le reste étant pour eux du domaine du
jeu... Mais encore une fois, dire que « le C n'est pas de la
programmation » revient à refuser un point de vue. Dire que « le C est
un langage pour le jeu » n'est qu'un point de vue de plus parmi
d'autres. Je vous accorde tout de même qu'il existe un large consens us
sur le fait que le C est un langage de programmation.
> Toi-même dans un autre fil j'ai remarqué que tu avais à plusieurs
> reprises refusé les fu2 qu'il mettait et remettait vers fcsmp: sans l e
> dire explicitement, ça revient à imposer ton point de vue aussi.
En fait, j'ai toujours du mal avec le fu2. Pourquoi priver de réponse u n
groupe dans lequel un message a été posté ? Et si par hasard, il m' est
arrivé de *supprimer* un groupe dans mes réponses, c'est soit acciden tel
soit parce que mon lecteur de news refuse de poster dans un groupe qu'il
ne connait pas.
> Je crois que la seule bonne manière aurait été de pouvoir produir e un
> certificat que mes ancêtres utilisaient tous un Mac depuis 5
> générations :-)
Je ne crois pas. Cela aurait sans doute pu passer avec une approche
beaucoup plus douce qui aurait suggéré le changement plutôt que le
proposer voire l'imposer (comme l'ont cru certains). C'est de la
manipulation de base (au sens noble du terme) : on amène les autres à
faire eux-mêmes les propositions qu'on souhaite voir aboutir ! C'est
souvent difficile à mettre en oeuvre mais c'est parfois le seul moyen
d'atteindre l'objectif.
À (at) Thu, 12 Jan 2012 07:27:57 +0100,
pehache <pehach...@gmail.com> écrivait (wrote):
> Oui enfin bon, le relativisme c'est bien joli, mais sur les questions
> techniques ça a quand même quelques limites. Si je viens dire "le C ce
> n'est pas de la programmation" est-ce légitime aussi ?
Certains (ils sont quand même de plus en plus rares ;-)) le pensent et
ne jurent que par l'assembleur, le reste étant pour eux du domaine du
jeu... Mais encore une fois, dire que « le C n'est pas de la
programmation » revient à refuser un point de vue. Dire que « le C est
un langage pour le jeu » n'est qu'un point de vue de plus parmi
d'autres. Je vous accorde tout de même qu'il existe un large consens us
sur le fait que le C est un langage de programmation.
> Toi-même dans un autre fil j'ai remarqué que tu avais à plusieurs
> reprises refusé les fu2 qu'il mettait et remettait vers fcsmp: sans l e
> dire explicitement, ça revient à imposer ton point de vue aussi.
En fait, j'ai toujours du mal avec le fu2. Pourquoi priver de réponse u n
groupe dans lequel un message a été posté ? Et si par hasard, il m' est
arrivé de *supprimer* un groupe dans mes réponses, c'est soit acciden tel
soit parce que mon lecteur de news refuse de poster dans un groupe qu'il
ne connait pas.
> Je crois que la seule bonne manière aurait été de pouvoir produir e un
> certificat que mes ancêtres utilisaient tous un Mac depuis 5
> générations :-)
Je ne crois pas. Cela aurait sans doute pu passer avec une approche
beaucoup plus douce qui aurait suggéré le changement plutôt que le
proposer voire l'imposer (comme l'ont cru certains). C'est de la
manipulation de base (au sens noble du terme) : on amène les autres à
faire eux-mêmes les propositions qu'on souhaite voir aboutir ! C'est
souvent difficile à mettre en oeuvre mais c'est parfois le seul moyen
d'atteindre l'objectif.
À (at) Thu, 12 Jan 2012 07:27:57 +0100,
pehache écrivait (wrote):
> Oui enfin bon, le relativisme c'est bien joli, mais sur les questions
> techniques ça a quand même quelques limites. Si je viens dire "le C ce
> n'est pas de la programmation" est-ce légitime aussi ?
Certains (ils sont quand même de plus en plus rares ;-)) le pensent et
ne jurent que par l'assembleur, le reste étant pour eux du domaine du
jeu... Mais encore une fois, dire que « le C n'est pas de la
programmation » revient à refuser un point de vue. Dire que « le C est
un langage pour le jeu » n'est qu'un point de vue de plus parmi
d'autres. Je vous accorde tout de même qu'il existe un large consens us
sur le fait que le C est un langage de programmation.
> Toi-même dans un autre fil j'ai remarqué que tu avais à plusieurs
> reprises refusé les fu2 qu'il mettait et remettait vers fcsmp: sans l e
> dire explicitement, ça revient à imposer ton point de vue aussi.
En fait, j'ai toujours du mal avec le fu2. Pourquoi priver de réponse u n
groupe dans lequel un message a été posté ? Et si par hasard, il m' est
arrivé de *supprimer* un groupe dans mes réponses, c'est soit acciden tel
soit parce que mon lecteur de news refuse de poster dans un groupe qu'il
ne connait pas.
> Je crois que la seule bonne manière aurait été de pouvoir produir e un
> certificat que mes ancêtres utilisaient tous un Mac depuis 5
> générations :-)
Je ne crois pas. Cela aurait sans doute pu passer avec une approche
beaucoup plus douce qui aurait suggéré le changement plutôt que le
proposer voire l'imposer (comme l'ont cru certains). C'est de la
manipulation de base (au sens noble du terme) : on amène les autres à
faire eux-mêmes les propositions qu'on souhaite voir aboutir ! C'est
souvent difficile à mettre en oeuvre mais c'est parfois le seul moyen
d'atteindre l'objectif.
