Faut-il migrer de JavaScript vers PureScript ? Oui

Version imprimable

Voir 40 message(s) de cette discussion en une page

23/05/2019, 08h54
Bill Fassinou

1 pièce(s) jointe(s)

Faut-il migrer de JavaScript vers PureScript ? Oui

Faut-il migrer de JavaScript vers PureScript ? Oui,
car, JavaScript serait très limité pour la programmation fonctionnelle, selon Alex Kelley

Pourquoi les programmeurs semblent-ils détester JavaScript ? Dans un sondage effectué récemment au sein du club, un peu plus de 52 % des développeurs ont désigné le JavaScript comme le langage de programmation qu’ils détestent le plus en 2019. Les avis étaient divers, la plupart évoquant un débogage difficile avec le langage, sa forme non typée, une façon « stupide » de gérer l’orientée objet et le fait que ce dernier permet d’ajouter facilement des bogues à son programme. Le JavaScript commence-t-il donc à être déprécié de tous ?

En se basant sur un autre aspect de la programmation, la programmation fonctionnelle (PF), Alex Kelley, développeur Web, a expliqué cette semaine que le JavaScript est très limité sur ce point et donc, qu’il faudrait penser à migrer vers un autre langage, PureScript. Selon lui, bien que le JavaScript reprenne assez bien certaines abstractions de la programmation fonctionnelle, ce dernier n’est pas du tout adapté pour cette architecture de travail. Si vous décidez quand même de faire de la programmation fonctionnelle avec le JavaScript, vous vous rendrez vite compte, dit-il, qu’il est facile de s’égarer, puis vous retrouvez vos habitudes anciennes et impératives.

Mais pourquoi parle-t-il de la programmation fonctionnelle ? Selon lui et beaucoup d’autres, la programmation fonctionnelle est en train de devenir la nouvelle tendance chez les programmeurs. Il s’agit en effet d’un paradigme de la programmation de type déclaratif qui considère le calcul en tant qu'évaluation de fonctions mathématiques. Comme le changement d'état et la mutation des données ne peuvent pas être représentés par des évaluations de fonctions, la programmation fonctionnelle ne les admet pas, au contraire elle met en avant l'application des fonctions, contrairement au modèle de programmation impérative qui met en avant les changements d'état. La programmation fonctionnelle s'affranchit de façon radicale des effets secondaires (ou effets de bord) en interdisant toute opération d'affectation.

Pièce jointe 477363

Ainsi, un langage fonctionnel est donc un langage de programmation dont la syntaxe et les caractéristiques encouragent la programmation fonctionnelle. Alors que l'origine de la programmation fonctionnelle peut être trouvée dans le lambda-calcul, on estime que le langage fonctionnel le plus ancien est Lisp, créé en 1958 par McCarthy. Lisp a donné naissance à des variantes telles que Scheme (1975) et Common Lisp (1984) qui, comme Lisp, ne sont pas ou peu typées. Des langages fonctionnels plus récents tels ML (1973), Haskell (1987), OCaml, Erlang, Clean et Oz, CDuce, Scala (2003) ou F# sont fortement typés. Le langage PureScript s'inscrit également dans cette dynamique.

De plus, le site Web du langage lui loue les avantages suivants : il offre la possibilité de compiler en JavaScript lisible et permet de réutiliser facilement le code JavaScript existant, il possède une vaste collection de bibliothèques pour le développement, il vous permet de construire des applications du monde réel en utilisant des techniques fonctionnelles et des types expressifs (tels que les types de données algébriques et correspondance de modèles, un polymorphisme de lignes et enregistrements extensibles, un polymorphisme de rang supérieur). Alors, cela fait-il du langage PureScript un remplaçant du JavaScript sur tous les points ou seulement du point de vue fonctionnel ?

« PureScript me tient vraiment à cœur et il est devenu mon langage fonctionnel préféré au cours des six derniers mois. Cela ressemble vraiment à une construction faite à la base avec Haskell avec certaines améliorations modernes (traitement des chaînes, enregistrements, compilation en JavaScript lisible). Vous pouvez facilement gérer les dépendances afin d’incorporer l’ensemble absolument minimal de packages nécessaires à l’exécution de votre projet, et je pense que sa sécurité est inégalée », a déclaré un utilisateur pour répondre à la question.

Néanmoins, Alex Kelley reconnaît que le JavaScript prend en charge certaines des fonctionnalités les plus importantes de FP, notamment les fonctions et les fermetures de première classe et anonymes. Toutefois, a-t-il continué, JavaScript doit desservir plusieurs maîtres, y compris la programmation impérative et orientée objet. En conséquence, l'utilisation de JavaScript pour la PF est soumise à des limitations et à des compromis. En particulier, il manque un système de types statique, une pureté forcée et une immuabilité.

Certaines de ces lacunes peuvent être atténuées en ajoutant un vérificateur de type statique comme Flux, des collections immuables et des bibliothèques d'abstraction. Cela signifie que la programmation fonctionnelle en JavaScript est principalement réalisée par convention, souvent pavée avec les « pansements » sus-cités. Un programmeur JavaScript fonctionnel doit rester vigilant à tout moment pour créer des fonctions pures qui évitent les effets secondaires, ce qui met trop de charges cognitives sur le programmeur et finit par gêner le codage de votre application. C’est à ce moment qu’intervient PureScript, a-t-il souligné.

Le langage PureScript vous offre des applications côté client et côté serveur. Selon Alex Kelley, vous y trouverez également une représentation de toutes les constructions de langage FP que vous avez probablement déjà entendues ou lues, y compris la curryfication (currying), la correspondance de modèle, l’optimisation des appels de queue et les types d'ordre supérieur et élevé. Il faut noter qu’en informatique et plus précisément en programmation fonctionnelle, la curryfication est la transformation d'une fonction à plusieurs arguments en une fonction à un argument qui retourne une fonction sur le reste des arguments.

La curryfication permet de créer des fonctions pures. L'opération inverse est possible et s'appelle la décurryfication. Le terme vient du nom du mathématicien américain Haskell Curry, bien que cette opération ait été introduite pour la première fois par Moses Schönfinkel. Enfin, a décrit Alex Kelley, PureScript n'a pas de système d'exécution pour ajouter à votre empreinte de téléchargement et en plus, il existe un FFI (foreign function interface) simple et très performant pour JavaScript. Donc, si vous ne trouvez pas encore de support pour les fonctions de votre module JavaScript préféré, il n’est pas difficile de les inclure vous-même, a-t-il conclu dans sa description.

