榆树的几点思考
两年前，我曾在一家公司工作，要求我学习Elm （一种功能性的前端编程语言）。 我发现语法很奇怪，而函数式编程范例却很困难。 我们最终转向其他前端框架，最终几乎都忘了Elm。
我最近在Redux上教过一课，我的学生向我询问了一些有关榆木的知识。 它促使我思考Elm，看看现在是否进入我的编程生涯再两年，这些部分是否就位了，我可以弄清楚。
学习过程
我决定从文档开始。 Elm的文档非常出名，许多进入门槛更高的技术必须使人们使用他们的工具。 我从他们的网站上的教程从零开始，然后迅速学习了该语言的更多标准部分。 有一些有趣的语法选择-例如用于更改记录属性的管道。 我还发现有趣的是，他们的标准集合是一个链表而不是一个数组。 使用前端语言在某种程度上是有意义的。 但是，这使我的最终项目更加棘手！
从那里开始，我进入了教程的“ Elm体系结构”部分。 我觉得这部分从0到100跳得非常快。 我肯定在这里迷路了。 总体而言，模型，更新，视图，订阅的设计模式是有意义的。 我喜欢知道一切都在哪里的能力。
在整个学习过程中，我不断返回到elm-architecture-tutorial中的示例代码。
其他非常好的功能包括错误消息和时间旅行。 在Elm的编译过程中，请确保不会出现任何运行时错误。 这个过程意味着在代码运行之前，您将获得非常好的清除错误消息。 我也非常喜欢“时间旅行”功能，可以在各个位置查看应用程序的状态。 开发经验的这些部分非常棒，我可以理解为什么其他工具（例如Redux）也基于这些想法。
在阅读了教程的“ Elm体系结构”部分之后，我能够一步一步地逐步学习代码，但是我仍然很努力地从头开始编写自己的Elm代码。 我最终查看了在Github上找到的其他一些项目，例如Flatris和Elm Hanoi 。 从那里，我发现了Tensor Programming的 Elm教程，最终对我们有很大帮助。 我真的很喜欢遵循学习风格，因此本教程对此非常有帮助。
最终项目
我本来想在Elm建造Hanoi塔，因为这是一个非常容易编写的JavaScript游戏； 但是，我发现它在Elm的联赛中还是有点差强人意。 相反，我按比例缩小并编写了一个琐事应用程序，这仍然很棘手。
我最终使用了create-elm-app ，它与create-react-app非常相似。 这对于开发和部署都非常有帮助。 我的代码中仍然需要解决一些问题。 首先是链表与阵列问题。 我最终使用了链表并对其进行迭代以检索不同的问题。 在其他语言中，我会保留一个索引值，并使用该值在问题之间移动。 该程序的体系结构在Elm中有些不同。
我还发现与“ maybes”一起工作很困难。 Maybes是Elm中的数据类型，类似于可以为“ Nothing”（类似于其他语言中的null或None）或具有值的字符串，整数或列表。 为了使用该值（如果存在），必须将其排除在外。 从严格类型化的角度和功能的角度来看，这是有意义的，但它会使代码有些笨拙。
最终，我确实提出了一个MVP琐事应用程序，该应用程序会询问问题，让用户单击带有不同答案的按钮，然后跟踪正确回答了多少个问题。 部署应用程序变得非常容易-我只需要运行elm-make并将build子目录推送到远程存储库的gh-pages分支。 代码在这里 ，应用程序在这里部署。
接下来是什么
事实证明，榆树在过去的几年中并没有变得更加轻松-榆树仍然是一种完全不同的思维方式。 尽管我制作了MVP，但要实现该目标的难度要比使用更舒适的语言构建它的难度高100倍。 设计模式仍然很困难，并且处理数据似乎比应有的要困难得多。 我仍然不会选择使用Elm，尽管我确实看到了它的一些好处-例如静态类型输入和捕获错误。 如果我要在前端使用函数式编程，那么我宁愿使用React和Redux，因为它们都仍在JavaScript中。 总的来说，我认为Elm是个好主意，但是某些语法和实现仍然有些困难。