我在StackOverflow 看到了这个ReasonML vs TypeScript问题,现在我想知道ReasonML和Elm如何相互比较.
他们有什么相似之处和不同之处？我应该在哪个时候使用？一个优于另一个的优势是什么？
gle*_*nsl 74
我对榆树并不熟悉,但是我对它有点了解,我对Reason非常熟悉,所以我会试一试.我确信这里会有不准确的地方,所以请不要把我说的任何事情当作事实,但是如果对你来说重要的话,请用它作为指针,更详细地了解一下.
Elm和Reason都是类似ML的语言,编程模型非常相似,因此我将重点关注差异.
语法:Elm使用类似Haskell的语法,这个语法是为Elm和Reason使用的编程模型设计的(和/或进化的),因此一旦你熟悉它就应该非常适合读写惯用代码,但看起来似乎大多数程序员都非常不同和陌生.
通过尽可能多地模仿JavaScript的语法,Reason会更加平易近人,这对于大多数程序员来说都是熟悉的.然而,它还旨在支持底层OCaml语言的整个功能集,这使得一些功能模式非常笨拙.
这样的一个例子是功能应用的语法,它在强调榆树功能的咖喱性质(f a b)和非常适用于构成功能和构建可读的DSL.Reason的括号语法(f(a, b))隐藏了这种复杂性,这使得它更容易进入(直到你不小心绊倒它,因为它当然在下面仍然不同),但是大量使用函数组合括起来.
可变性:榆木是一个纯粹的功能性语言,这在理论上是伟大的,但具有挑战性的做法,因为周围的世界很少关注榆木的追求纯度.我认为,榆树首选的解决方案是通过在JavaScript中编写有问题的代码来隔离杂质,然后通过Web组件或端口在Elm中访问它.这意味着您可能必须以单独且非常不安全的语言维护大量代码,需要相当多的连接它们的样板,以及必须弄清楚如何通过端口的方孔来安装圆形物体等第一名.
另一方面,理性是...... 务实,因为我喜欢称之为.您牺牲了一些安全,理想和长期利益,以提高生产力和短期效益.在Reason中隔离杂质仍然是一种很好的做法,但你不可避免地会采取捷径来完成任务,而这会让你以后再咬一口.
但即使你确实设法足以隔离所有杂质,你仍然需要为语言中的变异付出代价.这个价格的一部分是所谓的价值限制,你迟早会遇到它,它会混淆和激怒你,因为它会拒绝直觉应该工作的代码,因为编译器不能证明在某些时候不可能涉及可变参考.
JavaScript互操作性:如上所述,Elm提供了通过端口和Web组件与JavaScript进行互操作的能力,这些内容非常有限.你曾经能够使用原生模块,它提供了更大的灵活性(并且能够射击自己的脚),但这种可能性正在消失(至少是为了这些),这一举动并没有引起争议(但也是鉴于哲学,不应该是那么令人惊讶).在此处阅读有关此更改的更多信
Reason,或者更确切地说BuckleScript,提供了一组丰富的原语,可以直接绑定到JavaScript,并且经常生成一个惯用的Reason接口,而无需编写任何粘合代码.虽然不是非常直观,但一旦你理解它就很容易做到.然而,它也很容易弄错,然后在某个随机点将它炸掉.无论你需要写什么胶水代码来提供一个很好的惯用API,都可以在Reason中编写,并提供所有安全保证,而不必编写不安全的JavaScript.
生态系统:由于Elm有限的JavaScript互操作性,生态系统相当小.没有很多高质量的第三方JavaScript库可以提供Web组件,而自己完成这些工作需要花费很多精力.所以你会看到,而不是图书馆中直接实现在榆树本身,这需要更多的努力,当然,但往往会导致更高的质量,因为他们是专门为榆树设计.
工具:Elm因其出色的错误信息而闻名.尽管它努力,但在很大程度上的原因并没有.这至少部分是因为Reason本身不是编译器,而是建立在OCaml编译器之上,因此可用信息是有限的,并且可能的错误的表面区域非常大.但他们也没有经过深思熟虑.
Elm还有一个很好的打包工具,可以为您设置所有内容,甚至可以检查您发布的包的界面是否已更改,以及版本颠簸是否与语义版本控制相对应.Resaon/BuckleScript只是使用npm并要求您手动管理所有原因Reason/BuckleScript,例如bsconfig.json使用新依赖项进行更新.
Reason,BuckleScript,它的构建系统和OCaml都非常快速.我还没有体验过从头开始编译超过3秒的任何项目,包括所有依赖项,而增量编译通常只需要几毫秒(尽管这并非完全没有用户友好性的成本).榆树,据我所知,并不是那么高效.
Elm和Reason都有格式化工具,但Reason格式的代码质量明显较差(尽管慢慢改进).我认为这主要是因为它必须处理的语法要复杂得多.
成熟与腐朽:以OCaml为基础的理性,已有20多年的历史.这意味着它有一个坚实的基础,经过长时间的战斗测试并证明可以工作.此外,它是一种很大程度上由学者开发的语言,这意味着一个功能可能需要一段时间才能实现,但是当它确实进入它的时候,因为它基于理论,甚至可能正式证明.在不利方面,它的年龄和实验性质也意味着它聚集了一些难以摆脱的残余.
另一方面,榆树相对较新且官僚管理较少,可以更快地行动,并且不怕与过去打破.这使得更轻薄,更连贯,但也有一个不那么强大的类型系统.
可移植性:Elm编译为JavaScript,它本身非常便携,但目前仅限于浏览器,对Elm Architecture来说更是如此.这是一个选择,目标节点或平台并不太难.但正如我所理解的那样,反对它的论点是,它会转移焦点,从而使其在其利基市场上不那么优秀
理由,基于OCaml,实际上首先针对本机机器代码和字节码,但也有一个JavaScript编译器(或两个),使其能够针对浏览器,节点,电子,本机反应,甚至编译成一个unikernel.Windows支持据说有点粗略.作为一个生态系统,Reason首先反应React,但也有一些库允许Elm Architecture非常自然地使用
治理:榆树的设计和由一个人谁是能清楚地传达他的进球和推理和谁在照顾到就可以了全职工作的发展.这使得最终产品连贯且设计良好,但开发速度缓慢,总线因素可能使投资变得困难.
Reason的故事有点复杂,因为它更像是一个项目集合的伞形名称.
OCaml在公开场合进行管理,设计和开发,主要由学者,以及由各种基金会和商业支持者赞助的开发人员进行管理,设计和开发.
BuckleScript是一个源自OCaml编译器的JavaScript编译器,由一个开发人员开发,他的目标和就业情况不明确,谁也懒得解释他的推理或决策.开发在技术上更加开放,PR被接受,但缺乏解释和迟钝的代码库使其有效地封闭开发.不幸的是,这也不会导致特别连贯的设计,并且总线因素也可能使投资变得困难.
Reason本身和ReasonReact由Facebook管理.PR受到欢迎,并且大量的Reason开发是由外人推动的,但大多数决定似乎是在某个地方的后台进行的.对于ReasonReact的PR,除了琐碎的拼写错误修复等之外,经常被拒绝,可能是有充分理由但通常几乎没有解释.然后通常会在后面的某个时间从后面的房间出现更好的设计.