Posté par barmic 🦦 .
Évalué à 9.
Dernière modification le 22 novembre 2023 à 16:21.
Elm est un js-killer qui prends une syntaxe du genre haskell, une architecture d'application qui se rapproche de Flux/Redux/Vuex pour ceux qui ont essayé et qui est jusque-boutiste. Tu n'écris pas de html, mais une structure elm qui représente ton html est qui est typée (ça interdit par exemple d'écrire un href n'importe où). Le tout en ayant une approche qui se veut aussi user-friendly que possible avec un compilateur qui essaie de t'aider autant que possible.
On peut douter de la capacité d'elm a tuer js, mais ce qu'il apporte me parait indéniable.
Pour roc qui tente d'apporter elm ailleurs que dans le navigateur, j'ai du mal à voir l'intérêt. Il y a déjà des pleins d'alternatives. Éventuellement j'aurais mieux compris de faire une cible webassembly/WASI pour utiliser elm ailleurs que dans le navigateur.
On peut douter de la capacité d'elm a tuer js, mais ce qu'il apporte me parait indéniable.
Tout à fait d'accord. JS a un énorme écosystème et énormément de pratiquants, il ne sera pas remplacé de sitôt. Et ELM ne sait pas tout faire. Mais pour tout ce que ELM sait faire : réagir à des événements pour transformer un modèle et en faire un rendu DOM, c'est du bonheur. Et la communauté est top.
J'ai hâte d'expérimenter ce qu'est capable de faire Roc.
Posté par gUI (Mastodon) .
Évalué à 8.
Dernière modification le 23 novembre 2023 à 07:46.
Question con d'un dev embarqué qui n'y connaît rien (ou presque) en Web/JS : comment peut-on faire autre chose que du JS dans un browser ? Pour moi c'est du code interprété par le browser et seul JS est présent dans tous les browser.
En d'autres termes, si tu fais du ELM t'es certain que ça va tourner partout comme du JS ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
En d'autres termes, si tu fais du ELM t'es certain que ça va tourner partout comme du JS ?
C'est aux développeurs du compilateur de s'assurer de cela, en général ils font en sortent que le code puisse tourner sur tous les navigateurs connus, au moins en terme de version de JS (EcmaScript) supportée.
Après, rien n'empêche un dev Elm d'utiliser des fonctionnalités spécifiques à un navigateur et dans ce cas Elm ne changera pas le fait que le code ne sera pas compatible.
Par contre, le code Elm n'est pas compatible Node.js, vu que Elm se concentre exclusivement sur le front (les navigateurs quoi).
Par contre, le code Elm n'est pas compatible Node.js,
Exact. Je crois que cela fonctionnait sur les version avant la 0.19 mais je ne faisais pas de Elm à l'époque. Et il était alors possible de faire du backend en Elm. Pour simplifier encore plus le langage et son usage, le BDFL a décidé de supprimer cette possibilité. Et c'est ce manque que veut tenter de combler Roc.
Comme quoi, j'ai bien fait de poster ce lien. Je ne voyais pas l'intérêt de ce langage, et j'ai découvert Elm et son intérêt et maintenant je vois un intérêt à Roc… merci
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
En plus d'apporter les principes d'Elm sur le back, Roc a une approche vraiment intéressante en terme de séparation entre le monde "pur" et le monde "impur".
Ils ont la notion de "plateforme" qui se situe entre le runtime et l'applicatif.
Je n'ai pas encore essayé, mais ça à l'air d'être un chouette langage fonctionnel pure, qu tout comme Elm s'axe sur la lisibilité et la simplicité et cherche à avoir des performances le plus proche des langages système (c'est aussi un des aspects qui différencie ce langage des autres).
L'implémentation du compilateur est en Rust et la librairie standard en Zig. Y a sans doute plein plein de choses à apprendre en lisant le code source :).
J'aime vraiment Elm d'amour, mais pour quelqu'un comme moi qui n'ai pas d'habitude d'haskell, sur une ligne :
fctabc
Il m'est difficile de savoir si fct prends 3 paramètres, si b est une fonction qui prend c en paramètre et fct prend 2 paramètres (a et le résultat de b), si b c est bien une fonction b qui prend en paramètre c, mais qui sera évalué paresseusement et fct prend en fait 2 paramètres a et une lambda, etc
Après je n'en ai pas assez fait pour que ça devienne naturel.
elm (comme haskell) aussi peu le faire, mais c'est une pratique qui ne semble pas être recommandée ou établie (ce qui n'est pas nécessaire est inutile).
Il y avait deux mots pour indiquer que je trollais :
pour vendredi
Après, Elm/Haskel/OCaml/etc ont, comme dans Logo et d’autres adoptés une orthographe différente de Clojure/Scheme/Lisp/etc.
…parce-que les concepts fonctionnels (valable aussi pour l’objet ou l’événementiel ou autres) ne sont pas liés à la syntaxe (et c’est pour cela que c’est un gentil troll)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Oui oui bien sûr que le typage fais le travail, ce sont des instructions précises du langage. C'est le fait qu'il soit coutume de retirer de la syntaxe tout ce qui permet de le voir qui me surprend.
Et ton IDE (moi j'utilise helix avec elm-language-server) va t'aider en te mettant un tooltip avec le type.
J'imagine, j'avoue ne pas avoir creusé. Je ne connais pas helix, je vais regarder.
# Elm
Posté par barmic 🦦 . Évalué à 9. Dernière modification le 22 novembre 2023 à 16:21.
Elm est un js-killer qui prends une syntaxe du genre haskell, une architecture d'application qui se rapproche de Flux/Redux/Vuex pour ceux qui ont essayé et qui est jusque-boutiste. Tu n'écris pas de html, mais une structure elm qui représente ton html est qui est typée (ça interdit par exemple d'écrire un href n'importe où). Le tout en ayant une approche qui se veut aussi user-friendly que possible avec un compilateur qui essaie de t'aider autant que possible.
On peut douter de la capacité d'elm a tuer js, mais ce qu'il apporte me parait indéniable.
Pour roc qui tente d'apporter elm ailleurs que dans le navigateur, j'ai du mal à voir l'intérêt. Il y a déjà des pleins d'alternatives. Éventuellement j'aurais mieux compris de faire une cible webassembly/WASI pour utiliser elm ailleurs que dans le navigateur.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Elm
Posté par steph1978 . Évalué à 6.
Tout à fait d'accord. JS a un énorme écosystème et énormément de pratiquants, il ne sera pas remplacé de sitôt. Et ELM ne sait pas tout faire. Mais pour tout ce que ELM sait faire : réagir à des événements pour transformer un modèle et en faire un rendu DOM, c'est du bonheur. Et la communauté est top.
J'ai hâte d'expérimenter ce qu'est capable de faire Roc.
[^] # Re: Elm
Posté par gUI (Mastodon) . Évalué à 8. Dernière modification le 23 novembre 2023 à 07:46.
Question con d'un dev embarqué qui n'y connaît rien (ou presque) en Web/JS : comment peut-on faire autre chose que du JS dans un browser ? Pour moi c'est du code interprété par le browser et seul JS est présent dans tous les browser.
En d'autres termes, si tu fais du ELM t'es certain que ça va tourner partout comme du JS ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Elm
Posté par Andréas Livet . Évalué à 8.
Le compilateur Elm transpile vers du JS.
C'est aux développeurs du compilateur de s'assurer de cela, en général ils font en sortent que le code puisse tourner sur tous les navigateurs connus, au moins en terme de version de JS (EcmaScript) supportée.
Après, rien n'empêche un dev Elm d'utiliser des fonctionnalités spécifiques à un navigateur et dans ce cas Elm ne changera pas le fait que le code ne sera pas compatible.
Par contre, le code Elm n'est pas compatible Node.js, vu que Elm se concentre exclusivement sur le front (les navigateurs quoi).
[^] # Re: Elm
Posté par gUI (Mastodon) . Évalué à 6.
C'était ce qui me manquait pour comprendre. Merci pour les explications.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Elm
Posté par steph1978 . Évalué à 3.
Exact. Je crois que cela fonctionnait sur les version avant la 0.19 mais je ne faisais pas de Elm à l'époque. Et il était alors possible de faire du backend en Elm. Pour simplifier encore plus le langage et son usage, le BDFL a décidé de supprimer cette possibilité. Et c'est ce manque que veut tenter de combler Roc.
[^] # Re: Elm
Posté par abriotde (site web personnel, Mastodon) . Évalué à 3.
Comme quoi, j'ai bien fait de poster ce lien. Je ne voyais pas l'intérêt de ce langage, et j'ai découvert Elm et son intérêt et maintenant je vois un intérêt à Roc… merci
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Elm
Posté par Andréas Livet . Évalué à 1.
En plus d'apporter les principes d'Elm sur le back, Roc a une approche vraiment intéressante en terme de séparation entre le monde "pur" et le monde "impur".
Ils ont la notion de "plateforme" qui se situe entre le runtime et l'applicatif.
Je n'ai pas encore essayé, mais ça à l'air d'être un chouette langage fonctionnel pure, qu tout comme Elm s'axe sur la lisibilité et la simplicité et cherche à avoir des performances le plus proche des langages système (c'est aussi un des aspects qui différencie ce langage des autres).
L'implémentation du compilateur est en Rust et la librairie standard en Zig. Y a sans doute plein plein de choses à apprendre en lisant le code source :).
[^] # Re: Elm
Posté par barmic 🦦 . Évalué à 2.
J'aime vraiment Elm d'amour, mais pour quelqu'un comme moi qui n'ai pas d'habitude d'haskell, sur une ligne :
Il m'est difficile de savoir si fct prends 3 paramètres, si b est une fonction qui prend c en paramètre et fct prend 2 paramètres (a et le résultat de b), si
b c
est bien une fonction b qui prend en paramètre c, mais qui sera évalué paresseusement et fct prend en fait 2 paramètres a et une lambda, etcAprès je n'en ai pas assez fait pour que ça devienne naturel.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Elm
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Brouillon pour vendredi : c’est là que Lisp te désambigüe tout ça…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Elm
Posté par barmic 🦦 . Évalué à 2.
elm (comme haskell) aussi peu le faire, mais c'est une pratique qui ne semble pas être recommandée ou établie (ce qui n'est pas nécessaire est inutile).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Elm
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Il y avait deux mots pour indiquer que je trollais :
Après, Elm/Haskel/OCaml/etc ont, comme dans Logo et d’autres adoptés une orthographe différente de Clojure/Scheme/Lisp/etc.
…parce-que les concepts fonctionnels (valable aussi pour l’objet ou l’événementiel ou autres) ne sont pas liés à la syntaxe (et c’est pour cela que c’est un gentil troll)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Elm
Posté par steph1978 . Évalué à 2.
C'est là que le typage intervient
Prend la fonction map par exemple.
Pas évident de savoir ce que son arg1 et arg2.
Si je te donne le type de cette fonction
Tu comprends que map prend une fonction qui transforme un a en b, l'applique à une liste de a pour faire une liste de b.
Et ton IDE (moi j'utilise helix avec elm-language-server) va t'aider en te mettant un tooltip avec le type.
[^] # Re: Elm
Posté par barmic 🦦 . Évalué à 2.
Oui oui bien sûr que le typage fais le travail, ce sont des instructions précises du langage. C'est le fait qu'il soit coutume de retirer de la syntaxe tout ce qui permet de le voir qui me surprend.
J'imagine, j'avoue ne pas avoir creusé. Je ne connais pas helix, je vais regarder.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Elm
Posté par steph1978 . Évalué à 2.
Pour compléter la réponse de Andréas,
Si je prends le hello world de Elm
Le compilateur génère - après optimisation - un fichier JS de 17ko qui embarque le runtime et le code applicatif transformé en JS.
Et cela s'intègre dans une page HTML comme ceci :
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.