Quelqu’un d’autre ajoute que le JavaScript n’est pas un langage sûr, car il compile directement sur la machine de l’utilisateur donc il peut être utilisé pour de mauvaises intentions. Il souligne également son manque d’instabilité et son manque d’efficacité. Dans le premier cas, il estime que JavaScript est interprété et lu différemment par les différents moteurs JS et en retour, vous avez autant de lectures que de moteurs. Dans le deuxième cas, il explique que tous les types de variables peuvent être stockés dans une seule et même variable et les points-virgule sont obligatoires, mais inutiles. « D’autres langages existent et sont nettement mieux que le JavaScript », a-t-il conclu.

Cela dit, d’autres par contre ne sont pas favorables à laisser tomber le JavaScript. « Le JavaScript est le langage le plus connu et le plus utilisé. Du coup, statistiquement c’est celui qui fait le plus parler de lui. Cela traduirait peut-être le fait que la plupart des développeurs ne sont pas aussi bons que ça. Et tous les autres arguments anti-JS sont exactement dans le même genre, a chaque fois c’est issue d’un anti-pattern, d’une mauvaise utilisation », déclaré l’un d’entre eux.

Source : Billet de blog

Et vous ?

:fleche: JavaScript ou PureScript, lequel des deux langages choisissez-vous ? Pourquoi ?
:fleche: PureScript pourra-t-il remplacer le JavaScript ?
:fleche: Connaissez-vous une autre alternative au PureScript pour la programmation fonctionnelle ?

Voir aussi

:fleche: Sondage : quels sont les langages de programmation que vous détestez le plus en 2019 ? Pourquoi ?

:fleche: Le langage JavaScript est-il responsable de la lenteur des sites Web de nos jours ? Oui selon un expert

:fleche: AlaSQL.js, une base de données SQL JavaScript pour le navigateur et Node.js, est désormais disponible. Il serait rapide et très flexible
23/05/2019, 09h31
eleydet

Bonjour,

Il est écrit :

Citation:

Pourquoi les programmeurs semblent-ils détester JavaScript ?

Le JavaScript laisse rarement indifférent : Bien souvent, on l'adore ou on le déteste. Bien des programmeurs trouvent ce langage merveilleux.
23/05/2019, 10h01
SpaceFrog

Allez petit pari sur l'avenir ...
Comme toutes les autres tentatives de remplacement de JS... flop dans 6 mois ..
23/05/2019, 10h04
Drowan

Le vrai problème de ce genre de sondage est qu'il révèle surtout quels languages sont les plus populaires et c'est un peu tout.
Javascript étant un des language les plus connus et les plus pratiqué, il est logique qu'il possède le plus de programmeurs mécontents et de programmeurs contents.
En prenant le sondage, On pourrait se dire que Haskell est aimé puisque peu de gens on voté pour dire qu'il ne l'aimait pas, mais je soupçonne plutôt que peu de gens le connaisse et donc n'ont pas voter pour lui faute de pouvoir émettre un avis.

Il faudrait pouvoir répondre par Aime, n'aime pas, ne connait pas. Pour pouvoir plutôt présenté la proportion de programmeur connaissant un langage mais ne l'appréciant pas.
23/05/2019, 10h13
Daïmanu

Ma question peut paraître naïve, mais vu qu'à ma connaissance seul le javascript permet de scripter les pages web, peut-être il serait judicieux de permettre au navigateur d'interpréter d'autres langages ?
À partir du moment ou ce remplaçant sait manipuler le DOM et d'autres APIs, et qu'il tourne dans une sandbox, ça doit être jouable ?
Ça permettrait de programmer en Typescript, en Python ou autre.
Et ça serait plus constructif que cet éternel débat sur la valeur du javascript.
23/05/2019, 10h14
koyosama

Je croyais qu'on avait déjà la réponse avec Web Assembly. Juste une question de temps, non.
23/05/2019, 11h53
NBoulfroy

"Nieu nieu nieu, je suis nul en JS alors c'est forcément un langage à haïr" est l'argument le plus fréquent que j'ai vu à ce jour avec les développeurs.

Au départ, je supportais pas ce langage, j'ai mis le nez dedans par la force et au final, j'adore : c'est ultra intéressant de développer en JS Vanilla (à mort jQuery !) bien que j'admets qu'il souffre d'une lourdeur importante par moment (m'enfin, il y a des astuces pour ça).

J'avoue que la notion de Prototype est pas évidente mais quand même, vous pouvez pas dire que c'est "nul" et "insupportable" si vous avez pas au moins fait du forcing et pondu un système AJAX & gestion formulaire en JS Vanilla via Prototype à mes yeux (c'est un exemple parmi d'autres possibles évidemment).

Il faut désormais que je vois la question de l'injection de modules dans un JS Vanilla pour avoir quelque chose de très intéressant (modulation selon la librairie CSS utilisée parce que les classes entre Bootstrap, Fondation & Materialize (c'est des exemples) ne sont hélas pas les mêmes).
23/05/2019, 12h43
imag1

le problème de JavaScript est que le typage est extrêmement faible, on peut tout mettre dans une variable, d'un int à une fonction en passant par un objet.
on ne peu pas se reposer sur le compilateur pour voir les erreurs.

cela demande donc une hygiène de dev implacable.
23/05/2019, 12h47
KsassPeuk

Citation:

Envoyé par imag1

le problème de JavaScript est que le typage est extrêmement faible, on peut tout mettre dans une variable, d'un int à une fonction en passant par un objet.

Oui, c'est l'extreme late binding of everything cher à Kay. Ça a ses avantages et ses inconvénients.
23/05/2019, 13h41
mh-cbon

pourquoi pas..... Dans son argumentaire je n'ai pas trouvé de justifications certaines que le pure fonctionnel produira moins de bug... Mais pourquoi pas le passer sous les fourches caudines de plusieurs centaines de milliers de dév qu'on soit fixé une bonne foi pour toutes.
23/05/2019, 13h55
LordJerem

peut-être pour faire de la programmation fonctionnelle, sinon non
23/05/2019, 14h15
Engiwip

TypeScript et son alternative Babel + flow existe, pas besoin de plus.

Purescript, ReasonML, Coffescript... c'est juste pour briller à l apero en fin de meetup :mrgreen:
23/05/2019, 15h41
Lcf.vs

Citation:

Envoyé par imag1

cela demande donc une hygiène de dev implacable.

