Dans un monde parfait oui le versionnement suffirait, mais personne n'est capable de garantir qu'un changement ne va pas casser une compatibilité. Donc non changer une micro n'est jamais anodin pour un projet.
De même pour la stabilité des API l'esprit humain n'est pas capable de lire l'avenir donc tu n'a aucune garanti que l'API que tu décris est stable ou non. Ce qui tiens un peu mieux que les autres c'est les API qui font le minimum de choses.
En résumé: Les dépendances ont toujours été un problème, il va croissant avec les process généralisés ces 10 dernières années (totalement sortis de leur contexte initial, il faut le dire). Et en prime, aucun langage moderne ne sait plus s'en passer! De quoi expliquer le problème posé, certes, mais de là à le justifier…
J'ai rien compris… Pour la première partie je sais pas trop ce que tu veux dire. Pour la seconde, euh… Tu connais beaucoup de logiciels en C qui utilisent que la libc (qui ne permet pas de créer de thread) ? Ou qui n'utilisent que la libc + les appels système (ça te permet d'avoir des threads) ?
La gestion des dépendances est bien plus complexe que ce que tu semble croire. Beaucoup plus complexe.
Il y a généralement beaucoup de conflit entre des besoins différents par des gens différents.
le développeur
Son cheval de bataille c'est les fonctionnalités (c'est ce que les utilisateurs demandent).
C'est celui qui code l'appli. Il a un besoin primordial : gérer les dépendances en dehors du système. Il doit pouvoir avoir différentes versions d'une même bibliothèque sans détruire son système y compris un build de la version pas encore sorti.
Ensuite il a des besoins: comme l'envi de ne pas avoir à supporter des versions de dépendance toujours plus exotiques, ne pas être contraint par les cycles de vie de chaque SE et distributions, ne pas empaqueter des millions de fois son logiciel,…
opérationnel/admin sys
Lui quand on lui parle fonctionnalités, il voit nouveaux bugs.
Son besoin primordial c'est que les logiciels fonctionnent bien sur son système et pour ça il faut que le logiciel se plie totalement à son système. Donc utilise le système de packaging qui va bien, les dépendances du système uniquement, si vraiment une dépendance n'existe pas sur le système (pourquoi diable être allé chercher cette obscure dépendance ?) la packager séparément, etc
(évidemment j'exagère)
Les 2 points de vues ne sont pas réconciliables ils sont opposés. Le seul endroit où ça peut fonctionner c'est dans le cadre du devops où il n'y a qu'une seule cible de déploiement et les ops et les dev discutent. Aucun langage n'a résolu cette problématique, absolument aucun. Ni les vieux comme C ni les plus jeunes comme rust ou julia. Ceux qui te semblent avoir réussi ont juste privilégiés ton point de vue.
J'entends aussi (concernant le choix nodejs) c'est le même langage que le front : c'est faux !!!
En fait tu te concentre sur la technique, mais c'est pas le plus important là. Tu peux partager du code métier entre ton front et ton back et ça peut être très utile. Il peut facilement arriver qu'une logique implémenter coté client soit finalement plus utile dans le serveur et vice et versa.
Ça n'est pas compliqué d'avoir de la logique métier qui ne soit pas adhérente à ton framework (ça a aussi pleins de bonnes propriétés en particulier pour les tests) et ça te donne beaucoup de flexibilités d'évolutions.
Il n'a plus la hype, mais non il est encore très bien. Dango est une solution complète qui vient avec une opinion. Il t'expliquer comment accéder à ta base de données, comment faire de l'authentification, etc. Flask et les autres microframworks sont beaucoup plus petits, ils font donc bien moins de choses et on leur ajoute des plugins du coup.
Si ton but est de recréer un site web complet "classique" ou si tu veux être guidé, django est vraiment très bien. Si tu veux juste faire une API et que tu veux faire les choses à ta façon (possiblement mal) les microframworks sont là pour toi.
Tu retrouve la même dichotomie en ruby avec rail et synatra, en perl avec catalyst et dancer en java avec spring et vertx, en scala avec play et scalatra. Dédicace tout de même à python avec zope2 et java avec javaee d'avoir des trucs encore plus lourd.
Les pythonistes aiment bien taper sur les javaistes mais pourtant copient de plus en plus de choses des inférieurs :o La dernière en date est la syntaxe des annotations :)
Enfant on t'a appris à parler sans te faire ouvrir un dictionnaire et je présume que tu n'a pas remis en cause la définition de chaque mot que tu as appris à cette époque.
C'est marrant, c'est tout le contraire de mon enfance.
Tu as appris bien tardivement à parler.
Ah l'influençabilité (autre néologisme puisqu'on y est) par quelque algorithme.
Tu vois tu passe d'un terme neutre à un terme que tu veux politiser. Si j'ai appris une chose de linuxfr, c'est qu'il vaut que je me garde de parler politique sur linuxfr ^^1. Je laisse ceux qui ont pleins d'idées en faire la publicité.
il m'arrive encore de faire l'erreur, mais je finis toujours par le regretter ↩
Comme nous réécrivons l’API, c’est le moment de remettre en question le choix de Flask. D’où la découverte des nombreux nouveaux cadriciels web et l’envie d’écrire un journal pour partager.
Mon commentaire ne remet pas en cause le fais d'aller regarder autre chose. Pas mal de frameworks réactifs ont des fonctionnalités vraiment sympas et sont plutôt agréables à utiliser. On peut utiliser quelque chose de très performant pour des raisons autres que la performance ;)
Mais nos collègues développeurs Web aimeraient bien en profiter pour centraliser et rationaliser les API et avoir partout la même technologie : TypeScript et Node.js 😳
OSEF ? Le troll des langages c'est bien pour essayer d'amuser la galerie sur linuxfr, mais sorti de là ça n'a plus vraiment de sens. Tu regarde s'il y a des contraintes technologiques fortes, puis tu établi les procédés que tu souhaite mettre en place (performance, tests, qualité de code, que sais-je encore) et te regarde comment les mettre en place avec les langages proposés. Bref il y a moyen d'avoir une méthodologie pour répondre à cette question qui renvoie les remarques classiques aux cours de récréations d'écoles primaires.
Que valent ces bench ?
J'en sais rien, mais des graph comme ça ne veulent rien dire (mais bon la dépêche elle-même comporte les même biais).
« La performance » ça n'a pas de sens en soit. Ton besoin c'est quoi ? De fonctionner sur PI0 ? D'encaisser 10⁹⁹⁹⁹ requêtes/s ? De faire du temps réel dur ? Sans définir ton besoin de performance un bench n'est pas plus pertinent que de comparer les palettes de couleurs des sites des techno dont tu parle1.
Si tu veux répondre extrêmement vite, il vaut probablement mieux partir sur du C/C++/rust.
Si tu veux être en capacité d'encaisser énormément de requêtes, c'est une architecture reactive dont tu va avoir besoin (donc oui node, asgi, go, vertx, whatever).
etc
Après il faut aussi être humble, est-ce que ce que la charge que vous devez supporter est vraiment importante ? Aujourd'hui n'importe qui peut monter des infrastructures en recopiant ce que peuvent faire Instagram, Facebook, Google, Youtube,… pour gérer 20 requêtes/jour. C'est rigolo2, mais c'est typiquement de l'overengenering.
Que penser des nouveaux cadriciels Python ?
Qu'ils sont juste dans la veine actuelle. Tous les écosystèmes qui font du web sont entrain d'y passer. Ils ne sont ni les premiers ni particulièrement originaux.
La façon dont tu pose la question me donne l'impression que la performance n'est pas une vraie contrainte pour vous (tout du moins sur cette partie là). Vous ne virer flask que parce qu'on vous a dit qu'il y a quelque chose de plus hype et pas parce qu'il vous contraint. Donc pourquoi essayer de faire un choix en fonction de la perf alors que ça n'est pas si important ?
ça peut être un choix totalement assumé et c'est très bien. Mais alors le besoin ce n'est pas de faire de la performance, mais de s'amuser avec de la techno. ↩
c'est plutôt 300 mots communs, 900 standards, 3000 à vocabulaire élaboré ; nous sommes loin des exigences des chinois (ni n'avons le même système de comptage du nombre de mots…)
Effectivement ma source était fumeuse.
Si tu apprend 12 définitions par semaines il te faut 40 et 64 ans sans le moindre arrêt pour pouvoir les apprendre…
l'apprentissage ne se limitait pas à nos seuls échanges avec cette instit' de la vieille école hein, ton boulanger, ton boucher, le traiteur, le livreur, même la caissière du monop' et accessoirement le ouest-france apportent aussi des mots communs
C'est justement mon point. On apprends et on utilise des mots sans en connaître la définition. Déjà on commence à apprendre à parler avant de savoir lire, mais comme tu le dis on crée notre vocabulaire via nos échanges sans pour autant passer systématiquement par la case dictionnaire. Tu dis toi même ne pas apprendre les difinitions d'un mais juste celle qui est la plus simple à retenir.
bin, si. Par exemple : je te conchie a un sens, tu ne le connais pas forcément, bin tu vas le découvrir :p
C'est une façon qui se veut déguiser de m'insulter ? Soit.1
Ou alors il faut utiliser un méta langage qui te sert à décrire les mots français qui lui dit avoir des axiomes ou utiliser un méta méta langage…
les travaux en IA depuis au moins les années 70 vont à l'encontre de ce que tu sembles penser.
Hum je n'ai aucun problème pour faire intuiter mon hypothèse. Tu prends un mot du dictionnaire, tu regarde l'un de ses définitions et tu va rechercher chaque mot de cette définition. Pour chaque mot de cette définition, tu fais de même. Ça construit un arbre qui s'arrête où ? Même si mon hypothèse générale n'est pas exacte, je ne vois pas comment l'humain ferait pour avoir une définition à tous les mots qu'il utilise (parce que c'est uniquement ça ma thèse, hein).
Pour ce qui est des travaux en IA, je ne vois pas en quoi ça remet en cause le principe de la nécessité d'un métalangage et la difficulté pour un langage d'être totalement réflexif.
je vais m'arrêter là de toute manière. Je m'envais te plonker. À la revoyure. ↩
Posté par barmic 🦦 .
En réponse à la dépêche Portrait de Ken Thompson.
Évalué à 3.
Dernière modification le 01 octobre 2019 à 22:48.
Ça ne change pas grand chose. Tu as appris 3 définitions par semaine en sixième. Allez tu étais un élève appliqué, tu en apprenais 4 fois plus soit 12 définitions par semaine. À 3 ans tu apprend entre 4 et 10 mots par jour (donc 28 à 70 mots par semaine).
On considère que les adultes ont un vocabulaire de 25 à 40k mots. Si tu apprend 12 définitions par semaines il te faut 40 et 64 ans sans le moindre arrêt pour pouvoir les apprendre…
Donc je vais continuer à estimer que comme tout le monde tu ne connais pas les définitions des mots que tu utilise ;)
Note qu'on peut aller plus loin, il est impossible de définir tous les mots d'une langue. On a forcément soit des cycle de définition soit des axiomes. Ou alors il faut utiliser un méta langage qui te sert à décrire les mots français qui lui dit avoir des axiomes ou utiliser un méta méta langage…
Où est-ce que j'ai dis que les greens threads étaient nouveaux ? J'ai dis qu'ils n'étaient pas dans le minimalisme que mon interlocuteur semblait placer en haute estime.
Niveau sécurité, je ne crois pas qu'il y ait grand chose à relativiser dans sa prise en compte: Sa présentation à réception de son prix Turing est d'ailleurs fondatrice dans le domaine.
Encore de la théorie plus que du code.
Pour le reste, combien de personnes sont encore capables actuellement de coder un truc bare-metal[…]
Quel populisme. À l'époque quel proportion le faisait ? Compare ce qui peu l'être. Aujourd'hui il est à l'origine d'un langage dont le runtime est considéré comme relativement complexe (les gens de rust se sont intéressé au fait d'implémenter des green thread comme go et ils ont reculé devant la complexité de la mise en œuvre).
Et non on parle sans problème en dizaines de milliers de personne faut vraiment arrêter de mentir. Entre tout ceux qui font du plus ou moins bas niveau (bonjour CUDA/OpenCL), ceux qui font de l'embarqué (coucou py-zéro, salut ESP8266,…) les gens dont c'est juste le métier (développeur de noyau, de bios, de driver,…), ceux qui font ça juste pour le fun (on a une dépêche sur les consoles virtuelles, des trucs comme NachOS,…), ceux qui utilisent des unikernel,…
Non, sincèrement, je ne vois rien à relativiser!
Très bien pour toi. Je pense avoir suffisamment détaillé mon point de vu
C'est le problème d'utiliser des mots qui n'ont pas de définitions auxquelles on peu se référer. Ce n'est pas forcément très clair.
Bof on ne connait pas forcément la définition de tous les mots que l'on utilise. Enfant on t'a appris à parler sans te faire ouvrir un dictionnaire et je présume que tu n'a pas remis en cause la définition de chaque mot que tu as appris à cette époque.
Mais effectivement si j'avais eu visibilité en tête j'aurais utilisé ce mot. Dans découvrabilité j'aimais bien le sens "pouvoir être découvert".
Pour moi découvrabilité dans le contexte de *tube serait la propriété de découvrir des vidéos à partir d'une première.
Je suis par ailleurs entièrement d'accord avec lgmdmdlsr et adopte plus volontiers une approche descriptive de la langue plutôt que prescriptive.
Ma vision a beaucoup évolué en suivant la chaîne linguisticae sur… youtube.
Autant je suis d'accord que découvrabilité a du sens autant je me demande s'il ne parlait pas de visibilité.
J'ai déjà vu le mot découvrabilité pour décrire des API ou des logiciels dans les quels tu peux déduire des fonctionnalités à partir de premières. vi est très réputé pour ça grâce à sa grammaire simple. Les api fluent peuvent apporter de la découvrabilité.
Oui et non. Pour avoir utiliser kotlin et elm l'usage est vraiment différent. Rien que l'existence de l'opérateur !! montre que le problème n'est pas totalement résolue. NPE est une exception runtime, quand tu utilise tu délègue à quelqu'un d'autres gestion de l'absence de valeur sans lui dire.
C'est déroutant de voir ces langages sans valeur null qui ont complètement supprimé ce forme d'erreur (elle n'est pas représentable dans le langage), mais des fois c'est super agréable.
Je ne dirais pas qu'il évite entièrement le problème. Il donne quelques clefs très utile mais pour supprimer le problème il faut aller plus loin que ça. D'ailleurs le liens que tu donne explique dès le début qu'ils n'ont pas supprimé le problème.
La seule façon de supprimer le problème (que je connaisse), c'est de supprimer les valeurs null du langage. Si tu veux représenter du vide tu dois utiliser un type MonType|Nothing et vérifier le type à chaque usage dangereux.
Oula je vais retirer de mon propos toute tournure pour aller juste à l'essentiel :
déjà j'aime la mouvance craftsmanship, je veux évoluer dans cette notion là dans mon métier plus que dans l'architecture. Je ne remet pas en cause la qualité où l'intérêt du travail d'un développeur
je ne pense pas qu'on puisse évaluer un travail d'ingénieur à productivité quantitative
si Ken Thompson sort du lot ce n'est pas pour son code (que l'on utilise plus depuis très longtemps) ouais pour ses idées (que j'utilise quotidiennement). Son apport au monde moderne se sont ses idées plus que son code
Je présume que ça peu s'expliquer car le paiement est une forme d'engagement. Si tu paie et que c'est nul, tu as payer pour rien. Pour éviter de dire que tu as fauté en payant pour un truc nul, tu va chercher les éléments positifs et tenter de réduire les éléments négatifs.
Je pense que si Thompson est un gros codeur, ça n'est pas très intéressant. Il en existe pleins de gros codeurs. Ce qui fait qu'il sort du lot c'est que les concepts créé ne sont pas remis en cause 50 ans plus tard, qu'ils ont même trouvé d'autres champs des possibles,… La performance d'écriture d'un code en soit je ne sais pas trop qui sa passionne. Ça donne des effets pour le quidam, mais faut le mettre en balance avec la qualité qui est produite par exemple pour que ça ait du sens.
Pour un autre domaine que je connais bien, c'est comme si pour faire comprendre la qualité d'athlète de Teddy Riner, on énonçait le nombre de pompes qu'il peut enchainer parce qu'expliquer que gagner des championnat du monde sur une technique différente à chaque combat c'était trop compliqué.
Les gens qui utilisent ça doivent connaître Ctrl+z qui marche avec vim comme avec emacs. Ça permet au moins de lancer man pour savoir comment sortir. Rappel avec X11 les gens n'avais pas l'habitude de Fichier > Fermer ni d'utiliser la crois dans le coin de la fenêtre.
[^] # Re: Bazar!
Posté par barmic 🦦 . En réponse à la dépêche Python — partie 3 — Installation de Python et de paquets. Évalué à 1.
Je ne suis pas d'accord.
Dans un monde parfait oui le versionnement suffirait, mais personne n'est capable de garantir qu'un changement ne va pas casser une compatibilité. Donc non changer une micro n'est jamais anodin pour un projet.
De même pour la stabilité des API l'esprit humain n'est pas capable de lire l'avenir donc tu n'a aucune garanti que l'API que tu décris est stable ou non. Ce qui tiens un peu mieux que les autres c'est les API qui font le minimum de choses.
J'ai rien compris… Pour la première partie je sais pas trop ce que tu veux dire. Pour la seconde, euh… Tu connais beaucoup de logiciels en C qui utilisent que la libc (qui ne permet pas de créer de thread) ? Ou qui n'utilisent que la libc + les appels système (ça te permet d'avoir des threads) ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Bazar!
Posté par barmic 🦦 . En réponse à la dépêche Python — partie 3 — Installation de Python et de paquets. Évalué à 2.
Bon je me lance…
La gestion des dépendances est bien plus complexe que ce que tu semble croire. Beaucoup plus complexe.
Il y a généralement beaucoup de conflit entre des besoins différents par des gens différents.
le développeur
Son cheval de bataille c'est les fonctionnalités (c'est ce que les utilisateurs demandent).
C'est celui qui code l'appli. Il a un besoin primordial : gérer les dépendances en dehors du système. Il doit pouvoir avoir différentes versions d'une même bibliothèque sans détruire son système y compris un build de la version pas encore sorti.
Ensuite il a des besoins: comme l'envi de ne pas avoir à supporter des versions de dépendance toujours plus exotiques, ne pas être contraint par les cycles de vie de chaque SE et distributions, ne pas empaqueter des millions de fois son logiciel,…
opérationnel/admin sys
Lui quand on lui parle fonctionnalités, il voit nouveaux bugs.
Son besoin primordial c'est que les logiciels fonctionnent bien sur son système et pour ça il faut que le logiciel se plie totalement à son système. Donc utilise le système de packaging qui va bien, les dépendances du système uniquement, si vraiment une dépendance n'existe pas sur le système (pourquoi diable être allé chercher cette obscure dépendance ?) la packager séparément, etc
(évidemment j'exagère)
Les 2 points de vues ne sont pas réconciliables ils sont opposés. Le seul endroit où ça peut fonctionner c'est dans le cadre du devops où il n'y a qu'une seule cible de déploiement et les ops et les dev discutent. Aucun langage n'a résolu cette problématique, absolument aucun. Ni les vieux comme C ni les plus jeunes comme rust ou julia. Ceux qui te semblent avoir réussi ont juste privilégiés ton point de vue.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et Django?
Posté par barmic 🦦 . En réponse au journal Python pour la rentrée 2019 - Hors Série - Python revient dans la course face à Node.js. Évalué à 0.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et Django?
Posté par barmic 🦦 . En réponse au journal Python pour la rentrée 2019 - Hors Série - Python revient dans la course face à Node.js. Évalué à 4.
En fait tu te concentre sur la technique, mais c'est pas le plus important là. Tu peux partager du code métier entre ton front et ton back et ça peut être très utile. Il peut facilement arriver qu'une logique implémenter coté client soit finalement plus utile dans le serveur et vice et versa.
Ça n'est pas compliqué d'avoir de la logique métier qui ne soit pas adhérente à ton framework (ça a aussi pleins de bonnes propriétés en particulier pour les tests) et ça te donne beaucoup de flexibilités d'évolutions.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: [aiohttp|flask|bottle|pyramid] + hapic + [marshmallow|serpyco]
Posté par barmic 🦦 . En réponse au journal Python pour la rentrée 2019 - Hors Série - Python revient dans la course face à Node.js. Évalué à 2.
C'était uniquement pour la symétrie. OSEF qui aurait inventé ou pas ce genre de choses.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et Django?
Posté par barmic 🦦 . En réponse au journal Python pour la rentrée 2019 - Hors Série - Python revient dans la course face à Node.js. Évalué à 7.
Il n'a plus la hype, mais non il est encore très bien. Dango est une solution complète qui vient avec une opinion. Il t'expliquer comment accéder à ta base de données, comment faire de l'authentification, etc. Flask et les autres microframworks sont beaucoup plus petits, ils font donc bien moins de choses et on leur ajoute des plugins du coup.
Si ton but est de recréer un site web complet "classique" ou si tu veux être guidé, django est vraiment très bien. Si tu veux juste faire une API et que tu veux faire les choses à ta façon (possiblement mal) les microframworks sont là pour toi.
Tu retrouve la même dichotomie en ruby avec rail et synatra, en perl avec catalyst et dancer en java avec spring et vertx, en scala avec play et scalatra. Dédicace tout de même à python avec zope2 et java avec javaee d'avoir des trucs encore plus lourd.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: [aiohttp|flask|bottle|pyramid] + hapic + [marshmallow|serpyco]
Posté par barmic 🦦 . En réponse au journal Python pour la rentrée 2019 - Hors Série - Python revient dans la course face à Node.js. Évalué à 1.
Les pythonistes aiment bien taper sur les javaistes mais pourtant copient de plus en plus de choses des inférieurs :o La dernière en date est la syntaxe des annotations :)
cf
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: H.S.: Youtube
Posté par barmic 🦦 . En réponse à la dépêche Portrait de Ken Thompson. Évalué à 5.
Tu as appris bien tardivement à parler.
Tu vois tu passe d'un terme neutre à un terme que tu veux politiser. Si j'ai appris une chose de linuxfr, c'est qu'il vaut que je me garde de parler politique sur linuxfr
^^1. Je laisse ceux qui ont pleins d'idées en faire la publicité.il m'arrive encore de faire l'erreur, mais je finis toujours par le regretter ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Performance
Posté par barmic 🦦 . En réponse au journal Python pour la rentrée 2019 - Hors Série - Python revient dans la course face à Node.js. Évalué à 2.
Mon commentaire ne remet pas en cause le fais d'aller regarder autre chose. Pas mal de frameworks réactifs ont des fonctionnalités vraiment sympas et sont plutôt agréables à utiliser. On peut utiliser quelque chose de très performant pour des raisons autres que la performance ;)
De rien :)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Performance
Posté par barmic 🦦 . En réponse au journal Python pour la rentrée 2019 - Hors Série - Python revient dans la course face à Node.js. Évalué à 10.
OSEF ? Le troll des langages c'est bien pour essayer d'amuser la galerie sur linuxfr, mais sorti de là ça n'a plus vraiment de sens. Tu regarde s'il y a des contraintes technologiques fortes, puis tu établi les procédés que tu souhaite mettre en place (performance, tests, qualité de code, que sais-je encore) et te regarde comment les mettre en place avec les langages proposés. Bref il y a moyen d'avoir une méthodologie pour répondre à cette question qui renvoie les remarques classiques aux cours de récréations d'écoles primaires.
J'en sais rien, mais des graph comme ça ne veulent rien dire (mais bon la dépêche elle-même comporte les même biais).
« La performance » ça n'a pas de sens en soit. Ton besoin c'est quoi ? De fonctionner sur PI0 ? D'encaisser 10⁹⁹⁹⁹ requêtes/s ? De faire du temps réel dur ? Sans définir ton besoin de performance un bench n'est pas plus pertinent que de comparer les palettes de couleurs des sites des techno dont tu parle1.
Si tu veux répondre extrêmement vite, il vaut probablement mieux partir sur du C/C++/rust.
Si tu veux être en capacité d'encaisser énormément de requêtes, c'est une architecture reactive dont tu va avoir besoin (donc oui node, asgi, go, vertx, whatever).
etc
Après il faut aussi être humble, est-ce que ce que la charge que vous devez supporter est vraiment importante ? Aujourd'hui n'importe qui peut monter des infrastructures en recopiant ce que peuvent faire Instagram, Facebook, Google, Youtube,… pour gérer 20 requêtes/jour. C'est rigolo2, mais c'est typiquement de l'overengenering.
Qu'ils sont juste dans la veine actuelle. Tous les écosystèmes qui font du web sont entrain d'y passer. Ils ne sont ni les premiers ni particulièrement originaux.
La façon dont tu pose la question me donne l'impression que la performance n'est pas une vraie contrainte pour vous (tout du moins sur cette partie là). Vous ne virer flask que parce qu'on vous a dit qu'il y a quelque chose de plus hype et pas parce qu'il vous contraint. Donc pourquoi essayer de faire un choix en fonction de la perf alors que ça n'est pas si important ?
c'est évidement éxagéré ↩
ça peut être un choix totalement assumé et c'est très bien. Mais alors le besoin ce n'est pas de faire de la performance, mais de s'amuser avec de la techno. ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: H.S.: Youtube
Posté par barmic 🦦 . En réponse à la dépêche Portrait de Ken Thompson. Évalué à 2.
Effectivement ma source était fumeuse.
C'est justement mon point. On apprends et on utilise des mots sans en connaître la définition. Déjà on commence à apprendre à parler avant de savoir lire, mais comme tu le dis on crée notre vocabulaire via nos échanges sans pour autant passer systématiquement par la case dictionnaire. Tu dis toi même ne pas apprendre les difinitions d'un mais juste celle qui est la plus simple à retenir.
C'est une façon qui se veut déguiser de m'insulter ? Soit.1
Hum je n'ai aucun problème pour faire intuiter mon hypothèse. Tu prends un mot du dictionnaire, tu regarde l'un de ses définitions et tu va rechercher chaque mot de cette définition. Pour chaque mot de cette définition, tu fais de même. Ça construit un arbre qui s'arrête où ? Même si mon hypothèse générale n'est pas exacte, je ne vois pas comment l'humain ferait pour avoir une définition à tous les mots qu'il utilise (parce que c'est uniquement ça ma thèse, hein).
Pour ce qui est des travaux en IA, je ne vois pas en quoi ça remet en cause le principe de la nécessité d'un métalangage et la difficulté pour un langage d'être totalement réflexif.
je vais m'arrêter là de toute manière. Je m'envais te plonker. À la revoyure. ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: H.S.: Youtube
Posté par barmic 🦦 . En réponse à la dépêche Portrait de Ken Thompson. Évalué à 3. Dernière modification le 01 octobre 2019 à 22:48.
Ça ne change pas grand chose. Tu as appris 3 définitions par semaine en sixième. Allez tu étais un élève appliqué, tu en apprenais 4 fois plus soit 12 définitions par semaine. À 3 ans tu apprend entre 4 et 10 mots par jour (donc 28 à 70 mots par semaine).
On considère que les adultes ont un vocabulaire de 25 à 40k mots. Si tu apprend 12 définitions par semaines il te faut 40 et 64 ans sans le moindre arrêt pour pouvoir les apprendre…
Donc je vais continuer à estimer que comme tout le monde tu ne connais pas les définitions des mots que tu utilise ;)
Note qu'on peut aller plus loin, il est impossible de définir tous les mots d'une langue. On a forcément soit des cycle de définition soit des axiomes. Ou alors il faut utiliser un méta langage qui te sert à décrire les mots français qui lui dit avoir des axiomes ou utiliser un méta méta langage…
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Relativisons
Posté par barmic 🦦 . En réponse à la dépêche Portrait de Ken Thompson. Évalué à 2.
Où est-ce que j'ai dis que les greens threads étaient nouveaux ? J'ai dis qu'ils n'étaient pas dans le minimalisme que mon interlocuteur semblait placer en haute estime.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Relativisons
Posté par barmic 🦦 . En réponse à la dépêche Portrait de Ken Thompson. Évalué à 5.
Encore de la théorie plus que du code.
Quel populisme. À l'époque quel proportion le faisait ? Compare ce qui peu l'être. Aujourd'hui il est à l'origine d'un langage dont le runtime est considéré comme relativement complexe (les gens de rust se sont intéressé au fait d'implémenter des green thread comme go et ils ont reculé devant la complexité de la mise en œuvre).
Et non on parle sans problème en dizaines de milliers de personne faut vraiment arrêter de mentir. Entre tout ceux qui font du plus ou moins bas niveau (bonjour CUDA/OpenCL), ceux qui font de l'embarqué (coucou py-zéro, salut ESP8266,…) les gens dont c'est juste le métier (développeur de noyau, de bios, de driver,…), ceux qui font ça juste pour le fun (on a une dépêche sur les consoles virtuelles, des trucs comme NachOS,…), ceux qui utilisent des unikernel,…
Très bien pour toi. Je pense avoir suffisamment détaillé mon point de vu
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: H.S.: Youtube
Posté par barmic 🦦 . En réponse à la dépêche Portrait de Ken Thompson. Évalué à 2.
Bof on ne connait pas forcément la définition de tous les mots que l'on utilise. Enfant on t'a appris à parler sans te faire ouvrir un dictionnaire et je présume que tu n'a pas remis en cause la définition de chaque mot que tu as appris à cette époque.
Pour moi découvrabilité dans le contexte de *tube serait la propriété de découvrir des vidéos à partir d'une première.
Ma vision a beaucoup évolué en suivant la chaîne linguisticae sur… youtube.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: H.S.: Youtube
Posté par barmic 🦦 . En réponse à la dépêche Portrait de Ken Thompson. Évalué à 3.
Autant je suis d'accord que découvrabilité a du sens autant je me demande s'il ne parlait pas de visibilité.
J'ai déjà vu le mot découvrabilité pour décrire des API ou des logiciels dans les quels tu peux déduire des fonctionnalités à partir de premières.
viest très réputé pour ça grâce à sa grammaire simple. Les api fluent peuvent apporter de la découvrabilité.https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Source pour Java 17 en LTS ?
Posté par barmic 🦦 . En réponse au journal Enfin des NullPointerException plus explicites en Java. Évalué à 6.
L'employé en question c'est Mark Reinhold chef architect de Java SE (pour ceux à qui ça ne parle pas, il est l'un des 6 du board d'OpenJDK).
Le projet OpenJDK (c'est lui le site officiel) https://openjdk.java.net/projects/jdk/ pointe justement sur un mail de Mark Reinhold qui explique tout le cycle de vie: https://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
Il dit bien une version LTS tous les 3 ans.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pendant ce temps, à Saint-Pétersburg...
Posté par barmic 🦦 . En réponse au journal Enfin des NullPointerException plus explicites en Java. Évalué à 2.
Ah mais je n'ai jamais dis qu'il n'y avait pas de bonne explication. C'est juste le « ils ont complètement supprimé le problème » qui m'a fait réagir.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pendant ce temps, à Saint-Pétersburg...
Posté par barmic 🦦 . En réponse au journal Enfin des NullPointerException plus explicites en Java. Évalué à 2.
Oui et non. Pour avoir utiliser kotlin et elm l'usage est vraiment différent. Rien que l'existence de l'opérateur
!!montre que le problème n'est pas totalement résolue. NPE est une exception runtime, quand tu utilise tu délègue à quelqu'un d'autres gestion de l'absence de valeur sans lui dire.C'est déroutant de voir ces langages sans valeur
nullqui ont complètement supprimé ce forme d'erreur (elle n'est pas représentable dans le langage), mais des fois c'est super agréable.https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pendant ce temps, à Saint-Pétersburg...
Posté par barmic 🦦 . En réponse au journal Enfin des NullPointerException plus explicites en Java. Évalué à 4.
Je ne dirais pas qu'il évite entièrement le problème. Il donne quelques clefs très utile mais pour supprimer le problème il faut aller plus loin que ça. D'ailleurs le liens que tu donne explique dès le début qu'ils n'ont pas supprimé le problème.
La seule façon de supprimer le problème (que je connaisse), c'est de supprimer les valeurs null du langage. Si tu veux représenter du vide tu dois utiliser un type
MonType|Nothinget vérifier le type à chaque usage dangereux.https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Relativisons
Posté par barmic 🦦 . En réponse à la dépêche Portrait de Ken Thompson. Évalué à 8.
Oula je vais retirer de mon propos toute tournure pour aller juste à l'essentiel :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ah la vache
Posté par barmic 🦦 . En réponse au journal ukuu, un outil pour gérer ses kernels linux => Gniii ---- Payant ? => Gniii². Évalué à 3.
Je présume que ça peu s'expliquer car le paiement est une forme d'engagement. Si tu paie et que c'est nul, tu as payer pour rien. Pour éviter de dire que tu as fauté en payant pour un truc nul, tu va chercher les éléments positifs et tenter de réduire les éléments négatifs.
Du moins je présume que ça vient de ça
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Relativisons
Posté par barmic 🦦 . En réponse à la dépêche Portrait de Ken Thompson. Évalué à 4.
Je pense que si Thompson est un gros codeur, ça n'est pas très intéressant. Il en existe pleins de gros codeurs. Ce qui fait qu'il sort du lot c'est que les concepts créé ne sont pas remis en cause 50 ans plus tard, qu'ils ont même trouvé d'autres champs des possibles,… La performance d'écriture d'un code en soit je ne sais pas trop qui sa passionne. Ça donne des effets pour le quidam, mais faut le mettre en balance avec la qualité qui est produite par exemple pour que ça ait du sens.
Pour un autre domaine que je connais bien, c'est comme si pour faire comprendre la qualité d'athlète de Teddy Riner, on énonçait le nombre de pompes qu'il peut enchainer parce qu'expliquer que gagner des championnat du monde sur une technique différente à chaque combat c'était trop compliqué.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Jargon
Posté par barmic 🦦 . En réponse au journal Navigateur Next 1.3.1: améliorations du minibuffer, du support pour de multiples plateformes, etc. Évalué à 1.
Les gens qui utilisent ça doivent connaître Ctrl+z qui marche avec vim comme avec emacs. Ça permet au moins de lancer man pour savoir comment sortir. Rappel avec X11 les gens n'avais pas l'habitude de Fichier > Fermer ni d'utiliser la crois dans le coin de la fenêtre.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Relativisons
Posté par barmic 🦦 . En réponse à la dépêche Portrait de Ken Thompson. Évalué à 2.
Je trouve que ça le place comme un gros codeur au lieu de le placer comme un excellent architecte.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll