Ainsi écrire un pacman revient à écrire :
Pacman is a character who loves to run through a maze and eat dots. Whenever Pacman eat a dots, it disapears and he wins a point.
Qui génère :
def __main__() :
class Pacman(character) :
def run(maze) :
pass
def eat(dot):
dot.disappear()
Pacman.win(point)
def win(point)
pass
class dot:
def disappear() :
pass
Pas mal, non ?
Comment ça marche ?
En gros, le système cherche des structures verbe-sujet-objet-objet, ayant préalablement étiqueté chaque mot en fonction de sa morphologie, il réalise quelques transformation pour isoler ce genre de structure.
Il recherche ensuite des structures if-then, des listes, etc..
Grâce a une petite analyse sémantique, il détermine ce qui est animé ou ne l'est pas, de quel sorte d'objet a t-on affaire, quelle est la proximité linguistique (champ lexical).
A noter que l'auteur explique que les ambiguités peuvent être une aide, car elle permette parfois de préciser un concept en le comparant avec d'autres structures s'y rapportant.
Cela ne génère pas tout le code, mais c'est un jeu intéressant :-)
# Liens
Posté par Pinaraf . Évalué à 4.
J'ai trouvé ça : http://www.trnmag.com/Stories/2005/032305/Tool_turns_English(...)
[^] # Re: Liens
Posté par B16F4RV4RD1N . Évalué à 4.
La programmation à la portée du plus grand nombre ?
Je ne sais pas si cela facilite réellement la programmation de façon immédiate, en général si cela améliore un point c'est au détriment d'un autre, mais en tout cas cela permet d'avoir une nouvelle approche.
N'étant pas programmeur à la base, j'aime bien ce genre de chose, pour avoir utilisé le langage Inform en vue de faire des aventures textuelles. La version 7 permet justement de créer tout un monde, ainsi que toute la mécanique d'interaction avec ce monde. Il y a un court exemple de "code" sur wikipedia :
http://en.wikipedia.org/wiki/Inform#The_Inform_7_programming(...)
ainsi que des jeux complets avec le code, par exemple celui-ci qui est particulièrement remarquable :
http://www.inform-fiction.org/I7Downloads/Examples/bronze/so(...)
Le parallèle avec ce qui se fait pour python n'est pas anodin, en effet le code en langage naturel Inform 7 est ensuite converti en code Inform 6 "similaire au C", et le jeu est compilé en langage machine (pour une machine virtuelle indépendante de la plateforme)
Le bénéfice de cela, c'est que sur le forum dédié à la fiction interactive, on voit apparaître des personnes apparemment de talent qui se mettent à créer des jeux car ce système est abordable pour eux, et sans cela il ne l'aurait pas fait. Une bonne quantité de codeurs purs et durs semble ne pas trop apprécier ce nouveau système, ils préfèrent la programmation traditionnelle, bien qu'un pourcentage d'entre eux y soit passé quand même.
On peut peut-être espérer voir à terme une nouvelle façon d'utiliser son ordinateur (peut-être qu'Apple était précurseur dans ce domaine avec apple script ? je dis peut être un bêtise car je n'ai jamais utilisé, mais il peut y avoir des similitures dans le langage naturel utilisé)
Reste plus qu'à trouver un module pour sms et les jeunes pourront scripter msn messenger...
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Liens
Posté par ThesmallgamerS . Évalué à 2.
Je m'explique. Pour moi, la description d'un monde textuel suffisament grand doit-être non linéaire (orienté objet, si tu préfére), C-A-D utiliser un maximum les notions de classes dans la structure même du code. La notion de classe a toujours été un problème essentiel d'Inform 6. Vouloir factoriser le code demandait un véritable problème d'adaptation, notamment a cause de l'absence de fonctions avancés des L.O.B, un trop grande verbosité du code, pas de distinguo véritable entre objet et interaction, etc...
A tel point que j'ai commencé a écrire un petit compilo qui transforme du XML en Inform 6 (mais ceci est une autre histoire). Le XML, étrangement, se prête beaucoup mieux a cette exercice que cette version batarde du langage C.
Or, Inform 7 est encore pire que Inform 6 question factorisation et langage objet. Pour moi, il est impossible de faire ce que j'ai envis (un très grand monde a la sauce M.U.D solo) en Inform 7, ce serait trop compliqué. Ainsi, Inform 7 se limite a un petit langage pour de petit projet fait par des gens doué, et c'est un peu dommage.
[^] # Re: Liens
Posté par B16F4RV4RD1N . Évalué à 2.
Inform 7 n'est pas fait à la base pour faire un MUD solo, ni même un JDR, bien qu'il doive être possible via des tables aléatoires de prévoir l'idée d'un jeu pas forcément linéaire, avec des notions d'événements changeants et variables suivant le contexte, qui se mémorisent en fonction des actions du jeu (c'est d'ailleurs ce que je m'applique à faire pour un prochain jeu, mais cela restera modeste).
Pourrais tu donner un exemple précis de ce que tu n'arrives pas à faire à cause d'Inform 6 ou Inform 7 ? Là pour le coup je ne vois pas ce que le langage naturel a à voir avec cela, même si je reconnais que pour le français c'est un peu déroutant de mélanger les deux. Pour créer une classe, il suffit de dire "blabla is a kind of thing.", et de décrire simplement ce que fait cette classe, et on peut la réutiliser dans tout le jeu. Le fait de manipuler ainsi directement les objets les rends plus facile à conceptualiser.
La finalité du langage naturel, ce n'est pas que de pouvoir utiliser un simili anglais pour parler, car la syntaxe est rigide malgré tout, et si ce projet en python abouti, cela ne sera pas pour "causer avec l'ordinateur", mais pour rendre plus proche du programmeur la modélisation du projet, avec des références "naturelles" pour lui.
Je ne vois pas trop en quoi cela limite à "de petits projets", quelle est cette limite ? Parce que cela te semble trop fastidieux à générer ? (tu peux envisager de créer le code inform 7 via un autre programme, j'avais commencé à voir pour créer un semblant de monde virtuel dans inform 7 à partir d'inspiration pad : http://www.nbos.com/products/ipad/ipad.htm )
Ou parce que tu penses que l'on peut être dépassé par la taille de la machine virtuelle ? Avant d'en voir le bout à mon avis on a le temps d'emplir pas mal de tavernes d'aventuriers, de forêts d'elfes ou de cavernes d'orcs.
Je ne comprends pas trop ce que tu entends par "non linéaire", si tu as déjà joué à "Bronze", le jeu n'est pas spécialement linéaire, on est complètement immergé dedans, c'est un véritable roman interactif, ce qui est la première raison d'être d'inform. Après, il doit être possible de le modifier ou de s'en inspirer pour créer un système qui travaillerait autrement pour créer de nouveaux outils de programmation.
J'imaginerais bien un arkanoid ou un shoot them up programmé avec : "the pad is the player. It is rectangular (ration 6:1). The limits of the game are the walls. etc."
Pour en revenir au mélange anglais français d'inform 7, si on crée tous les objets avec des noms anglais cela passe, les descriptions en français, ce que lit le joueur, étant limitées à ce qui est entre guillemets, on le voit mieux avec un exemple si la syntaxe est colorée :
http://anamnese.online.fr/site2/if/inform7/ScarabeeKatana/so(...)
(dans cet exemple les noms des objets sont en français, ce qui peut faire effectivement un peu bizarre, mais ce n'est pas vraiment un problème pour la rédaction du jeu)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Liens
Posté par ThesmallgamerS . Évalué à 3.
Mon message ne parlait absolument pas des langages naturels généraux, mais du cas spécifique d'Inform 6/7 et je suis désolé si cela a pu paraître autrement. Inform est effectivement un langage crée pour le cas très particulier des romans interactifs. Or, les romans interactifs ne sont souvent que très peu interactif, justement, et empiètent beaucoup plus du coté roman. Les aventures textuelles ne se limitent absolument pas aux romans interactifs. Ces derniers ne couvrent, finalement, qu'une partie très petite de ces mêmes inventures.
Or, Inform 6/7 est très mal conçu pour programmer quoi que ce soit de plus complexe qu'un gros romans interactifs. Ce n'est pas tant l'absence de certaine fonctionnalitées qu'une mauvaise conception qui grèvent ce langage de programmation. Ceci est dommage. Inform est l'un des seuls langages de programmations qui permet de créer facilement des aventures textuelles, et le fait est qu'il se limite a des romans d'aventures, plus subis que joué, par essence.
Je sais pertinement qu'il est possible d'améliorer Inform. Je travaille actuellement sur un projet qui permettra, a partir d'un fichier XML, de créer du code inform 6 de base (les objets, les lieux, les personnages, certaines interactions). Je me suis rendu comptes que cette base XML permettait de s'affranchir de beaucoup des erreurs de conception latente d'Inform, contre une perte de liberté nette du récit. Mais on a rien sans rien...
Amicalement,
[^] # Re: Liens
Posté par B16F4RV4RD1N . Évalué à 3.
Et je ne vois pas non plus en quoi Inform 6 ou 7 sont mal conçus, aurais-tu un exemple un peu précis d'une limitation du langage par exemple ?
Sinon pour revenir au langage naturel en programmation, je viens de découvrir ce matin ce système en projet :
http://langagelinotte.free.fr/
cela tourne dans une machine java.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Liens
Posté par ThesmallgamerS . Évalué à 3.
L'une des limitations du langage auquel on pense dès le départ est la limitation de déplacement du joueurs selon des vagues notions Nord/Sud/Est/Ouest et l'inutilisation, même comme système d'appoint, de coordonnée élémentaire. Cette limitation peut être contournée, bien sûr, et s'explique aisément par le fait que on a toujours fait comme ça pour les romans interactifs, mais bride de manière monstrueuse les possibilités d'aventure textuelle out-the-box. De même, il n'existe aucune relation d'ordre dans les lieux, alors qu'il aurait été aisé de spécifier si tel lieu en contient un autre ; l'impossibilité de produire simplement une I.A avancée pour les NPC, ou, au moins, un emploi du temps ; La difficulté d'introduire un système de discussion avec ces derniers ; La difficulté d'introduire des paramêtres plus ou moins réels (temps, physique de base - même si, bien heureusement, la lumière l'est) dans le récit ; etc. La liste s'allonge indéfiniment, et pour plus de précision sur les problèmes plus techniques que ces langages batards ont avec les Objets, je te renvois a mon poste précédent.
Il y a quelques temps, pour prouver la viabilité du concept, j'ai imaginé de créer une aventure textuelle sur la base d'une chambre remplis d'objet, et d'imaginer toute les interactions possibles sur ces objets - pour pouvoir, si necessaire, factoriser tout cela à un niveau superieur. J'ai été désagréablement surpris par les limitations de langage d'Inform 6 et j'ai abandonné lorsqu'il s'est trouvé que je n'arrivais tout simplement pas a produire ce que je désirais, alors que c'était a priori très simple.
Amicalement,
[^] # Re: Liens
Posté par Ontologia (site web personnel) . Évalué à 5.
Le pdf publiant la chose : http://web.media.mit.edu/%7Ehugo/publications/papers/IUI2005(...)
Ya surtout la lib qui le permet : http://web.media.mit.edu/~hugo/montylingua/
dans une espèce de licence libre.
Voilà, désolé pour l'oubli, fatigué en ce moment...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Liens
Posté par eastwind☯ . Évalué à 2.
qqn sait ou trouver metafor ?
# On gagne en abstraction
Posté par Victor STINNER (site web personnel) . Évalué à 8.
Si on observe l'évolution du langage Python, on peut voir les objets de haut niveau naître petit à petit. Python 2 permet de manipuler des caractères plutôt que des octets ('unicode' vs 'str') et Python 2.4 permet enfin d'avoir des nombres entiers sans limite débile (et source de nombreux bugs) à quelques milliards ('long' vs 'int'). D'ailleurs, Python 3000 va utiliser les types de haut niveau par défaut : "abc" désigne un chaîne de vrais caractères (et non pas d'octets comme en C) et les types int & long fusionnent.
C'est pas spécifique à Python, la programmation orientée objet est plus lente qu'un programme cablé en dur (du C par exemple), mais aujourd'hui on peut se permettre des perdre quelques pourcents de CPU et de mémoire à l'exécution pour accélérer le temps de développement.
À mon avis, les langages de programmations doivent monter en abstraction. Le but ultime étant d'écrire un programme dans sa langue maternelle... comme ce qui est présenté dans ce journal... sauf que je doute que ce jeu pacman soit jouable (c'est pas encore au point) ;-)
[^] # Re: On gagne en abstraction
Posté par Yusei (Mastodon) . Évalué à 7.
Programmer dans un sous-ensemble de ma langue maternelle qui soit non-ambigü au niveau de la grammaire, pourquoi pas, mais là encore il y a des problèmes: la langue parlée est volontairement floue ("par là", "loin", "lourd"), si on veut être précis elle est verbeuse... peut-être pas l'idéal pour la programmation finalement.
[^] # Re: On gagne en abstraction
Posté par Ontologia (site web personnel) . Évalué à 3.
Premièrement, on programmera effectivement avec un sous ensemble "moins ambigue du langage". On pourra difficilement enlever toute ambiguité comme le lobjan mais c'est surment possible d'en retirer pas mal. De plus, les logiciels que l'on décrira seront par nature assez précis. On parlera de traiter des fichiers, des BDD, de l'XML, de faire des interfaces graphiques, etc... On pourra difficlement se passer de langages comme SQL, ou CQL (ou un de ses descendants bitable) pour travailler des données sur un SGBD, ou de l'XML...
Deuxièmement, un langage de dévelopement basé sur un sous ensemble de langage naturel sera amené à interagir avec l'utilisateur.
On y est pas habitué, donc on y pense pas, mais le changement de paradigme implique un changement de méthode.
Un langage de programmation classique comme ceux que nous connaissons possèdent intrinsèquement une structure non ambigüe du code : il n'est pas une représentation de ce que l'on veut faire, mais une représentation de ce que l'automate virtuelle doit faire.
Or, programmer en langage naturel implique que l'on glisse vers une logique de description de spécification, l'ordinateur devant rédiger l'algo pour y arriver.
Cela implique que dès que le moteur tombera sur une ambigüité, il entamera un dialogue afin de préciser cette ambigüité.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: On gagne en abstraction
Posté par Yusei (Mastodon) . Évalué à 6.
Et même s'ils commencent à comprendre ce qu'on dit, l'exercice est intéressant: faire un petit dessin à base de ronds, carrés et triangles, téléphoner à un ami, lui demander de refaire le dessin à partir de notre description. Il y a peu de chances que ça ressemble à quelque chose à moins d'utiliser un formalisme particulier (par exemple du papier quadrillé et des coordonnées). Le langage naturel pour être précis, c'est nul.
[^] # Le futur
Posté par Gof (site web personnel) . Évalué à 1.
On donne juste le cahier des charges à l'ordinateur :
« Je veux un programme qui fait ça et ça »
Eh oui, plus besoin de programmeur.
[^] # Re: Le futur
Posté par Dr BG (site web personnel) . Évalué à 10.
Je vous livre le code que je laisse en GPL :
[^] # Re: Le futur
Posté par Sylvain Sauvage . Évalué à 4.
— Alan Perlis, Epigrams on Programming in Sigplan Notices
[^] # Re: Le futur
Posté par Ontologia (site web personnel) . Évalué à 1.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: On gagne en abstraction
Posté par Miguel Moquillon (site web personnel) . Évalué à 8.
C'est sûr que Lisp, c'était un langage machine, et Smalltalk en son temps aussi ;-)
[^] # Re: On gagne en abstraction
Posté par Ontologia (site web personnel) . Évalué à 4.
Faux, le compilateur Lisaac en est la preuve. Ce n'est qu'un problème de compilateur, pas de paradigme de langage :-)
À mon avis, les langages de programmations doivent monter en abstraction. Le but ultime étant d'écrire un programme dans sa langue maternelle... comme ce qui est présenté dans ce journal... sauf que je doute que ce jeu pacman soit jouable (c'est pas encore au point) ;-)
C'est clair, le problème c'est qu'il y a peu de recherche dans le domaine...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: On gagne en abstraction
Posté par Yusei (Mastodon) . Évalué à 2.
Mouais... j'ai plutôt eu l'impression, à lire les news, que Lisaac se rapproche souvent de l'efficacité du C et la dépasse parfois. De là à affirmer que c'est généralement au moins aussi rapide que du C, il y a une petite marge :)
Dans le concept de programmation objet, le fait qu'un objet puisse redéfinir une fonction définie dans une classe parente pose un problème pour l'inlining dont je ne suis pas convaincu qu'il puisse être résolu par le compilateur. On aurait donc sur ce point là une supériorité du C si on s'oblige à coder sans pointeurs de fonction. Et d'un autre côté un compilateur de langage de haut niveau possède des informations qui lui permettent certainement d'optimiser d'une autre manière. Pour l'instant... je n'ai pas d'opinion sur la rapidité relative de différents types de programmation, mais je doute qu'on ait des "preuves".
[^] # Re: On gagne en abstraction
Posté par Ontologia (site web personnel) . Évalué à 2.
de plus l'inlining se fait aisément, si tu résoud la liaison dynamique en utilisant une table dynamique.
Tu trouveras des explications ici : http://isaacproject.u-strasbg.fr/download/workshop.pdf
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: On gagne en abstraction
Posté par Yusei (Mastodon) . Évalué à 5.
Quand on compile le compilateur, c'est ça ? (c'est ce qu'il m'a semblé comprendre dans la news précédente). Il y a des cas pas vraiment rares où le compilateur devrait être devin pour réussir à faire de l'inlining.
Pour prendre un exemple vraiment con, admettons que j'ai deux structures de données: une liste chaînée et un tableau. Au début de mon programme, je demande à l'utilisateur laquelle de ces deux structures il veut utiliser, et puis je fais des calculs. Par quel miracle Lisaac serait-il capable d'inliner le code de la liste ou du tableau dans mes calculs alors qu'il n'y a aucun moyen de savoir quelle est la structure de données choisie par l'utilisateur avant le runtime ?
Là j'avoue que je ne comprend pas ce que tu veux dire. Ce n'est pas du tout mon domaine mais pour moi la liaison dynamique c'est le contraire de l'inlining...
Non, j'ai trouvé des slides, et les slides ça ne sert à rien sans la présentation qui va avec...
[^] # Re: On gagne en abstraction
Posté par Ontologia (site web personnel) . Évalué à 4.
Simple : il inline les deux cas ;-)
Là j'avoue que je ne comprend pas ce que tu veux dire. Ce n'est pas du tout mon domaine mais pour moi la liaison dynamique c'est le contraire de l'inlining...
Justement, les compilateurs objets classiques utilisent une table de pointeurs en mémoire pour savoir sur quel fonction se brancher.
Lisaac transforme cela en appels statiques, en utilisant une recherche dichotomique.
Non, j'ai trouvé des slides, et les slides ça ne sert à rien sans la présentation qui va avec...
Exact, je vais donc le faire.
Slide 127 : Floppy et hard_disk hérite de drive et possède tout deux une fonction read. Liaison dynamique sur cette fonction.
Slide129 : les compilo classiques utilisent une table de fonction
Slide 130 : Lisac fait de l'analyse de flot. il analyse la géométrie du graphe du code pour prévoir les types.
Dans cette exemple, r peut être de type A, B , C ou D.
Avec une solution syntaxique type SmartEiffel, on supprime la liaison dynamique (la table de fonction), en faisant une recherche, pour savoir si, à l'exécution du code, r est de type A, B, C ou D.
C'est un bête switch case, mais on a déjà supprimé la liaison dynamique, donc on peut inliner.
Lisaac va plus loin :
Dans la branche où on évalue r.method, on voit que r ne peut être que de type A ou B (les branches correspondent à un test).
Donc, on fera un test sur A ou B seulement (Slide 131,132).
Slide 133 : on associe le type d'un objet en nombre, ce qui permet de faire des recherches dichotomique ayant l'avantage d'être en nlog(n) (si je me souviens bien)
Slide 134 : on inline... Et on réduit le résultat. ici on présente un cas extrême.
Slide 135 : dans l'ancienne version du compilateur (la nouvelle a fait de nettes progrès), on avait 91% d'appels monomorphiques natifs (sur le compilateur), plus 4 % d'appels polymorphique transformés en monomorphiques.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# enfin l'an 2000
Posté par Ben (site web personnel) . Évalué à 2.
ca faisiat longtemps qu'on en parlait mais que personne ne sortai quelque -chose à part les labos d'IBM qui... ne sortaient rien.
Tout homme qui dirige, qui fait quelque chose, a contre lui ceux qui voudraient faire la même chose, ceux qui font précisément le contraire, et surtout la grande armée des gens d'autant plus sévères qu'ils ne font rien du tout. -- Jules Claretie
# intéressant mais...
Posté par Djoul . Évalué à 2.
En tout cas cela me fait penser à AliceBot (www.alicebot.org) un logiciel de conversation assez bluffant (surtout en anglais d'ailleurs). Le bot Alice a déjà réussi à tromper des observateurs au test de Turing.
[^] # Re: intéressant mais...
Posté par ThesmallgamerS . Évalué à 2.
Exemple (parmis beaucoup d'autre) :
Human: You're kidding me.
ALICE: I have no reason to do that to you, unknown person.
Human: I'm not a unknow person.
ALICE: Oh I see you are NOT A unknow person.
Human: What i am ?
ALICE:" Oh I see you are NOT A unknow person." You are?
Human: 0wned
ALICE: That question has never crossed my mind before.
[^] # Re: intéressant mais...
Posté par Ontologia (site web personnel) . Évalué à 3.
Ahh, le politiquement correct !
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: intéressant mais...
Posté par Yusei (Mastodon) . Évalué à 3.
il manque un "n" après le "a". Avec la phrase correcte, Alice s'excuse, demande ton nom, et le mémorise pour continuer à t'appeler comme ça par la suite.
[^] # Re: intéressant mais...
Posté par ThesmallgamerS . Évalué à 3.
[^] # Re: intéressant mais...
Posté par Ontologia (site web personnel) . Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: intéressant mais...
Posté par Yusei (Mastodon) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.