C'est surtout cela, qui pose problème aux détracteurs du JS... après, à mon sens, que le langage soit strict ou non, le dev qui l'utilise devrait, de base, toujours avoir cette une hygiène de dev implacable, du coup, osef que le langage le soit ou non.
23/05/2019, 15h52
tarte-aux-fraises

Mouais, ce ne sont que de mauvais programmeurs qui veulent encore tout simplifier. JavaScript est un outil extrêmement puissant, le problème est que pour en faire le tour, ça prend des années. Non seulement ça prend des années mais en plus, il faut coder proprement pour faire une bonne appli. C'est ça qui les ennuie, certainement, eux veulent le beurre et l'argent du beurre, un langage de programmation qui fait tout à leur place.
C'est à cause de ces fainéants qu'il y a de plus en plus de code sale sur internet et que les sites web rament la mort. Il faut fuir comme la peste ces pseudo-langages de programmation qui ne sont en fait que des librairies très lourdes pour le client et totalement inutilisables seules.
23/05/2019, 16h01
AoCannaille

Citation:

Envoyé par Lcf.vs

C'est surtout cela, qui pose problème aux détracteurs du JS... après, à mon sens, que le langage soit strict ou non, le dev qui l'utilise devrait, de base, toujours avoir cette une hygiène de dev implacable, du coup, osef que le langage le soit ou non.

:roll:

Errare humanum est

Une erreur ça peut arriver. Et dans un environnement correct ça ne se transforme pas en bug systématiquement.
23/05/2019, 16h10
Lcf.vs

En effet, c'est pour ça qu'on centralise sa validation, qu'on place des garde-fous, ... c'est juste une question de méthodologie que tu devrais avoir quel que soit le langage, le langage en question pouvant accessoirement juste réduire les contrôles à faire.
23/05/2019, 16h28
Watilin

JS est détesté pour tout un tas de raisons. Les mauvais aspects du langage sont dûs à son histoire, et plus précisément à sa dépendance à l’Histoire. Par exemple, on ne peut pas supprimer document.write() parce que des sites web utilisent encore cette fonction aujourd’hui. On ne peut pas réparer typeof null === "object" parce que des scripts tiennent compte de ce résultat. Etc.

Je suis prêt à adopter n’importe quel langage de remplacement s’il est nativement pris en charge par les principaux navigateurs. (Et s’il n’est pas conçu avec des moufles.) Mais ça n’arrivera pas demain…
23/05/2019, 16h35
Lcf.vs

Citation:

Envoyé par Watilin

JS est détesté pour tout un tas de raisons. Les mauvais aspects du langage sont dûs à son histoire, et plus précisément à sa dépendance à l’Histoire. Par exemple, on ne peut pas supprimer document.write() parce que des sites web utilisent encore cette fonction aujourd’hui.

Hum, le problème n'est pas document.write() mais ce qu'on en fait... j'avais fait un article, il y a quelques années, concernant un usage légitime de cette fonction : la création de documents virtuels, avec un autre window que le window courant... il n'existe pas d'autre moyen de le faire (hormis jouer avec des iframes, mais c'est un peu trop bricolage)

Je serais curieux de savoir, d'après toi, pourquoi il faudrait carrément supprimer la fonctionnalité.

Puis ce n'est pas propre au JS mais à l'implémentation, ça, DOM, qui plus est.
23/05/2019, 17h04
AoCannaille

Citation:

Envoyé par Lcf.vs

En effet, c'est pour ça qu'on centralise sa validation, qu'on place des garde-fous, ... c'est juste une question de méthodologie que tu devrais avoir quel que soit le langage, le langage en question pouvant accessoirement juste réduire les contrôles à faire.

évidement. Mais tout ça n'est qu'une question de pognon.

