barmic a écrit 927 commentaires

Le mot que tu cherche c'est verbeux, ça n'a rien à voir (même hors langage informatique). Perl n'est pas verbeux, mais peux devenir illisible.

Pour ce qui est de yaml, les constructions comme les références (avec * ou &), le merge de clefs,… sont des fonctionnalités très puissante, mais se font à partir de quelques caractère.

Justement non.

Oui tu demande à apt de les télécharger. Bien. Maintenant comment tu fais pour avoir plusieurs versions de libc diférentes ? Comment tu fais pour tester la mise à jour de l'une de tes dépendance ? Comment tu fais pour expliquer à tes contributeurs la liste de tes dépendances qu'ils utilise nix, debian, redhat ou gentoo ? Comment tu t'assure que tes dépendances ont bien les bonnes options de compilation ?

Tu parle de ton principe, mais tu n'explique pas comment dans la pratique tu fais ces choses vitales. La seule autre option c'est d'utiliser des choses comme lxc ou docker. C'est un peu gros comme truc et ça marche pas bien multi plateforme.

Par contre… Vous décrivez toujours vos dépendances entre fichier dans l'outil de build ?!
Quand est-ce qu'on verra un compilateur C/C++ se charger de ça ? (prendre un ou plusieurs dossier et compiler tous les fichiers .o nécessaire en reconstruisant l'arbre de dépendances qui va bien)

Ce sera tellement performant et permettra de simplifier les outils de builds. Le compilateur sait lire la syntaxe du langage, il sait dont déduire les dépendances.

Tu viens de démontrer qu'il peut être lisible. Mais le fait de pouvoir écrire ta liste de 2 façon différentes, la manière de gérer des bloc de texte, le multidocument dans un même fichier, les liens au sein d'un document,… sont des trucs que j'arrive jamais à écrire du premier coup et pour relire je bloque toujours dessus avant d'arriver à bien comprendre.

C'est même pas un workaround, c'est comme si je disait que tu peux écrire du XML comme du JSON, il faut juste le convertir en XML avant de le donner au parseur XML…

Les commentaires font partie de la syntaxe d'un langage, je ne pas avoir voulu l'implémenter est un choix. Qu'il existe des workaround très bien (je crois que certains parseurs acceptent des syntaxes de commentaires), mais on perds toute capacité d'échange.

Euh ? Tu va les télécharger quoi qu'il arrive. Il n'y a pas de raison de penser que ton système est le système cible et même comme ça, le support des versions précédente de ton logiciel ou le test de la version suivante (ou d'options de compilation différentes) d'une bibliothèque t'oblige à faire des installations non système.

Je rejoins Yves c'est un faux problème. XML est largement plus facile à lire que json ou yaml par exemple. Son problème c'est qu'à être très explicite il en devient verbeux. Mais le xml étant trivial à manipuler par un programme tous les éditeurs qui s'y intéressent un minimum ont des méthodes pour le présenter et le manipuler de la façon qu'ils le souhaite (les code snippet d'intellij sont cool pour ça par exemple).

Ils aurait pu choisir un format xml plus compact ça n'aurait pas fait de mal, mais affirmer « c'est du xml bouh ! c'est pas bien ». C'est un leurre, tous les formats qui sont très utilisés rencontrent des problèmes que xml avait réfléchis au départ :

• json aimerait bien avoir de la description de format, mais ne sait pas trop comment s'y prendre du coup il tatonne entre plusieurs façon
• yaml est une plaie à écrire sa syntaxe possède des subtilités qui peuvent rendre fou si ton parseur ne présentent pas bien les erreur en question
• groovy (utilisé par gradle) ne permet pas de validation forte d'un fichier de build et sera probablement, à terme, remplacé par kotlin

Les autres outils de builds réinventent des formats/syntaxes, maven a choisi de ne pas réinventer la roue ça me paraît être quelque chose de plutôt malin.

