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+-'])"
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.
Il y a une difference entre recopier un truc que tu ne comprends pas forcement, mais dont tu disposes d'une explication (docs de la stdlib traduites par exemple) et devoir inventer des mots en anglais pour décrire les concepts que tu veux créer (variables, membres fonctions)
Et puis il y a le problème de l'interop entre le Python et d'autres outils exterrieurs qui accèptent des identifiants en non ASCII. Table de SGBD, code en C# utilisant librement les symboles mathématiques etc...
"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.
Il y a une difference entre recopier un truc que tu ne comprends pas
forcement, mais dont tu disposes d'une explication (docs de la stdlib
traduites par exemple) et devoir inventer des mots en anglais pour
décrire les concepts que tu veux créer (variables, membres fonctions)
Et puis il y a le problème de l'interop entre le Python et d'autres
outils exterrieurs qui accèptent des identifiants en non ASCII. Table de
SGBD, code en C# utilisant librement les symboles mathématiques etc...
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.
Il y a une difference entre recopier un truc que tu ne comprends pas forcement, mais dont tu disposes d'une explication (docs de la stdlib traduites par exemple) et devoir inventer des mots en anglais pour décrire les concepts que tu veux créer (variables, membres fonctions)
Et puis il y a le problème de l'interop entre le Python et d'autres outils exterrieurs qui accèptent des identifiants en non ASCII. Table de SGBD, code en C# utilisant librement les symboles mathématiques etc...
MCI, Shadok Gouroudoudou
Salut !
arguments concernant l'accessibilité du langage pour non-anglophones
Perso, je n'ai jamais utilisé cet argument, mais plutôt une augmentation de l'accessibilité de Python sur des trucs extérieurs (librairies dans d'autres langages, SGBD, applications externes, etc.)
Personne ne m'a répondu, sur la possibilité de connecter une classe sur des enregistrements contenant des champs accentués, que l'on pourrait considérer comme des propriétés de la classe : c = client() c.numéro = 'CL001' c.nom = 'Beatnik' c.prénom = 'Bruno' c.téléphone = '+331234567890'
-- @-salutations
Michel Claveau
Salut !
arguments concernant l'accessibilité du langage pour non-anglophones
Perso, je n'ai jamais utilisé cet argument, mais plutôt une
augmentation de l'accessibilité de Python sur des trucs extérieurs
(librairies dans d'autres langages, SGBD, applications externes, etc.)
Personne ne m'a répondu, sur la possibilité de connecter une classe sur
des enregistrements contenant des champs accentués, que l'on pourrait
considérer comme des propriétés de la classe :
c = client()
c.numéro = 'CL001'
c.nom = 'Beatnik'
c.prénom = 'Bruno'
c.téléphone = '+331234567890'
arguments concernant l'accessibilité du langage pour non-anglophones
Perso, je n'ai jamais utilisé cet argument, mais plutôt une augmentation de l'accessibilité de Python sur des trucs extérieurs (librairies dans d'autres langages, SGBD, applications externes, etc.)
Personne ne m'a répondu, sur la possibilité de connecter une classe sur des enregistrements contenant des champs accentués, que l'on pourrait considérer comme des propriétés de la classe : c = client() c.numéro = 'CL001' c.nom = 'Beatnik' c.prénom = 'Bruno' c.téléphone = '+331234567890'
-- @-salutations
Michel Claveau
MCI, Shadok Gouroudoudou
Bonjour !
Table de SGBD, code en C# utilisant librement les symboles mathématiques
Exact.
On pourrait ajouter les objets des pages HTML (id avec lettres accentuées), les librairies javascript/Ajax, etc.
Et j'ai trouvé d'autres trucs : la plupart des outils Python mappant des arbres XML ne sont pas entièrement compatibles avec XML 1.1, à cause du non support des tags accentués.
Idem avec YAML, avec les tags unicode.
-- @-salutations
Michel Claveau
Bonjour !
Table de SGBD, code en C# utilisant librement les symboles mathématiques
Exact.
On pourrait ajouter les objets des pages HTML (id avec lettres
accentuées), les librairies javascript/Ajax, etc.
Et j'ai trouvé d'autres trucs : la plupart des outils Python mappant
des arbres XML ne sont pas entièrement compatibles avec XML 1.1, à
cause du non support des tags accentués.
Table de SGBD, code en C# utilisant librement les symboles mathématiques
Exact.
On pourrait ajouter les objets des pages HTML (id avec lettres accentuées), les librairies javascript/Ajax, etc.
Et j'ai trouvé d'autres trucs : la plupart des outils Python mappant des arbres XML ne sont pas entièrement compatibles avec XML 1.1, à cause du non support des tags accentués.
Idem avec YAML, avec les tags unicode.
-- @-salutations
Michel Claveau
Eric Brunel
On Wed, 16 May 2007 11:53:55 +0200, <MCI> wrote:
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.
Si: ce sera pire. Avant, au moins, le code, tu pouvais le mettre à jour avec n'importe quel clavier. Il aurait certes été très difficile à comprendre sans la doc et les commentaires, mais si tu y arrives, tu peux. Avec les identificateurs non-ASCII, tu ne peux plus. Pour moi, c'est un problème.
[snip]
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.
Si on va par là, tous les français devraient coder en LSE... [1]
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...
... qui devraient voir plus loin que le bout de leur nez et accepter le fait que leur appli puisse un jour se retrouver chez des non-francophones... Mais je sais ce qu'est la relation client...
[1] LSE, à l'origine Langage Symbolique d'Enseignement, devenu depuis Langage Sans Espoir - http://fr.wikipedia.org/wiki/LSE_(langage_de_programmation) -- 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 11:53:55 +0200, <MCI> wrote:
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.
Si: ce sera pire. Avant, au moins, le code, tu pouvais le mettre à jour
avec n'importe quel clavier. Il aurait certes été très difficile à
comprendre sans la doc et les commentaires, mais si tu y arrives, tu peux.
Avec les identificateurs non-ASCII, tu ne peux plus. Pour moi, c'est un
problème.
[snip]
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.
Si on va par là, tous les français devraient coder en LSE... [1]
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...
... qui devraient voir plus loin que le bout de leur nez et accepter le
fait que leur appli puisse un jour se retrouver chez des
non-francophones... Mais je sais ce qu'est la relation client...
[1] LSE, à l'origine Langage Symbolique d'Enseignement, devenu depuis
Langage Sans Espoir -
http://fr.wikipedia.org/wiki/LSE_(langage_de_programmation)
--
python -c "print ''.join([chr(154 - ord(c)) for c in
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
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.
Si: ce sera pire. Avant, au moins, le code, tu pouvais le mettre à jour avec n'importe quel clavier. Il aurait certes été très difficile à comprendre sans la doc et les commentaires, mais si tu y arrives, tu peux. Avec les identificateurs non-ASCII, tu ne peux plus. Pour moi, c'est un problème.
[snip]
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.
Si on va par là, tous les français devraient coder en LSE... [1]
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...
... qui devraient voir plus loin que le bout de leur nez et accepter le fait que leur appli puisse un jour se retrouver chez des non-francophones... Mais je sais ce qu'est la relation client...
[1] LSE, à l'origine Langage Symbolique d'Enseignement, devenu depuis Langage Sans Espoir - http://fr.wikipedia.org/wiki/LSE_(langage_de_programmation) -- python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
MCI, Shadok Gouroudoudou
Salut à tous !
Je me demande si ceux qui refusent les caractères non-Ascii n'auraient pas, quelque part, peur d'être débordé, ou dépassés, par des caractères "étrangers".
Et ce pourrait être interprété au-delà du simple conservatisme, jusqu'à une sorte de xénophobie (pour ne pas employer un mot encore pire).
Evidement, cela se passe au niveau du subconscient, voire de l'inconscient.
S'il y a des fans de Jung, de Freud ou de Lacan dans la salle...
;o)
-- @-salutations
Michel Claveau
Salut à tous !
Je me demande si ceux qui refusent les caractères non-Ascii n'auraient
pas, quelque part, peur d'être débordé, ou dépassés, par des caractères
"étrangers".
Et ce pourrait être interprété au-delà du simple conservatisme, jusqu'à
une sorte de xénophobie (pour ne pas employer un mot encore pire).
Evidement, cela se passe au niveau du subconscient, voire de
l'inconscient.
S'il y a des fans de Jung, de Freud ou de Lacan dans la salle...
Je me demande si ceux qui refusent les caractères non-Ascii n'auraient pas, quelque part, peur d'être débordé, ou dépassés, par des caractères "étrangers".
Et ce pourrait être interprété au-delà du simple conservatisme, jusqu'à une sorte de xénophobie (pour ne pas employer un mot encore pire).
Evidement, cela se passe au niveau du subconscient, voire de l'inconscient.
S'il y a des fans de Jung, de Freud ou de Lacan dans la salle...
;o)
-- @-salutations
Michel Claveau
Eric Masson
"Eric Brunel" writes:
'Lut,
Si on va par là, tous les français devraient coder en LSE... [1]
Argh, je ne suis donc pas le seul à avoir subi cette ineptie que je me suis empressé d'oublier depuis quand même ;)
-- Je cherche un organisme fournisseur d'oeufs embryonnés autre que le centre d'élevage d'Artenay qui vient de fermer, pour la réalisation de TP de culture de cardiomyocytes -+- DZ in : Guide du Neuneu Usenet - Pas de neuneux félés chez fbci -+-
"Eric Brunel" <see.signature@no.spam> writes:
'Lut,
Si on va par là, tous les français devraient coder en LSE... [1]
Argh, je ne suis donc pas le seul à avoir subi cette ineptie que je me
suis empressé d'oublier depuis quand même ;)
--
Je cherche un organisme fournisseur d'oeufs embryonnés autre que le
centre d'élevage d'Artenay qui vient de fermer, pour la réalisation de
TP de culture de cardiomyocytes
-+- DZ in : Guide du Neuneu Usenet - Pas de neuneux félés chez fbci -+-
Si on va par là, tous les français devraient coder en LSE... [1]
Argh, je ne suis donc pas le seul à avoir subi cette ineptie que je me suis empressé d'oublier depuis quand même ;)
-- Je cherche un organisme fournisseur d'oeufs embryonnés autre que le centre d'élevage d'Artenay qui vient de fermer, pour la réalisation de TP de culture de cardiomyocytes -+- DZ in : Guide du Neuneu Usenet - Pas de neuneux félés chez fbci -+-
MCI, Shadok Gouroudoudou
Re !
les mots réservés, les instructions, les identifiants des builtins... ... sont en anglais
C'est une erreur d'interprétation.
Ces mots ne sont pas en anglais. Ce sont des mots dérivés de mots anglais, mais ils sont leur signification, leur orthographe, leur vie propre.
C'est le même principe que les acronymes. Batis à partir de quelque chose, ils acquièrent une autonomie propre, et une signification directe, qui devient indépendante du langage d'origine.
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.
Un exemple plus européen : "CH" pour les immatriculation suisses. Il est surprenant de voir le nombre de personnes qui sont capable d'identifier le pays de la voiture, sans connaitre la signification de l'acronyme.
Conclusion : les mots-clefs ne sont pas des mots-anglais, mais des éléments de Python.
-- @-salutations
Michel Claveau
Re !
les mots réservés, les instructions, les identifiants des builtins...
... sont en anglais
C'est une erreur d'interprétation.
Ces mots ne sont pas en anglais. Ce sont des mots dérivés de mots
anglais, mais ils sont leur signification, leur orthographe, leur vie
propre.
C'est le même principe que les acronymes. Batis à partir de quelque
chose, ils acquièrent une autonomie propre, et une signification
directe, qui devient indépendante du langage d'origine.
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.
Un exemple plus européen : "CH" pour les immatriculation suisses. Il
est surprenant de voir le nombre de personnes qui sont capable
d'identifier le pays de la voiture, sans connaitre la signification de
l'acronyme.
Conclusion : les mots-clefs ne sont pas des mots-anglais, mais des
éléments de Python.
les mots réservés, les instructions, les identifiants des builtins... ... sont en anglais
C'est une erreur d'interprétation.
Ces mots ne sont pas en anglais. Ce sont des mots dérivés de mots anglais, mais ils sont leur signification, leur orthographe, leur vie propre.
C'est le même principe que les acronymes. Batis à partir de quelque chose, ils acquièrent une autonomie propre, et une signification directe, qui devient indépendante du langage d'origine.
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.
Un exemple plus européen : "CH" pour les immatriculation suisses. Il est surprenant de voir le nombre de personnes qui sont capable d'identifier le pays de la voiture, sans connaitre la signification de l'acronyme.
Conclusion : les mots-clefs ne sont pas des mots-anglais, mais des éléments de Python.
-- @-salutations
Michel Claveau
jean-michel bain-cornu
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. A une époque, on a eu un mal de chien à obtenir à ce que les systèmes
puissent être en français, pour tout un tas de (mauvaises ?) raisons qu'on retrouve peu ou prou aujourd'hui ici. Commencer un projet en anglais, c'est bien à condition que ça aie un sens dans le contexte de la vie du projet, et c'est très réducteur car un grand nombre de développeurs ne sont pas à l'aise en anglais. Faire de l'anglais dans un contexte régional, voilà qui serait peut-être considéré comme irresponsable... Notons que si le projet devient international (0,001% des projets ?), il ne devrait tout de même pas être si difficile de scanner les sources et d'angliciser les identificateurs !
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.
A une époque, on a eu un mal de chien à obtenir à ce que les systèmes
puissent être en français, pour tout un tas de (mauvaises ?) raisons
qu'on retrouve peu ou prou aujourd'hui ici.
Commencer un projet en anglais, c'est bien à condition que ça aie un
sens dans le contexte de la vie du projet, et c'est très réducteur car
un grand nombre de développeurs ne sont pas à l'aise en anglais.
Faire de l'anglais dans un contexte régional, voilà qui serait peut-être
considéré comme irresponsable...
Notons que si le projet devient international (0,001% des projets ?), il
ne devrait tout de même pas être si difficile de scanner les sources et
d'angliciser les identificateurs !
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. A une époque, on a eu un mal de chien à obtenir à ce que les systèmes
puissent être en français, pour tout un tas de (mauvaises ?) raisons qu'on retrouve peu ou prou aujourd'hui ici. Commencer un projet en anglais, c'est bien à condition que ça aie un sens dans le contexte de la vie du projet, et c'est très réducteur car un grand nombre de développeurs ne sont pas à l'aise en anglais. Faire de l'anglais dans un contexte régional, voilà qui serait peut-être considéré comme irresponsable... Notons que si le projet devient international (0,001% des projets ?), il ne devrait tout de même pas être si difficile de scanner les sources et d'angliciser les identificateurs !
Eric Masson
MCI, Shadok Gouroudoudou writes:
'Lut,
Et ce pourrait être interprété au-delà du simple conservatisme, jusqu'à une sorte de xénophobie (pour ne pas employer un mot encore pire).
Evidement, cela se passe au niveau du subconscient, voire de l'inconscient.
Ben, tiens, vous n'êtes pas d'accord avec moi, donc vous êtes de vieux cons réactionnaires mais vous ne pouvez même pas vous en rendre compte.
Comment disqualifier toute éventuelle argumentation de ta part en un post.
-- je me fais un réveil matin qui m'énonce les SC6 et SC7 de word98 [avec le Speech de MacsBug]. Si je me lève pas pour l'éteindre, je suis sûr que ma femme le fera .-) -+- BL in Guide du Macounet Pervers : Tyran domestique ! -+-
Et ce pourrait être interprété au-delà du simple conservatisme,
jusqu'à une sorte de xénophobie (pour ne pas employer un mot encore
pire).
Evidement, cela se passe au niveau du subconscient, voire de
l'inconscient.
Ben, tiens, vous n'êtes pas d'accord avec moi, donc vous êtes de vieux
cons réactionnaires mais vous ne pouvez même pas vous en rendre compte.
Comment disqualifier toute éventuelle argumentation de ta part en un
post.
--
je me fais un réveil matin qui m'énonce les SC6 et SC7 de word98 [avec
le Speech de MacsBug]. Si je me lève pas pour l'éteindre, je suis sûr
que ma femme le fera .-)
-+- BL in Guide du Macounet Pervers : Tyran domestique ! -+-
Et ce pourrait être interprété au-delà du simple conservatisme, jusqu'à une sorte de xénophobie (pour ne pas employer un mot encore pire).
Evidement, cela se passe au niveau du subconscient, voire de l'inconscient.
Ben, tiens, vous n'êtes pas d'accord avec moi, donc vous êtes de vieux cons réactionnaires mais vous ne pouvez même pas vous en rendre compte.
Comment disqualifier toute éventuelle argumentation de ta part en un post.
-- je me fais un réveil matin qui m'énonce les SC6 et SC7 de word98 [avec le Speech de MacsBug]. Si je me lève pas pour l'éteindre, je suis sûr que ma femme le fera .-) -+- BL in Guide du Macounet Pervers : Tyran domestique ! -+-
MCI, Shadok Gouroudoudou
Re !
La plupart des langages à usage éducatif ne peuvent survivre en dehors du cadre universitaire.
D'ailleurs, il n'y a qu'à demander à R12y s'il fait beaucoup d'OCAML, en entreprises...
Au passage, le problème de LSE, ce n'est pas les mots-clefs en français, mais le langage lui-même.
-- @-salutations
Michel Claveau
Re !
La plupart des langages à usage éducatif ne peuvent survivre en dehors
du cadre universitaire.
D'ailleurs, il n'y a qu'à demander à R12y s'il fait beaucoup d'OCAML,
en entreprises...
Au passage, le problème de LSE, ce n'est pas les mots-clefs en
français, mais le langage lui-même.
