ReasonML vs Elm
J'ai vu cette question ReasonML vs TypeScript ici chez StackOverflow, je me demande maintenant comment ReasonML et Elm se comparent.
Quelles sont leurs similitudes et leurs différences? Lequel devrais-je utiliser quand? Quel est l'avantage de l'un sur l'autre?
Je ne connais pas très bien Elm, mais je me suis un peu penché sur la question et je connais assez bien Reason. Je vais donc tenter le coup. Je suis sûr qu'il y aura des inexactitudes ici, donc veuillez ne rien prendre de ce que je dis, mais utilisez-le plutôt comme un indicateur de ce que vous devriez approfondir vous-même si cela vous importe.
Elm et Reason sont tous deux des langages de type ML avec des modèles de programmation très similaires, je vais donc me concentrer sur les différences.
Syntaxe : Elm utilise une syntaxe de type Haskell conçue (et/ou évoluée) pour le modèle de programmation utilisé par Elm et Reason. bien pour lire et écrire du code idiomatique une fois que vous en êtes familier, mais semblera très différent et inconnu de la plupart des programmeurs.
Reason tente d'être plus accessible en imitant autant que possible la syntaxe JavaScript, qui sera familière à la plupart des programmeurs. Cependant, il a également pour objectif de prendre en charge l’ensemble des fonctionnalités du langage OCaml sous-jacent, ce qui rend certains modèles fonctionnels assez délicats.
Un exemple de ceci est la syntaxe d'application de fonction, qui, dans Elm, met l'accent sur la nature curry des fonctions (f a b) Et fonctionne très bien pour la composition de fonctions et la construction de DSL lisibles. La syntaxe entre parenthèses de Reason (f(a, b)) masque cette complexité, ce qui facilite son entrée dans le jeu (jusqu'à ce que vous y trébuchiez accidentellement, car il est toujours différent en dessous), mais fait un usage intensif de la composition de fonctions parenthèses.
Mutabilité : Elm est un langage purement fonctionnel, excellent en théorie mais difficile dans la pratique, car le monde qui l'entoure se soucie peu de la quête de pureté d'Elm. Je pense que la solution préférée par Elm consiste à isoler l'impureté en écrivant le code incriminé en JavaScript, puis à y accéder via des composants Web ou des ports. Cela signifie que vous devrez peut-être conserver des quantités importantes de code dans un langage séparé et très dangereux, avec un peu de passe-partout pour les connecter, ainsi que pour savoir comment ajuster les éléments ronds à travers les trous carrés des ports, etc. la première place.
La raison en revanche est ... pragmatique, comme j'aime l'appeler. Vous sacrifiez des avantages en termes de sécurité, d’idéaux et à long terme pour une productivité accrue et des avantages à court terme. Isoler les impuretés est toujours une bonne pratique dans Reason, mais vous allez inévitablement prendre des raccourcis pour faire avancer les choses, et cela vous en mordra plus tard.
Mais même si vous parvenez à être suffisamment discipliné pour isoler toute impureté, vous devez quand même payer le prix nécessaire pour que la langue soit mutée. Une partie de ce prix est ce qu'on appelle la restriction de valeur , que vous rencontrerez tôt ou tard, et qui va vous semer la confusion et vous rendre furieux, car il rejettera du code qui devrait intuitivement fonctionner, simplement parce que le compilateur est incapable de prouver qu’il ne peut y avoir de référence mutable.
Interopérabilité de JavaScript : Comme mentionné ci-dessus, Elm permet d'interagir avec JavaScript via des ports et des composants Web, qui sont délibérément assez limités. Vous pouviez utiliser des modules natifs, ce qui offrait beaucoup plus de flexibilité (et la possibilité de se tirer une balle dans le pied), mais cette possibilité est en train de disparaître ne devrait pas être si surprenant compte tenu de la philosophie). En savoir plus sur ce changement ici
Reason, ou plutôt BuckleScript, fournit un riche ensemble de primitives pour pouvoir se lier directement à JavaScript et génère très souvent une interface Reason idiomatique sans avoir besoin d'écrire de code collant. Et bien que ce ne soit pas très intuitif, il est assez facile à faire une fois que vous l’avez prise. Cependant, il est également facile de se tromper et de vous le faire exploser au visage à un moment donné au hasard. Quel que soit le code que vous devez écrire pour fournir une API Nice idiomatique, vous pouvez l'écrire dans Reason, avec toutes ses garanties de sécurité, au lieu de devoir écrire du code JavaScript non sécurisé.
Écosystème : En raison de l'interopérabilité limitée de JavaScript dans Elm, l'écosystème est plutôt petit. Il n'y a pas beaucoup de bibliothèques JavaScript de bonne qualité tierces qui fournissent des composants Web, et le faire soi-même nécessite beaucoup d'efforts. Vous verrez donc que les bibliothèques sont implémentées directement dans Elm, ce qui demande bien sûr plus d’efforts, mais aboutira souvent à une qualité supérieure, car elles sont spécialement conçues pour Elm.
Outillage : Elm est célèbre pour ses excellents messages d'erreur. La raison dans une large mesure ne le fait pas, bien qu'elle s'efforce de le faire. Ceci est au moins en partie dû au fait que Reason n'est pas en soi un compilateur mais est construit sur le compilateur d'OCaml, de sorte que les informations disponibles sont limitées et que les erreurs possibles sont très volumineuses. Mais ils ne sont pas aussi bien pensés.
Elm a également un excellent outil de packaging qui met tout en place pour vous et vérifie même si l'interface du paquet que vous publiez a été modifiée et si le bump de version correspond au versioning sémantique. Resaon/BuckleScript utilise uniquement npm et vous oblige à gérer manuellement tout ce qui est spécifique à Reason/BuckleScript, comme la mise à jour de bsconfig.json Avec de nouvelles dépendances.
Reason, BuckleScript, son système de construction et OCaml sont tous très rapides. Je n'ai pas encore rencontré de projet prenant plus de 3 secondes à compiler à partir de rien, y compris toutes les dépendances, et la compilation incrémentielle ne prend généralement que quelques millisecondes (bien que cela ne soit pas totalement gratuit en termes de convivialité). Si j'ai bien compris, Elm n'est pas aussi performant.
Elm et Reason possèdent tous deux des outils de formatage, mais la qualité du code au format Reason est nettement moins bonne (bien qu’elle s’améliore lentement). Je pense que c'est en grande partie à cause de la syntaxe beaucoup plus complexe à laquelle il faut faire face.
Maturité et décroissance : Reason, construit sur OCaml, a des racines qui remontent à plus de 20 ans. Cela signifie que ses bases sont solides et ont fait leurs preuves et ont fait leurs preuves sur une longue période. En outre, il s’agit d’un langage largement développé par les universitaires, ce qui signifie qu’une fonctionnalité peut prendre un certain temps à être mise en œuvre, mais quand elle est réellement intégrée, elle est solide comme un fondement, car elle est théorique et peut-être même officiellement prouvée. Par contre, son âge et son caractère expérimental signifient également qu’il s’agit d’un élément difficile à éliminer.
Elm, d’autre part, étant relativement nouveau et géré de manière moins bureaucratique, peut aller plus vite et n’a pas peur de rompre avec le passé. Cela fait un système plus fin et plus cohérent, mais a aussi un système de type moins puissant.
Portabilité : Elm compile en JavaScript, ce qui en soi est assez portable, mais est actuellement limité au navigateur, et plus encore à l'architecture Elm. C'est un choix, et il ne serait pas trop difficile de cibler un nœud ou une plate-forme. Mais si je comprends bien, l’argument à l’encontre est que cela détournerait l’attention, ce qui le rendrait moins excellent à
Basé sur OCaml, Reason cible avant tout le code machine natif et le bytecode, mais dispose également d'un compilateur JavaScript (ou deux) qui lui permet de cibler les navigateurs, les nœuds, les électrons, les réactions natives et même la capacité de compiler dans un noya . La prise en charge de Windows est cependant un peu fragmentaire. En tant qu'écosystème, Reason cible React avant tout, mais aussi possède des bibliothèques permettant d'utiliser l'architecture Elm de façon tout à fait naturelle
Gouvernance : Elm est conçu et développé par une seule personne capable de bien communiquer ses objectifs et son raisonnement et d'être rémunérée pour y travailler à plein temps. Cela donne un produit final cohérent et bien conçu, mais le développement est lent et le facteur bus peut rendre les investissements difficiles.
L'histoire de Reason est un peu plus complexe, car il s'agit plutôt d'un nom générique pour une collection de projets.
OCaml est géré, conçu et développé en public, en grande partie par des universitaires mais également par des développeurs parrainés par diverses fondations et parrains commerciaux.
BuckleScript, un compilateur JavaScript dérivé du compilateur OCaml, est développé par un seul développeur dont les objectifs et la situation de l'emploi sont incertains et qui ne se soucie pas d'expliquer son raisonnement ou ses décisions. Le développement est techniquement plus ouvert dans la mesure où les PR sont acceptés, mais le manque d’explication et de base de code obtuse en fait un développement fermé. Malheureusement, cela ne conduit pas non plus à une conception particulièrement cohérente, et le facteur bus pourrait également rendre les investissements difficiles.
Reason lui-même et ReasonReact, est géré par Facebook. Les RP sont les bienvenus, et une part importante du développement de Reason est conduite par des tiers, mais la plupart des décisions semblent être prises dans une pièce arrière. Les relations publiques de ReasonReact, au-delà des corrections de fautes de frappe triviales et autres, sont souvent rejetées, probablement pour une bonne raison, mais généralement avec peu d'explications. Une meilleure conception émergera alors généralement de l’arrière-plan un peu plus tard.