Quand tu suis le cycle en V (et on le fait tous, tout le temps, il n'existe pas d'autre méthode, l'agilité étant juste des cycle en V sur des scopes minuscules), sâche que plus une erreur est détecté tôt, moins elle coûte cher à corriger.

Avec un langage compilé , toutes les erreurs de syntaxes sont repérées à l'étape de développement, alors qu'avec un langage interprété, certaines peuvent être repérées pendant les TU (éventuellement toutes si les tests couvrent 100% du code), puis certaines peuvent être repérées pendant les tests composants puis certaines peuvent être repérées pendant les tests d'intégration, puis certaines peuvent être repérées pendant les test de validation, et enfin certaines peuvent être repérées en production.

Là, je ne parle que de syntaxe (genre une typo dans un nom de variable et baaaam undefined reference) et pas d'erreur de typage.

en ça, d'un point de vue industriel, professionnel, un langage interprété sera toujours inférieur à un langage compilé. Dans le cas particulier du JS, il y a beaucoup trop d'erreur de typages possible provoquant coup sur coup des bugs.

Et a ma connaissance, pas des 'ptits bugs hein, des scripts entiers qui s'arrêtent net, pas des exceptions catchable et dont on peut se dépatouiller...

Le coût de ta méthodologie réduit si tu supprimes cette contrainte, et avec le même budget tu peux faire des choses plus avancées en terme d'IVV.

Le succès de Javascript tient effectivement à son monopole forcé sur navigateur.
23/05/2019, 17h12
NBoulfroy

je n'avais pas vu ça dans ce sens pour la question du coût des langages interprétés.

Donc, en dehors d'ASP.NET, Python et Java, il y a pas d'alternative réelle et sérieuse à ce défaut qu'on les langages comme JavaScript, PHP & cie (je ne suis pas expert dans les langages compilés, désolé) ?

Pour la question de la dominance de Javascript, je pense que c'est aussi parce qu'on a pas trouvé mieux pour le travail demander ... Si, éventuellement Kotlin mais je pense qu'il ne fait que compiler en JS le code quand on l'utilise en web (enfin, je dis bien "je suppose" car je ne suis pas sûr à 100%).
23/05/2019, 17h37
Marco46

Citation:

Envoyé par AoCannaille

Avec un langage compilé , toutes les erreurs de syntaxes sont repérées à l'étape de développement, alors qu'avec un langage interprété, certaines peuvent être repérées pendant les TU (éventuellement toutes si les tests couvrent 100% du code), puis certaines peuvent être repérées pendant les tests composants puis certaines peuvent être repérées pendant les tests d'intégration, puis certaines peuvent être repérées pendant les test de validation, et enfin certaines peuvent être repérées en production.

Là, je ne parle que de syntaxe (genre une typo dans un nom de variable et baaaam undefined reference) et pas d'erreur de typage.

en ça, d'un point de vue industriel, professionnel, un langage interprété sera toujours inférieur à un langage compilé. Dans le cas particulier du JS, il y a beaucoup trop d'erreur de typages possible provoquant coup sur coup des bugs.

Si tu veux réduire le nombre de bug dans tes applis ce n'est pas le fait d'avoir du typage statique ou non qui va jouer là dessus.

Ce n'est pas parce que ton programme compile qu'il :

- ne provoquera pas de crash à l'exécution
- est valide fonctionnellement (qu'il satisfait le besoin)

Pour savoir ça il n'y a qu'une bonne politique de test. Et avec une bonne politique de test tu vas couvrir les problèmes levés par le typage statique dans la foulée. Comment ton test peut-il s'exécuter si tu as un undefined au runtime ? Tu vois ça immédiatement.

Perso j'ai fait plusieurs années de Java pour passer à du JavaScript et je ne constate pas une hausse du nombre de bugs du à l'absence de typage que ce soit de mon fait ou de celui des autres devs.

C'est très très rare dans les faits.

Là où le typage statique est surtout intéressant c'est qu'il documente et clarifie considérablement le code et sa conception. Pour avoir migré des projets de JS vers TS j'ai constaté ça. Ca n'a pas levé de bugs, par contre ça a forcé à clarifier les contrats et donc le code.

Donc le typage statique a indéniablement un impact sur le cout de la TMA en faisant baisser le brain overloading du développeur parce qu'il force une clarification explicite des entrées / sorties des fonctions.

Mais ça n'a pas de rapport avec les bugs, ça c'est du ressort des tests automatisés.

Si tu as des bugs dont la source est l'absence de typage statique, la bonne conclusion ce n'est pas qu'il te faudrait un langage à typage statique mais c'est que tu testes mal ton application. Tu dois voir ces problèmes immédiatement.

Pour être plus concret si ton commit ne contient les tests qui valident la révision, tu as un problème et ça n'a rien à voir avec la présence ou l'absence de typage statique.
23/05/2019, 17h58
Lcf.vs

Tout est dit ^^
24/05/2019, 04h00
air-dex

Au bon endroit au bon moment
Toujours la même chose avec JavaScript : de nombreuses critiques, mais au final il est et sera toujours là, encore plus vivant que jamais.

La chance de JavaScript aura été d'être là au bon endroit et au bon moment. Nous sommes au carrefour des années 2000 et 2010. Steve Jobs puis Mozilla ont lancé la chasse aux sorcières consistant à éradiquer les plugins de nos navigateurs Web. Loin de moi l'idée de relancer ces débats là, ce n'est pas le sujet ni mon intention. Toujours est-il que sans Flash, ni Java, ni Silverlight, ni tous les autres, que reste-t-il aux développeurs pour faire du Développement Web côté client ? La réponse est très simple : "JavaScript, et rien que JavaScript". JS a beau être critiqué, toujours est-il que ça reste le seul langage tournant sur nos navigateurs Web et qu'il sera incontournable tant que ça sera le cas.

Toutes les joyeusetés genre CoffeeScript, TypeScript, PureScript ne font au final qu'écrire du JS à la place du développeur, qui peut ainsi se vanter de ne pas s'être sali les mains avec ça. JS n'est pas aussi cryptique que de l'Assembleur. Faut pas déconner non plus.

JS ne cédera sa place que lorsque d'autres langages seront interprétés par les navigateurs, ou plutôt massivement interprétés par tous les navigateurs. Google avait commencé quelque chose sur ce plan là avec Dart mais ils étaient seuls et ont échoué.

Après reste la question de PureScript. Je trouve les arguments foireux :

Citation:

- Pourquoi migrer vers PureScript ?
- Parce que c'est de la programmation fonctionnelle !
- Pourquoi de la programmation fonctionnelle ?
- Parce que c'est à la mode !

En 2020 on aura le même article avec du C++ pour du Web côté client parce que la programmation fonctionnelle c'est "so 2019" et que la POO c'est "so 2020". :aie:

Cela étant je reconnais que le monopole du trio HTML/CSS/JS sur navigateurs est problématique, tant pour les paradigmes de développement " " "backend" " " côté client que pour la conception d'interface.

Parce que c'est pareil avec la conception d'interface. Le couple HTML/CSS n'est pas non plus ce qui se fait de mieux pour construire des interfaces. Du moins par pour tout le monde.

Citation:

Envoyé par Daïmanu

Ma question peut paraître naïve, mais vu qu'à ma connaissance seul le javascript permet de scripter les pages web, peut-être il serait judicieux de permettre au navigateur d'interpréter d'autres langages ?
À partir du moment ou ce remplaçant sait manipuler le DOM et d'autres APIs, et qu'il tourne dans une sandbox, ça doit être jouable ?
Ça permettrait de programmer en Typescript, en Python ou autre.
Et ça serait plus constructif que cet éternel débat sur la valeur du javascript.

Idée de génie sur le papier, mais comment intègres-tu les langages ?
- Soit le navigateur le supporte nativement et il n'y a rien à faire.
- Soit le navigateur ne le supporte pas nativement. Dans ce cas là il te faut étendre le navigateur, donc l'affubler d'un plugin. Or je rappelle que les greffons sur les navigateurs Web c'est tabou depuis le début des années 2010. Donc pas possible.
Il y aura également la question de qui couvre quoi. Un langage sera supporté par un navigateur mais pas par un autre. Sans parler de l'OS sur lequel tourne ton navigateur, ni des versions des navigateurs (mais ceci tend à disparaître, enfin je pense). Est-ce que les gens ont envie de revenir à "l'époque Flash" pour les greffons, au delà des problèmes de performances, de stabilité et de consommations de ressources ? Je ne pense pas. :aie: Est-ce que les développeurs ont envie de revenir à la bonne vieille époque où certaines choses étaient supportées par certains navigateurs et pas par d'autres, avec par exemple des sites qui boguent parce qu'ils utilisent du Python et parce que le navigateur du client ne comprend pas ce qui est écrit entre balises <script type="application/x-python"> ? Qui veut un nouveau VBScript, ou plutôt plein de nouveaux VBScript ? :aie:
24/05/2019, 09h51
KsassPeuk

Citation:

Envoyé par Marco46

Si tu veux réduire le nombre de bug dans tes applis ce n'est pas le fait d'avoir du typage statique ou non qui va jouer là dessus.

Ce n'est pas parce que ton programme compile qu'il :

- (1) ne provoquera pas de crash à l'exécution
- (2) est valide fonctionnellement (qu'il satisfait le besoin)

(1) Si ton système de types te le garantit, et il y en a, tu n'auras pas de crash.

(2) Si tu as des types dépendants et que tu prends la peine de les utiliser pour spécifier le besoin, tu peux.
24/05/2019, 09h54
Marco46

Citation:

Envoyé par air-dex

Toutes les joyeusetés genre CoffeeScript, TypeScript, PureScript ne font au final qu'écrire du JS à la place du développeur, qui peut ainsi se vanter de ne pas s'être sali les mains avec ça.

TypeScript n'est pas un langage à part entière, c'est une extension de JavaScript. Il ne peut pas être placé dans la même catégorie que CoffeeScript, PureScript ou Dart qui ont une syntaxe qui leur est propre.

Citation:

Envoyé par air-dex

En 2020 on aura le même article avec du C++ pour du Web côté client parce que la programmation fonctionnelle c'est "so 2019" et que la POO c'est "so 2020". :aie:

Ce n'est pas une mode par hasard, c'est une mode parce que ça répond à un besoin. Le dev d'applications web depuis quelques années c'est des Single Page Application. Donc de l'app qui s'exécute dans le browser en restant toujours sur la même page. Du coup gestion de state. Du rajoute à ça l'asynchrone et te retrouves avec un sacré bordel.

L'immutabilité et l'absence d'effets de bord liés à ce paradigme facilitent considérablement l'écriture d'applications dans ce contexte.

Regardez l'évolution des outils, on passe de plats de nouilles vers des choses structurées pour permettre facilement le paradigme fonctionnel : Backbone / ... -> AngularJS / Ember / ... -> React / Vue / ...
24/05/2019, 10h01
Marco46

Citation:

Envoyé par KsassPeuk

(1) Si ton système de types te le garantit, et il y en a, tu n'auras pas de crash.

Que tu obtiennes le crash à la compilation ou lors de l'exécution d'un TU qu'est-ce que ça change ? Tu l'as 2s après avoir écrit le code dans les deux cas.

Citation:

Envoyé par KsassPeuk

(2) Si tu as des types dépendants et que tu prends la peine de les utiliser pour spécifier le besoin, tu peux.

Tu es entrain de dire que l'on peut vérifier la validité d'un programme sans l'exécuter ... :weird:
24/05/2019, 10h12
KsassPeuk

Citation:

Envoyé par Marco46

Que tu obtiennes le crash à la compilation ou lors de l'exécution d'un TU qu'est-ce que ça change ? Tu l'as 2s après avoir écrit le code dans les deux cas.

Ça dépend de ton outillage. Mais c'est pas rare que de bons environnements te permettent de voir dès la sauvegarde de ton fichier que tu as fait une connerie avec tes types, c'est encore bien plus rapide que d'avoir à exécuter tes tests (exemple qui me vient en tête en premier, dans je dév en Ocaml avec Merlin, sauvegarder permet de voir le problème immédiatement pour ainsi dire tout le temps, et c'est assez rapide pour ne pas avoir la moindre latence même quand le fichier fait des milliers de lignes).

Par ailleurs, la production des TUs pour les situations de crash, c'est toujours des TUs en plus que tu pourrais ne pas avoir à écrire.

Après, je dis pas que l'autre solution est impraticable. Juste que certains systèmes de types te garantissent effectivement l'absence crash for free.

Citation:

Envoyé par Marco46

Tu es entrain de dire que l'on peut vérifier la validité d'un programme sans l'exécuter ... :weird:

Bien sûr, ça existe depuis pas mal d'années déjà, et c'est lié aux méthodes formelles. Il y a diverses manière de faire, ça peut être par un outil externe quand le langage n'est pas directement outillé pour ça (voir par exemple, Spark (Ada), Microsoft VCC (C), EVE Autoproof (Eiffel), KeY (Java), Frama-C (C), et bien d'autres), ou ça peut être fait directement au niveau du langage (F-Star, Coq, Agda, Idris, ...).
24/05/2019, 10h29
AoCannaille

Citation:

Envoyé par Marco46

Si tu as des bugs dont la source est l'absence de typage statique, la bonne conclusion ce n'est pas qu'il te faudrait un langage à typage statique mais c'est que tu testes mal ton application.

Citation:

Envoyé par Marco46

Que tu obtiennes le crash à la compilation ou lors de l'exécution d'un TU qu'est-ce que ça change ? Tu l'as 2s après avoir écrit le code dans les deux cas.

Au prix d'une couverture de TU à 100% (comme dit dans mon premier message hein...)
Peut être que je taffe dans des mauvaises boites, j'aimerais bien vos avis là dessus, mais en pourcentage de projets de plus de 50kloc, combien en avez-vous couvert à 100%?

Même en avionique on n'y arrive pas forcément! On arrivait à 97% de couverture, les 3autres% étant démontrés mathématiquement comme , le reste de mes projets allant de 20 à 50% de couverture.

Si là, vous me dites tous en coeur "tous mes projets JS ont une couverture à 100%", je m'incline, pas de soucis. En attendant, même avec 0% de couverture de code, un langage compilé d'aura, pas définition, aucune chance d'avoir un undefined à cause d'une typo dans le nom d'une variable.

Citation:

Tu es entrain de dire que l'on peut vérifier la validité d'un programme sans l'exécuter ... :weird:

La validité de type, oui, évidement, c'est une des particularités essentielles des langages fonctionnels type OCaml, Haskell et autre.
24/05/2019, 12h42
shenron42

Oui, c'est un vieil article, mais juste pour le LOL, et parce que le JS c'est beau :heart: :

http://sametmax.com/un-gros-troll-de...r-javacscript/
24/05/2019, 12h52
Marco46

Citation:

Envoyé par KsassPeuk

Ça dépend de ton outillage. Mais c'est pas rare que de bons environnements te permettent de voir dès la sauvegarde de ton fichier que tu as fait une connerie avec tes types, c'est encore bien plus rapide que d'avoir à exécuter tes tests

T'es quand même entrain de me dire que c'est mieux parce que tu gagnes 1 ou 2 secondes, parce que lancer l'exécution du TU concerné et avoir son résultat c'est cet ordre de grandeur hein ... Tu chipoterais pas un peu ?

T'as même des outils qui s'intègrent à ton EDI qui exécutent les TU correspondant au fichier que tu es entrain de modifier qui te pointent en temps réel pendant que tu codes quelle ligne est en échec sur un TU.

Donc oui c'est une question d'outillage. Donc est bien d'accord que ça n'a plus aucun rapport avec la présence ou l'absence de typage statique ?

Citation:

Envoyé par KsassPeuk

Par ailleurs, la production des TUs pour les situations de crash, c'est toujours des TUs en plus que tu pourrais ne pas avoir à écrire.

Dans la mesure où je commence par écrire un test avant d'écrire du code cette phrase me pose problème.

Avant d'écrire du code je détermine ce que j'ai en entrée et ce que je veux en sortie. Et je le documente sous la forme d'un test exécutable.

Ensuite j'écris mon code. Il n'y a pas à éviter d'écrire un test, ce n'est pas une contrainte.

Après la nature du test dépend aussi beaucoup de la nature du livrable, si j'écris un outil CLI qui manipule uniquement le filesystem je vais faire du e2e, mais sur un stack web là je vais faire du TU en mockant les I/O.

Bref.

Tout ça a manifestement aussi beaucoup de rapport avec la manière de travailler.

Citation:

Envoyé par KsassPeuk

Bien sûr, ça existe depuis pas mal d'années déjà, et c'est lié aux méthodes formelles. Il y a diverses manière de faire, ça peut être par un outil externe quand le langage n'est pas directement outillé pour ça (voir par exemple, Spark (Ada), Microsoft VCC (C), EVE Autoproof (Eiffel), KeY (Java), Frama-C (C), et bien d'autres), ou ça peut être fait directement au niveau du langage (F-Star, Coq, Agda, Idris, ...).