Gradle est le plus intéressant des 3 a mon avis. Déjà il a abandonner le XML au profit du JSON.

C'est du groovy pas du tout du json. Par contre il a un très gros défaut c'est que la syntaxe n'est pas complètement validée et on se retrouve avec des erreurs au runtime (runtime du build). C'est pour ça qu'ils regardent pour utilise kotlin à la place, mais ça fait un an et demi et c'est toujours pas vraiment la méthode conseillée.

Pour maven :

C'est un outil qui a l'air très professionnel. Ah mais attend… c'est pour ça qu'on comprend rien au descriptif ! La première version date de 2004 et c'est donc tout naturellement que le langage le plus populaire du début du siècle a été choisi pour les scripts de build, je parle bien sûr du 🎉 XML 🎉.

C'est marrant de reprocher à tous les outils de juste chercher à être rapide plutôt que fonctionnelle et de se foutre de la gueule de celui qui est juste fonctionnel ;)

Pour gradle :

Les trucs qui me fatiguent le plus avec Gradle sont d'abord le temps de compilation. La compilation du projet Java de nos jeux, une partie qui contient pourtant peu de code, prend quasiment une minute.

Je suis vraiment surpris, gradle est vraiment très efficace. Il faut par contre d'une part laisser le deamon se lancer et d'autre part ne pas utiliser de clean à tout bout de champ. Il prend très bien en compte les rebuilds (une étape de build est identifiée par les fichiers sources, la configuration de l'outil de build et éventuellement des éléments de ton système (l'architecture matériel par exemple).

C'est comme ça que Python fonctionne. Toutes les exceptions héritant de BaseException (genre SystemExit ou KeyboardInterrupt) sont déjà gérée comme ça. Note que ces exceptions ne sont pas invisible, les bonnes pratiques indiquent juste qu'il faut faire, sauf cas très particulier, un except Exception pour les laisser passer.

Elles sont invisibles. Quelque chose qui n'est visible qu'au runtime est invisible c'est quelque chose qui peut arriver implicitement et ça rend presque impossible une validation par revue du code (c'est précisément ce que l'on recherche quand on dit qu'il faut être explicite). Je sais que ça fait partie du langage (on peut écrire ce que l'on veut dans les PEP, le monkey patching existe en python, c'est un langage dynamique ça autorise à faire un tas de choses de manière implicite). C'est aussi le cas de mon langage de prédilection (java), hein ? C'est juste que ça limite la manière dont je vais exprimer mon code asynchrone.

