scala 优先级队列_我的优先考虑Scala

scala 优先级队列

TypeSafe应该在做什么

有一个Twitter线程开始讨论Clojure REPL的用法，但随后讨论了Scala的编译器。

一旁

好吧，还有一点……我的Clojure工作流程是：使用Clojure的REPL增量创建代码，一旦代码正确，围绕该代码编写测试并继续执行下一个任务。

这很有效，因为对Clojure代码的更改可以在逐个函数的基础上进行，而不是在整个类的基础上进行。 具有较小的更改单位意味着更简单地说“评估此S表达式”并在环境中进行更改。

另外，由于Clojure代码较少涉及静态数据结构，因此无需更改整个类就可以更轻松地更改函数。

这个“在这里改变一点然后再试一次”的周期非常非常短……这使我的思想顺畅。

在Scala中，我倾向于TDD…我将编写一个测试以测试我正在处理的内容，然后在sbt中运行该测试。 我对主代码进行了增量更改，运行测试，看看发生了什么并重复执行。 该周期有5-10秒的编译/测试暂停时间。 这与Clojure周期不同。 对我来说，它稍微慢一点，我的想法从一项任务转移到了另一项任务，这使我的速度放慢了。

但这不是Scala编译器速度的问题，而是Scala采用的方法的问题：所有的数据和行为东西都聚集为类/类型，因此当一个正在编码。 使用Clojure，您可以考虑一个功能以及该功能所基于的数据。

加速Scala编译器将无助于改变Scala进行编程的方式。 加速Scala编译器不会改变我的工作流程。

优先事项

在讨论中， Andriaan Moors说： “更快的编译=我们的首要任务” 。 这让我非常难过。

Scala和企业中采用Scala的最大挑战是Scala的版本脆弱性问题 。 版本的脆弱性使开发团队之间的协调工作成倍增加。 版本的脆弱性使Scala开源库之间的协调变得异常艰难。 而且，对于那些被它咬伤的人来说，它在嘴里留下了非常不好的味道。

ScalaC团队应优先考虑的事情是解决版本脆弱性问题。 解决方案并不难。 基本上，解决方案是为编译器提供两种不同的输出模式。 第一种输出模式用于“库”，并且在此输出模式下生成的JAR文件将不具有任何特征。 基本上，为具有在traits中定义的方法的类生成的字节码将引发异常，而不是被当作运行代码。 第二种输出模式是“可执行的”，可执行的JAR / WAR文件将具有完全经过特征化的特质类。 因此，如果在可执行编译阶段引用了相同特征的4个不同版本，则编译器将选择最高版本或生成错误。 因此，我们可以避免版本脆弱性问题。

ScalaC和sbt团队的第二要务是内存消耗。 在内存少于16GB的计算机上开发Scala应用程序是不合理的。 在使用Scala插件的sbt的2GB堆和IntelliJ的2GB堆之间，sbt和IntelliJ的JVM总大小约为6GB（总堆大小加上堆栈，perm-gen，JVM本身等为4GB）。 这比Java或Clojure或Haskell或C ++或Go或我熟悉的任何其他编程语言所必需的高一个数量级。 另外，如果减少了ScalaC的内存占用量，那么ScalaC的速度就会提高，因为处理内存垃圾的CPU时间大大减少了。

是的，在3Ghz机器上每秒只能编译200行代码的编译器确实需要引起注意。 但我不认为这是最高优先事项。

所以…

因此，我希望ScalaC团队专注于将帮助更大的团队采用Scala的方法，而不是追求确实需要解决的问题，但这并不是大大扩大Scala的采用的绝对障碍。

参考： DPP博客博客中我们的JCG合作伙伴 David Pollak的《 我对Scala的优先考虑》 。

翻译自: https://www.javacodegeeks.com/2014/01/my-priorities-for-scala.html

scala 优先级队列