Faut-il migrer de JavaScript vers PureScript ? Oui

Citation:

---

Envoyé par mh-cbon

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

---

Le langage et le compilateur apportent automatiquement de nombreuses vérifications et rendent certains cas d'erreur tout simplement impossibles. Si pour toi, c'est "si peu" et que tu préfères avoir à écrire plein de TU ou à avoir une méthode de développement parfaite, tant mieux. C'est juste que ce n'est pas le cas de tout le monde : https://twitter.com/rtfeldman/status/961051166783213570

Citation:

---

Envoyé par 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.

---

+1, mais ça mérite des exemples.

Je vais donner un exemple en Rust pour le deuxième point :

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 25 26 27 28 29 30 31 32 33 34 35

use std::fs::File; use std::io; use std::io::Read; use std::path::Path;   fn main() { let username_or_error = read_username_from_file("hello.txt");   let username = match username_or_error { Ok(username_) => username_, Err(e) => { panic!("There was a problem opening the file: {:?}", e) }, };   print!("The user name is: {}.", username); }   fn read_username_from_file<P: AsRef<Path>>(path: P) -> Result<String, io::Error> { let file_or_error = File::open(path);   let mut file = match file_or_error { Ok(file_) => file_, Err(e) => return Err(e), };   let mut string = String::new();   match file.read_to_string(&mut string) { Ok(_) => Ok(string), Err(e) => Err(e), } }

---

Presque pareil en moins verbeux :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

use std::fs::File; use std::io; use std::io::Read; use std::path::Path;   fn main() { let username = read_username_from_file("hello.txt").unwrap(); print!("The user name is: {}.", username); }   fn read_username_from_file<P: AsRef<Path>>(path: P) -> Result<String, io::Error> { let mut file = File::open(path)?; let mut string = String::new(); file.read_to_string(&mut string)?; Ok(string) }

---

Dans mes exemples, File::open(path) et read_username_from_file("hello.txt") ne sont pas de types respectifs File et String, mais de types respectifs Result<File, io::Error> et Result<String, io::Error>.
Result<T, E> n'est pas directement utilisable comme un objet de type T. Il faut explicitement traiter les deux cas : celui du happy path où il contient une valeur de type T et l'autre cas où il contient une erreur de type E.
On peut traiter ces deux embranchements de plusieurs manières. match permet de faire du pattern matching en vérifiant à la compilation que tous les cas ont été pris en compte. unwrap retourne la valeur de type T ou appelle panic! qui arrête le programme. ? permet de récupérer la valeur de type T ou de sortir de la fonction courante en propageant l'erreur de type E.

Du coup, pour les erreurs que Rust considère comme récupérables, l'utilisateur est obligé de prendre une décision consciente pour savoir quoi faire de l'erreur.
Remarque : la plupart des fonctions de Rust ne considèrent pas les erreurs d'allocation de mémoire comme récupérables.

Cette possibilité de vérifier à la compilation qu'on a bien découpé le code en plusieurs embranchements et que certaines données ne sont disponibles que dans certains embranchement peut être utilisée dans plein de contextes. Par exemple, admettons qu'un code manipule des UUID qui doivent faire 128 bits. Quand un code lit des UUID sous forme de chaînes (par exemple dans un fichier), au lieu de les laisser sous forme de chaînes sans donner de garantie qu'on a bien vérifié le format de ces chaînes, il vaut mieux créer une fonction qui prend en paramètre une chaîne et retourne un Result<Uuid, MyErrorType>, avec Uuid qui représente un UUID avec un format valide. Comme ça, dans le programme, chaque fois qu'on voit une variable de type Uuid, on n'a plus besoin de se demander si son format est bien valide.