Je pense qu'on se comprend mal, quand je parle d'exécuter le programme je veux dire exécuter le code. Exécuter un TU c'est exécuter le code. Typer ton code ne garanti en aucune façon que son exécution sera correcte fonctionnellement. Un test oui.

Citation:

Envoyé par AoCannaille

Au prix d'une couverture de TU à 100% (comme dit dans mon premier message hein...)

Pas tout à fait il y a toujours des morceaux qui ne le sont pas selon comment tu calibres ton outil de coverage mais oui et je ne vois pas où est le problème.

Ça permet au contraire d'aller plus vite. Évidemment il faut avoir assez de pratique pour que ça soit rentable, comme pour tout.

Citation:

Envoyé par AoCannaille

Peut être que je taffe dans des mauvaises boites, j'aimerais bien vos avis là dessus, mais en pourcentage de projets de plus de 50kloc, combien en avez-vous couvert à 100%?

Ca dépend effectivement de la boite et des pratiques. J'ai eu l'occasion de pouvoir lead et de faire ce que je voulais et on était autour de 80%.

Citation:

Envoyé par AoCannaille

En attendant, même avec 0% de couverture de code, un langage compilé d'aura, pas définition, aucune chance d'avoir un undefined à cause d'une typo dans le nom d'une variable.

Avec un IDE digne de ce nom tu sauras ça avant même de compiler ou d'exécuter les tests.

Je parlais plutôt du cas ou tu appelles une variable qui existe, donc spellée correctement mais qui dans ce contexte est undefined ou null. C'est là où le typage statique est intéressant mais tu vas couvrir ce cas avec tes tests, et si tu ne le fais pas avec des tests ça veut dire que tu testes à la main (ce qui est certes la pratique la plus répandue) en lançant ton appli ou pire que tu livres sans tester.

Citation:

Envoyé par AoCannaille

La validité de type, oui, évidement, c'est une des particularités essentielles des langages fonctionnels type OCaml, Haskell et autre.

Je ne parlais pas de la validité de type mais de la validité du programme par rapport au besoin.

Citation:

Envoyé par Marco46

T'es quand même entrain de me dire que c'est mieux parce que tu gagnes 1 ou 2 secondes, parce que lancer l'exécution du TU concerné et avoir son résultat c'est cet ordre de grandeur hein ... Tu chipoterais pas un peu ?

Sur un langage compilé, ça implique potentiellement de recompiler des parties d'un projet juste de pouvoir exécuter les tests (et généralement c'est plus d'une ou deux secondes ...), et plus tu es "haut" dans ton projet plus tu vas potentiellement payer le temps d'exécution du test qui peut être long. Le retypage automatique c'est instantané. Le temps d'attente c'est 0. Mais comme je l'ai dit j'ai pas dit que c'était la seule solution. Par contre, si il y a des gros avantages sur le typage même pour l'absence de crash, voir plus bas.

Citation:

Envoyé par Marco46

Dans la mesure où je commence par écrire un test avant d'écrire du code cette phrase me pose problème.

Ça dépend ce que concerne le dit test. Avec des tests, on vise la réponse à deux questions :

- trouver des potentiels crash
- trouver des potentiels problèmes fonctionnels

Un test ça montre la présence d'un bug, jamais l'absence de bugs. Tu ne peux pas écrire des tests qui t'apportent la garantie qu'il n'y a pas de crash par exemple parce qu'il faudrait tester exhaustivement, ce qui est irréaliste. Pour la garantie d'absence de crash, un système de type bien foutu garantit l'absence de crash quel que soit le chemin d'exécution parce que c'est pas basé sur du test, c'est de la correction par construction (et généralement c'est basé sur une preuve mathématique, et quand bien même le typeur ne serait pas prouvé, s'il y avait un bug de ce côté, c'est le typeur qu'il faudrait corriger). Dans les faits, on peut effectivement écrire des tests avant de coder, et on s'en servira très probablement pour cibler le deuxième objectif.

Donc à partir de là tu as deux choix :

- considérer que si ton test fonctionnel passe tu as aussi de bonnes raisons de penser que tu n'as pas de crash
- estimer qu'il faut ajouter des tests pour garantir plus finement l'absence de crash.

