Aux croisements de diverses dimensions advint un rêve. En fait plusieurs rêves mêmes :
- disposer de langages de programmation utilisant l’espéranto comme base lexicographique (et éventuellement tirant partie de la régularité grammaticale de la langue dans la grammaire des langages) ;
- disposer d’une chaîne de compilation entièrement codée dans des langages tels que les précédents ;
- en bonus, avoir des langages de programmation espérantiste totalement dépourvu de pictogramme.
De ces rêves naquirent deux projets de recherche Algoritmaro et Fabeleblaĵo et un projet avec quelques bribes de code nommée ilaro.
Cela étant, la théorie des langages de programmation et le développement d’une chaîne de compilation n’étant pas une mince affaire, les occasions d’errer et de patauger ne manquent pas.
Par exemple, disposer d’une chaîne de compilation auto-hébergé s’avère aussi attrayant que propice à s’arracher les cheveux en voulant démêler, non pas les dits cheveux, mais tout simplement par où commencer.
Car si potasser le Dragon book, en le griffonnant de traductions, fourni une certaine satisfaction, l’envie de coder concrètement en utilisant seulement du vocabulaire espérantophone vient se heurter à bien des difficultés. En utilisant un langage de programmation existant, selon toute probabilité il va y avoir des mots clés en anglais. Et par exemple dans Python, utilisé dans les quelques bribes de codes sus-cités, les mots clés ne peuvent pas se substituer aisément. Dans un langage comme C, il y a bien sûr possibilité d’utiliser des définition du préprocesseur pour substituer tout les mots clés du langage par leur équivalent espérantiste. Seulement pour prototyper rapidement des algorithmes, un langage comme python semble bien plus commode.
Et puis, quid du langage cible ? Faut-il au préalable se pencher sur cette question et produire un assembleur, ou autre langage intermédiaire, espérantophone ?
Bref, quelle approche adopter, quelles priorités fixer?
Aussi si vous avez des conseils, ou même des avis pas trop assassins sur ces projets, merci par avance de les partager.
# Facile
Posté par Moonz . Évalué à 7. Dernière modification le 05 mars 2015 à 20:27.
Dans le désordre :
Prend un langage qui n’a aucun (ou presque) mot de clé de base comme Lisp
Lua est connu pour être aisément modifiable
En Ruby, tu peux quasiment tout faire sans utiliser de mot clé, par exemple tu peux définir une méthode
sisur la classe bool pour te permettre de transformer :en
J’ai ouïe dire que tu peux aussi faire ce genre de chose en F#, SmallTalk, Nim, Scala et Rust. Les versions récentes de JavaScript (Harmony) sont aussi un bon candidat.
Je laisserai à d’autres le soin de troller sur l’intérêt douteux de la chose :)
[^] # Re: Facile
Posté par Moonz . Évalué à 10.
En fait, plus je te relis, plus je me dis que tu es très très mal parti.
De deux choses l’une :
Soit ton but est de produire un langage. Dans ce cas tu prends les choses d’un très mauvais angle en lisant le dragon rouge ; c’est un très bon bouquin pour qui veut comprendre les bases d’une toolchain de compilation, mais aujourd’hui on peut très bien écrire un langage sans écrire un compilateur. Et les chaînes de compilation d’aujourd’hui sont bien bien plus évoluées ; jamais tu n’arriveras à leur cheville avec cette approche. Ce serait quelqu’un qui dirait « bon, mon but est de concurrencer Intel. Étape numéro 1 : bouquiner un peu de logique booléenne ». Aujourd’hui, pour faire un langage pour de vrai, soit tu es un géant (et dans ce cas tu ne posterais pas ce genre de questions ici), soit tu t’appuies sur un géant (LLVM au plus bas niveau, Rust/F#/Nim au plus haut niveau, étant donné que plus haut niveau = chemin de moindre résistance)
Soit ton but est de te faire plaisir en apprenant, et dans ce cas oublie l’idée de « réutiliser un langage existant ». Ce serait comme essayer d’apprendre la mécanique newtonienne en faisant du reverse-engineering sur un airbus.
Bref : dans ton message, un truc n’a absolument rien à faire là, soit le Dragon Book, soit Python. Commence déjà par clarifier ça :)
[^] # Smalltalk
Posté par ... a little wood elfe . Évalué à 1.
Je me suis déjà fait la même réflexion après avoir lu quelques articles sur les DSL (http://fr.wikipedia.org/wiki/Domain-specific_programming_language).
Pour la même raison que Smalltalk est une bonne base pour un DSL, il me semble le candidat idéal : il n'y a pas de mots clés, tout est message et objet.
Du coup, dans un premier temps, il "suffit" juste de dupliquer toutes les fonctions des bibliothèques de base en les renommant et le tour est joué : tu peux développer dans ton langage.
Ce qui est sympa c'est que tu peux le faire petit à petit : tu commences à coder ton programme et à chaque fois que tu veux faire appel à une fonction en anglais, tu la dupliques.
À voir ceci dit s'il est plus intelligent de dupliquer (plus facile à faire et meilleures perfs) ou de coder une redirection vers la fonction en anglais (plus facile pour se synchroniser avec le code initial s'il évolue en anglais). La duplication est plus ambitieuse car permet petit à petit ensuite en récrivant tout le code de basculer sur une base entièrement en espéranto. Mais ce n'est intéressant que si le projet source est en phase pour basculer en espéranto et abandonner l'anglais. Ce qui me semble peu probable dès le départ.
Dans ce cas gérer la synchronisation est nécessaire. Le temps de constituer une base utilisateur suffisamment importante.
Encore une fois en Smalltalk cela se ferait assez facilement : un projet pouvant parfaitement ajouter des méthodes à une classe existante, on peut imaginer commencer un projet en Pharo3.0 puis l'appliquer sur Pharo4.0 avec uniquement les impacts classique d'une montée de version.
Si je maîtrisais l'espéranto, je me serais probablement déjà lancé.
[^] # Re: Smalltalk
Posté par psychoslave__ (site web personnel) . Évalué à 2.
Ok, merci pour les idées sur l’approche possible.
# Quelques pistes
Posté par anaseto (site web personnel) . Évalué à 2.
Je t'avoue que je ne suis pas très sûr que ton objectif soit raisonnable, car j'ai l'impression que le vocabulaire d'un langage de programmation reste très petit, et que le problème à ce niveau n'a quand même rien à voir avec celui des langues. Mais bon, ton idée est au minimum marrante, et m'a fait penser à ce qui est dit dans la page man "perlglossary" à la définition du mot "Unix" ;)
Voici quelques idées qui me viennent.
Si tu veux juste avoir un langage avec des mots-clés espéranto, je pense que pour un premier test le mieux est de partir d'un langage dynamique suffisamment flexible pour être adapté sans te compliquer la vie.
Tu peux par exemple essayer avec racket : à l'aide des macros et du fait qu'on peut modifier le lexeur et parseur facilement, tu peux créer un dialecte totalement à ta sauce, sans avoir à te coltiner l'écriture d'un compilateur raisonnable.
Je pense que tu dois pouvoir faire pareil avec factor, un langage à pile assez curieux mais qui n'a pour ainsi dire pas de syntaxe, et permet de faire des macros à la lisp également.
Sinon, peut-être que tu peux regarder du côté de perl6, qui, il me semble, permet de modifier à peu près comme on veut la grammaire, mais j'ai pas essayé de faire ce genre de choses.
Ou encore, tu peux regarder du côté de J : le langage n'utilise aucun mot (ni anglais), mais tout peut être redéfini, et il y a en particulier un fichier qui fait une traduction vers l'anglais (l'utf8 passe pas pour les identifiants donc faudrait utiliser la notation avec des « x » ou des « h »). Après, c'est pas un langage généraliste, donc ça limite un peu l'intérêt probablement.
[^] # Re: Quelques pistes
Posté par karteum59 . Évalué à 2.
Je suis assez d'accord, ça m'a fait un peu penser à Chinese Python :)
[^] # Re: Quelques pistes
Posté par anaseto (site web personnel) . Évalué à 2.
Pas mal !
Mais ça a l'air d'être un boulot énorme : c'est pas juste une traduction de mots-clés, c'est toute la doc, on dirait (du coup ça m'étonne pas que ce soit pas maintenu). Ce que je me demande, c'est ce qu'il en est des messages d'erreurs, par exemple. Parce ce que c'est quand même important pour le public de débutants visé. D'ailleurs, c'est un des trucs qui rendent une simple traduction des mots-clés et noms de fonction insuffisante, ce qui force un peu à réécrire son propre compilateur (du moins les parties hautes), ou modifier le code source d'un existant.
[^] # Re: Quelques pistes
Posté par psychoslave__ (site web personnel) . Évalué à 2.
Je dois avouer que c'est un des projet qui m’a inspiré l’idée de me lancer dans la construction d'un langage de programmation en espéranto. En fait à l'époque je ne parlais pas encore espéranto, mais pour moi ça à été une des motivations.
[^] # Re: Quelques pistes
Posté par lendemain . Évalué à 4.
Si ton objectif est de remplacer le vocabulaire alors racket est un choix intéressant.
Voila ce que j'ai fait en 10 minutes en suivant le guide.
fichier nommé esperanto-m.rkt
fichier nommé esperanto.rkt
et enfin un petit hello world
La seule partie que te ne pourra pas changer est le
#langau début des fichiers.[^] # Re: Quelques pistes
Posté par psychoslave__ (site web personnel) . Évalué à 2.
Et les parenthèses, il n’est pas possible de s’en débarrasser, si je ne m’abuse.
[^] # Re: Quelques pistes
Posté par lendemain . Évalué à 3.
Tu peux implémenter la syntaxe de ton choix, mais tu conservera #lang.
Par exemple voila une implémentation de python.
[^] # Re: Quelques pistes
Posté par psychoslave__ (site web personnel) . Évalué à 2.
D'accord, c'est bien plus intéressant que ce que je pensais dans ce cas. Merci.
# pourquoi pas regarder du coté de linotte
Posté par fabricius . Évalué à 6.
Les puristes vont hurler, mais il existe déja un langage qui s'est affranchi de l'anglais: le langage linotte.
Je pense aussi que l'objectif est trop haut (avoir une chaîne de compilation), il y a risque que tu lache l'affaire. Pourquoi ne pas t'inspirer de ce qui a été fait chez linotte, mais que tu produise ensuite une version espérantophone. Certes, il y a surement des pictogrammes, mais ils peuvent peut être se remplacer. Si tu obtiens déja quelque chose qui fonctionne, tu peux peut être ensuite travailler sur la compilation. N'oublie pas que tu ciblera la communauté esperantophone qui code, ça fait pas tant de monde que ça.
Mes 2 centimes. Bonne chance!
# Lingua::Romana::Perligata
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5.
ça me fait penser à Lingua::Romana::Perligata, un module Perl qui permet de programmer en… Latin:
http://www.csse.monash.edu.au/~damian/papers/HTML/Perligata.html
Un exemple est donné sur cette page avec l'algorithme du cribble d'Erathostène:
[^] # Re: Lingua::Romana::Perligata
Posté par KiKouN . Évalué à 3.
J'ai beau avoir fait du latin, je comprends que de chique. Mais j'aime bien le mot "decapitamentum"
[^] # Re: Lingua::Romana::Perligata
Posté par benoar . Évalué à 6.
« que de chique » ?! Faut qu'il retourne à l'école l'gadjo ! http://fr.wiktionary.org/wiki/que_tchi
[^] # Re: Lingua::Romana::Perligata
Posté par KiKouN . Évalué à 2.
Ha mais l'école, j'y suis allé. C'est tout.
Je trouve pourtant que mon commentaire d'avant en dit long sur mon niveau en langue.
[^] # Re: Lingua::Romana::Perligata
Posté par psychoslave__ (site web personnel) . Évalué à 2.
C’est un latin simplifié. J’avais déjà repéré ce projet, il est d'ailleurs dans la liste des références des projets que je cite…
# Intérêt
Posté par binbin . Évalué à 1.
Bien qu'ardent défenseur de l'espéranto, j'avoue ne pas vraiment voir l'intérêt pratique de ton idée.
Je ne me vois pas coder en espéranto, pour plusieurs raisons :
- l'anglais est plus concis, plus efficace. Tous les concepts de programmation sont en anglais et déjà difficiles à traduire en français (ex: un "wrapper", un "while", une "closure")
- la programmation n'exploiterait pas la puissance de l'espéranto, qui pour moi réside dans sa grammaire et sa conjugaison. Programmer, c'est de l'impératif ou de l'infinitif tout le temps…
- les caractères spéciaux, je me vois mal m'amuser à les tapper dans du code.
Dans le même genre les langages de programmation en français n'apportent pour moi que des vertus éducatives. Par exemple le langage 4D permet de coder en français, espagnol, japonais… et c'est très sympa. Mais ça n'apporte rien aux non-débutants.
Je serais toi je ferais simplement une petite lib JS, une couche espérantophone par dessus les objets de base du langage (Fenestro = Window, etc.)
Mais créer un langage entier me parait une tâche démesurée en comparaison de l'intérêt réel de la chose…
[^] # Re: Intérêt
Posté par Renault (site web personnel) . Évalué à 6.
Adaptateur, tant que et fermeture me semblent être des termes adéquats et assez clairs.
D'ailleurs le soucis de l'anglais à outrance, c'est que l'image mental que l'on se fait de ces mots devient plus flou. Quand tu tapes "while" mais tu ignores ce que ça veut dire, tu auras toujours un peu plus de difficulté surtout au début de l'apprentissage à mémoriser sa signification.
Alors que d'utiliser "tant que" suivi de sa condition, n'importe qui parlant le français un minimum comprend ce que ça signifie immédiatement.
[^] # Re: Intérêt
Posté par psychoslave__ (site web personnel) . Évalué à 7.
La concision de l’anglais ce paie au prix d’un lexique colossale. Si un langage se fixe comme objectif unique la concision, qui plus est picturale, alors sans aucun doute les symboles chinois sont actuellement de loin la meilleure solution disponible.
Seulement la concision scripturale n'est pas le seul facteur qui peut être pris en compte. La précision sémantique qui
est un autre critère possible.
L’anglais est excellent sur le plan évocation, surtout pour ceux dont c’est la langue maternel. Claude Piron à écrit un texte très intéressant à ce sujet, Le génie d'une langue
Pour ma part en apprenant l’espéranto j’ai été, au contraire de ce que tu sembles ressentir, tout à fait frappé par la pertinence qu'il y aurait à l'utiliser dans un contexte de programmation. Pouvoir identifier qu'un mot renvoie un nom de variable (substantif, terminaison -o), à un nom de fonction (infinitif, terminaison -i), ou exécute un appel de fonction (impératif, terminaison -u), cela me paraît très intéressant. Et la régularité grammaticale de l’espéranto, c'est justement ce qui rends possible l’exploitation de sa puissance d’expression à des fins programmatiques.
Et là on évoque même pas encore la facilité qu’il y a exprimer des concepts par agglutination d’affixes tout à fait intéressant en programmation -ar- pour désigner un ensemble, -er- pour l'élément d'un ensemble, -ing- pour un conteneur de, -ec- pour l'abstraction de, -aĵ- pour l’instanciation concrète d’une chose abstraite.
Même sans aller jusqu’à tirer partie de ces remarquables caractéristiques directement dans la grammaire des langages de programmation, il est évident que cet aspect de la langue trouverait des applications tout à fait pertinentes dans le développement d'applications.
Les « caractères spéciaux » avec une disposition de touche adaptée, il se saisissent comme n’importe quelle lettre. Et même sans, la convention cx pour ĉ fonctionne très bien, ton éditeur de texte pouvant tout à fait te faire la conversion à la volée.
Bien sûr, coder en anglais c’est de fait plus aisé du point de vue de l'existant sur lequel s’appuyer. Mais en soi utiliser l’anglais c’est tout aussi pertinent que de coder en français, espagnol ou japonais. Ça descend, peut-être, un peu la difficulté d’apprentissage pour le locuteur natif, et c'est bien la seule qualité qu'il y a attribuer à cette approche.
[^] # Re: Intérêt
Posté par binbin . Évalué à 0.
Merci pour ton message très intéressant.
Je ne voyais pas en quoi la programmation pouvait bénéficier de la grammaire géniale de l'espéranto.
Mais c'est vrai qu'en intégrant au coeur du langage cette grammaire on pourrait arriver à des résultats très intéressants. Bien que très différents des langages classiques !
On pourrait presque programmer en langue naturelle (ça me fait rêver)
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
L'anglais est concis en programmation parce que beaucoup de développeurs ont l'habitude de réfléchir en anglais, et de nommer les choses dans cette langue. Du coup dans les autres langues on a que des traductions, pas toujours heureuses, des concepts anglais.
Il est donc intéressant de voir ce qu'il peut se passer si on essaie de travailler avec un autre langage. L'utilisation de déclinaisons en Latin, et de préfixes et suffixes en Esperanto, par exemple (voir les commentaires au dessus et en dessous) permettent une conception assez différente d'un langage de programmation. Les mots dans ces langues sont "fortement typés" (verbe, sujet, complément) et du coup Lingua::Romana::Perligata arrive à se passer complètement de notations symboliques (du genre = pour l'affectation). ça ne serait pas possible avec l'anglais comme base car il y aurait souvent des ambiguïtés (sujet/complément en particulier).
C'est donc intéressant juste pour voir ce qu'il en ressort, à condition que ça soit un peu plus que juste un rechercher/remplacer des mots clés du langage et des noms de fonctions des bibliothèques standard.
[^] # Re: Intérêt
Posté par psychoslave__ (site web personnel) . Évalué à 3.
En ce qui concerne perligata, de mémoire il se base sur l'utilisation de l'accusatif et du datif pour déterminer les rôles de chaque élément du syntagme (de la « phrase »). En espéranto il y un accusatif (terminaison -n), mais pas de datif, il faut utiliser des prépositions pour introduire des termes jouant ce rôle. À la limite, il existe l’Arcaicam Esperantom, un ancêtre fictif qui rajoute des traits « archaïques » à l’espéranto, dont un datif (terminaison -d) et un génitif (terminaison -s).
[^] # Re: Intérêt
Posté par anaseto (site web personnel) . Évalué à 3.
J'ai quand même l'impression que vouloir faire correspondre à chaque classe grammaticale une classe d'objets en programmation, c'est pas forcément quelque chose qui va être optimal.
Pour les noms de variables, fonctions, etc. je suis d'accord que l'espéranto se débrouillerait de façon au moins aussi claire que l'anglais en juxtaposant des mots, grâce à l'agglutination et les suffixes, au sens où pas besoin de prépositions en général pour donner l'idée derrière une objet.
Mais, par exemple, il n'y a qu'un seul pluriel en espéranto. Perl utilise deux pluriels : un pour les listes, et un pour les tables de hachage. Le langage parlé n'a pas toujours les mêmes besoins en suffixes (ou préfixes), visiblement.
La même chose pour les contextes : les contextes dans les langages parlés sont beaucoup plus variés et complexes que ce d'un langage de programmation, mais ça ne veut pas dire qu'ils traduisent optimalement tous les contextes utiles en programmation.
Et souvent, les opérateurs et la syntaxes abstraient de façon efficace les notions, comme en mathématiques, et les mots-clés sont souvent juste des mots magiques qui sont censés évoquer intuitivement une idée (comme en maths), mais ça reste des mots magiques dont au contraire je pense qu'il ne faut pas attacher un rôle grammatical trop proche de celui qu'on lui attribue en prose. C'est le radical du mot qui est le plus intéressant, pour ce qu'il évoque, je trouve.
[^] # Re: Intérêt
Posté par psychoslave__ (site web personnel) . Évalué à 3.
Il y a au moins -j, -ar-, -uj-, -op- et -ing- pour exprimer l’idée de pluriel et de collection, contenant, etc. Et quand bien même aucun aucun lexème existant ne conviendrait, les règles du fudamento autorise explicitement l’emprunt, donc créer haŝo serait envisageable, voir même -aŝ-. Ce d’autant qu’il n’y aurait pas de conflit homonymique, si j'en crois le PIV, via [vortaro.net]. Cela étant, python n'hésite pas à parler de dictionnaire, pour présenter la même structure. Dictionnaire, soit vortaro (vort-aro, ensemble de mot).
Le changement contextuel s’exprime généralement très bien par un adverbe. J’espère que la boutade auto-référentiel méta-confirmatrice sera appréciée à sa juste valeur.
Pour ma part je ne conçois pas de distinction de structure fondamentale entre la prose et les autres approches cognitives : partout elles s'intersectent, se chevauchent et s'interfécondent. Or de l’intuition il n’y a, en ce qui me concerne, nulle possibilité de mathématiques. Et c'est toute la magie des mathématiques que de nous révéler des structures formelles qui donnent à contempler les constructions abstraites qu’inspirent l’imagination. Le terme mathémagique par exemple donne une bonne illustration de cette connivence cognitive.
L’évocation apparaît comme l’art de donner à l’esprit l’impression de redécouvrir ce qu’il n’a jamais expérimenté. Pour ma part je rejette la métempsychose platonicienne, l’esprit ne se rappel pas, il explore des voies parmi celles que son contexte d’errement permet d’accéder.
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
L'exercice est intéressant en tout cas, même si le résultat n'est pas forcément utilisable. ça permet de voir dans quelle mesure les langages de programmation existants sont plus ou moins influencés par l'anglais, par les notations mathématiques, etc.
Si on regarde les conventions de codage et de nommage souvent utilisées, on va trouver des choses du genre:
- une fonction doit être nommée par un verbe
- une variable doit être nommée par un nom
- utilisation de la notation hongroise pour marquer le type ou le rôle d'un objet dans son nom
Pourquoi ne pas inclure ces conventions directement dans un langage de programmation? Et du coup, est-ce qu'on ne pourrait pas enlever les mots clés utilisés actuellement pour exprimer la même chose?
Là, on se rapproche peut-être du BASIC, ou a$ est une chaîne de caractères, a% est un entier, etc (et le suffixe suffit au compilateur pour connaître le type des variables).
En utilisant le Latin dans Perligata, on obtient un langage assez verbeux, mais qui a la particularité d'identifier le rôle des objets utilisés par leurs déclinaisons et autres suffixes, plutôt que par leur position dans la phrase. Après, on peut "optimiser" le langage de programmation obtenu et utiliser des suffixes symboliques et plus concis, en essayant de conserver cette idée que l'ordre des mots n'est pas important.
Donc, le passage par l'Esperanto ou une autre langue permet peut-être d'exprimer des concepts d'une façon différente de l'Anglais, et du coup, d'arriver à un langage de programmation qui fonctionne différement, et éventuellement qui sera plus facile à prendre en main, même si au final on y met quand même de la notation symbolique.
[^] # Re: Intérêt
Posté par anaseto (site web personnel) . Évalué à 3. Dernière modification le 06 mars 2015 à 22:40.
Je suis d'accord qu'il y a beaucoup de bonnes idées à prendre. Après tout, Perl se base un peu sur la grammaire de l'anglais pour certaines choses, et c'est un de ses points forts, donc piocher des idées de l'espéranto qui est bien plus régulier et flexible me semble une très bonne idée.
Ceci dit, je ne suis pas convaincu par l'idée de n'utiliser aucun symbole sous prétexte qu'on ne les prononce pas. Au contraire, je trouve qu'en mathématiques les symboles ont un point fort, et c'est que chacun les prononce dans sa langue (ou choisit de ne pas les prononcer), et ils ont l'avantage d'être plus « visuels » pour certaines constructions. Je pense que trop utiliser les symboles est une mauvaise chose, et peut offusquer les choses, mais je ne pense pas qu'il faille les éviter à tout prix non plus. Par exemple, dans le wiki, je trouve la grammaire BNF version sans symboles moins lisible ; c'est peut-être en partie juste parce qu'il manque la coloration syntaxique, et par habitude, mais pas seulement, je pense. L'idée de structurer des idées visuellement sous forme d'un tableau, par exemple, n'est pas propre à la programmation. Parfois on veut séparer des choses visuellement sans avoir à lire phonétiquement le séparateur.
[^] # Re: Intérêt
Posté par psychoslave__ (site web personnel) . Évalué à 2.
Je suis d’accord que ce que j'ai pondu pour l'instant n'est pas satisfaisant. C'est un projet de recherche, il n'y a pas de certitude d'aboutir sur autre chose que « bah ce qui était visé n'est pas possible dans les contraintes des théories physiques modernes ».
L’objectif n’est certes pas de d’offusquer les relations qu’évoquent clairement des similarités dans les structures géométriques de la représentation typographique. Au contraire, il serait fort intéressant de pouvoir la combiner avec une structure phonologique ayant une même puissance évoquative.
D’ailleurs mes idées ont évolués sur les solutions envisageables depuis que j'ai modifié cette section pour la dernière fois. Notamment, il faudrait retirer l’usage que j’y fais de q.
Sur l’aspect visuel, j’ai aussi lu un peu de documentation sur comment nous lisons, à savoir non pas lettre à lettre, mais par reconnaissance de forme des mots entiers. De plus la prononciation des symboles influence positivement l’identification. Donc autant la mise en forme matriciel semble un facteur important, autant le fait d’avoir un symbole monographique ne semble pas l’être.
# Bof
Posté par reno . Évalué à 4.
Quand je vois les problèmes qu'à LibreOffice a se débarrasser des commentaires en Allemands.. j'avoue avoir du mal a comprendre l'intérêt des langages 'localisé'.
Bon l'esperanto est un concurrent de l'Anglais comme langage international donc ça a déjà plus de sens que des langages informatiques en Français, mais bon qui croit que l'esperanto va supplanter l'Anglais??
[^] # Re: Bof
Posté par psychoslave__ (site web personnel) . Évalué à 4.
Il ne s’agit pas de supplanter l’Anglais. Ça serait le cas si l’anglais était une langue élaborée pour faciliter les communications internationales efficaces.
L’espéranto ne vise pas à remplacer une langue nationale, régionale, locale, tribale, familiale ou idiomatique. L’objectif est de fournir un outil efficace et équitable pour les communications internationales. L’espéranto n’est certes pas le seul projet conçu avec cet objectif, mais il est actuellement le plus populaire.
L'Espéranto, c'est une navette spatiale, les langues vernaculaires c’est la paire de pied. Certes dans les deux cas il y a un outil de locution/locomotion, mais qui n’émergent pas du tout du même genre de processus et qui ne permettent pas d'atteindre les même objectifs.
[^] # Re: Bof
Posté par Jiel (site web personnel) . Évalué à 7.
L'anglais est un langage localisé (même si les Américains font tout pour nous l'imposer).
[^] # Re: Bof
Posté par ariasuni . Évalué à 4.
L’espéranto a quand de beaux atouts.
Écrit en Bépo selon l’orthographe de 1990
# Lojban
Posté par Ryzz . Évalué à 1.
Sur la page wikipedia du Lojban, il est dit que «Selon le degré d’abstraction voulu par le locuteur, la lojban peut se rapprocher du langage naturel, d’un langage de programmation ou de toute autre langue connue.
Pourquoi ne pas regarder de ce côté ?
[^] # Re: Lojban
Posté par psychoslave__ (site web personnel) . Évalué à 3.
Parce que, comme c'est indiqué dans l'un des projets que cité, et en dépit de la niaiserie qu'il est simple d'attribuer à ce type de projet, la popularité de la langue elle même est un critère de forte pondération. L’espéranto est une langue vivante avec une large communauté, large étant bien entendu à relativisé par rapport à ce type de projet.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.