Une flèche est approximativement une paire de pointeurs. Mais le développeur ou l'utilisateur n'a pas à le savoir: Il y a un ramasse-miettes et une gestion automatique des niveaux mémoires.
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 Sylvain Garden . En réponse au message projet "Entrelacs". É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 :)