Dans le premier cas, le typage statique est meilleur que ton test unitaire (qui ne considère qu'un nombre limité de scénario) parce qu'il donne la garantie pour tout scénario qu'il n'y a pas de crash. Dans le second cas, tu as besoin d'écrire des tests dont tu n'aurais pas eu besoin avec un typage statique (et tu resteras non exhaustif, donc moins bon). En l'occurrence ...

Citation:

Envoyé par Marco46

Ensuite j'écris mon code. Il n'y a pas à éviter d'écrire un test, ce n'est pas une contrainte.

Si, ce que le langage t'apporte gratuitement par le typage, tu n'as pas à le tester, c'est une perte d'énergie.

Citation:

Envoyé par Marco46

Je pense qu'on se comprend mal, quand je parle d'exécuter le programme je veux dire exécuter le code. Exécuter un TU c'est exécuter le code. Typer ton code ne garanti en aucune façon que son exécution sera correcte fonctionnellement. Un test oui.

Fait quelques recherches avec les mots clés que j'ai donné. Tu n'es pas obligé d'exécuter un code pour garantir sa correction. Exemple,

tu peux développer un programme écrit en langage C
le spécifier formellement avec un langage de spécification
établir mathématiquement la preuve que le code correspond à la spec (avec un outil comme Frama-C par exemple)
compiler ton code avec un compilateur prouvé comme CompCert

Dans le cas d'un langage comme C, en réalité il est probable que tu aies eu une phase de test par le passé parce que le langage n'est pas outillé pour passer facilement les étapes 2 et 3. Mais une fois que tu arrives à la fin de l'étape 3, tes tests tu t'en fous, t'as une garantie mathématique que le programme est correct. Et un compilateur prouvé te garantit que tu produis un code sémantiquement équivalent à ton code d'entrée.

Exemple simple pour donner l'idée des étapes 2 et 3 :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 /*@ requires 0 < length; requires \valid_read(array + (0 .. length-1)); assigns \nothing; behavior in: assumes \exists size_t off ; 0 <= off < length && array[off] == element; ensures array <= \result < array+length && *\result == element; behavior notin: assumes \forall size_t off ; 0 <= off < length ==> array[off] != element; ensures \result == NULL; disjoint behaviors; complete behaviors; */ int* search(int* array, size_t length, int element){ /*@ loop invariant 0 <= i <= length; loop invariant \forall size_t j; 0 <= j < i ==> array[j] != element; loop assigns i; loop variant length-i; */ for(size_t i = 0; i < length; i++) if(array[i] == element) return &array[i]; return NULL; }
Si tu files ce code à un outil de preuve, sans exécuter ton programme, il te dira "oui, ton programme est correct, quelque soit les entrées, tant qu'elles respectent la précondition".

Ensuite, pour le fait que le typage ne garantit pas la correction fonctionnelle, ça dépend du système de types. Si ton système de types ne permet pas l'expression de propriétés fonctionnelles, effectivement. Mais il y a des systèmes de types qui le permettent, notamment dans les langages à types dépendants (voir la liste que j'ai donné plus haut). Et dans un langage à type dépendants, équipés pour ce genre de tâches, tu écris le programme en même temps que sa preuve. Et comme ils sont généralement super bien outillés pour ce genre de tâches, c'est relativement accessible, et tu n'auras pas à faire de tests pour montrer que le programme fonctionne.

24/05/2019, 14h18
blbird

Citation:

Envoyé par KsassPeuk

- considérer que si ton test fonctionnel passe tu as aussi de bonnes raisons de penser que tu n'as pas de crash
- estimer qu'il faut ajouter des tests pour garantir plus finement l'absence de crash.

