Je m'étais dit de ne pas rajouter d'huile sur le feu vu le nombre de détracteurs ci-dessus... mais bon... j'ai un peu de temps à perdre.
Moi aussi.
Normal donc de se faire incendier quand on arrive avec une description longue d'un projet, qui au final, n'explique pas vraiment son intérêt
Pour la description du projet, il débute juste, il correspond à un projet de stockage de données en RAM. Désolé si je n'arrive pas à 15 tonnes de documentation, d'exemples, je suis tout seul.
Ce stockage permet de gérer des valeurs, des entrées typées, sous la forme d'un arbre qui peut grandir et se déployer suivant ce que veulent les clients. Dit autrement : une valeur peut en stocker d'autres, elles-même d'autres...
On parcours cet arbre (un par canal), grâce à un chemin, qui est une chaîne comme le serait le chemin dans une navigateur de fichiers.
l'ascii est à préféré car évite les problème de clavier, d'encodage, est plus compacte et rapide à traiter (1 octet = 1 caractère).
Et ? Ta seule logique c'est l'efficacité brute ? On doit tous envoyer que de l'ASCII car c'est plus simple ? Tu parles de réalité dans ton post : soit, la réalité c'est qu'on utilise plein de signes différents, pour plein de langues, pour davantage de sens différents.
Il y a toujours un arbitrage entre performance et usage. L'arbitrage que j'ai pris ici, c'est d'avoir un système qui gère de l'UTF-8 de bout en bout et donc, qui n'avait aucune raison de pas supporter du français, des accents.
le français n'est pas universel en informatique
On est d'accord. Mais en faire un caractère d'exclusion définitif est risible. J'ai hâte de voir les commentaires lorsque de plus en plus de sources ne seront pas en anglais, ni en français... parce que l'évolution du monde agira sur l'évolution des conventions en informatique.
Python n'a rien d'un langage performant
J'ai marqué plus haut dans les commentaires la même chose (cf. les implémentations de Hashmap). Je parle de puissance au global, en terme conceptuel. A moins que je sois particulièrement abruti (ce n'est pas exclu), il y a une place de choix du langage dans la "science des données", peut-être parce qu'il est souple, rapide en développement, avec des bibliothèque de qualité en d'autres langages parfois, qui en font un langage de "colle". La puissance ne se limite pas à un nombre d'opérations par seconde pour un langage (à la rigueur, son implémentation pourquoi pas).
Rust produit du code compilé comme des centaines de langages
Effectivement il manque de maturité mais il est (très) prometteur et gère très bien la mémoire. Deux qualités qui me semblent intéressantes pour une informatique moderne dans ce type de langage. Le ramener à un effet de mode, c'est tout de même faire peu de cas des articles de comparaison et d'études à son sujet.
Sur LISP, c'est gentil de relever la même chose que moi : il est dans des cas particuliers, mais souvent le seul vraiment pertinent dans ces cas-là. Et les implémentations gèrent là encore des imports d'autres langages pour dépasser le nombre limité de bibliothèques.
Le choix d'un langage devrait dépendre du besoin et d'une réflexion technique, pas de la mode.
Bref, avant de s'extasier devant tel ou tel langage, je serais déjà content qu'un développeur "contemporain" maîtrise les aspects bas niveau (architecture, gestion des caches, latence..) des entités avec lesquels il interagit...afin de comprendre que parser du JSON à 2Go/s n'est pas de la science fiction.
J'ai passé des mois à attendre ça, de quelques dév. De la perf pour de la perf. Super. Mais le monde du développement et heureusement, ne se limite pas à ça. Attention, je ne dis pas que ça n'a pas d'intérêt, mais tu es aussi dans des bornes limitées que les miennes : elles sont juste différentes.
Les interfaces au sens large, les modalisations de processus organisationnels, des modèles de données type RDF, l'intérêt des systèmes experts ou des procédures de qualité, d'audit et de contrôle légaux sur les SI, etc. nécessitent aussi des compétences, d'autres, qui font des personnes dont c'est le métier des personnes pas moins capables de produire des logiciels. J'imagine que ça te coûte de lire ça mais oui, tu as des personnes moins expérimentées que toi, qui sont capables de faire des logiciels qui fonctionnent, et pas trop mal.
Cela fait déjà quelques années que les conceptions logique et logicielle ne se bornent plus aux seules questions de performance et aux limites matérielles à contourner.
Finalement et j'arrête moi aussi là :
(...) assène post après post un discours idéologique en mode 'je sais tout'.
Tu me dis que je fais "M. je sais tout" ? Mais quelle est ta posture face à moi, sinon dire "j'ai tellement du temps à perdre que je vais m'abaisser à lui répondre, ce pauvre crétin ignorant" ? A ce point affreux d'avoir un avis qui ne soit pas le tien : ton avis qui serait donc la vérité vraie et révélée ?
Ne crois-tu pas que ta morne ne vaut pas la mienne lorsque tu écris ça ?
Je ne cherche pas le concours du mérite. J'ai bossé des années sur ce sujet des liaisons sciences de l'information et de l'informatique, alors oui, j'ai une opinion, que j'essaie d'éclairer autant que je peux, qui ne se limite à la taille de mon JSON et qui s'essaye à d'autres choses.
[^] # Re: Formatage automatique
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 2.
Moi aussi.
Pour la description du projet, il débute juste, il correspond à un projet de stockage de données en RAM. Désolé si je n'arrive pas à 15 tonnes de documentation, d'exemples, je suis tout seul.
Ce stockage permet de gérer des valeurs, des entrées typées, sous la forme d'un arbre qui peut grandir et se déployer suivant ce que veulent les clients. Dit autrement : une valeur peut en stocker d'autres, elles-même d'autres...
On parcours cet arbre (un par canal), grâce à un chemin, qui est une chaîne comme le serait le chemin dans une navigateur de fichiers.
Et ? Ta seule logique c'est l'efficacité brute ? On doit tous envoyer que de l'ASCII car c'est plus simple ? Tu parles de réalité dans ton post : soit, la réalité c'est qu'on utilise plein de signes différents, pour plein de langues, pour davantage de sens différents.
Il y a toujours un arbitrage entre performance et usage. L'arbitrage que j'ai pris ici, c'est d'avoir un système qui gère de l'UTF-8 de bout en bout et donc, qui n'avait aucune raison de pas supporter du français, des accents.
On est d'accord. Mais en faire un caractère d'exclusion définitif est risible. J'ai hâte de voir les commentaires lorsque de plus en plus de sources ne seront pas en anglais, ni en français... parce que l'évolution du monde agira sur l'évolution des conventions en informatique.
J'ai marqué plus haut dans les commentaires la même chose (cf. les implémentations de Hashmap). Je parle de puissance au global, en terme conceptuel. A moins que je sois particulièrement abruti (ce n'est pas exclu), il y a une place de choix du langage dans la "science des données", peut-être parce qu'il est souple, rapide en développement, avec des bibliothèque de qualité en d'autres langages parfois, qui en font un langage de "colle". La puissance ne se limite pas à un nombre d'opérations par seconde pour un langage (à la rigueur, son implémentation pourquoi pas).
Effectivement il manque de maturité mais il est (très) prometteur et gère très bien la mémoire. Deux qualités qui me semblent intéressantes pour une informatique moderne dans ce type de langage. Le ramener à un effet de mode, c'est tout de même faire peu de cas des articles de comparaison et d'études à son sujet.
Sur LISP, c'est gentil de relever la même chose que moi : il est dans des cas particuliers, mais souvent le seul vraiment pertinent dans ces cas-là. Et les implémentations gèrent là encore des imports d'autres langages pour dépasser le nombre limité de bibliothèques.
J'ai passé des mois à attendre ça, de quelques dév. De la perf pour de la perf. Super. Mais le monde du développement et heureusement, ne se limite pas à ça. Attention, je ne dis pas que ça n'a pas d'intérêt, mais tu es aussi dans des bornes limitées que les miennes : elles sont juste différentes.
Les interfaces au sens large, les modalisations de processus organisationnels, des modèles de données type RDF, l'intérêt des systèmes experts ou des procédures de qualité, d'audit et de contrôle légaux sur les SI, etc. nécessitent aussi des compétences, d'autres, qui font des personnes dont c'est le métier des personnes pas moins capables de produire des logiciels. J'imagine que ça te coûte de lire ça mais oui, tu as des personnes moins expérimentées que toi, qui sont capables de faire des logiciels qui fonctionnent, et pas trop mal.
Cela fait déjà quelques années que les conceptions logique et logicielle ne se bornent plus aux seules questions de performance et aux limites matérielles à contourner.
Finalement et j'arrête moi aussi là :
Tu me dis que je fais "M. je sais tout" ? Mais quelle est ta posture face à moi, sinon dire "j'ai tellement du temps à perdre que je vais m'abaisser à lui répondre, ce pauvre crétin ignorant" ? A ce point affreux d'avoir un avis qui ne soit pas le tien : ton avis qui serait donc la vérité vraie et révélée ?
Ne crois-tu pas que ta morne ne vaut pas la mienne lorsque tu écris ça ?
Je ne cherche pas le concours du mérite. J'ai bossé des années sur ce sujet des liaisons sciences de l'information et de l'informatique, alors oui, j'ai une opinion, que j'essaie d'éclairer autant que je peux, qui ne se limite à la taille de mon JSON et qui s'essaye à d'autres choses.