Une discussion fait rage en ce moment sur c.l.py concernant le PEP 3131
qui propose d'introduire le support des caractères non-ASCII dans les
identificateurs en Python. Par identificateurs, on entend bien sûr les
noms des variables, fonctions, classes, méthodes, etc... définis par
l'"utilisateur" (il n'est pas question de traduire les mot-clefs ou la
librairie standard).
Certains ont fait remarquer à juste titre que conduire cette discussion
sur un newsgroup 100% anglophone risquait de donner un résultat
franchement orienté - les personnes lisant et postant sur ce groupe ont
forcément un niveau d'anglais au moins correct - et qu'il serait bon de
"forwarder" (en voilà du français qu'il est bon) la discussion sur des
newsgroups non-anglophones.
Je ne vais toutefois pas traduire l'intégralité du PEP. Voici par contre
les questions à l'origine de la discussion, que j'essaie de traduire le
plus fidèlement possible:
- Est-ce que les caractères non-ASCII doivent être supportés dans les
identificateurs? Pourquoi?
- Si cette possibilité était offerte, l'utiliseriez-vous? Dans quels cas?
Voilà: battons-nous!
(NB: pour éviter d'éventuelles incompréhensions, je préfère donner mon
avis tout de suite: je suis résolument contre ce PEP. J'ai essayé de faire
en sorte que ça ne se voie pas dans ce qui précède, mais on ne sait
jamais; je préfère être clair.)
--
python -c "print ''.join([chr(154 - ord(c)) for c in
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
On Tue, 15 May 2007 08:58:41 +0200, Eric Brunel wrote:
Bonjour à tous,
Une discussion fait rage en ce moment sur c.l.py concernant le PEP 3131 qui propose d'introduire le support des caractères non-ASCII dans les identificateurs en Python. Par identificateurs, on entend bien sûr les noms des variables, fonctions, classes, méthodes, etc... définis par l'"utilisateur" (il n'est pas question de traduire les mot-clefs ou la librairie standard).
Certains ont fait remarquer à juste titre que conduire cette discussion sur un newsgroup 100% anglophone risquait de donner un résultat franchement orienté - les personnes lisant et postant sur ce groupe ont forcément un niveau d'anglais au moins correct - et qu'il serait bon de "forwarder" (en voilà du français qu'il est bon) la discussion sur des newsgroups non-anglophones.
Je ne vais toutefois pas traduire l'intégralité du PEP. Voici par contre les questions à l'origine de la discussion, que j'essaie de traduire le plus fidèlement possible: - Est-ce que les caractères non-ASCII doivent être supportés dans les identificateurs? Pourquoi? - Si cette possibilité était offerte, l'utiliseriez-vous? Dans quels cas?
Voilà: battons-nous!
(NB: pour éviter d'éventuelles incompréhensions, je préfère donner mon avis tout de suite: je suis résolument contre ce PEP. J'ai essayé de faire en sorte que ça ne se voie pas dans ce qui précède, mais on ne sait jamais; je préfère être clair.)
Allo? (...o ...o ...o ...)
Y'a quelqu'un? (...un ...un ...un ...) -- python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
On Tue, 15 May 2007 08:58:41 +0200, Eric Brunel
<eric.brunel@pragmadev.com> wrote:
Bonjour à tous,
Une discussion fait rage en ce moment sur c.l.py concernant le PEP 3131
qui propose d'introduire le support des caractères non-ASCII dans les
identificateurs en Python. Par identificateurs, on entend bien sûr les
noms des variables, fonctions, classes, méthodes, etc... définis par
l'"utilisateur" (il n'est pas question de traduire les mot-clefs ou la
librairie standard).
Certains ont fait remarquer à juste titre que conduire cette discussion
sur un newsgroup 100% anglophone risquait de donner un résultat
franchement orienté - les personnes lisant et postant sur ce groupe ont
forcément un niveau d'anglais au moins correct - et qu'il serait bon de
"forwarder" (en voilà du français qu'il est bon) la discussion sur des
newsgroups non-anglophones.
Je ne vais toutefois pas traduire l'intégralité du PEP. Voici par contre
les questions à l'origine de la discussion, que j'essaie de traduire le
plus fidèlement possible:
- Est-ce que les caractères non-ASCII doivent être supportés dans les
identificateurs? Pourquoi?
- Si cette possibilité était offerte, l'utiliseriez-vous? Dans quels cas?
Voilà: battons-nous!
(NB: pour éviter d'éventuelles incompréhensions, je préfère donner mon
avis tout de suite: je suis résolument contre ce PEP. J'ai essayé de
faire en sorte que ça ne se voie pas dans ce qui précède, mais on ne
sait jamais; je préfère être clair.)
Allo? (...o ...o ...o ...)
Y'a quelqu'un? (...un ...un ...un ...)
--
python -c "print ''.join([chr(154 - ord(c)) for c in
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
On Tue, 15 May 2007 08:58:41 +0200, Eric Brunel wrote:
Bonjour à tous,
Une discussion fait rage en ce moment sur c.l.py concernant le PEP 3131 qui propose d'introduire le support des caractères non-ASCII dans les identificateurs en Python. Par identificateurs, on entend bien sûr les noms des variables, fonctions, classes, méthodes, etc... définis par l'"utilisateur" (il n'est pas question de traduire les mot-clefs ou la librairie standard).
Certains ont fait remarquer à juste titre que conduire cette discussion sur un newsgroup 100% anglophone risquait de donner un résultat franchement orienté - les personnes lisant et postant sur ce groupe ont forcément un niveau d'anglais au moins correct - et qu'il serait bon de "forwarder" (en voilà du français qu'il est bon) la discussion sur des newsgroups non-anglophones.
Je ne vais toutefois pas traduire l'intégralité du PEP. Voici par contre les questions à l'origine de la discussion, que j'essaie de traduire le plus fidèlement possible: - Est-ce que les caractères non-ASCII doivent être supportés dans les identificateurs? Pourquoi? - Si cette possibilité était offerte, l'utiliseriez-vous? Dans quels cas?
Voilà: battons-nous!
(NB: pour éviter d'éventuelles incompréhensions, je préfère donner mon avis tout de suite: je suis résolument contre ce PEP. J'ai essayé de faire en sorte que ça ne se voie pas dans ce qui précède, mais on ne sait jamais; je préfère être clair.)
Allo? (...o ...o ...o ...)
Y'a quelqu'un? (...un ...un ...un ...) -- python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
Laurent Pointal
- Est-ce que les caractères non-ASCII doivent être supportés dans les identificateurs? Pourquoi?
Non cf post sur clp
- Si cette possibilité était offerte, l'utiliseriez-vous? Dans quels cas?
Non.
Voilà: battons-nous!
(en anglais, sur clp)
- Est-ce que les caractères non-ASCII doivent être supportés dans les
identificateurs? Pourquoi?
Non
cf post sur clp
- Si cette possibilité était offerte, l'utiliseriez-vous? Dans quels cas?
- Est-ce que les caractères non-ASCII doivent être supportés dans les identificateurs? Pourquoi?
Non cf post sur clp
- Si cette possibilité était offerte, l'utiliseriez-vous? Dans quels cas?
oui, une fois de temps en temps j'utiliserais 'terminé' au lieu de 'fini' comme nom de booleen pour sortir d'une boucle! -- Pierre
MCI, Shadok Gouroudoudou
Bonsoir !
Est-ce que les caractères non-ASCII doivent être supportés dans les identificateurs? Pourquoi?
OUI !
Parce que çe permettrait une meilleure inter-opérabilité de Python avec d'autres langages / logiciels / applications
La lisibilité peut être supérieure. Quelques exemples :
a = fselect(téléphone = '0475010203')
d = dict( code34, libellé="Article d'essai",
p = person( ) p.civilité = 'M' p.adresse = 'rue du bon français' p.cité = "Vallon Pont d'Arc" p.téléphone = '0102030405'
De nombreux autres langages : javascript, C#, XML 1.1, SQL, ObjectPAL (partiel), etc. ont cette possibilité. Il est temps que Python rattrape son retard sur ce sujet.
Le fait que l'utilisation de caractères non-Ascii soit possible n'entraine pas d'obligation de les utiliser. Chacun continuera à écrire son code selon ses propres critères de lisibilité.
Si cette possibilité était offerte, l'utiliseriez-vous? Dans quels cas?
Oui. Les deux utilisations immédiates seront : - les connexions à des objets javascripts, dont les noms peuvent contenir des lettres non ASCII - la mappage de champs de bases de données, contenant des caractères accentués, vers des propriétés de classes. Cela arrive très souvent, surtout pour accéder à des bases de données déjà en place.
-- @-salutations
Michel Claveau
Bonsoir !
Est-ce que les caractères non-ASCII doivent être supportés dans les
identificateurs? Pourquoi?
OUI !
Parce que çe permettrait une meilleure inter-opérabilité de Python avec
d'autres langages / logiciels / applications
La lisibilité peut être supérieure. Quelques exemples :
a = fselect(téléphone = '0475010203')
d = dict( code34, libellé="Article d'essai",
p = person( )
p.civilité = 'M'
p.adresse = 'rue du bon français'
p.cité = "Vallon Pont d'Arc"
p.téléphone = '0102030405'
De nombreux autres langages : javascript, C#, XML 1.1, SQL, ObjectPAL
(partiel), etc. ont cette possibilité. Il est temps que Python rattrape
son retard sur ce sujet.
Le fait que l'utilisation de caractères non-Ascii soit possible
n'entraine pas d'obligation de les utiliser. Chacun continuera à
écrire son code selon ses propres critères de lisibilité.
Si cette possibilité était offerte, l'utiliseriez-vous? Dans quels cas?
Oui.
Les deux utilisations immédiates seront :
- les connexions à des objets javascripts, dont les noms peuvent
contenir des lettres non ASCII
- la mappage de champs de bases de données, contenant des caractères
accentués, vers des propriétés de classes. Cela arrive très souvent,
surtout pour accéder à des bases de données déjà en place.
Est-ce que les caractères non-ASCII doivent être supportés dans les identificateurs? Pourquoi?
OUI !
Parce que çe permettrait une meilleure inter-opérabilité de Python avec d'autres langages / logiciels / applications
La lisibilité peut être supérieure. Quelques exemples :
a = fselect(téléphone = '0475010203')
d = dict( code34, libellé="Article d'essai",
p = person( ) p.civilité = 'M' p.adresse = 'rue du bon français' p.cité = "Vallon Pont d'Arc" p.téléphone = '0102030405'
De nombreux autres langages : javascript, C#, XML 1.1, SQL, ObjectPAL (partiel), etc. ont cette possibilité. Il est temps que Python rattrape son retard sur ce sujet.
Le fait que l'utilisation de caractères non-Ascii soit possible n'entraine pas d'obligation de les utiliser. Chacun continuera à écrire son code selon ses propres critères de lisibilité.
Si cette possibilité était offerte, l'utiliseriez-vous? Dans quels cas?
Oui. Les deux utilisations immédiates seront : - les connexions à des objets javascripts, dont les noms peuvent contenir des lettres non ASCII - la mappage de champs de bases de données, contenant des caractères accentués, vers des propriétés de classes. Cela arrive très souvent, surtout pour accéder à des bases de données déjà en place.
-- @-salutations
Michel Claveau
olive
'Lut,
Je serais assez d'accord avec Michel pour ce qui concerne les langues latines.
Par contre, je travaille également avec des japonais, chinois, coréens, russes, arabes ...
Je prendrais ma retraite le jour ou j'ai à traiter du code, des bases ou des fichiers XML comportants des identifiants dans ces langues !
Olive.
'Lut,
Je serais assez d'accord avec Michel pour ce qui concerne les langues
latines.
Par contre, je travaille également avec des japonais, chinois,
coréens, russes, arabes ...
Je prendrais ma retraite le jour ou j'ai à traiter du code, des bases
ou des fichiers XML comportants des identifiants dans ces langues !
Je serais assez d'accord avec Michel pour ce qui concerne les langues latines.
Par contre, je travaille également avec des japonais, chinois, coréens, russes, arabes ...
Je prendrais ma retraite le jour ou j'ai à traiter du code, des bases ou des fichiers XML comportants des identifiants dans ces langues !
Olive.
Eric Brunel
On Wed, 16 May 2007 08:08:11 +0200, olive wrote:
'Lut,
Je serais assez d'accord avec Michel pour ce qui concerne les langues latines.
Par contre, je travaille également avec des japonais, chinois, coréens, russes, arabes ...
Je prendrais ma retraite le jour ou j'ai à traiter du code, des bases ou des fichiers XML comportants des identifiants dans ces langues !
C'est en fait tout le problème que je vois là-dedans: tout ça serait effectivement très bien si on pouvait garantir qu'un code prévu a priori comme "local" le reste jusqu'à la fin des temps. Dans le monde où nous vivons, ça me paraît extrèmement difficile à garantir: des codes "privés" finissent par devenir open-source, ou une appli se retrouve maintenue par une équipe à l'autre bout du monde, etc... Si déjà la doc et les commentaires sont en "étranger", c'est déjà pas facile... Si en plus les identificateurs sont avec des caractères que je ne peux peut-être pas lire, et de toutes façons pas écrire, ça va devenir infaisable...
J'oserais même dire (mais tout ça c'est AMHA, hein, même MHA est celui d'un chef de projet depuis pas mal d'années) qu'il est aujourd'hui limite irresponsable de commencer un projet informatique dans une autre langue que l'anglais. Alors j'estime que le support des identificateurs non-ASCII fera plus de mal que de bien. Donc, -1. -- python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
On Wed, 16 May 2007 08:08:11 +0200, olive <ocollioud@gmail.com> wrote:
'Lut,
Je serais assez d'accord avec Michel pour ce qui concerne les langues
latines.
Par contre, je travaille également avec des japonais, chinois,
coréens, russes, arabes ...
Je prendrais ma retraite le jour ou j'ai à traiter du code, des bases
ou des fichiers XML comportants des identifiants dans ces langues !
C'est en fait tout le problème que je vois là-dedans: tout ça serait
effectivement très bien si on pouvait garantir qu'un code prévu a priori
comme "local" le reste jusqu'à la fin des temps. Dans le monde où nous
vivons, ça me paraît extrèmement difficile à garantir: des codes "privés"
finissent par devenir open-source, ou une appli se retrouve maintenue par
une équipe à l'autre bout du monde, etc... Si déjà la doc et les
commentaires sont en "étranger", c'est déjà pas facile... Si en plus les
identificateurs sont avec des caractères que je ne peux peut-être pas
lire, et de toutes façons pas écrire, ça va devenir infaisable...
J'oserais même dire (mais tout ça c'est AMHA, hein, même MHA est celui
d'un chef de projet depuis pas mal d'années) qu'il est aujourd'hui limite
irresponsable de commencer un projet informatique dans une autre langue
que l'anglais. Alors j'estime que le support des identificateurs non-ASCII
fera plus de mal que de bien. Donc, -1.
--
python -c "print ''.join([chr(154 - ord(c)) for c in
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
Je serais assez d'accord avec Michel pour ce qui concerne les langues latines.
Par contre, je travaille également avec des japonais, chinois, coréens, russes, arabes ...
Je prendrais ma retraite le jour ou j'ai à traiter du code, des bases ou des fichiers XML comportants des identifiants dans ces langues !
C'est en fait tout le problème que je vois là-dedans: tout ça serait effectivement très bien si on pouvait garantir qu'un code prévu a priori comme "local" le reste jusqu'à la fin des temps. Dans le monde où nous vivons, ça me paraît extrèmement difficile à garantir: des codes "privés" finissent par devenir open-source, ou une appli se retrouve maintenue par une équipe à l'autre bout du monde, etc... Si déjà la doc et les commentaires sont en "étranger", c'est déjà pas facile... Si en plus les identificateurs sont avec des caractères que je ne peux peut-être pas lire, et de toutes façons pas écrire, ça va devenir infaisable...
J'oserais même dire (mais tout ça c'est AMHA, hein, même MHA est celui d'un chef de projet depuis pas mal d'années) qu'il est aujourd'hui limite irresponsable de commencer un projet informatique dans une autre langue que l'anglais. Alors j'estime que le support des identificateurs non-ASCII fera plus de mal que de bien. Donc, -1. -- python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
Eric Masson
"Eric Brunel" writes:
'Lut,
J'oserais même dire (mais tout ça c'est AMHA, hein, même MHA est celui d'un chef de projet depuis pas mal d'années) qu'il est aujourd'hui limite irresponsable de commencer un projet informatique dans une autre langue que l'anglais. Alors j'estime que le support des identificateurs non-ASCII fera plus de mal que de bien. Donc, -1.
Tout pareil. C'est ce que l'on appelle une fausse bonne idée (et surtout une source d'emmerdes potentiels de premier choix)
-- [OUI] à fr.rec.tv.poubelle. Ca dépasse la perspective de Loft Story et il pourrait être réutilisé à l'avenir. C'est même le plus prometteur des groupes tv. A terme on devrait pouvoir supprimer tous les autres. -+- SP in <http://www.le-gnu.net> - La poubelle pour aller mater -+-
"Eric Brunel" <see.signature@no.spam> writes:
'Lut,
J'oserais même dire (mais tout ça c'est AMHA, hein, même MHA est celui
d'un chef de projet depuis pas mal d'années) qu'il est aujourd'hui
limite irresponsable de commencer un projet informatique dans une autre
langue que l'anglais. Alors j'estime que le support des identificateurs
non-ASCII fera plus de mal que de bien. Donc, -1.
Tout pareil. C'est ce que l'on appelle une fausse bonne idée (et surtout
une source d'emmerdes potentiels de premier choix)
--
[OUI] à fr.rec.tv.poubelle. Ca dépasse la perspective de Loft Story et
il pourrait être réutilisé à l'avenir. C'est même le plus prometteur
des groupes tv. A terme on devrait pouvoir supprimer tous les autres.
-+- SP in <http://www.le-gnu.net> - La poubelle pour aller mater -+-
J'oserais même dire (mais tout ça c'est AMHA, hein, même MHA est celui d'un chef de projet depuis pas mal d'années) qu'il est aujourd'hui limite irresponsable de commencer un projet informatique dans une autre langue que l'anglais. Alors j'estime que le support des identificateurs non-ASCII fera plus de mal que de bien. Donc, -1.
Tout pareil. C'est ce que l'on appelle une fausse bonne idée (et surtout une source d'emmerdes potentiels de premier choix)
-- [OUI] à fr.rec.tv.poubelle. Ca dépasse la perspective de Loft Story et il pourrait être réutilisé à l'avenir. C'est même le plus prometteur des groupes tv. A terme on devrait pouvoir supprimer tous les autres. -+- SP in <http://www.le-gnu.net> - La poubelle pour aller mater -+-
Bruno Desthuilliers
"Eric Brunel" writes:
'Lut,
J'oserais même dire (mais tout ça c'est AMHA, hein, même MHA est celui d'un chef de projet depuis pas mal d'années) qu'il est aujourd'hui limite irresponsable de commencer un projet informatique dans une autre langue que l'anglais. Alors j'estime que le support des identificateurs non-ASCII fera plus de mal que de bien. Donc, -1.
Tout pareil. C'est ce que l'on appelle une fausse bonne idée (et surtout une source d'emmerdes potentiels de premier choix)
Mon humble avis également. Accessoirement, les arguments concernant l'accessibilité du langage pour des non-anglophones me fait doucement sourire dans la mesure où les mots réservés, les instructions, et tous les identifiants des builtins et de la bibliothèque standard sont en anglais... Sauf à trouver un moyen d'avoir une traduction de tous ces éléments, les bénéfices me semblent bien plus faibles que les emmerdements.
Accessoirement, les réactions à ce PEP sont assez tranchées sur c.l.py, et bon nombres d'opposants (dont votre humble serviteur) ne sont pas de culture anglophones.
"Eric Brunel" <see.signature@no.spam> writes:
'Lut,
J'oserais même dire (mais tout ça c'est AMHA, hein, même MHA est celui
d'un chef de projet depuis pas mal d'années) qu'il est aujourd'hui
limite irresponsable de commencer un projet informatique dans une autre
langue que l'anglais. Alors j'estime que le support des identificateurs
non-ASCII fera plus de mal que de bien. Donc, -1.
Tout pareil. C'est ce que l'on appelle une fausse bonne idée (et surtout
une source d'emmerdes potentiels de premier choix)
Mon humble avis également. Accessoirement, les arguments concernant
l'accessibilité du langage pour des non-anglophones me fait doucement
sourire dans la mesure où les mots réservés, les instructions, et tous
les identifiants des builtins et de la bibliothèque standard sont en
anglais... Sauf à trouver un moyen d'avoir une traduction de tous ces
éléments, les bénéfices me semblent bien plus faibles que les emmerdements.
Accessoirement, les réactions à ce PEP sont assez tranchées sur c.l.py,
et bon nombres d'opposants (dont votre humble serviteur) ne sont pas de
culture anglophones.
J'oserais même dire (mais tout ça c'est AMHA, hein, même MHA est celui d'un chef de projet depuis pas mal d'années) qu'il est aujourd'hui limite irresponsable de commencer un projet informatique dans une autre langue que l'anglais. Alors j'estime que le support des identificateurs non-ASCII fera plus de mal que de bien. Donc, -1.
Tout pareil. C'est ce que l'on appelle une fausse bonne idée (et surtout une source d'emmerdes potentiels de premier choix)
Mon humble avis également. Accessoirement, les arguments concernant l'accessibilité du langage pour des non-anglophones me fait doucement sourire dans la mesure où les mots réservés, les instructions, et tous les identifiants des builtins et de la bibliothèque standard sont en anglais... Sauf à trouver un moyen d'avoir une traduction de tous ces éléments, les bénéfices me semblent bien plus faibles que les emmerdements.
Accessoirement, les réactions à ce PEP sont assez tranchées sur c.l.py, et bon nombres d'opposants (dont votre humble serviteur) ne sont pas de culture anglophones.
hg
Justin Avis wrote:
J'oserais même dire (mais tout ça c'est AMHA, hein, même MHA est celui d'un chef de projet depuis pas mal d'années) qu'il est aujourd'hui limite irresponsable de commencer un projet informatique dans une autre langue que l'anglais.
Aïe ! On dit que les Français sont connus pour leur mauvaise maitrise des langues étrangères. L'anglais ne fait pas exception. Ni la population des informaticiens / développeurs. La modeste entreprise qui m'emploie a vu passer bon nombre de développeurs. Très très peu maitrisent vraiment l'anglais... La plupart se débrouille lorsqu'il est question de lire une documentation en anglais. C'est mieux si ladite documentation donne un petit bout de code en exemple. Là comme ailleurs, un "schéma" vaut mieux qu'un long discours...
Clairement, il n'y avait aucun lien entre la qualité du travail des développeurs et l'éventuelle maitrise réelle de l'anglais...
Bref, sauf pour des projets impliquant des personnes de langues différentes, il n'y a aucune raison de ne pas privilégier sa belle langue natale... Quelle que soit cette langue !
Dans les autres cas, cela dépend... L'anglais est alors une option. On peut imaginer l'allemand pour un projet intéressant des pays d'Europe centrale, le français pour l'Afrique de l'ouest, l'espagnol pour l'amérique latine, etc, etc...
En tant que citoyen de France, je m'insurge contre cet anglais déjà bien assez présent et auquel il me parait sain de ne pas donner d'avantage d'espace encore ! Aussi votre proposition de faire travailler vos gens en anglais sur "vos" projets me fait bondir, à moins que vous ne soyez dans une situation particulière qu'assez peu de monde connait dans sa vie professionelle : à savoir un projet informatique impliquant ou pouvant réellement concerner des personnes (pas les utilisateurs finaux) de langues natales différentes...
Au delà de ces quelques remarques, j'approuve totalement la remarque suivante de de M. CLAVEAUX :
Un (double) exemple : "USA" et "print". Dans les deux cas, la compréhension est devenue indépendante du langage d'origine, la signification a suivi sa propre voie.
Pour autant, je ne suis pas un chaud partisant des caractères accentués... Cela me parait une vraie source de problèmes très pénibles... En français, déjà, les fautes sont - hélas - loin de se faire rares... Alors en anglais... S'agissant des fautes, d'ailleurs, merçi de ne pas relever celles que j'aurais pû faire dans ce post ;-)
Cela étant, certains arguments de M. Claveaux laissent clairement à penser que les caractères accentués, cela peut se révéler utile... Ne pourrait-on imaginer une sorte de "directive de compilation", par défaut à "false" qui autoriserait l'usage de caractères accentués dans un source... Histoire de mettre tout le monde d'accord, et que reignent la paix et la concorde :-)
PS : Question subsidiaire : comment font donc les Suisses ? Les Belges ? Un retour d'expérience de développeurs francophones de ces pays serait sans doute riche d'enseignements ! Même si le bi-linguisme est sans doute d'avantage un réflex dans ces pays... Méfiance donc... Il ne faudrait donc pas généraliser hativement... A moins que leurs expéricens n'abondent dans mon sens, cela va de soi ;-)
Je le répète: les langages informatiques sont _déjà_ en anglais.
Il faut bien standardiser quelque part ... il fut un temps, la langue diplomatique internationale était le Français (sigh!)
Rien de plus moche qu'un code (donc syntaxe en Anglais) avec des attributs en Français.
Pour ce qui est de la délocalisation ... il faut savoir que tous les softs (ou presque) développés aux US sont en fait sous-traité en Inde (oui je sais, encore un coup des British, ils avaient prévus le coups ils y a des siècles rien que pour nous emm.... !)
Et que serait aujourd'hui FSF/GNU si chaque membre codait dans sa propre langue ?
Ne _pas_ le prendre personnellement: "... les imbéciles heureux qui sont nés quelque part ..." (Brassens) ... les guerres de paroisses n'ont jamais crées que des morts.
Un source mal codé même en Anglais est de toutes les façons _déjà_ incompréhensible.
Voilà je m'énerve ...
hg
Justin Avis wrote:
J'oserais même dire (mais tout ça c'est AMHA, hein, même MHA est celui
d'un chef de projet depuis pas mal d'années) qu'il est aujourd'hui
limite irresponsable de commencer un projet informatique dans une autre
langue que l'anglais.
Aïe ! On dit que les Français sont connus pour leur mauvaise maitrise des
langues étrangères. L'anglais ne fait pas exception. Ni la population des
informaticiens / développeurs. La modeste entreprise qui m'emploie a vu
passer bon nombre de développeurs. Très très peu maitrisent vraiment
l'anglais... La plupart se débrouille lorsqu'il est question de lire une
documentation en anglais. C'est mieux si ladite documentation donne un
petit bout de code en exemple. Là comme ailleurs, un "schéma" vaut mieux
qu'un long discours...
Clairement, il n'y avait aucun lien entre la qualité du travail des
développeurs et l'éventuelle maitrise réelle de l'anglais...
Bref, sauf pour des projets impliquant des personnes de langues
différentes, il n'y a aucune raison de ne pas privilégier sa belle langue
natale... Quelle que soit cette langue !
Dans les autres cas, cela dépend... L'anglais est alors une option. On
peut imaginer l'allemand pour un projet intéressant des pays d'Europe
centrale, le français pour l'Afrique de l'ouest, l'espagnol pour
l'amérique latine, etc, etc...
En tant que citoyen de France, je m'insurge contre cet anglais déjà bien
assez présent et auquel il me parait sain de ne pas donner d'avantage
d'espace encore ! Aussi votre proposition de faire travailler vos gens en
anglais sur "vos" projets me fait bondir, à moins que vous ne soyez dans
une situation particulière qu'assez peu de monde connait dans sa vie
professionelle : à savoir un projet informatique impliquant ou pouvant
réellement concerner des personnes (pas les utilisateurs finaux) de
langues natales différentes...
Au delà de ces quelques remarques, j'approuve totalement la remarque
suivante de de M. CLAVEAUX :
Un (double) exemple : "USA" et "print". Dans les deux cas, la
compréhension est devenue indépendante du langage d'origine, la
signification a suivi sa propre voie.
Pour autant, je ne suis pas un chaud partisant des caractères accentués...
Cela me parait une vraie source de problèmes très pénibles... En français,
déjà, les fautes sont - hélas - loin de se faire rares... Alors en
anglais... S'agissant des fautes, d'ailleurs, merçi de ne pas relever
celles que j'aurais pû faire dans ce post ;-)
Cela étant, certains arguments de M. Claveaux laissent clairement à penser
que les caractères accentués, cela peut se révéler utile... Ne pourrait-on
imaginer une sorte de "directive de compilation", par défaut à "false" qui
autoriserait l'usage de caractères accentués dans un source... Histoire de
mettre tout le monde d'accord, et que reignent la paix et la concorde :-)
PS : Question subsidiaire : comment font donc les Suisses ? Les Belges ?
Un retour d'expérience de développeurs francophones de ces pays serait
sans doute riche d'enseignements ! Même si le bi-linguisme est sans doute
d'avantage un réflex dans ces pays... Méfiance donc... Il ne faudrait donc
pas généraliser hativement... A moins que leurs expéricens n'abondent dans
mon sens, cela va de soi ;-)
Je le répète: les langages informatiques sont _déjà_ en anglais.
Il faut bien standardiser quelque part ... il fut un temps, la langue
diplomatique internationale était le Français (sigh!)
Rien de plus moche qu'un code (donc syntaxe en Anglais) avec des attributs
en Français.
Pour ce qui est de la délocalisation ... il faut savoir que tous les softs
(ou presque) développés aux US sont en fait sous-traité en Inde (oui je
sais, encore un coup des British, ils avaient prévus le coups ils y a des
siècles rien que pour nous emm.... !)
Et que serait aujourd'hui FSF/GNU si chaque membre codait dans sa propre
langue ?
Ne _pas_ le prendre personnellement: "... les imbéciles heureux qui sont nés
quelque part ..." (Brassens) ... les guerres de paroisses n'ont jamais
crées que des morts.
Un source mal codé même en Anglais est de toutes les façons _déjà_
incompréhensible.
J'oserais même dire (mais tout ça c'est AMHA, hein, même MHA est celui d'un chef de projet depuis pas mal d'années) qu'il est aujourd'hui limite irresponsable de commencer un projet informatique dans une autre langue que l'anglais.
Aïe ! On dit que les Français sont connus pour leur mauvaise maitrise des langues étrangères. L'anglais ne fait pas exception. Ni la population des informaticiens / développeurs. La modeste entreprise qui m'emploie a vu passer bon nombre de développeurs. Très très peu maitrisent vraiment l'anglais... La plupart se débrouille lorsqu'il est question de lire une documentation en anglais. C'est mieux si ladite documentation donne un petit bout de code en exemple. Là comme ailleurs, un "schéma" vaut mieux qu'un long discours...
Clairement, il n'y avait aucun lien entre la qualité du travail des développeurs et l'éventuelle maitrise réelle de l'anglais...
Bref, sauf pour des projets impliquant des personnes de langues différentes, il n'y a aucune raison de ne pas privilégier sa belle langue natale... Quelle que soit cette langue !
Dans les autres cas, cela dépend... L'anglais est alors une option. On peut imaginer l'allemand pour un projet intéressant des pays d'Europe centrale, le français pour l'Afrique de l'ouest, l'espagnol pour l'amérique latine, etc, etc...
En tant que citoyen de France, je m'insurge contre cet anglais déjà bien assez présent et auquel il me parait sain de ne pas donner d'avantage d'espace encore ! Aussi votre proposition de faire travailler vos gens en anglais sur "vos" projets me fait bondir, à moins que vous ne soyez dans une situation particulière qu'assez peu de monde connait dans sa vie professionelle : à savoir un projet informatique impliquant ou pouvant réellement concerner des personnes (pas les utilisateurs finaux) de langues natales différentes...
Au delà de ces quelques remarques, j'approuve totalement la remarque suivante de de M. CLAVEAUX :
Un (double) exemple : "USA" et "print". Dans les deux cas, la compréhension est devenue indépendante du langage d'origine, la signification a suivi sa propre voie.
Pour autant, je ne suis pas un chaud partisant des caractères accentués... Cela me parait une vraie source de problèmes très pénibles... En français, déjà, les fautes sont - hélas - loin de se faire rares... Alors en anglais... S'agissant des fautes, d'ailleurs, merçi de ne pas relever celles que j'aurais pû faire dans ce post ;-)
Cela étant, certains arguments de M. Claveaux laissent clairement à penser que les caractères accentués, cela peut se révéler utile... Ne pourrait-on imaginer une sorte de "directive de compilation", par défaut à "false" qui autoriserait l'usage de caractères accentués dans un source... Histoire de mettre tout le monde d'accord, et que reignent la paix et la concorde :-)
PS : Question subsidiaire : comment font donc les Suisses ? Les Belges ? Un retour d'expérience de développeurs francophones de ces pays serait sans doute riche d'enseignements ! Même si le bi-linguisme est sans doute d'avantage un réflex dans ces pays... Méfiance donc... Il ne faudrait donc pas généraliser hativement... A moins que leurs expéricens n'abondent dans mon sens, cela va de soi ;-)
Je le répète: les langages informatiques sont _déjà_ en anglais.
Il faut bien standardiser quelque part ... il fut un temps, la langue diplomatique internationale était le Français (sigh!)
Rien de plus moche qu'un code (donc syntaxe en Anglais) avec des attributs en Français.
Pour ce qui est de la délocalisation ... il faut savoir que tous les softs (ou presque) développés aux US sont en fait sous-traité en Inde (oui je sais, encore un coup des British, ils avaient prévus le coups ils y a des siècles rien que pour nous emm.... !)
Et que serait aujourd'hui FSF/GNU si chaque membre codait dans sa propre langue ?
Ne _pas_ le prendre personnellement: "... les imbéciles heureux qui sont nés quelque part ..." (Brassens) ... les guerres de paroisses n'ont jamais crées que des morts.
Un source mal codé même en Anglais est de toutes les façons _déjà_ incompréhensible.
Voilà je m'énerve ...
hg
MCI, Shadok Gouroudoudou
Salut !
une appli se retrouve maintenue par une équipe à l'autre bout du monde Si déjà la doc et les commentaires sont en "étranger", c'est déjà pas facile ... Si en plus les identificateurst avec des caractères que je ne peux peut-être pas lire, et de toutes façons pas écrire ça va devenir infaisable...
Si tu ne peux pas lire doc & commentaires, le problème se pose déjà, et la possibilité, ou l'impossibilité, de caractères non-Ascii dans les identifiants ne changera rien.
limite irresponsable de commencer un projet informatique dans une autre langue que l'anglais
On peut très bien avoir la possibilité d'identificateurs non-ASCII et n'utiliser que de l'anglais.
Exactement comme pour les commentaires, docs, etc. ACTUELLEMENT.
Il me semble important d'avoir la POSSIBILITE d'utiliser des caractères non-Ascii, sans avoir l'OBLIGATION de le faire. Chacun sera libre de ses choix, ce qui n'est pas le cas actuellement.
Pour le choix de l'anglais comme langue unique, dans des projets informatiques, je trouve ça abhérant, en France. Qu'il y ait les deux langues (français + anglais), OK. Mais, anglais seul, non.
Déjà, lorsque j'ai des revues de codes, chez certains clients, s'ils trouvent des mots anglais, je me fais incendier, alors, tout en anglais, ça serait catastrophique.
En fait, il faut tenir compte des destinataires du code (pour qui on développe), et des utilisateurs. Je sais, c'est plutôt une démarche commerciale, voire propriétaire. Mais je travaille surtout pour des clients...
-- @-salutations
Michel Claveau
Salut !
une appli se retrouve maintenue par une équipe à l'autre bout du monde
Si déjà la doc et les commentaires sont en "étranger", c'est déjà pas
facile ... Si en plus les identificateurst avec des caractères que
je ne peux peut-être pas lire, et de toutes façons pas écrire ça va
devenir infaisable...
Si tu ne peux pas lire doc & commentaires, le problème se pose déjà, et
la possibilité, ou l'impossibilité, de caractères non-Ascii dans les
identifiants ne changera rien.
limite irresponsable de commencer un projet informatique dans une
autre langue que l'anglais
On peut très bien avoir la possibilité d'identificateurs non-ASCII et
n'utiliser que de l'anglais.
Exactement comme pour les commentaires, docs, etc. ACTUELLEMENT.
Il me semble important d'avoir la POSSIBILITE d'utiliser des caractères
non-Ascii, sans avoir l'OBLIGATION de le faire. Chacun sera libre de
ses choix, ce qui n'est pas le cas actuellement.
Pour le choix de l'anglais comme langue unique, dans des projets
informatiques, je trouve ça abhérant, en France.
Qu'il y ait les deux langues (français + anglais), OK. Mais, anglais
seul, non.
Déjà, lorsque j'ai des revues de codes, chez certains clients, s'ils
trouvent des mots anglais, je me fais incendier, alors, tout en
anglais, ça serait catastrophique.
En fait, il faut tenir compte des destinataires du code (pour qui on
développe), et des utilisateurs. Je sais, c'est plutôt une démarche
commerciale, voire propriétaire. Mais je travaille surtout pour des
clients...
une appli se retrouve maintenue par une équipe à l'autre bout du monde Si déjà la doc et les commentaires sont en "étranger", c'est déjà pas facile ... Si en plus les identificateurst avec des caractères que je ne peux peut-être pas lire, et de toutes façons pas écrire ça va devenir infaisable...
Si tu ne peux pas lire doc & commentaires, le problème se pose déjà, et la possibilité, ou l'impossibilité, de caractères non-Ascii dans les identifiants ne changera rien.
limite irresponsable de commencer un projet informatique dans une autre langue que l'anglais
On peut très bien avoir la possibilité d'identificateurs non-ASCII et n'utiliser que de l'anglais.
Exactement comme pour les commentaires, docs, etc. ACTUELLEMENT.
Il me semble important d'avoir la POSSIBILITE d'utiliser des caractères non-Ascii, sans avoir l'OBLIGATION de le faire. Chacun sera libre de ses choix, ce qui n'est pas le cas actuellement.
Pour le choix de l'anglais comme langue unique, dans des projets informatiques, je trouve ça abhérant, en France. Qu'il y ait les deux langues (français + anglais), OK. Mais, anglais seul, non.
Déjà, lorsque j'ai des revues de codes, chez certains clients, s'ils trouvent des mots anglais, je me fais incendier, alors, tout en anglais, ça serait catastrophique.
En fait, il faut tenir compte des destinataires du code (pour qui on développe), et des utilisateurs. Je sais, c'est plutôt une démarche commerciale, voire propriétaire. Mais je travaille surtout pour des clients...
