(@totof2000) Mais bon, LUA a pour gros intéret d'être très rapide et très léger. Je ne sais pas ce que vaudrait python à côté.
Je veux pas dire de bêtise (vraiment, je fais de mémoire), mais finalement LUA c'est un simili-code C qui est compilé en JIT comme ce serait avec GCC. Donc oui, question efficacité pure, ce serait bien mieux que Python (bytecode oblige).
Question lib dispo, Python gagne j'imagine.
(@YetiBarBar) Tu peux avoir une équipe qui s'occupe d'améliorer un programme core où tu veux profiter des avantages du Rust et vouloir exploiter des modules existants ou à développer par des personnes dont la programmation n'est pas le métier (et qui te pondront un Python correcte mais jamais de Rust).
Tu peux aussi avoir une forte dépendance à une librairie exploitable uniquement en Python.
A la limite, faire des appels Rust depuis python pourquoi pas…
Cf. l'extrait de l'article sur RedHat. NumPy est l'exemple parfait d'un intérêt à avoir autre chose que du pur Python. Rust permet d'avoir un code conforme au C. La transition est vite faite.
… mais le contraire me paraît un peu antinomique avec les objectifs de Rust.
La possibilité de le faire ne veut pas dire toujours le faire, ni que ça ait un sens tout le temps.
En ayant la possibilité de renvoyer vers Rust une fonction générée lors de l'exécution, lambda ou autre, ça peut être sympa de profiter dans Rust d'une composition issue des bibliothèques de Python. Tu profites d'un code en Python en façade, avec du Rust derrière.
Autre point, Rust agit avec du C sans difficulté, il suffit de prendre les bonnes précautions.
Peux-tu m'indiquer plus précisément l'antinomie que tu y vois ?
Contrairement à ce que tu penses, cela m’intéresse de comprendre pourquoi on a arrive à des architectures logicielles compliquées pour des résultats catastrophiques sans que personne ne se remette en question (d'où les quelques exemples cités).
Peut-être parce que l'informatique ce n'est pas qu'une unique question de logiciels justement ? Mais d'infrastructure, d'organisation, etc. - et que c'est l'architecture globale autour d'un besoin et du possible qui importe.
Un exemple qui me vient : la mise en place d'un bastion d'administration (je pense par exemple aux contraintes des normes voulues dans les OIV… mais ça semble se généraliser grâce à l'action de l'ANSSI) dans une "vieille" architecture, figée et difficile à bouger, comme on en trouve beaucoup dans les PME françaises : l'éditeur peut ne plus exister ; les sources non-documentées ; les personnes qui ont pensé certaines parties ou certaines organisations des traitements ne sont plus là: ce qu'elles ont pu faire avait peut-être du sens à leur époque, …
Face au décideur, bon courage si tu penses seulement "logiciel" comme un tout unique et cohérent dans ta réponse, qui évolue forcément bien et uniformément.
Car il y a le logiciel, mais aussi le réseau à gérer. Les traitements métiers, qui ont pu évolué, qui peuvent être en partie analogiques voire physiques. Du SCADA. Certains applicatifs ne supportent pas tel ou tel protocole (pas de TLS/SSL, etc.). Il faut des proxy partout, des routes à ne plus en finir, être capable de faire dialoguer des choses qui n'ont pas été forcément prévues pour communiquer vers l'extérieur.
Rajouter les contraintes de redondance, de sécurité, logger pour motifs légaux. C'est une réalité. Pas juste un discours de "marketeux". Et avant de parler de la seule performance, on parle de viabilité, d'intérêts, de conditions préalables.
Bref tu te retrouves avec une évolution "organique" d'un logiciel ou d'un ensemble applicatif, qui peut être monolithique ou pas, avec des blocs qui ont été faits à des périodes différentes, des besoins différents - dont un contexte qui évolue.
Tu pars du principe que forcément personne ne remet en question une "mauvaise" architecture. Je ne crois pas que ça soit blanc ou noir. Tu peux être conscient d'une situation et devoir gérer une basse réalité qui soit complexe à gérer et faire évoluer.
ça augmente la complexité de ton application, elle fait pleins de choses différentes ça multiplie les droits que tu va devoir lui donner et rends son observation plus compliquée
+1 : un "cache" (amélioré) peut servir aussi à vérifier les droits, servir d'intermédiation au sens large, accélérer un accès, etc. Ou comme indiqué juste avant, servir d'agent nécessaire pour la mise en place d'un bastion d'administration qui ceinture un applicatif pas nécessaire sûr ou éditable, pour faire remonter des informations sur le fonctionnement de l'ensemble.
tu peux vouloir que ton cache survive à un redémarrage de ton applicatif
Voire dans certains cas, c'est même plus ou moins lui qui sera le co-pilote, si tu as du batch processing qui peut planter, se séquencer sans lien entre les opérations, etc. Le cache devient la clé de voûte, évolue et sert à maintenir des connexions à des bases de données, à alerter sur une situation anormale autant qu'à faire réellement du cache de requêtes.
Est ce que qu'on parle toujours informatique avec quelque chose d'aussi flou que :
"pleins de contexte différents qui amènent à des solutions différentes et donc des solutions différentes"
En faisant court : tu as défini un périmètre, mais c'est une des visions qui existent du logiciel, propre à l'ingénierie informatique mais certainement pas à "l'informatique" dans toutes ses ramifications et branches. Encore moins de ce qui est attendu aujourd'hui dans les organisations. J'insiste là-dessus.
Amha, ça mérite d'avoir un débat plus large, de qui (me) semble intéressant sur la définition finalement, de ce que c'est le développement et son attendu. Mon propos n'est pas de dire que tu as tort (tu n'as pas tort), mais que ta position ne me semble pas tenir lieu d'une généralité.
En faisant long : Si tu ne veux pas bouger de ton périmètre alors soit, mais ne me dit pas que je cherche "par tous les moyens" de mon côté. Que tu déjuges ou déconsidères un argument, ne le rend pas inopérant pour autant, parce que tu restes sur le pas de ta porte.
Le projet que j'ai soumis est "parfaitement imparfait" : une proposition sur des travaux perso., toujours en cours pour la meilleure approche.
Sur la question de l'orientation attendue sur la performance, le sujet a été débattu dès 1958/59, où les travaux plus universitaires ont accentué leur séparation avec l'ingénierie informatique pure émergente. L'histoire est connue :
- la branche "proche système" (au démarrage impérative, avec Fortran, C, etc.) ;
- (vs) la branche "abstractive" (Lisp et dérivés, les AST, le fonctionnel).
… Entre ceux qui vont exploiter complètement la puissance de calcul de la machine (qui iront très vite dans les entreprises, désireuses d'investir à moindre coût dans une informatisation extrêmement coûteuse), et ceux qui en veulent d'abord un usage généraliste, une "intelligence artificielle" - nb : le terme a l'époque porte sur les systèmes expert, la faculté de décision et de raisonnement pour une machine ; rien à avoir avec notre acceptation moderne : on est alors sur des systèmes de résolution d'assertions.
Notre débat est une ramification grossière de ces deux visions, qui se sont affrontées, avant de devenir plus complémentaires et de concert.
On avait encore à l'époque une grande diversité d'architectures matérielles et parfois, même pas de distinction dans les types de "mémoire" (je pense aux premières machines LISP, avec quelques parallèles que l'on peut faire avec l'approche choisie par Intel sur Optane Memory).
Avec en toile de fonds, la prise de possession par les sciences de gestion d'une partie des sciences informatiques avant qu'elles ne deviennent, au sein des organisations durant le milieu / fin des années 70, une entité de recherche et d'application indépendante.
Dit autrement : le logiciel est bien plus que qu'un assemblage applicatif, de scripts ou de codes divers. Il n'est pas éthéré et vient dans un SI qui est l'organisation elle-même. Il répond à un besoin (métier) et n'y a aucun autre intérêt, aucun but, aucun moyen à dépenser qui n'y soit pas rattaché. L'optimum d'un traitement strictement machine dont tu parles, était vrai il y a longtemps, où l'octet coûtait cher et les machines """rares""" (fin des années 90/début 2000). Cela reste largement enseigné dans les études informatiques, notamment celles où l'ingénierie est reine. Cependant ce n'est pas forcément une attente économique.
Désormais l'optimum est à chercher entre le coût de développement et de maintenance (ton salaire et celui de tes homologues n'est pas gratuit : optimiser un programme n'est pas toujours financièrement intéressant) ; la rentabilité d'un processus organisationnel qui l'utilisera (un logiciel très performant mais que personne ne maîtrise est détourné, abandonné ou pire pas maintenu par de futures équipes) ; la capacité à en extraire de l'information utile et à se justifier (audit, suivi et maîtrise, etc.) ; dernièrement les questions de sécurité et de sûreté, comme de la tolérance du SI aux pannes et à la gestion de la redondance.
Perdre 5% ou 10% de performance d'un logiciel n'est pas toujours un drame, même en augmentant les charges d'infras derrière. Parce que tes choix comme DSI ou proche de la DSI, sont contraints par des aspects sociaux, légaux, métiers - tout ce que tu veux.
Je ne parle même pas de la dette technique, qui pour le coup, parfois, oblige à des recherches très pointues sur l'optimisation "du 2Go/s pour un JSON" parce que l'architecture globale est déficiente, ou simplement n'est plus adaptée, ou face à un soucis hors norme de masse (tout le monde n'est pas Netflix, Facebook… !). Dans la quasi-totalité des organisations, on cherche donc moins à dépasser la dette que la contourner à moindre coût (souvent, cela revient à ne pas arrêter la production, ni modifier trop en profondeur un équilibre logiciel fragile, non-documenté, bloquant des refontes plus larges). Là effectivement, l'impératif d'efficacité peut se faire jour avec force. La fréquence de cette recherche d'efficacité en fait une généralité, mais pas un fait systématique et encore moins un but. Je tente de ne pas mélanger la cause et la conséquence.
Pour la maîtrise de l'architecture, encore faut-il avoir donc pensé aux points de la scalabilité et de la redondance - et là où nous pouvons nous rejoindre, c'est que Robert n'a certainement pas atteint l'objectif (mais après tout, c'est une proposition initiale, personne n'est contraint d'en faire usage…).
Ce n'est pas un effet de style si on est passé d'une qualification de "système informatique" (et donc de direction informatique) à "système d'information" (et donc de "direction des systèmes d'information"). Il y a une logique derrière. Personnellement ça ne me dérange pas qu'on considère que l'informatique n'est qu'elle-même, un concept un peu "indépassable", mais c'est un signe si les "cellules de gestion de projets" et autres modalités d'organisations se multiplient dans les DSI pour modifier les habitudes et les approches.
"par la magie des discours commerciaux, on s'éloigne du sujet"
Je n'ai rien, absolument rien à te vendre : je ne te rapporte pas un propos commercial, je ne te vends pas du rêve ; je te donne mon opinion de ce que j'ai pu trouvé après des heures à la bibliothèque universitaire ou en entretien. Tu ne prendras certainement pas les arguments, mais toi comme moi, nous nous ne nous adressons pas à l'autre mais aux lecteurs qui nous ont le mérite de nous lire.
Et je t'assure, évoquer les sciences de gestion dans les années 70 ou l'intérêt d'un travail ontologique au sein d'une organisation pour piloter le schéma de données et le développement applicatif d'une DSI n'a rien de bandant ! Au contraire, ça provoque le rejet et l'impatience (voire une pointe de mépris…).
Anecdote : lors de ma soutenance, mon jury me dit "propos passionnant, innovant [en réalité pas tant que ça, je fais une synthèse de travaux d'autres horizons pas encore rapprochés]. Comment voulez-vous vendre ça à une entreprise ?!" -> Je ne peux pas. L'historique culturel est en défaveur de l'approche "organisationnelle" des SI… mais des signes commencent à émerger.
Illustrons le propos. Un exemple que je suis attentivement : la ré-émergence du "no-/low-code", les services Amazon Lambda (idem chez Microsoft, IBM, Google… ces 3 dernières années), l'approche "fonctionnelle" sur tout un tas de langages très différents et une logique événementielle. Le schéma global de ces services :
1. un événement quelconque
2. un filtre
3. une fonction déclenchée, éventuellement avec la notion de grappes de travail derrière
4. une réponse renvoyée et/ou stockée.
Plutôt que d'agir sur l'efficacité d'une fonction, on dimensionne sa réplication (maîtrise des coûts : arbitrage sur le temps de calcul global plutôt que l'efficacité unitaire). L'orchestration des fonctions entre elles, créée l'applicatif. En gros tu as un stock de fonctions (ou de fonctionnalités, c'est-à-dire de sous-applicatifs), qui tu lies entre elles, de manière arbitraire, possiblement sans ligne de code pour l'utilisateur final.
Ces services cherchent justement à minimiser les coûts globaux pour les clients. Ils reprennent de vieilles théories, qui ont facilement 30 ans, avec les systèmes experts, qui eux-même n'avaient aucunement besoin de personnes ayant des talents de codeurs pour faire des logiciels (je pense à CLips par exemple*), en l'adaptant à ce qui est possible aujourd'hui.
Réellement, ce n'est ni plus ni moins que la ré-invention un poil modernisé des systèmes experts.
(* : L'expression choisie était celle des maths en inspiration, car il n'y avait pas guère de possibilités d'une interface évoluée. Ce n'est plus le cas aujourd'hui et je serais heureux le jour où une personne qui n'a pas de compétence informatique, sera capable de faire un logiciel convenable, avec un code généré propre et relativement bien pensé, parce qu'il se sera concentré sur les besoins de son métier et pas plus. On y arrive, doucement.)
Le but est de moins chercher cette partie d'optimisation purement mixte logicielle/matérielle, mais d'aller vers une meilleure applicabilité du logiciel au global et pour répondre aux exigences des procédures. C'est le sens de l'histoire : sinon autant rester à l'assembleur (zéro abstraction, tu n'auras pas mieux en terme de performance).
Deux des exemples qui allient beaucoup de facettes que j'évoque :
- le projet européen SPECIAL (l'application d'une politique de sécurité à maillage très fin sur n'importe quel d'objets) https://www.specialprivacy.eu/
- la thèse doctorale de Jérémy Lhez sur le "Filtrage, stockage et raisonnement sur de grands volumes de triplets RDF ordonnancés" https://pastel.archives-ouvertes.fr/tel-02084022/document
Comme je l'ai indiqué auparavant dans les commentaires, c'est bien le métier qui fait l'outil et pas l'outil qui fait le métier. Il doit donc être efficient et après, éventuellement, performant.
Les grandes boîtes ont un temps d'avance du fait de leurs moyens justement, et elles ne sont déjà plus sur la question de la numérisation (terminée) mais de l'abstraction de leurs outils numériques (SAAS, "cloudification" et autres) :
- elles ne veulent plus piloter du code mais une interface et un traitement logique (interface + traitement = logiciel) ;
- elles veulent davantage de développements rapides (c-à-d écrits vite) et efficients ;
- elles ne veulent plus gérer de la dette technique ni de contraintes organisationnelles trop fortes à cause de problématiques informatiques.
L'efficacité (en octets traités/seconde), les profils techniques pointus, arrivent après, en support pour rester dans du temps de calcul raisonnable mais pas en chef orchestre ni en finalité (exemple des "product owners" qui ne sont plus plus des pilotes techniques et couvres d'abord les attentes fonctionnels).
Pour le reste :
- tu es probablement un très bon programmeur et je ne doute pas une seconde que tu aies une meilleure connaissance que moi, notamment pour la gestion fine stack ou heap. Pour Robert, ma priorité est davantage la mise en grappe du processus que l'usage de la mémoire, tout en continuant à assurer la possibilité de soutenir un modèle RDF ;
- tu as entièrement raison un protocole binaire est plus efficace qu'un protocole qui se lit humainement. Mais j'ai préféré qu'il soit lisible par le plus grand nombre (dans l'espace francophone). Sur le sujet nos positions sont irrésolubles.
Enfin et pour conclure là, les hypothèses sur lesquelles j'ai travaillé ces dernières années et qui me motivent encore aujourd'hui. Elles n'ont aucune force de lois. Je les donne ici, pour parfaire le contexte de mon propos.
A. HYPOTHÈSE N°1 – « IL EXISTE UN ‘AUTRE CHEMIN’ POUR LES SI. »
Deux visions historiques s’affrontent dans les années 70 : les sciences de gestion (« vision organisationnelle ») ainsi que les ingénieurs de la micro-informatique naissante (« vision techniciste »).
La « vision techniciste » est celle qui a été très quasi-exclusivement sélectionnée par les organisations, comme choix par défaut qui n’est que rarement motivé « consciemment », devenant une sorte d’habitude collective.
Il est légitime, voire nécessaire dans certains cas, de remettre en cause cette « vision techniciste » et sortir de la dette technique mais aussi la dette organisationnelle créée par les outils informatiques.
B. HYPOTHÈSE N°2 – « LE SI EXISTE DANS DES CADRES HUMAINS TRÈS CONTRAINTS. »
La finalité sociale, comme le droit, n’autorisent pas toutes les « formes » d’outils informatiques. Certains de ces outils informatiques peuvent engendrer des rejets sociaux.
La finalité sociale comme le droit sont non seulement légitimes, évoluant au gré de la société (exemple avec la RSE), mais également des phénomènes permanents et coercitifs dans les organisations et leur histoire. Le débat est endogène à toute organisation.
La finalité sociale comme le droit, sont des sources de menaces mais aussi d’opportunités, qui agissent sur le système d’information.
C. HYPOTHÈSE N°3 – « LA DIRECTION DES SI DOIT DÉSORMAIS ÉVOLUER FORTEMENT. »
La Direction des Systèmes d’Information ne doit pas être un « frein » aux métiers – comme c’est trop souvent le cas.
La DSI doit être isomorphe à l’organisation et aux circuits d’information formalisés et non-formalisés.
La DSI ne doit pas être un centre technique de l’information, mais l’appui du centre de pilotage de l’information.
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.
Au-delà, ça pose la question de la frontière entre sciences informatiques et de l'information. Un clavier n'est pas quelque chose de si naturel pour l'écriture, car ça limite le nombre de signes utilisables directement. Mécaniquement : on imagine difficilement un clavier avec des centaines voire des milliers de touches.
J'en rajoute une couche, mais tant pis.
Un exemple qui me tient à cœur: ASCII prévoit ainsi des caractères pas particulièrement spéciaux pour le coup, mais qui n'ont pas de "matérialité" sur un clavier : GROUP / RECORD / UNIT SEPARATOR (29-31). L'intérêt c'était alors de faire la distinction entre ce qui tient des signes d'imprimerie classiques (lisibles, visibles) de ce qui tient des caractères de séparation propre à un système informatique (fin de ligne, de fichier, etc.). J'imagine que je n'apprends rien à personne. Ainsi pas besoin de gérer les séparateurs type tabulation dans le texte, car il y a des séparateurs pour ça (exemple de CSV).
Si les claviers avaient ces touches, le format fréquent des fichiers aurait été peut-être différent. Mais probablement aussi plus simple. L'histoire fourmille de (bons) standards qui n'ont pas ou mal été utilisés, face à des arguments fallacieux (la disposition du clavier en est une).
Enfin pour les langues qui n'utilisent pas un alphabet mais un logogramme (permettant de former des idéogrammes), un clavier est dans toutes les situations, quelque chose de relativement fastidieux. Il faut une combinaison de touches pour former un mot, correspondant donc pour nous à un "caractère"… En soi c'est bien "pire" à retenir et à utiliser que n'importe quelle disposition classique AZERTY / QZERTY face à notre propre langue.
Et donc ? Ils ont arrêté les accents ? Non, ils tapent les touches nécessaires. Incroyable. Il faut taper sur un clavier, c'est exceptionnel.
Leur clavier est Qwerty pour des raisons économiques très largement (rapports francophonie). Pas besoin d'être devin pour imaginer qu'ils utiliseraient un clavier adapté à leur langue s'ils avaient le choix.
J'ai bien compris que la question des accents et de la francophonie hérissent le poil, et que c'est pas la peine d'argumenter : bien, oubliez ma contribution.
Pour la phase douloureuse, je suis ENTIÈREMENT (d'accord et) conscient de la courbe d'apprentissage (moi aussi seul, il m'a fallu 2 bons mois plusieurs heures par jour, pour arriver à un résultat vraiment correct et en écrire sans regarder la doc).
Tout ce que je peux te dire, c'est de t'essayer à OCAML et Haskell avant de continuer, si ce n'est pas le cas. Ce sont tous deux des langages fonctionnels puissants, très puissants et certaines pratiques du développement fonctionnel comme une partie de la gestion des types, sont intégrés à Rust. En testant les deux (dans l'ordre indiqué), j'ai trouvé Rust étonnament beaucoup plus facile, notamment Haskell qui est un langage aux fonctions pures, ce qui est déroutant.
Finalement c'est logique : Rust c'est "rouillé", voire les autres langages, c'est voir les bonnes pratiques qui en ont été extraites.
Autre piège que j'ai personnellement rencontré : le C et l'impératif plus généralement…
1. Trop souvent on peut lire que Rust c'est un C "évolué" - ou alternativement "limité". Personnellement je trouve ça dingue (et faux). Rust a un garbage collector statique, ce qui élimine 99% des "bugs" (oubli, maladresse, etc.) dans la gestion de la mémoire. Juste pour cela, la comparaison ne tient pas. Je ne parle même pas d'une gestion moderne des chaînes de caractères ! De plus il y a considérablement plus d'aspects à prendre en compte avant même d'écrire la première ligne, comme les durées de vie et la gestion des emprunts, ce qui oblige à réfléchir vraiment.
2. Il y a comme tous les langages, souvent plusieurs moyens d'arriver au même résultat mais tous, tant qu'ils compilent, sont bons. La gestion par trait, la composition, renforcent la qualité globale sans qu'on s'en rende compte. Rust est un excellent moyen d'écrire du code à plusieurs. C'est un signe si Microsoft et d'autres, dont l'orientation est à l'opposé de Mozilla, s'intéresse de plus en plus à ce bijou.
A ce sujet, certains commentaires de cet article, me laissent à penser que ces points ont négligés notamment sur la question de la performance et de la robustesse qui sont procurés justement par les qualités intrinsèques du langage. Bref.
Pour la question des durées de vie qui semble empoisonner le langage (au début), n'oublie pas que c'est un prix à payer pour avoir un résultat d'une qualité "minimale" déjà importante. Et c'est une question d'habitude. Tu peux contourner la plupart des explicitations nécessaires en passant par des structures et des énumérations (abuse-en. Si si, encore). Lorsque tu ne peux pas faire autrement, raisonne en terme de "séquences" de traitement (puis en faire une fonction ?) : cela t'évite certains des problèmes de partage mutable et non-mutable, en définissant une clôture ou un bloc, ou simplement repenser ton organisation.
"Dialogue" avec le compilateur. D'ailleurs les bouquins sur le sujet rust-lang pousse à cela. J'ai pas de scruJ'utilise énormément https://play.rust-lang.org/ pour tester des portions, des organisations d'un code plus vaste. C'est rapide et facile. D'ailleurs pas besoin de cargo ou du site : rustc et c'est parti ! Mon environnement de dév. pour des bouts de code, c'est la commande suivante (sans honte) :
Enfin et j'arrête là mon lirisme : pour moi, un développeur contemporain, c'est - au moins - Python + Rust + Common LISP.
* Python par sa grande popularité, sa présence quasi par défaut dans les environnement Linux, sa souplesse et sa rapidité à concevoir des traitements, la clarté du code et sa puissance / richesse dans le traitement moderne des données (via Jupyter ou autre) ;
* Rust car il produit un code compilé ainsi que les qualités évoquées plus haut ;
* Common LISP (je pense notamment à l'implémentation SBCL), parce que c'est LISP, parce que c'est normalisé, parce que tu prends un claque quand tu comprends le vrai sens de "macro", parce que c'est la puissance grammaticale, la facilité de résolution des AST et la beauté des lambdas. Bref CL lorsque tu dois aller vers des aspects de programmation que les deux autres langages ne supportent pas ou mal. Et d'ailleurs que parfois, seul CL supporte (plus de possibilités que Scheme, même si le débat est ouvert à ce propos).
Bref je pourrais passer des heures, j'adore ça et si je peux aider, ce sera avec plaisir :)
Franchement j'ai pas de raison… Je ne l'ai pas fait même pas par flemme, mais parce que j'ai pas mal travaillé dessus en linéaire (sans vraiment de pause dans mes pensées) et comme j'étais seul, ça ne m'est pas venu en réflexe. Au prochain "push", je fais le nécessaire.
Si on commence à devoir changer de disposition clavier pour pouvoir écrire sa conf on est pas sorti d’affaire.
En quoi utiliser un séparateur ou un autre - et offrir la possibilité d'en changer -, a une incidence sur le clavier ?
c’est comme si la configuration de Redis, selon la compilation, pouvait avoir des commentaire avec # par défaut, mais avec | dans d’autres cas, tout ça parce que la personne veut des | parce que c’est plus simple à écrire dans son cas…
Personnellement, j'en serais très heureux si ça pouvait être le cas.
Effectivement, ta pensée était éloignée de ce que j'avais compris. Cependant si tu as une configuration X, un fichier d'entrée Y et que tu t'attends que ça fonctionne - pour Robert ou un autre -, c'est illusoire.
Soit tu ne changes pas la configuration, soit tu la changes et tu adaptes ton entrée à ton changement.
N'est-ce pas comme ça pour tous les logiciels qui existent ?
Exemple : il attend du TOML, tu lui fournis un JSON, ça coince. L'exemple est caricatural mais la logique suivie est la même. Ton programme a son environnement et ses possibilités. Si tu en sors, tu sors du fonctionnement normal et attendu.
D'autant que tu ne compiles pas non plus ton logiciel tous les 4 matins. Tu peux même automatiser ta compilation pour les nouvelles versions, afin de modifier la valeur configurée pour l'adapter à ce qui existe déjà et que ta version soit adaptée à ton usage.
Je suis d'accord. C'est un nouveau projet : l'UTF-8 est LE standard, il convient de l'utiliser le plus possible (tout le temps).
Qu'un programme nécessite des impératifs particuliers dans un environnement complexe (embarqué, industriel, etc.) ou alors pour des questions de compatibilité avec des versions antérieures, ça s'entend.
Je ne suis pas sûr que ça soit pertinent de faire cette comparaison (enfin si, j'en suis sûr mais je suis trop poli pour le dire).
Je parle d'une modification avant compilation, avec d'autres critères à prendre en compte pour que le programme (celui-ci ou un autre) fasse ce que l'on souhaite.
De plus, c'est la modification d'un type char : quelque soit sa valeur, il est toujours de type char… ça ne modifie en RIEN le fonctionnement logique ou interne.
Certes c'est problématique dans ce cas-là. J'en suis conscient. Cependant il y a beaucoup de cas où le support de l'UTF-8 n'est pas un problème.
Par ailleurs, compte tenu de l'organisation du projet, il est très facile de modifier les caractères séparateurs. Peut-être faut-il cependant que j'améliore encore ce point, en passant les caractères séparateurs directement en variable globale dans le fichier de configuration. Ainsi la modification serait unique avant la compilation, et obtenu un programme qui répond à un usage plus limité.
Seulement si vous êtes gentil avec lui et ses frères. Le petit Robert est plus casanier, toujours plongé dans un grand nombre de pages… ;)
Plus sérieusement : oui, avec des modifications, car aujourd'hui l'outil de diffusion des messages porte sur les messages des clients entre eux.
La souscription devrait être modifiée comme suit :
- soit message entre clients ;
- soit le suivi des valeurs (modifiées / ajoutées / supprimées) - ce qui permettrait de créer une instance maîtresse et des instances enfantes.
Pour "clusterister" un gros volume de données entre plusieurs instances, tout dépend du projet et de la formalisation derrière. Je n'ai pas vraiment de réponse. En soi ça me semble tout à fait possible, mais je n'ai pas réfléchi à une mise à mettre en œuvre.
Oui il sera lu, par moi-même et j'espère beaucoup d'autres !, dans le futur. En français, comme des centaines de millions de personnes dans le monde : https://fr.wikipedia.org/wiki/Francophonie
Quelqu'un qui ne parle pas le français fera comme moi quand je lis le commentaire du code source (en mandarin) de ma box 4G chez Bouygues : il utilisera un outil de traduction.
Si l'on tient à rester sur le cadre purement logique, les noms de variables apportent un sens et facilite la compréhension, mais on peut aussi retrouver le fonctionnement avec la grammaire d'un langage.
Je vois que cette question irrite beaucoup dans les commentaires. Je suis (réellement) surpris.
J'attire votre attention que la transposition professionnelle de la thèse n'est pas publique et n'est donc pas présent dans le document (seulement la partie sur le modèle RDF appliquée aux entreprises et l'intérêt du fonctionnel dans le développement moderne).
Sur les structures, il y en a pas mal : les canaux en sont, les clients (stream TCP avec d'autres paramètres), le contexte d'utilisation (qui regroupe l'état du service, du client, les accès mutex, etc.), ainsi que les valeurs.
Chacun a son implémentation propre, avec des traits pour la généricité, notamment pour l'écriture sur le socket du client.
L'ensemble est dans un canevas d'exécution (une fonction, retrouvée lors du traitement d'une commande) qui doit répondre à un type particulier, indépassable.
(Pour le point sur le français, j'ai publié un commentaire précédent sur le sujet)
J'espère ne pas dire de bêtise, mais Memcached ne gère pas des objets complexes, permettant la récursivité. Il gère des données binaires et des flags (il """ne comprend pas""" ce qu'il stocke).
Robert peut être considéré comme un gestionnaire de canaux où chacun gère un arbre, doté d'une profondeur qui peut évoluer sans grande limite, sur des types fixés à l'avance.
J'ai essayé de créer un environnement très favorable à l'ajout de nouvelles commandes (on ajoute une fonction avec deux arguments - permettant d'obtenir le contexte d'exécution et les arguments fournis - avec un retour à destination du client, on compile, c'est prêt).
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.
Certes. L'anglais est une convention. Une convention est par nature, une convention : ce qui est convenu dans un groupe donné. Aucune langue n'est éternelle, sans évolution. Je ne crois pas que l'anglais le soit pour l'informatique car, comme tu le soulignes, l'indien ou le chinois ont un poil plus d'utilisateurs (surtout réunis) dans les informaticiens que ceux du bloc classique occidental dans un proche avenir (si ce n'est pas déjà le cas).
Le débat sur ce point, fait de ma position une position ultra-minoritaire j'en suis conscient. Mais je crois qu'il faut des projets qui ne soit pas nécessairement en anglais "parce que c'est comme ça". Pour moi, fondamentalement, c'est un rapport d'abord à la communauté que l'on créée, où l'on est, où l'on agit.
Pour la lib standard, justement. Combien - je m'inclue dedans - ont passé parfois des heures à comprendre tel ou tel point, en anglais ? Si la réponse est "Google Translate" alors soit, c'est "Google Translate" - mais ce qui est valable anglais -> français est donc valable français -> anglais.
Pour l'utilisateur lambda, la doc et le code en français peut avoir un sens car le français ne se limite pas à la France et est une communauté parmi les plus nombreuses au monde.
Par contre on est d'accord : en soi du code en français, on s'en fiche, d'autant que ce qui compte c'est que la machine comprenne les instructions…
Pour ce qui est de la traduction des « crate » Rust, je ne pense pas que cela rende les choses plus claires :)
Non, et Rust est limité en pouvoir descriptif dans ses concepts. Juste le terme "module" reprend parfois des choses différentes, entre une "caisse", un fichier du projet..
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.
Tu as tout à faire raison, c'est un risque. Mais comme c'est sous-entendu, le risque était soit de faire un rassemblement de projets extérieurs avec des dépendances qui, sérieusement, ne seraient relues (et potentiellement seraient abandonnées), soit le refaire et avoir un projet homogène dans sa maturation. J'ai fait le choix de l’homogénéité.
Sur Hashmap, j'ai pris le choix d'aller vers la simplicité conceptuelle : une paire clé/valeur pour chaque entrée, qui sont rassemblées ensemble. Hashset aurait impliqué de faire un travail supplémentaire, car le hash est sur l'objet stocké et non sur la clé. Hashmap a une gestion des clés par hash.
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.
De fait si l'on prend toutes les attendus du projet (intégrité de l'outil ; support natif ; performance ; simplicité conceptuelle et de maintenance), je trouve que c'est un choix raisonnable.
J'entends parfaitement ce que c'est pas le choix le plus performant (encore que), mais c'est un choix qui ne prend pas que la performance.
Pour la comparaison avec Python, compte tenu que Rust est compilé avec des performances très proches du C, j'ai un doute que l'implémentation soit moins bonne. Pour Go, je sais pas trop.
Tu me mets le doute, je vais regarder et tester ça.
Si je comprends bien c’est à la fois un "pub/sub" et une "base" comme on pourrait en avoir dans redis ?
Oui je crois.
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 ?
Bien sûr. L'actualité n'est sûrement pas clair. Le canal dispose d'une hashmap qui est une valeur comme une autre, de type "objet" (qui contient donc d'autres valeurs). Le chemin correspond à tous les objets à traverser pour atteindre la valeur finale (qui est un des 5 types).
Ce n'est donc pas du tout une base "à plat" mais un arbre de hashmap, dont l'origine est le canal lui-même (j'espère que c'est plus clair ?).
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.
Ce n'est pas pour l’ambiguïté, mais au contraire pour être sûr que le scripteur veux bien l'inconditionnalité (c'est-à-dire que la commande sera toujours exécutée).
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.
Ce qui est déjà pas mal tu ne crois pas ? Beaucoup de choses dans la surface d'attaque ou de problématiques portent sur la question des pointeurs et des débordements.
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.
Je te remercie de ton commentaire, qui me permet d'être, j'espère, plus clair et précis, comme d'argumenter sur le projet.
[^] # Re: Beurk, écoeurant ....
Posté par JulienG . En réponse au journal Rust et Python associés grâce au C. Évalué à 3.
Je veux pas dire de bêtise (vraiment, je fais de mémoire), mais finalement LUA c'est un simili-code C qui est compilé en JIT comme ce serait avec GCC. Donc oui, question efficacité pure, ce serait bien mieux que Python (bytecode oblige).
Question lib dispo, Python gagne j'imagine.
Exactement, c'était mon idée !
[^] # Re: Beurk, écoeurant ....
Posté par JulienG . En réponse au journal Rust et Python associés grâce au C. Évalué à 4.
?
[^] # Re: Beurk, écoeurant ....
Posté par JulienG . En réponse au journal Rust et Python associés grâce au C. Évalué à 3.
Cf. l'extrait de l'article sur RedHat. NumPy est l'exemple parfait d'un intérêt à avoir autre chose que du pur Python. Rust permet d'avoir un code conforme au C. La transition est vite faite.
La possibilité de le faire ne veut pas dire toujours le faire, ni que ça ait un sens tout le temps.
En ayant la possibilité de renvoyer vers Rust une fonction générée lors de l'exécution, lambda ou autre, ça peut être sympa de profiter dans Rust d'une composition issue des bibliothèques de Python. Tu profites d'un code en Python en façade, avec du Rust derrière.
Autre point, Rust agit avec du C sans difficulté, il suffit de prendre les bonnes précautions.
Peux-tu m'indiquer plus précisément l'antinomie que tu y vois ?
[^] # Re: Formatage automatique
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 1.
Peut-être parce que l'informatique ce n'est pas qu'une unique question de logiciels justement ? Mais d'infrastructure, d'organisation, etc. - et que c'est l'architecture globale autour d'un besoin et du possible qui importe.
Un exemple qui me vient : la mise en place d'un bastion d'administration (je pense par exemple aux contraintes des normes voulues dans les OIV… mais ça semble se généraliser grâce à l'action de l'ANSSI) dans une "vieille" architecture, figée et difficile à bouger, comme on en trouve beaucoup dans les PME françaises : l'éditeur peut ne plus exister ; les sources non-documentées ; les personnes qui ont pensé certaines parties ou certaines organisations des traitements ne sont plus là: ce qu'elles ont pu faire avait peut-être du sens à leur époque, …
Face au décideur, bon courage si tu penses seulement "logiciel" comme un tout unique et cohérent dans ta réponse, qui évolue forcément bien et uniformément.
Car il y a le logiciel, mais aussi le réseau à gérer. Les traitements métiers, qui ont pu évolué, qui peuvent être en partie analogiques voire physiques. Du SCADA. Certains applicatifs ne supportent pas tel ou tel protocole (pas de TLS/SSL, etc.). Il faut des proxy partout, des routes à ne plus en finir, être capable de faire dialoguer des choses qui n'ont pas été forcément prévues pour communiquer vers l'extérieur.
Rajouter les contraintes de redondance, de sécurité, logger pour motifs légaux. C'est une réalité. Pas juste un discours de "marketeux". Et avant de parler de la seule performance, on parle de viabilité, d'intérêts, de conditions préalables.
Bref tu te retrouves avec une évolution "organique" d'un logiciel ou d'un ensemble applicatif, qui peut être monolithique ou pas, avec des blocs qui ont été faits à des périodes différentes, des besoins différents - dont un contexte qui évolue.
Tu pars du principe que forcément personne ne remet en question une "mauvaise" architecture. Je ne crois pas que ça soit blanc ou noir. Tu peux être conscient d'une situation et devoir gérer une basse réalité qui soit complexe à gérer et faire évoluer.
+1 : un "cache" (amélioré) peut servir aussi à vérifier les droits, servir d'intermédiation au sens large, accélérer un accès, etc. Ou comme indiqué juste avant, servir d'agent nécessaire pour la mise en place d'un bastion d'administration qui ceinture un applicatif pas nécessaire sûr ou éditable, pour faire remonter des informations sur le fonctionnement de l'ensemble.
Voire dans certains cas, c'est même plus ou moins lui qui sera le co-pilote, si tu as du batch processing qui peut planter, se séquencer sans lien entre les opérations, etc. Le cache devient la clé de voûte, évolue et sert à maintenir des connexions à des bases de données, à alerter sur une situation anormale autant qu'à faire réellement du cache de requêtes.
Oui, mille fois oui.
[^] # Re: Formatage automatique
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 2.
[ante scriptum : mon dernier commentaire]
En faisant court : tu as défini un périmètre, mais c'est une des visions qui existent du logiciel, propre à l'ingénierie informatique mais certainement pas à "l'informatique" dans toutes ses ramifications et branches. Encore moins de ce qui est attendu aujourd'hui dans les organisations. J'insiste là-dessus.
Amha, ça mérite d'avoir un débat plus large, de qui (me) semble intéressant sur la définition finalement, de ce que c'est le développement et son attendu. Mon propos n'est pas de dire que tu as tort (tu n'as pas tort), mais que ta position ne me semble pas tenir lieu d'une généralité.
En faisant long : Si tu ne veux pas bouger de ton périmètre alors soit, mais ne me dit pas que je cherche "par tous les moyens" de mon côté. Que tu déjuges ou déconsidères un argument, ne le rend pas inopérant pour autant, parce que tu restes sur le pas de ta porte.
Le projet que j'ai soumis est "parfaitement imparfait" : une proposition sur des travaux perso., toujours en cours pour la meilleure approche.
Sur la question de l'orientation attendue sur la performance, le sujet a été débattu dès 1958/59, où les travaux plus universitaires ont accentué leur séparation avec l'ingénierie informatique pure émergente. L'histoire est connue :
- la branche "proche système" (au démarrage impérative, avec Fortran, C, etc.) ;
- (vs) la branche "abstractive" (Lisp et dérivés, les AST, le fonctionnel).
… Entre ceux qui vont exploiter complètement la puissance de calcul de la machine (qui iront très vite dans les entreprises, désireuses d'investir à moindre coût dans une informatisation extrêmement coûteuse), et ceux qui en veulent d'abord un usage généraliste, une "intelligence artificielle" - nb : le terme a l'époque porte sur les systèmes expert, la faculté de décision et de raisonnement pour une machine ; rien à avoir avec notre acceptation moderne : on est alors sur des systèmes de résolution d'assertions.
Notre débat est une ramification grossière de ces deux visions, qui se sont affrontées, avant de devenir plus complémentaires et de concert.
On avait encore à l'époque une grande diversité d'architectures matérielles et parfois, même pas de distinction dans les types de "mémoire" (je pense aux premières machines LISP, avec quelques parallèles que l'on peut faire avec l'approche choisie par Intel sur Optane Memory).
Avec en toile de fonds, la prise de possession par les sciences de gestion d'une partie des sciences informatiques avant qu'elles ne deviennent, au sein des organisations durant le milieu / fin des années 70, une entité de recherche et d'application indépendante.
Dit autrement : le logiciel est bien plus que qu'un assemblage applicatif, de scripts ou de codes divers. Il n'est pas éthéré et vient dans un SI qui est l'organisation elle-même. Il répond à un besoin (métier) et n'y a aucun autre intérêt, aucun but, aucun moyen à dépenser qui n'y soit pas rattaché. L'optimum d'un traitement strictement machine dont tu parles, était vrai il y a longtemps, où l'octet coûtait cher et les machines """rares""" (fin des années 90/début 2000). Cela reste largement enseigné dans les études informatiques, notamment celles où l'ingénierie est reine. Cependant ce n'est pas forcément une attente économique.
Désormais l'optimum est à chercher entre le coût de développement et de maintenance (ton salaire et celui de tes homologues n'est pas gratuit : optimiser un programme n'est pas toujours financièrement intéressant) ; la rentabilité d'un processus organisationnel qui l'utilisera (un logiciel très performant mais que personne ne maîtrise est détourné, abandonné ou pire pas maintenu par de futures équipes) ; la capacité à en extraire de l'information utile et à se justifier (audit, suivi et maîtrise, etc.) ; dernièrement les questions de sécurité et de sûreté, comme de la tolérance du SI aux pannes et à la gestion de la redondance.
Perdre 5% ou 10% de performance d'un logiciel n'est pas toujours un drame, même en augmentant les charges d'infras derrière. Parce que tes choix comme DSI ou proche de la DSI, sont contraints par des aspects sociaux, légaux, métiers - tout ce que tu veux.
Je ne parle même pas de la dette technique, qui pour le coup, parfois, oblige à des recherches très pointues sur l'optimisation "du 2Go/s pour un JSON" parce que l'architecture globale est déficiente, ou simplement n'est plus adaptée, ou face à un soucis hors norme de masse (tout le monde n'est pas Netflix, Facebook… !). Dans la quasi-totalité des organisations, on cherche donc moins à dépasser la dette que la contourner à moindre coût (souvent, cela revient à ne pas arrêter la production, ni modifier trop en profondeur un équilibre logiciel fragile, non-documenté, bloquant des refontes plus larges). Là effectivement, l'impératif d'efficacité peut se faire jour avec force. La fréquence de cette recherche d'efficacité en fait une généralité, mais pas un fait systématique et encore moins un but. Je tente de ne pas mélanger la cause et la conséquence.
Pour la maîtrise de l'architecture, encore faut-il avoir donc pensé aux points de la scalabilité et de la redondance - et là où nous pouvons nous rejoindre, c'est que Robert n'a certainement pas atteint l'objectif (mais après tout, c'est une proposition initiale, personne n'est contraint d'en faire usage…).
Ce n'est pas un effet de style si on est passé d'une qualification de "système informatique" (et donc de direction informatique) à "système d'information" (et donc de "direction des systèmes d'information"). Il y a une logique derrière. Personnellement ça ne me dérange pas qu'on considère que l'informatique n'est qu'elle-même, un concept un peu "indépassable", mais c'est un signe si les "cellules de gestion de projets" et autres modalités d'organisations se multiplient dans les DSI pour modifier les habitudes et les approches.
Je n'ai rien, absolument rien à te vendre : je ne te rapporte pas un propos commercial, je ne te vends pas du rêve ; je te donne mon opinion de ce que j'ai pu trouvé après des heures à la bibliothèque universitaire ou en entretien. Tu ne prendras certainement pas les arguments, mais toi comme moi, nous nous ne nous adressons pas à l'autre mais aux lecteurs qui nous ont le mérite de nous lire.
Et je t'assure, évoquer les sciences de gestion dans les années 70 ou l'intérêt d'un travail ontologique au sein d'une organisation pour piloter le schéma de données et le développement applicatif d'une DSI n'a rien de bandant ! Au contraire, ça provoque le rejet et l'impatience (voire une pointe de mépris…).
Anecdote : lors de ma soutenance, mon jury me dit "propos passionnant, innovant [en réalité pas tant que ça, je fais une synthèse de travaux d'autres horizons pas encore rapprochés]. Comment voulez-vous vendre ça à une entreprise ?!" -> Je ne peux pas. L'historique culturel est en défaveur de l'approche "organisationnelle" des SI… mais des signes commencent à émerger.
Illustrons le propos. Un exemple que je suis attentivement : la ré-émergence du "no-/low-code", les services Amazon Lambda (idem chez Microsoft, IBM, Google… ces 3 dernières années), l'approche "fonctionnelle" sur tout un tas de langages très différents et une logique événementielle. Le schéma global de ces services :
1. un événement quelconque
2. un filtre
3. une fonction déclenchée, éventuellement avec la notion de grappes de travail derrière
4. une réponse renvoyée et/ou stockée.
Plutôt que d'agir sur l'efficacité d'une fonction, on dimensionne sa réplication (maîtrise des coûts : arbitrage sur le temps de calcul global plutôt que l'efficacité unitaire). L'orchestration des fonctions entre elles, créée l'applicatif. En gros tu as un stock de fonctions (ou de fonctionnalités, c'est-à-dire de sous-applicatifs), qui tu lies entre elles, de manière arbitraire, possiblement sans ligne de code pour l'utilisateur final.
Présentation ici (la vidéo explicite bien) :
https://aws.amazon.com/fr/lambda/
Ces services cherchent justement à minimiser les coûts globaux pour les clients. Ils reprennent de vieilles théories, qui ont facilement 30 ans, avec les systèmes experts, qui eux-même n'avaient aucunement besoin de personnes ayant des talents de codeurs pour faire des logiciels (je pense à CLips par exemple*), en l'adaptant à ce qui est possible aujourd'hui.
Réellement, ce n'est ni plus ni moins que la ré-invention un poil modernisé des systèmes experts.
(* : L'expression choisie était celle des maths en inspiration, car il n'y avait pas guère de possibilités d'une interface évoluée. Ce n'est plus le cas aujourd'hui et je serais heureux le jour où une personne qui n'a pas de compétence informatique, sera capable de faire un logiciel convenable, avec un code généré propre et relativement bien pensé, parce qu'il se sera concentré sur les besoins de son métier et pas plus. On y arrive, doucement.)
Le but est de moins chercher cette partie d'optimisation purement mixte logicielle/matérielle, mais d'aller vers une meilleure applicabilité du logiciel au global et pour répondre aux exigences des procédures. C'est le sens de l'histoire : sinon autant rester à l'assembleur (zéro abstraction, tu n'auras pas mieux en terme de performance).
Deux des exemples qui allient beaucoup de facettes que j'évoque :
- le projet européen SPECIAL (l'application d'une politique de sécurité à maillage très fin sur n'importe quel d'objets)
https://www.specialprivacy.eu/
- la thèse doctorale de Jérémy Lhez sur le "Filtrage, stockage et raisonnement sur de grands volumes de triplets RDF ordonnancés"
https://pastel.archives-ouvertes.fr/tel-02084022/document
Comme je l'ai indiqué auparavant dans les commentaires, c'est bien le métier qui fait l'outil et pas l'outil qui fait le métier. Il doit donc être efficient et après, éventuellement, performant.
Les grandes boîtes ont un temps d'avance du fait de leurs moyens justement, et elles ne sont déjà plus sur la question de la numérisation (terminée) mais de l'abstraction de leurs outils numériques (SAAS, "cloudification" et autres) :
- elles ne veulent plus piloter du code mais une interface et un traitement logique (interface + traitement = logiciel) ;
- elles veulent davantage de développements rapides (c-à-d écrits vite) et efficients ;
- elles ne veulent plus gérer de la dette technique ni de contraintes organisationnelles trop fortes à cause de problématiques informatiques.
L'efficacité (en octets traités/seconde), les profils techniques pointus, arrivent après, en support pour rester dans du temps de calcul raisonnable mais pas en chef orchestre ni en finalité (exemple des "product owners" qui ne sont plus plus des pilotes techniques et couvres d'abord les attentes fonctionnels).
Pour le reste :
- tu es probablement un très bon programmeur et je ne doute pas une seconde que tu aies une meilleure connaissance que moi, notamment pour la gestion fine stack ou heap. Pour Robert, ma priorité est davantage la mise en grappe du processus que l'usage de la mémoire, tout en continuant à assurer la possibilité de soutenir un modèle RDF ;
- tu as entièrement raison un protocole binaire est plus efficace qu'un protocole qui se lit humainement. Mais j'ai préféré qu'il soit lisible par le plus grand nombre (dans l'espace francophone). Sur le sujet nos positions sont irrésolubles.
Enfin et pour conclure là, les hypothèses sur lesquelles j'ai travaillé ces dernières années et qui me motivent encore aujourd'hui. Elles n'ont aucune force de lois. Je les donne ici, pour parfaire le contexte de mon propos.
A. HYPOTHÈSE N°1 – « IL EXISTE UN ‘AUTRE CHEMIN’ POUR LES SI. »
B. HYPOTHÈSE N°2 – « LE SI EXISTE DANS DES CADRES HUMAINS TRÈS CONTRAINTS. »
C. HYPOTHÈSE N°3 – « LA DIRECTION DES SI DOIT DÉSORMAIS ÉVOLUER FORTEMENT. »
[^] # Re: Conflit sur le nom «Robert»
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 1.
J'y réfléchis… Cerise serait pas mal mais Google me retourne le résultat d'un éditeur de base de données (Cerise Assemple).
"Bertro" ? Moche mais sans aucune autre occurrence semble t-il ?
[^] # 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.
[^] # Re: Mes deux centimes de vieux francs
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 2.
Effectivement.
Au-delà, ça pose la question de la frontière entre sciences informatiques et de l'information. Un clavier n'est pas quelque chose de si naturel pour l'écriture, car ça limite le nombre de signes utilisables directement. Mécaniquement : on imagine difficilement un clavier avec des centaines voire des milliers de touches.
J'en rajoute une couche, mais tant pis.
Un exemple qui me tient à cœur: ASCII prévoit ainsi des caractères pas particulièrement spéciaux pour le coup, mais qui n'ont pas de "matérialité" sur un clavier : GROUP / RECORD / UNIT SEPARATOR (29-31). L'intérêt c'était alors de faire la distinction entre ce qui tient des signes d'imprimerie classiques (lisibles, visibles) de ce qui tient des caractères de séparation propre à un système informatique (fin de ligne, de fichier, etc.). J'imagine que je n'apprends rien à personne. Ainsi pas besoin de gérer les séparateurs type tabulation dans le texte, car il y a des séparateurs pour ça (exemple de CSV).
Si les claviers avaient ces touches, le format fréquent des fichiers aurait été peut-être différent. Mais probablement aussi plus simple. L'histoire fourmille de (bons) standards qui n'ont pas ou mal été utilisés, face à des arguments fallacieux (la disposition du clavier en est une).
Enfin pour les langues qui n'utilisent pas un alphabet mais un logogramme (permettant de former des idéogrammes), un clavier est dans toutes les situations, quelque chose de relativement fastidieux. Il faut une combinaison de touches pour former un mot, correspondant donc pour nous à un "caractère"… En soi c'est bien "pire" à retenir et à utiliser que n'importe quelle disposition classique AZERTY / QZERTY face à notre propre langue.
[^] # Re: Mes deux centimes de vieux francs
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 0.
Et donc ? Ils ont arrêté les accents ? Non, ils tapent les touches nécessaires. Incroyable. Il faut taper sur un clavier, c'est exceptionnel.
Leur clavier est Qwerty pour des raisons économiques très largement (rapports francophonie). Pas besoin d'être devin pour imaginer qu'ils utiliseraient un clavier adapté à leur langue s'ils avaient le choix.
J'ai bien compris que la question des accents et de la francophonie hérissent le poil, et que c'est pas la peine d'argumenter : bien, oubliez ma contribution.
Franchement je regrette !
[^] # Re: Formatage automatique
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 3.
Pour la phase douloureuse, je suis ENTIÈREMENT (d'accord et) conscient de la courbe d'apprentissage (moi aussi seul, il m'a fallu 2 bons mois plusieurs heures par jour, pour arriver à un résultat vraiment correct et en écrire sans regarder la doc).
Tout ce que je peux te dire, c'est de t'essayer à OCAML et Haskell avant de continuer, si ce n'est pas le cas. Ce sont tous deux des langages fonctionnels puissants, très puissants et certaines pratiques du développement fonctionnel comme une partie de la gestion des types, sont intégrés à Rust. En testant les deux (dans l'ordre indiqué), j'ai trouvé Rust étonnament beaucoup plus facile, notamment Haskell qui est un langage aux fonctions pures, ce qui est déroutant.
Finalement c'est logique : Rust c'est "rouillé", voire les autres langages, c'est voir les bonnes pratiques qui en ont été extraites.
Autre piège que j'ai personnellement rencontré : le C et l'impératif plus généralement…
1. Trop souvent on peut lire que Rust c'est un C "évolué" - ou alternativement "limité". Personnellement je trouve ça dingue (et faux). Rust a un garbage collector statique, ce qui élimine 99% des "bugs" (oubli, maladresse, etc.) dans la gestion de la mémoire. Juste pour cela, la comparaison ne tient pas. Je ne parle même pas d'une gestion moderne des chaînes de caractères ! De plus il y a considérablement plus d'aspects à prendre en compte avant même d'écrire la première ligne, comme les durées de vie et la gestion des emprunts, ce qui oblige à réfléchir vraiment.
2. Il y a comme tous les langages, souvent plusieurs moyens d'arriver au même résultat mais tous, tant qu'ils compilent, sont bons. La gestion par trait, la composition, renforcent la qualité globale sans qu'on s'en rende compte. Rust est un excellent moyen d'écrire du code à plusieurs. C'est un signe si Microsoft et d'autres, dont l'orientation est à l'opposé de Mozilla, s'intéresse de plus en plus à ce bijou.
A ce sujet, certains commentaires de cet article, me laissent à penser que ces points ont négligés notamment sur la question de la performance et de la robustesse qui sont procurés justement par les qualités intrinsèques du langage. Bref.
Pour la question des durées de vie qui semble empoisonner le langage (au début), n'oublie pas que c'est un prix à payer pour avoir un résultat d'une qualité "minimale" déjà importante. Et c'est une question d'habitude. Tu peux contourner la plupart des explicitations nécessaires en passant par des structures et des énumérations (abuse-en. Si si, encore). Lorsque tu ne peux pas faire autrement, raisonne en terme de "séquences" de traitement (puis en faire une fonction ?) : cela t'évite certains des problèmes de partage mutable et non-mutable, en définissant une clôture ou un bloc, ou simplement repenser ton organisation.
"Dialogue" avec le compilateur. D'ailleurs les bouquins sur le sujet rust-lang pousse à cela. J'ai pas de scruJ'utilise énormément https://play.rust-lang.org/ pour tester des portions, des organisations d'un code plus vaste. C'est rapide et facile. D'ailleurs pas besoin de
cargoou du site :rustcet c'est parti ! Mon environnement de dév. pour des bouts de code, c'est la commande suivante (sans honte) :Enfin et j'arrête là mon lirisme : pour moi, un développeur contemporain, c'est - au moins - Python + Rust + Common LISP.
* Python par sa grande popularité, sa présence quasi par défaut dans les environnement Linux, sa souplesse et sa rapidité à concevoir des traitements, la clarté du code et sa puissance / richesse dans le traitement moderne des données (via Jupyter ou autre) ;
* Rust car il produit un code compilé ainsi que les qualités évoquées plus haut ;
* Common LISP (je pense notamment à l'implémentation SBCL), parce que c'est LISP, parce que c'est normalisé, parce que tu prends un claque quand tu comprends le vrai sens de "macro", parce que c'est la puissance grammaticale, la facilité de résolution des AST et la beauté des lambdas. Bref CL lorsque tu dois aller vers des aspects de programmation que les deux autres langages ne supportent pas ou mal. Et d'ailleurs que parfois, seul CL supporte (plus de possibilités que Scheme, même si le débat est ouvert à ce propos).
Bref je pourrais passer des heures, j'adore ça et si je peux aider, ce sera avec plaisir :)
[^] # Re: Formatage automatique
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 3.
Franchement j'ai pas de raison… Je ne l'ai pas fait même pas par flemme, mais parce que j'ai pas mal travaillé dessus en linéaire (sans vraiment de pause dans mes pensées) et comme j'étais seul, ça ne m'est pas venu en réflexe. Au prochain "push", je fais le nécessaire.
[^] # Re: Mes deux centimes de vieux francs
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à -1.
En quoi utiliser un séparateur ou un autre - et offrir la possibilité d'en changer -, a une incidence sur le clavier ?
Personnellement, j'en serais très heureux si ça pouvait être le cas.
[^] # Re: Mes deux centimes de vieux francs
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à -2. Dernière modification le 21 avril 2020 à 16:34.
Effectivement, ta pensée était éloignée de ce que j'avais compris. Cependant si tu as une configuration X, un fichier d'entrée Y et que tu t'attends que ça fonctionne - pour Robert ou un autre -, c'est illusoire.
Soit tu ne changes pas la configuration, soit tu la changes et tu adaptes ton entrée à ton changement.
N'est-ce pas comme ça pour tous les logiciels qui existent ?
Exemple : il attend du TOML, tu lui fournis un JSON, ça coince. L'exemple est caricatural mais la logique suivie est la même. Ton programme a son environnement et ses possibilités. Si tu en sors, tu sors du fonctionnement normal et attendu.
D'autant que tu ne compiles pas non plus ton logiciel tous les 4 matins. Tu peux même automatiser ta compilation pour les nouvelles versions, afin de modifier la valeur configurée pour l'adapter à ce qui existe déjà et que ta version soit adaptée à ton usage.
Bref à mon sens, ça reste hors de propos.
[^] # Re: Mes deux centimes de vieux francs
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 3.
Je suis d'accord. C'est un nouveau projet : l'UTF-8 est LE standard, il convient de l'utiliser le plus possible (tout le temps).
Qu'un programme nécessite des impératifs particuliers dans un environnement complexe (embarqué, industriel, etc.) ou alors pour des questions de compatibilité avec des versions antérieures, ça s'entend.
Mais là… ? Je suis perplexe.
[^] # Re: Mes deux centimes de vieux francs
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 1.
Je ne suis pas sûr que ça soit pertinent de faire cette comparaison (enfin si, j'en suis sûr mais je suis trop poli pour le dire).
Je parle d'une modification avant compilation, avec d'autres critères à prendre en compte pour que le programme (celui-ci ou un autre) fasse ce que l'on souhaite.
De plus, c'est la modification d'un type
char: quelque soit sa valeur, il est toujours de typechar… ça ne modifie en RIEN le fonctionnement logique ou interne.[^] # Re: Mes deux centimes de vieux francs
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 1.
Certes c'est problématique dans ce cas-là. J'en suis conscient. Cependant il y a beaucoup de cas où le support de l'UTF-8 n'est pas un problème.
Par ailleurs, compte tenu de l'organisation du projet, il est très facile de modifier les caractères séparateurs. Peut-être faut-il cependant que j'améliore encore ce point, en passant les caractères séparateurs directement en variable globale dans le fichier de configuration. Ainsi la modification serait unique avant la compilation, et obtenu un programme qui répond à un usage plus limité.
Merci de votre retour.
[^] # Re: Hautement escaladable?
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 3.
Seulement si vous êtes gentil avec lui et ses frères. Le petit Robert est plus casanier, toujours plongé dans un grand nombre de pages… ;)
Plus sérieusement : oui, avec des modifications, car aujourd'hui l'outil de diffusion des messages porte sur les messages des clients entre eux.
La souscription devrait être modifiée comme suit :
- soit message entre clients ;
- soit le suivi des valeurs (modifiées / ajoutées / supprimées) - ce qui permettrait de créer une instance maîtresse et des instances enfantes.
Pour "clusterister" un gros volume de données entre plusieurs instances, tout dépend du projet et de la formalisation derrière. Je n'ai pas vraiment de réponse. En soi ça me semble tout à fait possible, mais je n'ai pas réfléchi à une mise à mettre en œuvre.
[^] # Re: Conflit sur le nom «Robert»
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 1.
Heureusement nous ne sommes pas au même niveau de visibilité (loin, très très loin), aussi je doute leur faire de l'ombre :)
Il y a une indication en début d'article sur ce sujet.
[^] # Re: Mes deux centimes de vieux francs
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 4.
Oui il sera lu, par moi-même et j'espère beaucoup d'autres !, dans le futur. En français, comme des centaines de millions de personnes dans le monde :
https://fr.wikipedia.org/wiki/Francophonie
Quelqu'un qui ne parle pas le français fera comme moi quand je lis le commentaire du code source (en mandarin) de ma box 4G chez Bouygues : il utilisera un outil de traduction.
Si l'on tient à rester sur le cadre purement logique, les noms de variables apportent un sens et facilite la compréhension, mais on peut aussi retrouver le fonctionnement avec la grammaire d'un langage.
Je vois que cette question irrite beaucoup dans les commentaires. Je suis (réellement) surpris.
[^] # Re: Supports téléchargeables ?
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 4.
Voici un lien pour télécharger directement le PDF :
https://drive.google.com/file/d/1_YyU2jGJn4-4Iu8c25n1VeSU0jRcwgYx/view?usp=sharing
J'attire votre attention que la transposition professionnelle de la thèse n'est pas publique et n'est donc pas présent dans le document (seulement la partie sur le modèle RDF appliquée aux entreprises et l'intérêt du fonctionnel dans le développement moderne).
[^] # Re: Comparaison ?
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 3.
Je regarde pour faire un exemple d'usage.
[^] # Re: Mes deux centimes de vieux francs
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 3.
Sur les structures, il y en a pas mal : les canaux en sont, les clients (stream TCP avec d'autres paramètres), le contexte d'utilisation (qui regroupe l'état du service, du client, les accès mutex, etc.), ainsi que les valeurs.
Chacun a son implémentation propre, avec des traits pour la généricité, notamment pour l'écriture sur le socket du client.
L'ensemble est dans un canevas d'exécution (une fonction, retrouvée lors du traitement d'une commande) qui doit répondre à un type particulier, indépassable.
[^] # Re: lapin compris
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 2.
Non malheureusement, je n'ai aucun comparatif à te fournir. J'espère pouvoir le faire très bientôt.
[^] # Re: Comparaison ?
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 2.
(Pour le point sur le français, j'ai publié un commentaire précédent sur le sujet)
J'espère ne pas dire de bêtise, mais Memcached ne gère pas des objets complexes, permettant la récursivité. Il gère des données binaires et des flags (il """ne comprend pas""" ce qu'il stocke).
Robert peut être considéré comme un gestionnaire de canaux où chacun gère un arbre, doté d'une profondeur qui peut évoluer sans grande limite, sur des types fixés à l'avance.
J'ai essayé de créer un environnement très favorable à l'ajout de nouvelles commandes (on ajoute une fonction avec deux arguments - permettant d'obtenir le contexte d'exécution et les arguments fournis - avec un retour à destination du client, on compile, c'est prêt).
[^] # Re: Mes deux centimes de vieux francs
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 10.
Merci !
Certes. L'anglais est une convention. Une convention est par nature, une convention : ce qui est convenu dans un groupe donné. Aucune langue n'est éternelle, sans évolution. Je ne crois pas que l'anglais le soit pour l'informatique car, comme tu le soulignes, l'indien ou le chinois ont un poil plus d'utilisateurs (surtout réunis) dans les informaticiens que ceux du bloc classique occidental dans un proche avenir (si ce n'est pas déjà le cas).
Le débat sur ce point, fait de ma position une position ultra-minoritaire j'en suis conscient. Mais je crois qu'il faut des projets qui ne soit pas nécessairement en anglais "parce que c'est comme ça". Pour moi, fondamentalement, c'est un rapport d'abord à la communauté que l'on créée, où l'on est, où l'on agit.
Pour la lib standard, justement. Combien - je m'inclue dedans - ont passé parfois des heures à comprendre tel ou tel point, en anglais ? Si la réponse est "Google Translate" alors soit, c'est "Google Translate" - mais ce qui est valable anglais -> français est donc valable français -> anglais.
Pour l'utilisateur lambda, la doc et le code en français peut avoir un sens car le français ne se limite pas à la France et est une communauté parmi les plus nombreuses au monde.
Par contre on est d'accord : en soi du code en français, on s'en fiche, d'autant que ce qui compte c'est que la machine comprenne les instructions…
Non, et Rust est limité en pouvoir descriptif dans ses concepts. Juste le terme "module" reprend parfois des choses différentes, entre une "caisse", un fichier du projet..
Tu as tout à faire raison, c'est un risque. Mais comme c'est sous-entendu, le risque était soit de faire un rassemblement de projets extérieurs avec des dépendances qui, sérieusement, ne seraient relues (et potentiellement seraient abandonnées), soit le refaire et avoir un projet homogène dans sa maturation. J'ai fait le choix de l’homogénéité.
Sur Hashmap, j'ai pris le choix d'aller vers la simplicité conceptuelle : une paire clé/valeur pour chaque entrée, qui sont rassemblées ensemble. Hashset aurait impliqué de faire un travail supplémentaire, car le hash est sur l'objet stocké et non sur la clé. Hashmap a une gestion des clés par hash.
De fait si l'on prend toutes les attendus du projet (intégrité de l'outil ; support natif ; performance ; simplicité conceptuelle et de maintenance), je trouve que c'est un choix raisonnable.
J'entends parfaitement ce que c'est pas le choix le plus performant (encore que), mais c'est un choix qui ne prend pas que la performance.
Pour la comparaison avec Python, compte tenu que Rust est compilé avec des performances très proches du C, j'ai un doute que l'implémentation soit moins bonne. Pour Go, je sais pas trop.
Tu me mets le doute, je vais regarder et tester ça.
Oui je crois.
Bien sûr. L'actualité n'est sûrement pas clair. Le canal dispose d'une hashmap qui est une valeur comme une autre, de type "objet" (qui contient donc d'autres valeurs). Le chemin correspond à tous les objets à traverser pour atteindre la valeur finale (qui est un des 5 types).
Ce n'est donc pas du tout une base "à plat" mais un arbre de hashmap, dont l'origine est le canal lui-même (j'espère que c'est plus clair ?).
Ce n'est pas pour l’ambiguïté, mais au contraire pour être sûr que le scripteur veux bien l'inconditionnalité (c'est-à-dire que la commande sera toujours exécutée).
Ce qui est déjà pas mal tu ne crois pas ? Beaucoup de choses dans la surface d'attaque ou de problématiques portent sur la question des pointeurs et des débordements.
Je te remercie de ton commentaire, qui me permet d'être, j'espère, plus clair et précis, comme d'argumenter sur le projet.