Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Bill Fassinou

105PARTAGES

13  0 
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.


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 ?

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

Voir aussi

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

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

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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de SpaceFrog
Rédacteur/Modérateur https://www.developpez.com
Le 23/05/2019 à 10:01
Allez petit pari sur l'avenir ...
Comme toutes les autres tentatives de remplacement de JS... flop dans 6 mois ..
7  1 
Avatar de imag1
Membre à l'essai https://www.developpez.com
Le 23/05/2019 à 12:43
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.
5  0 
Avatar de Marco46
Modérateur https://www.developpez.com
Le 23/05/2019 à 17:37
Citation Envoyé par AoCannaille Voir le message

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.
6  2 
Avatar de eleydet
Membre confirmé https://www.developpez.com
Le 23/05/2019 à 9:31
Bonjour,

Il est écrit :
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.
3  0 
Avatar de Drowan
Membre éprouvé https://www.developpez.com
Le 23/05/2019 à 10:04
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.
3  0 
Avatar de KsassPeuk
Membre confirmé https://www.developpez.com
Le 24/05/2019 à 10:12
Citation Envoyé par Marco46 Voir le message
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 Voir le message
Tu es entrain de dire que l'on peut vérifier la validité d'un programme sans l'exécuter ...
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, ...).
3  0 
Avatar de KsassPeuk
Membre confirmé https://www.developpez.com
Le 25/05/2019 à 12:37
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.
3  0 
Avatar de Engiwip
Membre régulier https://www.developpez.com
Le 23/05/2019 à 14:15
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
3  1 
Avatar de Watilin
Expert éminent https://www.developpez.com
Le 23/05/2019 à 16:28
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…
2  0 
Avatar de shenron42
Membre à l'essai https://www.developpez.com
Le 24/05/2019 à 12:42
Oui, c'est un vieil article, mais juste pour le LOL, et parce que le JS c'est beau :

http://sametmax.com/un-gros-troll-de-plus-sur-javacscript/
3  1 
Contacter le responsable de la rubrique JavaScript

Partenaire : Hébergement Web