Remarque pour les développeurs TypeScript dont Marco46 :
D'après la doc, TypeScript est capable de faire ce genre de contrôle : https://www.typescriptlang.org/docs/...ced-types.html
Il suffit juste de bien typer les variables et de choisir les bonnes options de compilation (notamment --strictNullChecks, que l'on peut activer avec --strict).

Citation:

---

Envoyé par SimonDecoline

Le langage et le compilateur apportent automatiquement de nombreuses vérifications et rendent certains cas d'erreur tout simplement impossibles. Si pour toi, c'est "si peu" et que tu préfères avoir à écrire plein de TU ou à avoir une méthode de développement parfaite, tant mieux. C'est juste que ce n'est pas le cas de tout le monde : https://twitter.com/rtfeldman/status/961051166783213570

---

Pas de souci avec les méthodes que vous préférez ou trouvez les meilleurs. C'est juste que quand j'ai lu ton poste je m'attendais à quelque chose de plus "révolutionnaire".

est ce qu'on peut s'accorder à dire que c'est pas révolutionnaire..... c'est juste de la déclaration explicite.

Si je reprends l'exemple de Pyramidev, qui me semble valable rapport à ton précédent post, tout la mécanique installée, finalement, ne fait que remonter l'erreur dans un panic. encore une fois, pas extraordinaire.
il n'y a même pas d'enrichissement de l'erreur pour améliorer le détail à l'utilisateur.

Les exemples de la vidéo youtube autour de différents cas d'usage sur le questionnaire (+15min si j'ai bon souvenir) avaient au moins le mérite d'utiliser les types d'une manière à contraindre des cas d'usage, c'est déjà plus intéressant.

ce qui est marrant par ailleurs, Pyramidev nous dit:

"Il faut explicitement traiter les deux cas : celui du happy path où il contient une valeur de type T et l'autre cas où il contient une erreur de type E."

Juste après nous avoir présenté un exemple whatfuck de l'erreur,

Code:

---

1 2	let username = read_username_from_file("hello.txt").unwrap(); print!("The user name is: {}.", username);

---

non ?

Un langage fonctionnel n'offre pas beaucoup d'avantage coté client, puisque la force des langages fonctionnels est la performance élevée qui ont quand ils travaillent sur des tableaux ou des listes. Et ces types ne sont pas partiellement présent. Les interfaces utilisateurs s’intègre bien avec un modèle orienté-objet..

Et du coté serveur, les solutions avec de véritable langage fonctionnels ne manquent pas.

Citation:

---

Envoyé par Marco46

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 / ...

---

Dans ce cas là ce n'est pas une "mode" ou une "tendance", avec le côté éphémère que cela peut avoir.

De plus un paradigme est aussi une manière de penser et de construire son code. C'est une certaine logique à avoir lors de la conception du code. Le paradigme est donc aussi lié à la logique du développeur qui l'utilise. "Penser fonctionnel" n'est pas la même chose que "penser objet". Il sera plus facile pour un développeur de concevoir un programme avec un paradigme proche de sa manière de penser. Un autre paradigme aura peut-être d'autres qualités, mais il forcera le développeur qui ne pense pas comme ça à se contorsionner le cerveau pour pouvoir produire quelque chose, avec les erreurs finales que cela peut avoir. Quelque part on retombe sur le fait que le meilleur outil, ici le paradigme, est d'abord celui que l'on connait et que l'on maîtrise. À ce titre le fonctionnel n'est donc pas la solution miracle pour tous, pas plus que l'objet ou le prototypage.

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

---

Le typage statique permet d'économiser des tests, pas d'en remplacer. Prends le cas de la fonction qui prend deux nombres et qui les additionne.

• Avec un typage faible tu seras obligé de tester le cas où tu passeras un booléen et une string, par exemple.
• Avec un typage fort le compilateur gueulera dès qu'il constatera que t'essayes d'additionner un bool et une string. :nono: Pas besoin donc d'écrire un test pour ça, puisque si tu commets cette erreur dans le code alors tu ne pourras rien tester ni exécuter puisque ça ne compilera même pas.

Citation:

---

Envoyé par blbird

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.

---