Je le répète: les problèmes d'init/teardown (en particulier dans le cas d'un crash) sont ce qu'il y a de plus compliqué en asynchrone, l'intérêt de trio est de te donner un contexte pour gérer ça simplement (on fonctionne avec des paradigmes très proche de ce qu'on ferait en programmation single thread classique).

Pourquoi ne pas gérer ça dans une forme de machine à état ? C'est ce que font les circuit breaker et les systèmes à acteurs (OTP ou akka le font pour toi), ça marche très bien et tu as la garantie que ton programme ne va pas exploser en vol à cause d'une erreur quelque part. Lancer une exception et carpe diem ce n'est pas sécurisé.

« let it crash » c'est particulier. Ça dépend de ce que tu fais comme application. Si tu es dans un monde de microservice, avec un kubernetes qui te redémarre pourquoi pas (et encore…¹) si tu fais une application mobile par exemple ce n'est pas envisageable.

L'exception ne modifie que le context de la coroutine touchée, c'est au développeur de choisir si la coroutine en question travaille sur toutes les données ou bien sur un sous ensemble isolé du reste du système.

Interrompre son taf c'est déjà modifier son contexte, le fait de sortir manu military des blocs de codes détruits un tas de variables,… Imposer un try/except à tous les niveaux c'est difficilement tenable. Et ça empêche de continuer normalement son travail avant de gérer l'erreur.

Ou bien des locks à grain fin, ce que la programmation asynchrone rend beaucoup plus simple qu'en utilisant des threads classiques.
De mémoire Redis fonctionne de cette façon (il implémente sa propre boucle asynchrone et lance une coroutine par connection client), on peut activer un journal de logs mais c'est pour rendre les données persistantes (donc dans tous les cas on se retrouve avec des coroutines qui travaillent sur les même données dans la base).

Redis n'est pas capable de gérer de multiples CPU et ne permet pas de véritablement gérer des écritures sur différents nœuds. Je ne suis pas certains qu'il fasse vraiment du lock à grain fin. Il fait du lock oui… Pour utiliser plusieurs CPU il faut faire du sharding de ton coté. À comparer avec hazelcast qui est une base de données comparable, mais architecturée en P2P avec un sharding automatique (ce qui permet de réduire la pression sur les event log - tu en crée un par shard). Tu peux aussi regarder du coté de cassandra qui fait précisément ça (aussi en P2P).

Sinon un autre exemple (quoi que plus bas niveau) de ce type de besoin serait le Kernel Linux. Travailler par passement de messages est intéressant mais coûteux (cf. les débat kernel monolithique vs microkernel).

Ah mais carrément ! Ça ne fonctionne pas pour tout. Le noyau a notamment besoin de débit et de latence délirante :

• une latence sur les IRQ serait vraiment affreux pour notre utilisation
• envoyer une image à la carte graphique par messages serait affreux

---

Pour l'aspect sémantique c'est intéressant, mais j'ai plus le temps d'en parler tout de suite.

Pour moi l'asynchrone est un mécanisme de programmation parallèle au même titre de la concurrence. Dans le premier cas (l'asynchrone) un seul traitement est réalisé à un moment donné contre plusieurs dans le second (et encore, à condition d'avoir plusieurs cœurs physiques…), mais ça c'est justement des détails et pas un besoin fonctionnel.

Tu te contredis entre ta première et ta seconde phrase… L'asynchrone est un pattern qui découple temporellement une portion de code et celle qui l'a appelé. Le fait que ce soit parallèle n'est pas une obligation (c'est ce qui se passe quand on utilise POE par exemple).

Si une des deux branches se plante ça veut dire qu'on est dans un état qui mérite un traitement particulier, ça peut être arrêter toutes les coroutines jusqu'à un certain niveau, retenter de zéro la traitement de la coroutine ayant échoué et bien encore ne rien etc.

Ce genre de besoin devrait amha se gérer via des commandes. Tu crée des commandes et tu choisi leur comportement en cas de problème, leur timeout, etc. Ça permet de gérer les choses dans un contexte plus concis, tu ne viens pas demander à l'appelant de gérer cela.

Ensuite effectivement une fois qu'on sait ce qu'on doit arrêter, encore faut-il le faire proprement. À ce niveau trio injecte une exception CancelledError dans la coroutine à terminer, ce qui permet à celle-ci de se nettoyer proprement, voir même d'annuler son arrêt si le cœur lui en dit (mais encore une fois ça dépend totalement du cas d'usage).

Les exceptions sont déjà complexe à gérer là ça signifie que n'importe où une exception invisible peut subvenir ? Si ça intervient dans le code d'une bibliothèque ça se passe comment ? La seule façon de survivre correctement à cela est d'avoir un code très défensif et perso ça ne me plaît pas des masses d'écrire ce genre de code.

j'imagine que tu parles de twisted ?

Effectivement.

Je n'ai pas compris ce que tu voulais dire par contexte principal ? Dans un framework asynchrone lambda une fois l'event loop lancée il n'y a pas une coroutine plus principale qu'une autre. Et de toute façon l'event loop en question passe déjà son temps à switcher d'une coroutine à une autre donc je ne vois pas en quoi aller dans un contexte supplémentaire serait intenable…

On parle de lever d'exception. Lever une exception c'est manipuler l'état de ton contexte. La façon normale de remonter une erreur dans une event loop c'est de lui publier un évènement d'erreur. Le problème n'est pas le switch, mais le fait de remonter un comportement par une manipulation de l'état.

