J’invite à la clémence, c’est ma contribution à la communauté... :)
Pas de souci :)
c’est un projet entièrement francophone
En dehors de projets éducatifs je ne comprends pas l’intérêt étant donné la masse de documentations et projets existants en anglais.
Robert se veut être un logiciel utilisable par le plus grand nombre
En rapport avec le choix de la langue, pour moi c’est un frein à l’adoption : on privilégie sa localité au détriment des autres. Ça me rappelle tous ces projets en Chinois dont on ne peut pratiquement rien faire car il n’existe aucune documentation en anglais.
Ça donne aussi un mélange très étrange entre anglais et français, vu que le langage et la lib standard sont en anglais. Ça fait encore plus de gymnastique pour passer de l’un à l’autre.
De plus, au niveau du code, ça n’a amha que peu d’importance : les utilisateurs utilisent un binaire, pas du code source.
Le projet ne dépend d’aucune « caisse » (module) externe, volontairement, afin d’éviter le serpent des dépendances, qui rend complexe la maintenance
Selon les objectifs, tout refaire sois-même peut-être autant sinon plus de code à maintenir, sans parler des problèmes de sécurité/performance résolus par d’autres projets.
Choisir consciencieusement ses dépendances est à mon avis plus intéressant. Tu prends l’exemple de Regex, je pensais aussi à ce genre de chose, mais pas que. Il existe des bibliothèques permettant d’atteindre des performances bien meilleures que les dictionnaires (hashmap/hashset) de la lib standard par exemple.
Pour ce qui est de la traduction des « crate » Rust, je ne pense pas que cela rende les choses plus claires :)
La base est constituée de « canaux »
Si je comprends bien c’est à la fois un "pub/sub" et une "base" comme on pourrait en avoir dans redis ?
Une valeur peut être [...] un objet qui lui‐même est un dictionnaire de paires clé‐valeur. Il est donc possible de faire des « chemins » amenant à une valeur particulière dans l’arbre du canal.
Quel est l’intérêt par rapport à une modélisation "à plat" clef-valeur toute simple ?
En terme de performance, cela veut dire qu’à chaque fois que l’on veut traverser des objets, il faut charger en cascade des espaces mémoire aléatoirement dans la RAM.
En terme d’usage, je ne vois pas d’avantage à simplement avoir une clef correspondant au chemin complet, et une valeur au bout. Sauf peut-être pour l’expiration d’un groupe de valeurs, éventuellement.
Peux-tu m’éclairer à ce sujet ?
Sur la partie scripting, j’ai pas compris le choix d’un caractère "difficile" à taper, limitant encore plus l’accessibilité : ø. Si c’était pour désambiguïser l’usage du "o" et du "0", ok, mais alors choisir un caractère facilement accessible me semble judicieux.
En terme de code (j’ai largement survolé, de très très haut), je vois que tu te sers de HashMap provenant de la lib standard. Les performances de ce type sont vraiment mauvaises : les implémentations de Python et Go font largement mieux par exemple. S’il y a une volonté d’être performant, il faut absolument s’orienter vers d’autres implémentations en attendant.
Voilà mon petit retour :) Personnellement je ne vois pas d’intérêt de ce projet par rapport à Redis, ou même memcached si ce n’est l’utilisation d’un langage théoriquement exempt de problèmes de pointeurs null et autres overflows.
Après peu importe, c’est toujours une bonne expérience de faire quelque chose de concret, et j’espère que mon commentaire pourra t’apporter quelque chose.
# Mes deux centimes de vieux francs
Posté par Ruminant . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 9. Dernière modification le 20 avril 2020 à 15:15.
Pas de souci :)
En dehors de projets éducatifs je ne comprends pas l’intérêt étant donné la masse de documentations et projets existants en anglais.
En rapport avec le choix de la langue, pour moi c’est un frein à l’adoption : on privilégie sa localité au détriment des autres. Ça me rappelle tous ces projets en Chinois dont on ne peut pratiquement rien faire car il n’existe aucune documentation en anglais.
Ça donne aussi un mélange très étrange entre anglais et français, vu que le langage et la lib standard sont en anglais. Ça fait encore plus de gymnastique pour passer de l’un à l’autre.
De plus, au niveau du code, ça n’a amha que peu d’importance : les utilisateurs utilisent un binaire, pas du code source.
Selon les objectifs, tout refaire sois-même peut-être autant sinon plus de code à maintenir, sans parler des problèmes de sécurité/performance résolus par d’autres projets.
Choisir consciencieusement ses dépendances est à mon avis plus intéressant. Tu prends l’exemple de Regex, je pensais aussi à ce genre de chose, mais pas que. Il existe des bibliothèques permettant d’atteindre des performances bien meilleures que les dictionnaires (hashmap/hashset) de la lib standard par exemple.
Pour ce qui est de la traduction des « crate » Rust, je ne pense pas que cela rende les choses plus claires :)
Si je comprends bien c’est à la fois un "pub/sub" et une "base" comme on pourrait en avoir dans redis ?
Quel est l’intérêt par rapport à une modélisation "à plat" clef-valeur toute simple ?
En terme de performance, cela veut dire qu’à chaque fois que l’on veut traverser des objets, il faut charger en cascade des espaces mémoire aléatoirement dans la RAM.
En terme d’usage, je ne vois pas d’avantage à simplement avoir une clef correspondant au chemin complet, et une valeur au bout. Sauf peut-être pour l’expiration d’un groupe de valeurs, éventuellement.
Peux-tu m’éclairer à ce sujet ?
Sur la partie scripting, j’ai pas compris le choix d’un caractère "difficile" à taper, limitant encore plus l’accessibilité :
ø. Si c’était pour désambiguïser l’usage du "o" et du "0", ok, mais alors choisir un caractère facilement accessible me semble judicieux.En terme de code (j’ai largement survolé, de très très haut), je vois que tu te sers de
HashMapprovenant de la lib standard. Les performances de ce type sont vraiment mauvaises : les implémentations de Python et Go font largement mieux par exemple. S’il y a une volonté d’être performant, il faut absolument s’orienter vers d’autres implémentations en attendant.Voilà mon petit retour :) Personnellement je ne vois pas d’intérêt de ce projet par rapport à Redis, ou même memcached si ce n’est l’utilisation d’un langage théoriquement exempt de problèmes de pointeurs null et autres overflows.
Après peu importe, c’est toujours une bonne expérience de faire quelque chose de concret, et j’espère que mon commentaire pourra t’apporter quelque chose.