Guillaume Denry a écrit 2975 commentaires

Si je comprends bien ton propos, une politique commerciale ne regarde personne d'autre que ceux qui la produisent et il n'est pas logique de la critiquer de l'extérieur ?
Par exemple, imaginons une stratégie commerciale qui consiste à faire un prix d'appel, à capter un monopole ou un quasi-monopole, puis à monter les prix petit à petit, après tout, c'est une politique commerciale comme une autre hein, qu'est-ce qu'on aurait à lui reprocher ?

Ok, je sens le gros private joke :)

Je pige pas le score de ce journal (35), j'ai raté quoi ?

C'est juste parce que y'a des gens qui connaissaient pas encore La Poudre Verte ?

Tu te sens d'aller voir un boulanger pour râler à propos de sa politique commerciale ?

De la politique commerciale d'une entreprise émane des effets publics très concrets qu'il est parfaitement possible de critiquer, par quelque biais que ce soit.
Lorsque je souligne ce qui me paraît être disconvenant dans la façon dont un(e) commerçant(e) vend quelque chose, je ne suis pas en train de lui dire "Vous devriez faire comme ci, comme ça" mais plutôt "ce que vous faites actuellement ne me plaît pas, je vais (voir ailleurs)/(reste quand même)". La personne fait ce qu'elle veut de cette info, mais à mon avis, si c'est une personne/société agile, elle prendra soin de recueillir les avis de sa clientèle pour éventuellement agir en conséquence. Ou pas.

je trouve qu'on n'a pas à se mêler de la politique commerciale d'une entreprise

Je ne comprends toujours pas. L'intention ici n'est pas de se "mêler" de la politique commerciale, mais de la désapprouver en n'en étant plus client.
C'est "mal" de désapprouver une politique commerciale quelle qu'elle soit, surtout en étant client ? On doit tout accepter ?

Ok, en effet, j'ai lu trop vite, mais du coup, y'a toujours un truc qui coince dans ma compréhension pleine et entière de ta réponse initiale : qu'est-ce qui te semble aberrant dans le fait de se désabonner pour manifester son désaccord avec la politique commerciale de Free ? (Surtout si le désabonnement précise bien la raison, ce qui est mieux). Ou autrement dit, pourquoi le fait qu'il s'agisse de la politique commerciale et non de, mettons, l'éco-responsabilité d'une entreprise change quoique ce soit ici ?

Bizarre, on ne peut pas aussi voir plus loin que le bout de son propre intérêt personnel et de consommer de façon "stratégique" ?

Pourtant il est soft ce goatse, par rapport à l'original…

Ca dépend.
C'est en évitant les breaking changes qu'on se retrouve parfois avec des gros bloatwares parce qu'on a pas voulu "brusquer l'utilisateur".

Il avance des chiffres, peut-être fantaisiste, mais en attendant, ta réponse n'aide pas des masses…

return Promise.resolve(obj.totozes.totoz.length ? obj.totozes.totoz : [obj.totozes.totoz])

Pas besoin du return Promise.resolve ici, puisque la fonction est déclarée comme async, elle retournera systématiquement une promesse qui sera résolue avec l'objet retourné.

Je ne comprends pas. async, si j'en crois NDM, s'applique uniquement aux fonctions.

Oui, je me suis relu et il manquait clairement quelque chose ; mon commentaire était à sous-entendre dans le contexte d'une fonction asynchrone qui comporte les promesses ou les await.

Dans le cas des promesses, notre fonction F va déclarer autant de fonctions (le plus souvent courtes et anonymes) qu'il y a d'étages dans la promise chain.
Dans le cas des async/await, le code habituellement déclaré dans les fonctions courtes et anonymes se retrouvent juste comme autant d'instructions dans la fonction F.