Dans le premier cas, le typage statique est meilleur que ton test unitaire (qui ne considère qu'un nombre limité de scénario) parce qu'il donne la garantie pour tout scénario qu'il n'y a pas de crash. Dans le second cas, tu as besoin d'écrire des tests dont tu n'aurais pas eu besoin avec un typage statique (et tu resteras non exhaustif, donc moins bon). En l'occurrence ...

Le typage statique meilleur que des tests (ici en particulier TDD). Ca m'apprendra à manger devant le PC, j'ai faillit m'étouffer.

Citation:

Envoyé par AoCannaille

En attendant, même avec 0% de couverture de code, un langage compilé d'aura, pas définition, aucune chance d'avoir un undefined à cause d'une typo dans le nom d'une variable.

Avec un IDE de ce nom, c'est le cas dans n'importe quel langage. Et encore une fois, ces fameuses erreurs que vous redoutez tant, elles n'arrivent réellement quasiment plus jamais, en JS ou en autre chose.
24/05/2019, 14h22
KsassPeuk

Citation:

Envoyé par blbird

Le typage statique meilleur que des tests (ici en particulier TDD). Ca m'apprendra à manger devant le PC, j'ai faillit m'étouffer.

Peut être que ce n'était pas clair : pour la partie absence de crash, dans le cadre de l'exécution du test d'absence de problème fonctionnel.

Après relecture, je vois pas comment ça pouvait ne pas être clair :

Citation:

Envoyé par KsassPeuk

- considérer que si ton test fonctionnel passe tu as aussi de bonnes raisons de penser que tu n'as pas de crash
- estimer qu'il faut ajouter des tests pour garantir plus finement l'absence de crash.

Dans le premier cas, le typage statique est meilleur que ton test unitaire (qui ne considère qu'un nombre limité de scénario) parce qu'il donne la garantie pour tout scénario qu'il n'y a pas de crash.
24/05/2019, 14h25
Marco46

Citation:

Envoyé par KsassPeuk

Sur un langage compilé, ça implique potentiellement de recompiler des parties d'un projet juste de pouvoir exécuter les tests (et généralement c'est plus d'une ou deux secondes ...), et plus tu es "haut" dans ton projet plus tu vas potentiellement payer le temps d'exécution du test qui peut être long. Le retypage automatique c'est instantané. Le temps d'attente c'est 0.

Sur JavaScript le temps d'attente pour avoir le résultat est de l'ordre de la seconde.

Citation:

Envoyé par KsassPeuk

Un test ça montre la présence d'un bug, jamais l'absence de bugs. Tu ne peux pas écrire des tests qui t'apportent la garantie qu'il n'y a pas de crash par exemple parce qu'il faudrait tester exhaustivement, ce qui est irréaliste.

Oui évidemment. Je disais juste que tu vas asserter ton fonctionnel. Je ne parlais pas d'absence de bugs dans l'absolu ...

Citation:

Envoyé par KsassPeuk

Dans le premier cas, le typage statique est meilleur que ton test unitaire (qui ne considère qu'un nombre limité de scénario) parce qu'il donne la garantie pour tout scénario qu'il n'y a pas de crash. Dans le second cas, tu as besoin d'écrire des tests dont tu n'aurais pas eu besoin avec un typage statique (et tu resteras non exhaustif, donc moins bon). En l'occurrence ...

[...]

Si, ce que le langage t'apporte gratuitement par le typage, tu n'as pas à le tester, c'est une perte d'énergie.

[...]

Et dans un langage à type dépendants, équipés pour ce genre de tâches, tu écris le programme en même temps que sa preuve. Et comme ils sont généralement super bien outillés pour ce genre de tâches, c'est relativement accessible, et tu n'auras pas à faire de tests pour montrer que le programme fonctionne.

Du coup il ne s'agit pas de tous les langages à typage statique mais de certains ?

On est d'accord que ce que tu viens de dire ne s'applique ni au Java ni au C# par exemple ?

Du coup l'argumentaire d'ensemble tombe à l'eau puisque pour avoir le bénéfice de ce "type" de typage statique qui permet d'éviter du testing il faut utiliser des langages qui ne sont à peu près jamais utilisé par 99% des développeurs qu'ils soient chez des éditeurs ou en SS2I.

Ça confirme simplement que les tests sont bien plus importants pour diminuer le nombre de bugs que d'avoir du typage statique puisque les fonctionnalités nécessaires ne sont pas présentes dans tous les langages à typage statique.

Ceci dit, je te remercie pour les infos et l'exemple concret, pas le temps d'analyser maintenant, je ne connais pas ces notions là, mais je me les mets de côté pour plus tard :)
24/05/2019, 14h35
KsassPeuk

Citation:

Envoyé par Marco46

Du coup il ne s'agit pas de tous les langages à typage statique mais de certains ?

Il faut regarder au cas par cas, les garanties sont légèrement différentes d'un langage à l'autre.

Citation:

Envoyé par Marco46

On est d'accord que ce que tu viens de dire ne s'applique ni au Java ni au C# par exemple ?

Aucune idée pour le système de types de ces deux là. De mémoire il garantissent l'impossibilité de forger une référence depuis nulle part, mais j'en mettrais pas ma main à couper.

Citation:

Envoyé par Marco46

Du coup l'argumentaire d'ensemble tombe à l'eau puisque pour avoir le bénéfice de ce "type" de typage statique qui permet d'éviter du testing il faut utiliser des langages qui ne sont à peu près jamais utilisé par 99% des développeurs qu'ils soient chez des éditeurs ou en SS2I.

Je parle de l'avantage d'un système de type dans l'absolu. Il y a pas mal de langages qui entrent progressivement en industrie qui peuvent donner des garanties semblables. Parfois dans une moindre mesure, encore une fois c'est au cas par cas. Une constante malgré tout, il est plus facile de corriger un système de types qui merde que d'écrire des tests qui font le boulot d'un système de types tout le temps.

Citation:

Envoyé par Marco46

Ça confirme simplement que les tests sont bien plus importants pour diminuer le nombre de bugs que d'avoir du typage statique puisque les fonctionnalités nécessaires ne sont pas présentes dans tous les langages à typage statique.

Pour les propriétés fonctionnelles oui. Pour l'absence de crash, ça va dépendre du système de types. Et il y a aussi la question des interactions à plus large échelle qui peut être plus ou moins difficile à tester. Après j'avais vu passer des études sur l'influence de la taille d'une base de tests pour évolution d'un projet, mais impossible de remettre la main dessus.
24/05/2019, 18h59
blbird

Citation:

Envoyé par KsassPeuk

Peut être que ce n'était pas clair : pour la partie absence de crash, dans le cadre de l'exécution du test d'absence de problème fonctionnel.

Et moi je ne vois pas comment tu peux comparer des tests TDD unitaires à un simple système de typage statique...

Dans un cas tu ne vérifies que le type à la compilation, dans l'autre tu peux vérifier le contenu, l'existence, les limites, et même si tu as besoin comparer à d'autres valeurs, tout dépend de tes contrats. Rien à voir en fait.

Un typage statique ne ta sauvera pas non plus à la connexion à des données externes asynchrones dont le contenu t'arrive forcément de manière dynamique et que tu ne maitrise pas souvent, ces cas sont monnaie courant maintenant. Pourtant tout le monde y arrive, et sans typage statique... Incroyable. Il faut juste respecter le contrat et ses évolutions.
24/05/2019, 21h25
mh-cbon

Citation:

Envoyé par shenron42

Oui, c'est un vieil article, mais juste pour le LOL, et parce que le JS c'est beau :heart: :

http://sametmax.com/un-gros-troll-de...r-javacscript/

comme c'est le status quo, c'est toujour valable ;) bon je sort j'ai des bugs à corriger sur des parseInt ^ ^
25/05/2019, 00h34
Invité

Citation:

Envoyé par blbird

Et moi je ne vois pas comment tu peux comparer des tests TDD unitaires à un simple système de typage statique...

Dans un cas tu ne vérifies que le type à la compilation, dans l'autre tu peux vérifier le contenu, l'existence, les limites, et même si tu as besoin comparer à d'autres valeurs, tout dépend de tes contrats. Rien à voir en fait.

Un typage statique ne ta sauvera pas non plus à la connexion à des données externes asynchrones dont le contenu t'arrive forcément de manière dynamique et que tu ne maitrise pas souvent, ces cas sont monnaie courant maintenant. Pourtant tout le monde y arrive, et sans typage statique... Incroyable. Il faut juste respecter le contrat et ses évolutions.

KsassPeuk a raison : les langages fonctionnels à typage fort, comme purescript ou elm, apportent des garanties sur la cohérence des types, la gestion des erreurs, les data asynchrones, etc, qu'un langage "classique", même avec des tests unitaires ou un IDE performant, ne peut pas apporter. Il y a de nombreux travaux, articles et présentations à ce sujet,

https://hackernoon.com/error-handlin...lm-7ffaf9ff3f8

https://www.youtube.com/watch?v=IcgmSRJHu_8
25/05/2019, 11h42
mh-cbon

bein tout ce que j'ai trouvé se résume à

Citation:

Async Failures

When making HTTP requests those requests can ultimately fail for a variety of reasons. With Javascript you’ll pass a success callback to handle successful responses and there’s an optional failure callback to handle failures.

Elm is different. Rather than exposing an optional failure callback you’ll instead be asked to provide a callback that accepts a Result (the same specialized either type discussed above) as input and that callback returns a Message that will likely be different depending on the Result.

What this means is async errors have to be explicitly handled, as opposed to being accidentally forgotten.

je vais pas me fouetter pour si peu, la conclusion est explicite

Citation:

I find handling error situations in Elm to be a rather pleasant experience. Elm will force you to handle errors essentially by leveraging the type system which is great both in its simplicity and the resulting developer experience.
25/05/2019, 12h37
KsassPeuk

Un pattern assez générique pour garantir la safety par le typage :

- pour tout ce qui est prévisible, garantir que le développeur ne peut pas créer les comportements problématiques,
- pour tout ce qui est imprévisible, créer des chemins d'erreur que le développeur ne peut pas ignorer en le forçant à traiter une donnée qui est dans un type qu'il ne peut pas directement manipuler.

Voir 40 message(s) de cette discussion en une page