Discussion :

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

[shenron42]

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

[mh-cbon]

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

comme c'est le status quo, c'est toujour valable bon je sort j'ai des bugs à corriger sur des parseInt ^ ^

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

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

[Marco46]

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.

[blbird]

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

[Marco46]

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

[Madmac]

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.

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.