Ca ne change rien au fait que ta remarque est judicieuse (je suis fan d'Elixir et Elm donc je comprends ce que tu veux dire), même si je pense que dans le cadre d'une utilisation raisonnable d'async/await en JavaScript, ça ne pose pas de problèmes particuliers.

Voici le genre de code sous forme de promesses traditionnelles qu'on retrouvait fréquemment dans notre codebase au boulot :

function f() {
  return asyncFunc1()
    .then(res1 => {
      (...) // code synchrone qui déclare une variable res2, la calcul, et qui a besoin de transmettre res1 à l'étage suivant
      return [res1, res2];
    })
    .then(([res1, res2] => asyncFunc2(res1, res2))
    .then(res3 => {
      (...) // code synchrone qui fait un calcul depuis res3 et le retourne
    })
    .catch(err => {
      console.error(err);
    });
}

Voici ce que le même code devient avec async/await :

async function f() {
  try {
    const res1 = await asyncFunc1();
    (...) // code synchrone qui déclare une variable res2, la calcule
    const res3 = await asyncFunc2(res1, res2);
    (...) // code synchrone qui fait un calcul depuis res3 et le retourne
  catch (err) {
    console.error(err);
  }
}

Franchement, je préfère la deuxième version.
Maintenant, avec une fonction d'une complexité cyclomatique de ouf, des await noyés dans la masse, je dis pas…

Je n'ai pas compris le rapport avec async/await par contre ?

Bin notre discussion portait sur le choix (ou non) de la forme async/await par rapport à la forme des promesses traditionnelles.

Lorsqu'on choisit async/await, on a plus vraiment de fonctions, contrairement aux enchaînements de promesses, puisqu'on écrit la chaîne sous forme d'une suite d'instructions "pseudo-synchrones".
Si on choisit tout de même de scinder la logique en plusieurs fonctions, alors oui, il faut s'efforcer d'écrire des fonctions les plus pures possibles.
Du coup, passer à async/await pour des fonctions courtes ne me paraît pas si nocif que ça, tant qu'on respecte des bonnes pratiques qui datent d'avant même l'invention des promesses : complexité cyclomatique faible, nommage expressif, etc.

Etant donné que Java n'a pas le mot clef const, tu fais références à quels langages ? Ca interpelle ma curiosité :)

Sauf que je ne suis pas certain que l'utilisation du mot const dans d'autre langage OO soit vraiment celle de JavaScript. Ca fait longtemps mais il me semble qu'en C++ par exemple, si on déclare un objet en const, on ne peut pas appeler de méthodes qui modifient cet objet, ou bien en tout cas que c'est une mauvaise pratique.

En javascript, si tu fais :

maFunc1()
  .then(() => {
    const res = [1, 2];
    return res;
  })
  .then(res => {
    res.push(3);
  });

Tu n'as pas gagné l'immutabilité hein.

Dans l'écriture async/await, on a même plus les fonctions de l'écriture traditionnelle des promesses, donc c'est difficile de commencer à parler de fonctions "pures" dans ce cas là.

D'expérience, je trouve qu'à condition de garder les fonctions async/await courtes et avec une bonne séparation des responsabilités, on y gagne plutôt globalement en légèreté d'écriture.

Dans l'exemple, tout est déclaré avec le mot-clé const, rien ne peut être écrasé.

Malheureusement en JavaScript, c'est pas aussi simple :

const a = [1, 2];

a.push(3); // autorisé

Par ailleurs, avec les promesses, on ne mélange pas les scopes, et donc on ne partage pas les variables: on réduit par la même occasion les chances d'écrasement ou d'utilisation de variable accidentels de par cette isolation, le code est potentiellement plus robuste (pas forcément plus robuste à l'exécution, mais plus résistant à l'erreur humaine).

Je comprends ton point de vue, mais j'ai toujours trouvé ultra relou de transmettre une variable par le biais des enchaînements de retour de promesses et j'ai très souvent besoin de le faire, et je ne pense pas que c'est nécessairement une mauvaise pratique que d'avoir besoin d'accéder à une variable à plusieurs étages de son traitement asynchrone.

Après, il est vrai que l'isolation "cognitive" du code asynchrone est moins simple avec du async/await.

J'ai du mal à me départager quant à ma compréhension de ton commentaire, soit :

1. Tu n'as pas compris que async/await est grosso-modo du sucre syntaxique au dessus des promesses
2. Tu le sais très bien mais ton opinion c'est que les fonctions async sont plus pénibles à comprendre que l'écriture sous forme de promesses

En Haskell (je ne connais pas Elm) ce n'est pas nécessaire. Tu as d'ailleurs intérêt à ne pas le faire car cela te permet de te rendre compte que ta fonction est plus générique que ce que tu pensais en l'écrivant.

Je ne suis pas un expert d'Haskell, mais ce que tu dis me surprend beaucoup, compte tenu qu'il est très simple d'écrire une signature de fonction aussi générique soit-elle. Au lieu d'utiliser Int ou String, tu utilises a par exemple.
Bref, je ne sais pas d'où sort cette recommandation de ne pas écrire les signatures de fonction mais ça ne me semble pas un très très bon conseil.

"
Functions also have types. When writing our own functions, we can choose to give them an explicit type declaration. This is generally considered to be good practice except when writing very short functions.
"

(issu de http://learnyouahaskell.com/types-and-typeclasses)

"
It is considered good style to add a type signature to every top-level variable.
"

(issu de https://wiki.haskell.org/Type_signature)

Il se trouve qu'en Haskell ou en Elm (les deux langages en FP que j'ai pu pratiquer jusqu'à présent), on écrit tout de même les signatures des fonctions et donc les types des arguments, principalement parce que le code est destiné à être lu par des êtres humains, qui n'ont pas toujours le temps ou l'envie d'analyser le corps d'une fonction pour inférer eux-même les types "manuellement".

Donc en pratique, quand on est un minimum rigoureux, on tape quand même les types. La bonne nouvelle, c'est que cette signature est séparée physiquement de la fonction (au moins par un retour chariot) et donc :

• La fonction reste tout de même légère en tant que telle.
• La signature se concentre uniquement sur les types des paramètres d'entrée et du retour sans être polluée par d'autres détails techniques, et ça se lit facilement et on peut même parfois savoir ce que fait la fonction sans lire la doc, juste en lisant la signature

On peut écrire des immondices dans n'importe quel langage. Si les choses sont faites avec un peu de discipline, on peut arriver à un résultat correct.

Le relativisme absolu.
On peut écrire des immondices et du beau code en brainfuck aussi, ou avec le ruban de Turing.

Sur le fond du problème : Javascript a clairement ses travers et son écosystème est étouffant mais ce n'est clairement pas un mauvais langage.

Si tu arrives à me définir ce qu'est un "mauvais langage", on pourra peut-être discuter. Jusque là, ta définition est aussi arbitraire que de dire "Javascript est un mauvais langage".

Ce qui est certain, c'est que JavaScript est un langage qui permet plus que beaucoup d'autres d'écrire des immondices in-maintenables. Parce qu'il n'y a qu'au runtime qu'on peut vraiment dire si le programme fonctionne, et encore, en testant et re-testant. Ce langage n'offre quasiment aucune garantie de bon fonctionnement, c'est son principal problème. Il plaît beaucoup aux gens qui n'aiment pas les contraintes. C'était mon cas il y a quelques années, j'ai longtemps trouvé génial le typage dynamique. Sauf qu'au bout d'un moment, on réalise que les contraintes sur un langage ne sont pas des entraves mais au contraire, des moyens d'émancipation et des guides.

Je suis un peu hors-sujet, mais voici une conf abordant des concepts de garantie de fonctionnement par le biais de la génération de code et qui s'appuie sur Elm.
La vidéo aborde graphql dans une grosse partie (*), mais termine par typescript en montrant comment le développeur peut s'assurer que si son code typescript généré compile, alors il peut avoir de fortes garanties sur le fonctionnement de son programme. Voici le projet en question https://github.com/dillonkearns/elm-typescript-interop.
La CLI proposé par ce projet va analyser les ports (c'est l'outil pour l'interopabilité entre le monde Elm et le monde JavaScript) déclarés dans le code Elm et généré du code Typescript qui sera utilisé par le monde JavaScript pour transmettre des données au monde Elm (et vice versa).

(*) Pour ceux qui s'intéressent à graphql (et Elm mais pas obligé pour trouver la conf intéressante), c'est vraiment un truc à voir ; son système permet de générer dynamiquement tout un toolkit Elm en allant juste interroger les données d'introspection d'un serveur graphql et donc ensuite, le développeur n'a juste qu'à écrire ses requêtes en ayant une très forte garantie de fonctionnement à la compilation. C'est vraiment caviar.

Exactement. Et ça ne fonctionne que parce qu'on a derrière des outils de type virtualdom qui optimisent de ouf ce qu'il faut changer dans le (vrai) DOM en fonction de ta vue.
Bref, le virtualdom est certes regénéré à chaque changement de ton modèle de données (et encore, c'est vraiment un raccourci car on peut également optimiser cette partie), mais le "moteur" de rendu (react ou vuejs, ou Elm) est intelligent et va juste toucher ce qu'il faut sur ton DOM.
Donc, il ne faut avoir aucun scrupule quand on se dit "mais, c'est curieux que ma vue soit générée au moindre changement d'état", car ça marche plutôt bien.