Chers lecteurs de Linuxfr,
Voilà quelques temps que je réfléchis sur mon temps libre à la conception d'un... heu... système... heu... logiciel... d'une nature heu... particulière.
J'ai pris comme résolution de nouvelle année de ne plus travailler seul sur ce sujet.
Je suis à la recherche de partenaires de "jeu": des personnes qui pourraient apporter leurs connaissances théoriques et un regard neuf sur mon idée première, des personnes avec qui je pourrais développer un prototype.
J'invite les lecteurs intéressés par les 2 liens ci-dessous, à réagir.
* projet googlecode : http://code.google.com/p/entrelacs/
* wiki naïf et archivé : http://sgarden.club.fr/entrelac/
Question annexe: y'a t'il une meilleure place sur le web pour démarrer un fil de discussion sur ce sujet?
Forum général.petites-annonces projet "Entrelacs"
14
jan.
2009
# euhhh
Posté par briaeros007 . Évalué à 4.
Est ce tu peux dire en 2 mots/2 phrases/ 2 § ton idée sur le projet ?
Ce que j'ai compris c'est que tu faisais mumuse avec des graphes qui portaient pas leur noms (parce qu'il suffit de définir un noeud comme étant la jonction de flèche et n'ayant pas d'autre fonction, et le graphe de flèche devient un graphe tout court, sans perte d'information, ou encore de considérer qu'une flèche c'est aussi un noeud).
mais plus dans le détail j'avour que je suis perdu
[^] # Re: euhhh
Posté par BAud (site web personnel) . Évalué à 4.
[^] # Re: euhhh
Posté par Sylvain Garden (site web personnel) . Évalué à 2.
Dans le détail, il y a donc un système de stockage spécialement inventé pour stocker ces briques élémentaires d'information que sont les flèches. Le tout avec cache, ramasse-miettes et persistence fiable et "transparente" sur disque.
Cet espace stocke aussi les infos de connectivité qui permet de parcourir/chercher les flèches de n'importe quelle façon.
Le même espace stocke aussi des blocs de données arbitraires (disons les pixels d'une image ou une chaîne de caractères), ces données peuvent à la fois être référencée ou servir de référence dans la construction de flèches.
Ah oui, il y aussi une théorie derrière qui prétend que ces blocs de données sont aussi des flèches, et que leur stockage par le système ne renie pas le principe premier "Tout est flèche". Ca c'est pour le spectacle.
Sinon, tu es peut-être passé à coté de l'idée que chaque flèche identifiable n'est présente qu'une seule fois dans tout l'espace de stockage, un peu comme si la valeur approximative du nombre PI n'était présente qu'une seule fois dans toute l'image disque d'un Linux opérationnel et que tous les programmes/données pointent sur cette valeur.
La solution technique consiste à placer ces flèches à des emplacements déterminés par un haché. Le système exploite par ailleurs plusieurs autres stratégies habituellement employées dans la conception de tables de hachage.
Une fois stockée, une flèche peut être dé-référencée et disparaître mais il va sans dire qu'elle ne peut être modifiée. C'est pas comme une valeur dans une variable. En fait, c'est comme si des objets mathématiques pures (des nombres, des paires et toutes les constructions dérivées) étaient mappés un-pour-un à des id dans le système.
Pour que le tout soit exploitable efficacement, le système embarque aussi le moteur d'un langage adapté à la situation. C'est une sorte de Lisp des flèches, sachant que le code source et l'état d'exécution du moteur sont sous la forme de... je te laisse deviner... oui des flèches.
Selon mon humeur, ce moteur/langage dédié est soit un simple interpréteur de requêtes à la SQL initiées par des logiciel tiers, soit la base d'une machine virtuelle prête à animer toute les applications de l'utilisateur. En tout cas, je crois qu'il sera capable de faire des choses incroyables grâce aux flèches, notamment de "mémoizer" tous les calculs qui peuvent l'être. Du genre: tu développes un gestionnaire d'images qui génère des miniatures, et sans rien lui dire, le système économise le calcul d'une miniature s'il a déjà été fait.
Au final, cela introduit une approche qui fait sauter une espèce de "verrou mental", à savoir le principe du "registre mémoire" sur lequel sont basées toutes les technos actuelles. En gros, ce système de flèches est à la réprésentation des connaissances ce que le "Lambda Calcul" est au calcul informatique, une sorte de théorie jusqu'au-boutiste qui débouche sur des technologies puissantes.
Le gain pour l'utilisateur, c'est de pouvoir réaliser simplement des choses qui paraissent énormes aujourd'hui, comme au hasard:
* avoir ses données indexées nativement par le système, prêtes à être cherchées, filtrées, explorées, manipulées dans tous les sens.
* disposer après un reboot de tout l'état d'une application et de son historique, comme "l'hibernation" mais en mieux. Les applications sont comme perpétuellement démarrées et on oublie définitivement des concepts moisis tels que... les fichiers.
* pouvoir nativement manipuler et cloner n'importe quoi n'importe où dans tout le système en mode zero-copy, un échantillon vidéo de 100 giga cité à pleins d'endroits ne prenant jamais plus de place.
* pouvoir nativement versionner le système à la sauce "Apple Time Machine"/"subversion"/"git".
* pouvoir nativement abstraire/virtualiser le système et y faire s'exécuter les agents logiciels douteux pour tout abandonner en cas de problème.
* etc.
Coté développeur, l'approche aboutie aussi à des conséquences intéressantes:
* Dans une conception orientée objet, ce qui identifie un "slot" dans un objet n'est plus un terme (un nom, un symbole...). Ca peut être n'importe quoi, par exemple une image. Le plus bizarre, c'est que la liaison entre un slot et sa valeur peut elle même servir de matériel pour construire d'autres objets.
* Dans une tagsonomie, le tag et la chose à étiqueter peuvent être n'importe quoi dans le système, et notamment une relation tag/item prééexistante. On peut donc typer des relations, lever des ambiguïtés...
* Dans une base de données, on peut construire, enrichir et changer son modèle de données sans jamais prévoir de "schéma".
* Un programme peut manipuler un programme, comme dans un langage réflexif comme Lisp, mais il peut vraiment le faire au plus bas niveau, de sorte que le comportement d'une application peut s'auto-modifier pour de bon et reconstruire de toutes pièces des pans de programmes plus adaptés aux besoins de l'utilisateur.
* les frontières entre le développeur et l'utilisateur, l'administrateur, etc. sont largement floutées, notamment parce qu'il n'y a définitivement plus aucune distinction en termes de représentation entre un conteneur et son contenu, entre un programme et ses données.
bon, heu ca fait un peu plus de 2 paragraphes, je vais peut-être m'arrêter là.
[^] # Re: euhhh
Posté par briaeros007 . Évalué à 5.
Je plains et les developpeur, et le système vu le nombre de pointeur^n (ben oui un pointeur c'est un peu comme une flèche) qu'ils vont se farcir XD
Pour que le tout soit exploitable efficacement, le système embarque aussi le moteur d'un langage adapté à la situation. C'est une sorte de Lisp des flèches, sachant que le code source et l'état d'exécution du moteur sont sous la forme de... je te laisse deviner... oui des flèches.
En clair tu essaie de faire un renouveau du brainfuck (8 flèches et ca y'est c'est parti)
En tout cas, je crois qu'il sera capable de faire des choses incroyables grâce aux flèches, notamment de "mémoizer" tous les calculs qui peuvent l'être. Du genre: tu développes un gestionnaire d'images qui génère des miniatures, et sans rien lui dire, le système économise le calcul d'une miniature s'il a déjà été fait.
Ça me rapelle curieusement le système "cactus" d'un copain.
En gros il s'agit d'un langage qui qu'un seul mot clé "cactus", et ce dernier sait exactement ce que souhaite faire l'utilisateur.
Bientot des flèches cactus ?
une sorte de théorie jusqu'au-boutiste qui débouche sur des technologies puissantes.
Je croyais qu'actuellement il n'y avait pas de proto ?
Après ton commentaire j'hesite entre plusieurs choses
- génie visionnaire incompris et difficilement compréhensible (cas le moins probable, sans vouloir te vexer)
- un bon gros délire sans trop de réalité (cas le plus probable)
- un projet qui oublie toute contraintes techniques pour se concentrer sur un aspect purement théorique.
[^] # Re: euhhh
Posté par Sylvain Garden (site web personnel) . Évalué à 1.
Tout ce que l'être humain a à faire est à importer les flèches qui exprime son besoin. C'est pas bien plus différent que de poser ou de streamer un fichier, ou de saisir un programme ou des données.
On pouvait déja dire que les interpréteurs transforme le code source en "arbres", les objet en "peigne", ça ne change rien au développement. Autant que je sache, les paires de pointeurs sont aussi beaucoup employées dans la compilation de langages fonctionnels.
Le brainfuck est une blague d'informaticien, toutefois c'est vrai que les opérateurs de base de cette nouvelle VM sont a priori très peu nombreux. Je t'assure que ca ne me fait pas plaisir d'inventer encore un nouveau langage. Mais pour une fois, ça vaut le coup, ça permet d'accéder à la puissance de ce nouveau mode paradigme. Je n'ai pas dis qu'il fallait directement développer dans ce langage, c'est juste une VM. Et puis dans un premier temps, je vois surtout ça comme une glue pour lier les opérateurs de consultation/édition des données avec des "callbacks" vers l'extérieur du système.
La "mémoization" ne consiste pas à deviner ce que veut le programmeur. C'est juste que si le résultat d'un calcul est dans le cache, on ne le refait pas. Toutes les infras complexe à la J2EE emploient ce genre de pools et de caches à tous les étages. Ici, c'est une fonctionnalité transparente.
C'est vrai qu'il n'y a pas de proto. Le gain annoncé est pour l'instant anticipé. Je n'aurai pas du utiliser le mot "Puissant". Je ne voulais pas dire que le système allait affiché le dernier jeu 3D du moment, mais plutôt qu'il allait rendre des services très utiles.
Concernant le proto, il s'agirait d'un serveur sous Linux avec une API réseau basé sur HTTP. Mais je bloque un peu sur la réalisation du langage, la machine à états et les transitions du moteur. Je me serais bien passé d'un tel développement. Le reste me paraît prêt pour passer à la conception détaillée et la réalisation: le stockage disque, le cache RAM, le ramasse-miettes, etc. Pour l'implémentation du serveur HTTP, j'ai aussi ma petite idée.
Pour ta conclusion, je choisirai la première version :)
[^] # Re: euhhh
Posté par benoar . Évalué à 3.
J'avoue que j'ai pas trop le temps de regarder pour l'instant, mais au départ ce genre d'idée se basait d'après les travaux que j'avais vu sur les ontologies (qui ne permettent malheureusement pas de "méta"-bordel parce qu'elles séparent les objets des relations). Et en ce qui concerne le langage, je te conseille de regarder du coté des types dépendants en:Dependent_type et en gros des travaux de Conor McBride, et des mathématiques constructivistes (ça va faire mal à la tête, je te préviens).
Bon, moi j'avais une approche à la base plutôt centrée sur les langages et les types, d'où l'orientation de mes conseils. Et puis ça c'est les trucs que j'ai vu récemment seulement, je suis passé par un bon paquet de trucs entre temps ...
[^] # Re: euhhh
Posté par Sylvain Garden (site web personnel) . Évalué à 1.
[^] # Re: euhhh
Posté par Sylvain Garden (site web personnel) . Évalué à 2.
En fait, n'importe quel langage peut prendre place dans un système Entrelacs: concernant un langage fonctionnel, il peut être non typé, typé dynamiquement ou statiquement, typé simplement ou fortement. Un langage peut aussi offrir, comme le suggèrent les travaux que tu m'as recommandés, une algèbre des types permettant de démontrer par la preuve mathématique la sécurité du code. Bref, on peut faire ce qu'on peut déjà faire dans un système traditionnel.
Mais lire des articles sur les sujets que tu m'a conseillés m'a surtout permis d'identifier un peu mieux en quoi les aptitudes d'un langage peuvent être étendues par le choix d'une représentation des connaissances par des flèches.
Si l'on parle d'un langage comme Lisp par exemple. Et bien il s'agit d'un langage connu pour homogénéiser la syntaxe concrète et la syntaxe_abstraite d'une expression. Cela permet entre autres choses, de déclarer des macros qui modifient en profondeur l'interpréteur du langage. Cela peut permettre aussi de recréer de nouvelles fonctions qui viennent compléter ou remplacer des fonctions existantes.
Toutefois, même si les syntaxes abstraites et concrètes sont homogènes, elles restent fondamentalement séparées dans un système traditionnel, puisque que que la syntaxe abstraite correspond à la représentation en mémoire vive de l'arbre-expression du programme tandis que la syntaxe concrète est rattachée aux fichiers source du même programme dans le file system.
Or ces derniers échappent à la modification par le programme. C'est une opération trop complexe dans un système traditionnel. Un logiciel Lisp ne peut donc pas pratiquer l'intercession (Réflexion) au niveau de la syntaxe concrète. En d'autres termes, un agent Lisp peut modifier son propre programme une fois chargé en mémoire, mais il ne peut pas modifier le programme originel (le fichier source), ni les autres programmes du système. L'intercession n'est pas pérenne. La méta-programmation (des programmes qui manipulent des programmes) reste alors une technologie couteuse, et la réflexivité du langage Lisp une curiosité.
Entrelacs, en fusionnant tous les formats d'information structurées et tous les niveaux mémoires dans un espace unique pour tout le système, élimine cette contrainte arbitraire (même si elle peut être réintroduire plus tard pour des raisons de sécurité). C'est à dire qu'un langage à la Lisp dans Entrelacs peut facilement être enrichi d'opérateurs permettant à un programme, non seulement d'accéder à une représentation syntaxique de lui-même, mais aussi de modifier cette expression de façon pérenne.
Par ailleurs, on propose souvent en exercice de fabriquer rapidement un interpréteur Lisp en Lisp, histoire de démontre que Lisp est un peu la mère de tous les langages. Toutefois, l'état de l'interpréteur qui anime un programme est rarement lui-même accessible par le dit-programme.
Il est vrai que les langages fonctionnels permettent souvent de manipuler la continuation courante, de la mémoriser et de la restaurer. Mais Entrelacs permettrait sans peine à un programme de récupérer tout l'état de l'interpréteur à l'instant présent: la continuation, mais aussi l'environnement courant et l'expression courante, le tout sous la forme de flèches, c'est à dire des entités de premier ordre, manipulables par le programme. Le programme pourrait donc stocker tout ou une partie de cet état, le modifier, et enfin le réinjecter dans l'interpréteur. Par exemple, un agent pourrait faire une "sauvegarde immédiate" de lui-même exactement comme le font certains jeux vidéo.
Bon, je vais m'arrêter, c'est épuisant de parler dans le vide abyssal d'internet. Le but de ce forum était au départ d'arrêter de déblatérer tout seul dans mon coin. C'est un peu raté pour l'instant.
Quoi qu'il en soit, merci encore pour le coup d'oeil.
[^] # Re: euhhh
Posté par benoar . Évalué à 3.
Je suis d'accord avec ta réflexion sur lisp, bien que la suite de ce que tu racontes me fait beaucoup penser à Smalltalk. Oui, je rapproche encore ça d'un langage. C'est peut-être parce que pour moi, c'est un peu la base des choses, même si la représentation sous-jacente est souvent "négligée", alors que quelque de plus "travaillé" pourrait te sembler indispensable. Mais bon, c'est qu'à force de vouloir rendre ta représentation puissante, en fait, tu la fais devenir un langage ... (c'est un peu une vague supposition, je n'ai pas regardé de si près Entrelacs).
Voilà, je pense que ce sont des choses très intéressantes à étudier, mais j'avoue que depuis quelques temps j'ai un peu laissé tomber, miné par tout ce que je vois sur le poid du passé. Donc ça pourrait être intéressant comme projet expérimental, mais j'ai peur que ça n'aille pas plus loin. Bon après, si on est négatif comme moi, on fait jamais rien, alors je te souhaite quand même bon courage !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.