迪杰斯卡拉算法
我曾经认为Scala很简单。 它曾经并且一直是解决Java众多问题中的一些问题的良方。 从“ Scala中Java很难或不可能的东西很简单”开始，Scala是一种非常简单的语言。 在Scala中处理收藏非常容易。 隔离业务逻辑使程序更易于维护，在Scala中比在Java中容易得多。
那么，为什么Scala很难？ 这是我能拿出的最好的清单：
- Scala尝试做太多事情。 这意味着您可以像Java一样编写代码，这是一个诅咒和祝福，但从长远来看，我认为这是一个诅咒。 这意味着关于OO与FP的争论太多了。 如果您是一个小型团队，则这类决策/辩论是可以的，但是当您尝试教Java开发人员不想真正学习的Scala时，它们确实很烂。 当您主要是在编写FP时，Scala的压倒性优势才真正体现出来，但是，除非OO开发人员真正想去那里，否则几乎不可能让他们在那里。 在这种情况下，较少的语言功能/选择（例如Java或Ruby）更容易。 它减少了选择。
- IDE支持很弱，而且会一直如此。 Scala的Eclipse插件（或本周所说的任何插件）都糟透了。 在我做Scala的5年中，它很烂，而且始终“即将变得更好”，但是很烂。 IntelliJ的Scala支持对我来说是合理的。 但是在IDE中需要模式的人不会发现Scala支持很好。 首先，Scala模式是如此多样化和分离（通过mixins一直到ScalaZ的OO），将有太多的模式/模板。 如果您对使用Emacs或Vi或TextMate进行编码感到满意，那么Scala可以，并且转向IntelliJ很好。 如果您期望获得Java IDE的支持，那么它就不存在，也永远不会发生，因为要用简单的范式来包含Scala的功能很困难，而且还需要大量资源，即使是银行中拥有300万美元的TypeSafe也无法承保。
- Scala类型的系统功能强大，但是对您来说实在太多了。 在ScalaDocs中，类型签名简直令人恐惧。 看看flatMap [B，That]（f：（A）？Traversable [B]）（隐式bf：CanBuildFrom [List [A]，B，That]）：那并告诉我，这不会使您想要运行尖叫。 初学者每天使用这种方法， 一天20次 ，这太吓人了。 Scala文档需要更多的库使用者来隐藏正在发生的复杂性，而这实际上使flatMap变得异常强大。 类型系统和相关的文档需要一个更简单的模式，该模式隐藏在库级别上权衡功能和复杂性的功能，以便最终用户级别的简化。
- 要求维护高级开发人员编写的代码的初级开发人员必须了解代码中的习惯用法和模式。 尽管Scala将业务逻辑放在代码的最前面（而不是通过一堆for循环和复杂的if语句进行分配），但取决于所使用的惯用法，对该逻辑的解码并不明显。 这是缺少成语问题的一种变体，但是到了最后，您需要一个有头脑的团队来编写一些Scala代码。 在Ruby和Rails中也是如此，哈希表几乎替代了所有其他编程范例。 但是在Rails-land中，范例是统一的（尽管未经类型检查），并且因为它是“方式”而得到了很好的理解。 在Java中，模式是从IDE中呕吐出来的，因此开发人员长大后就能发现这些模式。 Scala的习惯用法是多种多样的，并且特定于团队/框架，而事实并非如此。
有许多团队类型，Scala比Java或Ruby或我所知道的任何其他语言明显更好。 Twitter是典型的例子。 他们需要简洁，类型检查，高性能等语言和运行时。 Scala为他们提供了这个。 Foursquare使用Scala的难度作为过滤机制。 您必须足够好，才能学习Scala在Foursquare上取得成功。
但是，如果您的团队更接近平均技能水平，那么Scala可能不会为您的公司带来胜利（这取决于管理层……它是否想利用Scala的挑战作为筛选和改善团队的一种方式？）如果您是中心机构（COTM），那么Scala会在学习曲线，现有开发人员拒绝，缺乏模式等方面给您带来成本。 您将需要一个强大的CTO或架构师来实施这些模式，而不是从书籍和IDE中获取它们，而拥有强大CTO或架构师的COTM公司的数量则是“有限的”。
因此，您如何确定Scala对您的组织而言是“轻松”还是“艰难”：
- 贵公司在JavaOne，OSCON，Strangle Loop和QCon上都有演讲者：Scala会很简单
- 午餐时间的讨论涉及从开发人员转到高级开发人员的标准：Scala很难
- 您的开发人员可以在以下情况下在NotePad中编写代码：轻松
- 当您的开发人员听到名字“ Zed Shaw”时，茫然地凝视或说3个“冰雹玛丽”：Scala == Hard
- 开发人员都在Twitter上关注Dean Wampler：Scala Easy
- 您的开发人员在9:15进来，在6点之前离开，并且晚上不检查工作电子邮件：辛苦
反正你懂这个意思。 但是我完全同意这样的主张，即对于一个普通的团队来说，斯卡拉很难 。 对于普通团队来说，这不仅是困难的，而且不会带来短期或长期的好处，这对于技能等级为95％的成员组成的团队来说是一样的。
一些注意事项：
- 是的，Scala的类型系统功能强大，并且会生成一些功能精美的代码，例如Scala的集合。 参见http://stackoverflow.com/questions/1722726/is-the-scala-2-8-collections-library-a-case-of-the-long-suicide-note-in-histo和http：// www .scala-lang.org / docu / files / collections-api / collections-impl.html但是，语言/库设计人员需要什么与COTM开发人员需要什么有所不同。 由于Scala中没有分隔，因此对于COTM开发人员来说很难。 就我个人而言，我认为我无法用任何其他语言的简洁或有力地表达《 Lift》中的思想，因此作为图书馆作者，我喜欢Scala。 我也意识到，Lift令人恐惧，对于COTM开发人员来说可能太多了。 作为了解类型签名的图书馆用户，我喜欢Scala。 但是我不是在刻薄，大多数不认为Scala如此艰辛的人也不是刻薄。 而写Scala的11岁小子并非刻薄。
- 是的，改进ScalaDocs以允许“简单”视图和“体系结构”视图将是一个巨大的胜利。 但这只是一个开始，而不是终点。
- 我明确拒绝了“那么，找到更好的开发人员”的论点。 我们可以通过提高开发人员（可以读取类型签名的人员，可以用数学方法表达程序的人员等）的整体质量来解决“ Scala很难”的问题，但是这没有切合实际。 关键是，Scala尚不足以迫使其在培训，教育和招聘方面进行一场革命，以至于Scala能够改变普通开发人员的质量，从而使Scala对该开发人员而言并不难。
- 我怀疑阅读此书或阅读我的Twitter流的任何人都是普通开发人员，而Paul Snively，您是如此平均，您甚至不应该尝试！
参考： 是的，弗吉尼亚州，在GOOD STUFF博客上，Scala与我们的JCG合作伙伴 David Pollak 很难 。
相关文章 ：
翻译自: https://www.javacodegeeks.com/2011/09/yes-virginia-scala-is-hard.html
迪杰斯卡拉算法
167
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