Le type est une chose, la valeur en est une autre. Ne mélangeons pas tout. Le typage statique permet d'éviter d'avoir à tester le premier, mais tu devras toujours tester le second quelque soit le typage (sinon il n'y aurait jamais de tests à faire). Que tu passes "53", 53 ou 53.0 est une chose que le typage fort te permet de ne pas avoir à tester. Par contre tu devras toujours tester si ton fichu cinquante-trois respecte le contrat, quelque soit le typage.

Citation:

---

Envoyé par mh-cbon

Juste après nous avoir présenté un exemple whatfuck de l'erreur,

Code:

---

1 2	let username = read_username_from_file("hello.txt").unwrap(); print!("The user name is: {}.", username);

---

non ?

---

C'était dans le main. En dehors du main, je n'aurais pas utilisé unwrap pour un problème d'ouverture ou de lecture de fichier.
Mon exemple n'est pas parfait, mais je voulais illustrer unwrap quelque part.
Je construirai un meilleur exemple une autre fois.

Citation:

---

Envoyé par mh-cbon

Pas de souci avec les méthodes que vous préférez ou trouvez les meilleurs. C'est juste que quand j'ai lu ton poste je m'attendais à quelque chose de plus "révolutionnaire".

est ce qu'on peut s'accorder à dire que c'est pas révolutionnaire..... c'est juste de la déclaration explicite.

---

Etant donnés le "no runtime exception" de Elm et son influence sur Redux et sur Vue.js, je pense que si, ce genre d'outils est plutôt révolutionnaire et est très lié aux aspects du langage abordés précédemment.

"Even if you don't plan to use Elm, you should read about the Elm architecture, and play with it. There is an interesting JavaScript library playground implementing similar ideas. We should look there for inspiration on Redux! One way that we can get closer to the static typing of Elm is by using a gradual typing solution like Flow." (https://redux.js.org/introduction/prior-art#elm)

"Vue has even taken this model a step further with Vuex, an Elm-inspired state management solution" (https://vuejs.org/v2/guide/comparison.html#Scale)

Citation:

---

Envoyé par Madmac

Un langage fonctionnel n'offre pas beaucoup d'avantage coté client, puisque la force des langages fonctionnels est la performance élevée qui ont quand ils travaillent sur des tableaux ou des listes. Et ces types ne sont pas partiellement présent. Les interfaces utilisateurs s’intègre bien avec un modèle orienté-objet..

---

Côté back c'est surtout que le paradigme fonctionnel permet de paralléliser plus facilement. C'est surtout ça qui joue sur les perfs.

Côté client en SPA on est sur une state machine, l'immutabilité et l'absence d'effets de bords permettent d'éviter d'obtenir des soupes mutantes indémerdables comme on en voit souvent sur des applis AngularJS (ou même Angular) par exemple. On décrit un modèle qui représente le view model (ce qui est publié dans l'IHM) et un modèle qui représente le "domain" exposé par les API et on effectue les transformations avec un paradigme fonctionnel. L'immutabilité permet alors d'obtenir la liste des évolutions des states du front. Plus facile à gérer et à déboguer dans un environnement asynchrone.

C'est le sens des outils décrits par Simon Decoline dans son dernier post (Vuex, Redux, Elm, ...). Il est évident qu'avoir du typage dans ce contexte est intéressant, ce n'est pas un hasard si Vue3 supporte TypeScript et qu'on voit de plus en plus de projets React intégrant TypeScript qui n'est plus le domaine réservé de Angular. Même côté back le reboot de Node (deno) supporte TypeScript "out of the box".

TypeScript présente l'avantage d'étendre JS au lieu de le générer. C'est très différent. L'adoption de PureScript sera probablement très très marginale dans les années à venir.

Je n'ai pas compris dans ton message le lien entre immutabilité et le typage statique?

Citation:

---

Envoyé par SimonDecoline

Etant donnés le "no runtime exception" de Elm et son influence sur Redux et sur Vue.js, je pense que si, ce genre d'outils est plutôt révolutionnaire et est très lié aux aspects du langage abordés précédemment.

"Even if you don't plan to use Elm, you should read about the Elm architecture, and play with it. There is an interesting JavaScript library playground implementing similar ideas. We should look there for inspiration on Redux! One way that we can get closer to the static typing of Elm is by using a gradual typing solution like Flow." (https://redux.js.org/introduction/prior-art#elm)

"Vue has even taken this model a step further with Vuex, an Elm-inspired state management solution" (https://vuejs.org/v2/guide/comparison.html#Scale)

---

Pour être un peu taquin, c'est encore valable ce qu'il raconte sur le dom ? (~22:00)

https://www.youtube.com/watch?v=uQjivmLan0E

Citation:

---

Envoyé par blbird

Je n'ai pas compris dans ton message le lien entre immutabilité et le typage statique?

---

L'immutabilité est une des propriétés du paradigme fonctionnel comme l'absence d'effets de bords du fait de l'usage de fonctions pures (une entrée et une seule, une sortie et une seule). Si on veut résumer grossièrement se sont les plus importantes :
- pas de shared state
- pas de mutation
- chaque fonction a une entrée et une sortie, l'entrée ne sera jamais mutée et la sortie sera toujours une nouvelle variable.

Ajouter du typage statique sur ça est intéressant pour documenter ses fonctions et expliciter leur usage. Je trouve que ça clarifie pour faire de la composition de fonction derrière, par ex const r = f(g(h(x)));.

Citation:

---

Envoyé par mh-cbon

Pour être un peu taquin, c'est encore valable ce qu'il raconte sur le dom ? (~22:00)

...

---

Tout est expliqué dans ta vidéo. Elm permet d'éviter d'avoir à manipuler le DOM à bas-niveau. Cela permet de simplifier une grosse partie du dev, d'assurer le "no runtime error" et d'avoir un virtual-dom performant. Si tu as vraiment besoin de manipuler le DOM à bas-niveau, la méthode recommandée est d'utiliser un web component. Et comme expliqué dans la vidéo, c'est également la méthode recommandée par React.

Maintenant, si tu as des remarques de fond, je serai ravi d'en discuter avec toi mais si c'est pour le plaisir de troller, non merci.

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.
on ne peu pas se reposer sur le compilateur pour voir les erreurs.

cela demande donc une hygiène de dev implacable.

---

C'est uniquement un problème que pour les programmeurs qui n'ont pas eu de bon professeur. Un peut avoir les même avantages qu'un langage strictement typé avec un langage dynamique, si on en comprend le principes:

Le typage ne se fait pas par déclaration, mais par initialisation.

x = 0 # ceci est devenu un nombre réel
y = 0.0 # ceci est devenu un nombre irréel
z ="" # ceci est devenu une chaîne de caractère

Par contre, on ne peut-avoir les avantages d'un langage dynamique avec un typage strict. Par exemple, il est courant d'avoir des tableaux de différents types, dans un même programme. Avec un langage dynamique, vous n'aller avoir qu'à écrire une version des fonctions que vous devez avoir pour utiliser vos tableaux. Par contre, avec un langage strictement type, si vous avez 3 types différents, vous allez devoir écrire en triple vos fonctions. Ce qui n'est pas intelligent pour des programmes destiné au web.

Citation:

---

Envoyé par Marco46

Côté back c'est surtout que le paradigme fonctionnel permet de paralléliser plus facilement. C'est surtout ça qui joue sur les perfs.

---

C'est en théorie, j’attende toujours de voir que cette théorie devienne intégré avec un langage. Particulièrement pour des langage fonctionnelles. En Ruby, il y la fonctionne each pour traverser un tableau ou une liste, Et cette fonction n'est utilisé que sur des ensembles. Et on ne trouve ce genre de fonction que sur des langages fonctionnelles , l'exception de Ruby. Mais même, les programmes utilisant each ne pourraient pas paralléliser d'une façon optimale, car il a deux cas de figure possible: parallélisation d'un ensemble avec résultat ordonnée et avec résultats non ordonnées. Ce genre d'optimisation ne sera possible tant que le programmeur ne se pas en mesure de spécifier ce qu'il désire.

Citation:

---

Envoyé par Marco46

Côté client en SPA on est sur une state machine, l'immutabilité et l'absence d'effets de bords permettent d'éviter d'obtenir des soupes mutantes indémerdables comme on en voit souvent sur des applis AngularJS (ou même Angular) par exemple. On décrit un modèle qui représente le view model (ce qui est publié dans l'IHM) et un modèle qui représente le "domain" exposé par les API et on effectue les transformations avec un paradigme fonctionnel. L'immutabilité permet alors d'obtenir la liste des évolutions des states du front. Plus facile à gérer et à déboguer dans un environnement asynchrone.

---

Je me demande si ces soupes mutantes indermerdables, ne sont pas plus attribuable de l'absence d'un modèle alternatif clair et éprouvé au modèle: Modèle-vue-contrôleur. On était dans un modèle qui nous dictaient le où et le moment les choses devaient être fait. Et nous nous retrouvons avec quelque chose qui ne tient plus la route avec les tâches exécutées par un serveur-client. Mon impression est que l'avenir sera vers un modèle événementiel. j'en connais un brin sur ce modèle car j'ai commencé à programmer sur Mac. Et cela couvre tous les cas de figure. Le seul problème est qu'en abandonnant les Frames, la norme HTML fait en sorte que l'on doit rechargé le serveur coté client à chaque page. Et chargé l'équivalent d'un GUI, c'est lourd pour un téléphone portable

Je viens commencé à étudier ELM, (cela me semble un bon complément pour Rails). Et il y a un point qui me chicote au sujet de l’immutabilité est que cela doit entraîné une plus grande consommation de mémoire.