C'est justement la force des nursery, cela te permet de créer des scope regroupant tes coroutines. Et donc De fait quand une coroutine plante ça remonte ton arbre de scopes (en arrêtant les coroutines en bonne ordre dans la foulée) jusqu'à ce que un try/except veuille bien s'en occuper. Si personne ne veut s'en occuper, ben ton programme crash. Et c'est bien normal, explicit is better than implicit comme ils disent.

Cette remontée est une fuite de ton scope, là où un passage de message ferrait l'affaire. Quant à l'explicite, je ne pense pas qu'injecter une exception comme tu as l'air de le décrire soit explicite. Si tu écris une méthode et qu'elle est finalement utilisée dans une tâche nursery, il sera impossible de voir dans le code de cette méthode qu'il manque potentiellement la gestion de cette dernière.

Tout à fait d'accord. Malgré tout c'est parfois difficile de travailler uniquement avec un système de messages (typiquement dans le cas d'une base de donnée qui doit pouvoir traiter plusieurs requêtes en parallèle alors que celles-ci travaillent sur les mêmes données).

Toutes les bases de données ont déjà résolues se problème par la création d'un event log. Ça fige l'ordre des actions (et ça apporte un tas d'autres propriété sympa). Un event log c'est justement pour rester dans un système à message et ne manipuler un état que lorsque les évènements qui l'ont composés sont triés et rejouables. Au contraire, gérer une base de données par modification directe de l'état du système (ce que fait une levée d'exception) impose de gérer un lock global pour serialiser les opérations.

Merci pour la discussion je la trouve enrichissante (ainsi qu'à Yves et Galndos).

Donc oui, Trio, c’est pour les bambins en liberté surveillée, pas pour les orphelins abandonnés :-p

Pas vraiment, l'idée c'est que les interactions doivent se faire par un passage de message que ton traitement asynchrone finisse ou plante ça émet un message qui va pouvoir être récupérer par une autre tâche pour y réagir. Il ne s'agit donc pas de ne pas les contrôler, mais d'avoir un pattern différent d'interaction.

C'est ce tu trouvera dans les systèmes d'acteurs (voir erlang ou akka), avec le couple goroutines/channel de go ou avec node pour ne citer que les plus connus.

Pour les threads, pour embêter je dirais même que là où il y a des threads il n'y a pas d'asynchrone. C'est tellement caricatural que c'est limite faux, mais c'est pour mettre en évidence que c'est pas une question de thread et que dans le meilleur des cas on est asynchrone sans thread supplémentaire (merci les I/O asynchrones !).

Et il faut gérer les exceptions, pour éviter qu'un client ne pollue le programme complet.

Je ne suis pas certain de comprendre ta phrase, mais pour expliciter. Je pense que tu as en tête le pattern reactor et on ne veux clairement pas avoir de lever d'exception (pour toutes les raisons habituelles qui posent problèmes avec les exceptions).

C'est ce que fais le bout de code que j'ai décris plus haut. Les actions 1, 2 et 3 sont asynchrones (pas forcément parallèle) et tu place ton action G dans le subscribe. Si je reprends ta liste :

1. ça gère que C—E et D—F sont en parallèle => c'est bien ce que je reproche c'est du parallélisme plus que de l'asynchrone. Le fait que ce soit parallèle ou pas est un détail pas un besoin fonctionnel.
2. ça gère que si l’une des deux branches se plante, il faut interrompre l’autre => ouf ça veut dire quoi ? Je veux dire, il va préempter ton code et tout interrompre ? C'est particulièrement dangereux. Je vois pas bien à quoi ça sert et comment garantir qu'on retombe correctement sur nos pieds avec ça.
3. les exceptions se remontent toujours au thread principal => c'est un besoin bizarre encore une fois, j'y reviens juste après
4. ça gère automatiquement le point de rendez-vous avant G => c'est l'équivalent sur subscribe

J'ai vraiment l'impression qu'il s'agit d'un pattern qui sert à ajouter un peu d'asynchrone dans un programme synchrone. Je ne connais pas les autres framework, mais quand tu fais du twist, tu es massivement asynchrone. Remonter dans le contexte principal à chaque fois que quelque chose se passe mal est intenable. Il faut réduire le scope de tes actions et chercher à porter les informations dans des messages plus que dans un état. La gestion d'un état dans un monde asynchrone est sincèrement dangereux parce qu'il est difficile de s'assurer qu'il reste cohérent quelque soit l'ordre dans le quel tes actions asynchrones se résolvent.

Ouf… J'arrive un peu tard, mais j'étais loin de toute connexion ce week-end…

J'avais lu l'article de sam&max, mais pas encore celui du développeur de trio. C'est intéressant, mais il répond à un problème que je n'ai pas personnellement.

Lancer une série d'actions asynchrones et attendre qu'elles aient toutes finies, n'est pas quelque chose que je fais quotidiennement. En fait je ne le fais même pas du tout. Si j'en avais le besoins je pense que mon Rx (que j'essaie de privilégier dès que je fais de l'asynchrone) rempli ce rôle :

Completable action1 = Completable.fromCallable(this::act1);
Completable action2 = Completable.fromCallable(this::act2);
Completable action3 = Completable.fromCallable(this::act3);

Completable.concat(action1, action2, action3)
           .subscribe(() -> log.info("finish !"),
                      exception -> log.error("Error !", exception));

Mais le comportement qui est proposé avec les nurseries me semble vraiment très risqué. Il mélange allègrement du comportement asynchrone et du comportement synchrone. Le switch de l'un des mondes à l'autre est (généralement) vraiment néfaste pour le comportement du programme. Bloquer le programme principal en attendant des tâches asynchrones c'est précisément ce que l'on ne veux pas faire. C'est plus une forme de parallélisme que de l'asynchrone.

Il y a quelque chose que je n'ai pas compris dans le concept ou bien ?

Ça a était répété un paquet de fois, mais il y a un paquet de fonctionnalités qui arrivent de base avec les team chat. Tu les trouve optionnels, mais pas ceux qui utilisent ces team chat.

• envoyer une image
• création de rappels
• historique avec recherche
• création de sondages/votation
• création dynamique de channels
• intégration avec des services comme github, travis, etc

Alors oui irc tu peux t'en servir à travers ssh, mais faut croire que ça ne doit pas intéresser tant que ça les utilisateurs de team chat.

Le mouvement libriste est toujours divisé entre ce que tu décris et les des libéraux qui y voient une implémentation parfaite de la concurrence libre et non faussé.

Ce sont des menaces ?

j'avais initialement pensé que le point de vue d'un professionnel de la blockchain vous intéresserait

Le problème c'est que tu ne dis rien de concret. Il y a une bulle d'investissement, ok, mais en pratique quel est le scénario catastrophe qui fait qui peur ?

J'ai une idée sur pourquoi ça bougerai plus pour les crypto monnaies : ce sont des projets qui sont là à coup d'investissement délirant fait par des gens qui n'entravent rien à la technique, mais à qui MS fait peur. Donc il faut les rassurer avant qu'ils se barrent mettre leur argent ailleurs.

savez-vous si Firefox dispose déjà de ces protections (contre la prise d'empreintes digitales et contre les autres formes de traçage furtif) ???

Peut être, je n'ai pas regardé les contre-mesures exactes utilisées, mais :

• sur android tu as une version du navigateur qui oublie tout
• sur PC tu as les conteneurs pour les plus motivés (j'aime bien perso)
• tu as une forme de blocage décrite ici : https://support.mozilla.org/en-US/kb/tracking-protection
• et ils sont entrain de voir pour implémenter tor

Nous on utilise Slack. J'en suis plutôt content et les problèmes que je rencontre sont plus liés à l'usage qu'à l'outil.

1. Trop de bruit dans certaines conversation (sur des chan qui ont un intérêt). C'est vraiment compliqué de commencer une conversation et de savoir quand switcher sur un thread pour ne pas trop embêter les autres.
2. Trop d'utilisation de @channel pour certains là où @here pourrait être utile.
3. Il manque à Slack une fonctionnalité d'hangout nommé « ferme ta gueule pendant X temps » (oui c'est comme ça qu'ils l'ont appelé !) c'est très pratique. Quand on est entrain de bosser à la première notification qui me dérange je coupe tout et j'ai pas à me souvenir de le réactiver.

Après je n'ai pas travaillé avec des équipes véritablement matures sur le team chat. C'est un outil de conversation comme un autre pour la plupart (c'est bien triste).

C'est se que eux disent et, au vu du nombre de malwares (*1) qui pullulent sur Android je ne suis pas d'accord avec leurs raisons évoquées. Afin de réduire l'article au maximum (*2) j'ai donc évité volontairement d'expliquer cela.

He ben je ne suis pas du tout d'accord avec ton excuse. Tu prends le temps d'affirmer ton opinion, mais tu n'évoque pas l'argument d'en face. Tu aurais voulu limiter la taille de l'article tu n'aurais pas expliqué. Parce que :

• soit on considère qu'il faut rooter son téléphone en son âme et conscience et on donne toutes les clefs de compréhension (même celles qui ne nous plaisent pas)
• soit on considère que ça n'est pas utile au déroulement de ton tuto et on dit juste que ça permet aux appli de passer administrateur

En l'état je trouve sincèrement malhonnête d'avoir une présentation uniquement dans un sens alors qu'il ne s'agit pas clairement d'un billet d'humeur. C'est ton avis, peut être, mais il n'est pas indiqué comme ça dans l'article.

En soit ce n'est pas grave, mais j'aime de moins en moins les articles (de manière générale) qui sont hyper orientés comme cela. Ça me donne l'impression qu'on me prend pour un idiot.

La raison pour laquelle l'accès root est aussi difficile à avoir est simple : vous interdire de supprimer les applications publicitaires, ainsi que les spywares fabricants/opérateurs/fournisseurs/étatiques et vous empêcher d'avoir le contrôle complet de votre machine.

Je trouve dommage de ne pas faire l'effort d'instruire à charge et à décharge. Que tu pense que c'est faux est une chose et tu peux l'expliquer, mais indiquer l'argument des OEM et Google serait plus honnête : ils le font pour limiter les problèmes dans les cas où l'utilisateur installe du code malicieux (et c'est pour ça qu'ils remettent en cause le support). Cela permet par exemple de garantir que l'outillage de google pour bloquer à distance un appareil perdu/volé fonctionne.

Oui ça permet aussi à Google de potentiellement bloqué lui-même l'appareil, oui ça infantilise l'utilisateur, etc. Mais c'est mieux en l'expliquant qu'en essayant de le cacher.

Android n'utilise pas la JVM (c'est tout le problème que Google a avec Oracle). Il a une machine virtuelle (en fait il y en a eu différentes) qui exécutent un bytecode qui n'est pas celui de la JVM non plus. Quand tu développe pour Android, tu écris du java que tu compile en bytecode JVM. Puis il est transpilé en Dex bytecode pour la VM d'android (historiquement Dalvik aujourd'hui ART).

Je ne me suis par contre jamais intéressé au fonctionnement internet de Dalvik ou de ART ni à la représentation Dex.

C'est ce que je voulais exprimer en disant :

Le fait qu'il n'y a pas de d'étapes pour passer de ses critères aux tests exécutés est presque nécessaire sinon tu peux jeter tes critères car ils ne seront jamais à jour donc jamais lisibles par un expert du domaine.

Tu dois pouvoir t'ajouter comme extension intéressée lors de l'ajout d'un flux sur ce genre de page :