Guillaume Denry a écrit 2937 commentaires

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.

Les trucs à la redux ou vuex proposent surtout un formalisme pour encourager le développeur à épouser les concepts de flot de données unidirectionnel.
En bref, idéalement, tu as UN état centralisé pour ton application, qui va permettre de "rendre" ta vue, et ta vue va ensuite émettre des événements qui vont provoquer la modification de ton état centralisé, qui va provoquer un nouveau rendu de ta vue, etc etc.

Dans ce système, le moindre élément de la vue est affiché en fonction de données de ton état et il est souhaitable de ne pas avoir des "morceaux" d'état stockés ailleurs que dans ton état central (genre l'item courant d'une combobox, l'élément qui a le focus, etc).

C'est souvent difficile d'être pur à ce niveau là, surtout avec des frameworks javascripts, mais il y a des environnements où c'est plus facile et où l'on a pas le choix. Je pense en particulier à mon petit chouchou : Elm.

Le fait également de ne pas avoir le choix que de passer par un système de messages (on peut les appeler aussi "action" dans certains frameworks) pour modifier l'état permet de soulager la charge cognitive qu'on doit se traîner quand on essaye de comprendre un code.

Non, je répondais à Nanawel, et la confusion vient de se phrase "En tant que développeur back…"

Mais j'avoue que ça me démangeait de faire le même commentaire directement en réponse à ton nourjal :)

Un cri de désespoir, sûrement…

Je réalise que j'ai un peu compris ton commentaire de travers, tu parlais de front uniquement, sorry.

En tant que développeur sur un "gros" projet nodejs pro depuis quelques années, je n'ai qu'une seule envie, c'est d'aller me balader dehors avec une pancarte sur laquelle serait écrit "N'utilisez surtout pas cette techno ! Fuyez, pauvres fous ! La fin est proche !".

Au début du projet, c'est fun, javascript te permet d'aller très vite, tu déclares un nom de paramètre dans ta fonction comme ça et paf, tu t'en sers direct. Tu veux un serveur web ? C'est fait en 3 lignes ! Wow et puis Express est vachement simple et sympa à utiliser !
Et puis au fil des mois, des années, tu réalises que l'extrême liberté dont tu disposes pour faire absolument tout ce que tu veux se transforme peu à peu en espèce de dette technique monstrueuse, à moins d'avoir couvert absolument toutes tes arrières avec des millions de tests auto. Tu réalises aussi que le monothread pour faire du traitement - parce qu'au bout d'un moment, ton back va forcément faire du traitement - à côté de la prise en charge des requêtes, c'est vraiment la cata absolue, alors tu regardes autour de toi, on te parle de workers, de microservices, etc, alors que ton appli ne gère juste que quelques milliers de connexions à tout casser et que tu veux juste faire un petit calcul sur tes données en même temps, et ton back en a déjà raz la gueule.

Après, tu vois des petits copains à côté qui sont partis sur une stack elixir et qui font tourner une appli qui gère des centaines de milliers de connexions et qui font simultanément le même genre de traitement que toi en même temps et qui commencent juste à se demander s'il faudrait pas modulariser l'appli, pour des raisons fonctionnelles différentes des performances.
Et là, tu pleures.

Donc non, tu ne rates pas grand chose.

Je suis un peu triste, j'aimais beaucoup ses films, surtout Manhattan.

Tu as raison de contre-balancer les arguments de l'article, mais comme toujours, je pense que la vérité de se trouve à mi-chemin.
Si on prend les faits et rien que les faits, un utilisateur qui souhaite recevoir et envoyer des mails n'a pas des besoins beaucoup plus raffinés qu'il y a 10 ou 15 ans, et pourtant, même ce genre d'appli (pas toutes bien sûr) prend désormais un temps fou rien qu'à se lancer. Moi je veux juste écrire mon fucking mail, quoi, pas charger des Mo de javascript.
Je pense que l'informatique est un domaine où on tolère beaucoup plus que dans d'autres (aéronautique, mécanique) l'exploitation insensée de ressources, et du coup, tout le monde s'en fout, puisque de toute façon "l'appli tourne" et "n'est pas critique".
De plus, en lisant ton message, j'ai l'impression que tu nous dépeins la situation chez toi au niveau de l'ingénierie logicielle qui semble assez saine, mais je ne sais pas ce qui te conduit à généraliser.
Tout cela n'est pas sain, pas sain du tout, surtout qu'on ne se dirige pas vers un monde où l'énergie sera de plus en plus disponible.

Le nouveau gmail est abominablement lent, moi qui était fan de son efficacité à une époque, je commence sérieusement à me demander si je ne vais pas tout migrer ailleurs. Ils sont devenus complètement fous…

Bin visiblement, c'est pas un "problème" pour eux.

C'est juste qu'en parler comme si ça coulait de source, je trouve ça rigolo.

Note quand même que ta première réaction faisait écho à "Le mode de développement de Rust est très ouvert, comme Mozilla sait si bien le faire."

On attend toujours que tu nous expliques en quoi un mode de développement ouvert est synonyme de "réussite systématique".

et la façon de transmettre les tâches sur le serveur distant sont eux aussi un régale.

Tu peux développer stp ?

Tu peux me montrer un exemple de code elixir mutable stp ?

OK et dans un code source de logiciel de rencontre ?

Je sais où tu veux m'emmener, et non, il n'y a pas forcément de règle systématique et d'algorithme pour savoir si en fonction d'un contexte A et d'une phrase B on peut dire si c'est *phobe ou pas.

Mais tu peux aussi faire confiance à ton intuition pour saisir l'intention de l'auteur lorsqu'il utilise une telle phrase dans le contexte public où il l'utilise. Sur la présentation d'un site de rencontre, un exemple où l'on choisit uniquement les femmes lorsqu'on est un homme ne me semblerait pas homophobe.

Non, c'est pas son argumentation qui perd de sa substance, en tout cas, c'est pas ce que j'ai voulu dire :-)

Je voulais juste dire que l'utilisation de la phrase "je refuse toute relaxation sexuelle avec des hommes" dans le contexte où on souhaite contre-argumenter avec quelqu'un pour prouver que dire sa préférence (de façon décontextualisée là pour le coup) n'est pas raciste/homophobe/etc passe à côté du propos, puisque le soucis n'est précisément pas là. C'est typiquement un homme de paille, quoi.