Journal Elm sort en version 0.19.1

Posté par . Licence CC by-sa.
Tags :
20
22
oct.
2019

Alors que la dépêche concernant les versions 0.17, 0.17 et 0.19 attend toujours d'être terminée. Le langage Elm atteint la version 0.19.1.
La principale nouveauté vient du compilateur qui apporte encore plus d'aide pour résoudre les problèmes qu'il rencontre dans votre code. Je vous laisse parcourir le lien précédent pour plus de détails ou les différents contenu avec le tag elm.

Pour ceux qui ne savent pas ce qu'est Elm, il s'agit d'un langage fonctionnel, fortement typé qui compile vers le Javascript. Il promet de ne plus avoir d'erreur au runtime. Côté outillage, il possède une ligne de commande interactive pour tester des bouts de code, un compilateur à la volée pour voir les modifications au fur et à mesure.

En plus d'avoir inspiré React, Elm a son pendant qui tourne sur la Common Language Runtime en F# avec Elmish.

Il semblerait que les gens qui s'y mettent ont du mal à faire machine arrière, voici un témoignage. J'avais croisé un tweet qui disait qu'une entreprise avait commencé à utiliser le langage l'été 2018 dans leurs logiciel et récemment il avait viré React.

Des gens ont des retours positifs comme négatifs sur le langage ?

  • # Heureux

    Posté par . Évalué à 7 (+6/-0).

    Moi je m'en sers et j'en suis très satisfait. Je n'ai effectivement jamais rencontré d'erreurs au runtime avec lui et le compilateur est très gentil. Je n'ai pas vraiment pratiqué de langages fonctionnels purs avant elm et je ne maîtrisais pas bien la syntaxe d'haskel.

    Il paraît que Facebook a une alternative dérivée d'ocaml.

    Elm vient avec un framework, mais je le rapprocherai plus de redux que de react. Dernier point important c'est qu'il n'y a pas de bibliothèque de composants directement utilisable.

    • [^] # Re: Heureux

      Posté par . Évalué à 6 (+4/-0). Dernière modification le 23/10/19 à 17:17.

      Il paraît que Facebook a une alternative dérivée d'ocaml.

      Oui, c'est le langage Reason. Par contre ce n'est pas dérivée de OCaml, c'est du OCaml mais avec une syntaxe à la javascript. Dinosaure en avait fait une présentation lors de la dépêche sur les sorties 4.04 et 4.05 de OCaml (au passage le choix de l'image pour illustrer n'est pas de moi, mais de lui ;-) et pour le citer :

      Reason n’est ni plus ni moins qu’une option dans le compilateur. Nous parlons ici de l’option -pp qui permet de remplacer la partie frontale du compilateur par un préprocesseur ad hoc. Le préprocesseur Reason prend donc du code Reason en entrée, le transforme en arbre de syntaxe abstrait OCaml et passe cet arbre au compilateur OCaml classique.

      Il est tout à fait possible de mélanger du code Reason et du code OCaml : c'est le même langage mais avec deux syntaxes concrètes distinctes. On peut compiler du Reason en natif ou vers du bytecode OCaml. Pour la compilation vers javascript, la communauté Reason utilise le backend bucklescript, mais il en existe un autre plus ancien (quant à l'origine, il est toujours actif et surtout utilisé par les personnes de la communauté OCaml) à savoir js_of_ocaml.

      Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

      • [^] # Re: Heureux

        Posté par . Évalué à 1 (+0/-0). Dernière modification le 23/10/19 à 17:52.

        Reason n’est ni plus ni moins qu’une option dans le compilateur.

        Du coup il ne vient pas avec un framework comme elm. C'est dommage parce que c'est une grande part de ce qui fait la force d'elm je trouve. Après il peut être implémenté à coté. Mais je n'en vois aucune trace dans la page de documentation du site officiel.

        Ce que je trouve génial avec elm c'est que c'est un langage intéressant avec un framework qui se combinent parfaitement.

        Tiens c'est surprenant le lien en dessous indique que reason n'est pas fonctionnellement pur je pensais qu'Ocaml l'était.

        • [^] # Re: Heureux

          Posté par (page perso) . Évalué à 4 (+2/-0).

          Non, OCaml n'est pas fonctionnellement pur, il a des tableaux mutables, des références, etc, et le système de types ne capture pas cela.

          Après, la notion de « langage pur » est assez vague de toutes façons, et en fonction de celle qu'on prend même des langages souvent dits fonctionnellement purs comme Haskell peuvent ou ne pas l'être. Par exemple Haskell l'est (enfin, peut-être qu'il y a des échappées unsafe), au sens, toute impureté (~ effet de bord) est capturée par le système de types. C'est une sur-approximation, c'est-à-dire des fonctions globalement pures peuvent êtres considérées impures, mais toute fonction impure est bien considérée impure par le système de types.

    • [^] # Re: Heureux

      Posté par . Évalué à 3 (+0/-0).

      C'est reasonml qui est un dérivé de ocaml avec une syntaxe plus proche de javascript. Il marche avec react :

      https://www.imaginarycloud.com/blog/reasonml-react-as-first-intended/

      "La première sécurité est la liberté"

    • [^] # Re: Heureux

      Posté par (page perso) . Évalué à 3 (+1/-0).

      Je n'ai pas vraiment pratiqué de langages fonctionnels purs avant elm et je ne maîtrisais pas bien la syntaxe d'haskel.

      Question: Quel temps selon toi prendrait-il à un développeur Junior ( un petit nouveau dans une team, sans expérience en dev fonctionnel ) pour apprendre Elm from scratch et être productif.

      Tu peux ramener ma question à la suivante: Si les technos, disons non-commune, comme Elm, Reason ( ou autre compiler de language "safe" vers JS ) semble très attractives sur le papier. Est-ce risqué de les utiliser au coeur d'une infrastructure alors que les développeurs formés à cette techno ne cours pas les rues ?

      Certaines news récentes semble faire valoir que oui (https://news.ycombinator.com/item?id=21204761). Mais je serai intéressé par d'autres son de cloches.

      • [^] # Re: Heureux

        Posté par . Évalué à 2 (+1/-0).

        Quel temps selon toi prendrait-il à un développeur Junior ( un petit nouveau dans une team, sans expérience en dev fonctionnel ) pour apprendre Elm from scratch et être productif.

        Combien de temps je ne saurais dire, mais ça va assez vite. Une partie de ce que tu perds en palier initial, tu le gagne en mur que tu ne prends pas un peux plus tard.

        Par contre de mon point de vu (je ne suis pas très friand de html+css), c'est l'écosystème plus faible que chez angular qui va réduire la productivité.

        Là où avec angular les compatibilité de langages et la manière de faire du framework permettent d'encapsuler n'importe quoi dans un composant et de s'en servir sans à se soucier de l'implémentation (et donc à le combiner avec n'importe quel autre composant en principe). Avec elm on va plutôt faire ça en dehors de l'application elm et interagir avec via des envoie/réception de messages. Ça permet de continuer de garantir toutes les propriétés qu'elm veut donner à ses utilisateurs. Par contre manipuler le DOM via elm et via autre chose en même temps ne se mélange pas aussi bien. Personnellement j'ai très peu besoin de choses que je ne trouve pas en elm directement et si j'ai besoin de quelque chose d'autres je le met dans une branche bien distincte du DOM.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.