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 Sylvain Garden . En réponse au message projet "Entrelacs". É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à.