对Scala及其周围环境的问题

是的，这是我的意见，是的，它可能看起来像一个仇恨的帖子。但是我将尝试解决我对Scala及其周围环境的问题。我在一个相对较小的项目中使用了Scala(目前正在生产中)，因此我猜我介于“n00b”和“中间”之间。

• 做同一件事有多种正确的方法。-Scala中的一两行代码都可以完成许多任务。但通常有不止一种方法可以做到这一点，而且没有明显的赢家。这些选项在简洁可读性尺度上，在功能命令式尺度上，以及在许多其他方面都是不同的。我知道什么是赛跑，部分函数，部分应用函数，折叠，收集，地图，应用等等，但是给了一个简单的任务，我可以全部使用它们，我不知道是哪一个。可能是因为我是个初学者，而且随着时间的推移，我想我会建立一套更好的方法。这可能会与其他同事的不同，而这些项目会让我感到“混乱”。这就像是有一半的项目在同一行上有花括号，而另一半在下一行。
• 很神秘-你可能可以接受所有的符号在编码后飞来飞去，但我觉得它很难看。它是一种高级语言，使用这么多符号是很麻烦的意思。
• 二元不相容-我有一个错误，在Scala2.10项目中，我不能使用用Scala2.9编译的库。会在未来得到改善或完全修复，但就目前而言，它正在使生活变得更加艰难。
• 与现有java框架和工具的集成不顺利-这部分是由于思维方式不同(例如，您可能不需要Scala中的DI框架)，而且已经有几种可行的Scala替代方案(例如ORMS)，但有时您会更喜欢使用您熟悉的经过验证的技术。它不仅是框架，也是工具--我发现6个月前序列化JSON是一场噩梦。所有选项中至少有一件事情不像我所需要的那样起作用，或者缺少我需要的特性(Java的、JavaScala桥和原生Scala桥)。最后我使用了一个废弃的项目(杰克森)。幸运的是，杰克逊的支持现在是固定的(至少对于我的用例)，我转而使用它。其他库也是如此。
• 随机故障-我在编译过程中浪费在随机事件上的时间是很重要的。我只记得最后一个例子，其中我扩展了一些Java类，并得到了一个“AssertionError”，其中包含了一些我认为除了编译器的作者之外没有意义的额外信息。这个特殊的例子与前面的一点有关(因为我扩展了一个Java类)，但是还有一些我不记得的地方，因为它们是随机的。
• 无关编译器错误-这并不是通用的，但有时您会得到与实际问题完全无关的编译器错误。
• 缓慢编译-我在很大程度上没有经历过，因为这个项目很小，但值得一提的
• IDE过去很糟糕。我使用的Scala-ide是6个月前使用的，它实际上是不可用的--重构不起作用，调试中的检查不起作用，有时编译不起作用(同时maven构建运行良好，类被编译)。当时我尝试了IntelliJ，它稍微好一点，但不知怎么的，我并不总是在保存时编译。现在最新的IntelliJ插件工作得更好了，我认为它实际上是可用的。基于Eclipse的Scala-ide可能也是如此。因此，事情确实在改善，但在你期望一项技术更加成熟的时候，情况会变得很糟糕。不，我不想用vim/emacs/jedit/任何静态类型的语言来支持重构、调用层次结构等等。
• 注释、枚举、反射-来自爪哇，我“珍惜”这些东西。如果你是在一个纯粹的斯卡拉思还没有到达那个Nirvana，我还需要结合Java库来使用它。解决方法是在项目中与Scala类一起定义Java注释。我只是不喜欢他们的定义方式，这是不必要的冗长。反射正在进入Scala，但是@ScalaSignature(字节)之类的东西让我有点害怕。
• 陡峭学习曲线即使您熟悉函数式编程，Scala也引入了很多东西，包括上面提到的“神秘”符号。不仅如此，为了获得一个功能齐全的Scala项目，您可能需要学习大量或新的框架和工具，如Scalate、Scalatest、Squeryl等。部分原因是Java替代方案不能很好地与Scala一起工作，部分原因是Scala替代品正在利用Scala特性。

我不是说你不应该使用Scala。很明显，我还没有列出所有的优点。但就目前而言，我不喜欢使用它--由于上面提到的Java问题，我的工作效率较低，而且对我来说，这比酷酷的语言特性带来的生产率优势更大。事情显然在改善(IDE、语言、运行时和库)，我当然不会后悔在Scala中执行这个项目，因为这是我以后可能使用的宝贵知识。

https://movie.douban.com/review/14026710/

那是什么？很可能，你没有一个完全清楚的想法。但是为什么网络还没有“语义”呢？

https://m.douban.com/movie/review/14026710/

首先，理解起来很复杂。有大量的标准围绕着它-RDF，RDFa，RDFS，URI，OWL，SPARQL等等。将其与使用HTML的简单、旧的网页进行比较，在HTML中，您编写了一些标记，并有了一个网页。很简单。

如果有明显的好处，复杂性就不是什么大问题了。语义网所依赖的是，每个网站都应该符合一个语义概念(例如使用RDF)。但是，如果您以结构化的方式公开数据呢？没什么。是的，你的页面变得更容易理解我的机器，但你什么也得不到。为什么网店、社交网络或个人网站会被“信号化”？它需要额外的努力，一些无形和难以理解的好处。请注意，我并不是说没有好处--当然有，但它们离普通网站/在线企业主的头脑太远了。

https://m.douban.com/movie/review/14021703/

这是一个鸡与蛋的问题-没有直接的好处，所以人们没有使他们的网站语义。而且，由于语义网站太少，没有任何流行的产品能够提供预期的好处。这里有一个很好的例。它是一种专有的解决方案(更不用说标题中的“打开”)，它定义了一种提供网页元数据的方法。RDF(以及其他事情)应该做的事情。然而，Facebook认为RDF过于复杂(上面的第一点)，于是“发明”了一个新东西。你猜怎么着-每个人都在用它。因为它提供了立竿见影的好处--你的页面变得“Facebook友好”，而且由于数百万人在Facebook上，所以公开你的元数据很重要。开放图形协议是相当有限的，当然，但它表明，为了使网络变得更加语义，网站所有者需要一个商业激励。

我的最后一点是关于开放和合作。语义网的前提是人们愿意让自己的数据为他人不提供rss提要或api，将其数据隐藏在密码保护的领域中，禁止刮刀(即使它们没有增加任何负载)。因为他们的数据是他们的资产，他们不愿意免费提供数据。

因此，与其依赖于网络的语义，现时，试着理解网络上的非结构化数据。数据，这是有用的第三方，但网站所有者不提供。

结合这三个因素，我们需要的是一种激励网站所有者使用更多语义技术的方法，并使他们希望将自己的数据公之于众(因为同样的动机)。当然，试着让它变得更简单一些。所有这些，假设有一个语义网络，一个对机器有意义的数据网络是好的。这看起来是正确的原因，但我们还没有实现。