Question

对于您的项目，您是否对Groovy有良好的体验？这个项目有多大？那语言有问题吗？你考虑过Jython，JRuby还是Clojure？

Answer 1

我喜欢

闭包
诽谤者
不需要通常冗余的声明MyType x = new MyType()，可以简化为def x = MyType()。但是，在Groovy中输入是没有意义的（我不喜欢这样）。
您可以使用控制台快速轻松地进行测试（尽管如此，您可以使用main（...）方法对Java类进行类似的操作）。

我不喜欢

弱类型。这会影响性能，并导致错误。没有什么可以阻止你，甚至不警告你，做以下事情：

def x = new MyComplexClass()

// oops! accidentally made x equal to 1, that is, an integer
x = 1

// Many lines later ...

// big fat error. Now x is an Integer, so it doesn't know handle myComplexOperation
println "The result is ${x.myComplexOperation(a,b,c)}"

它会在运行时失败。

很难维护别人的代码。考虑到你可以为对象注入属性，你突然发现自己有变量，你不知道它们来自哪里，或者它们是什么类型。
类型问题可以通过更多的单元测试来“缓解”，但是，通过编写以下方法来节省时间：
```
def add(a, b) { a + b}
```
可能会被其他考虑因素遗失：
- 您需要决定是否可以接受'a'和'b'是您创建的字符串，整数或矩阵类，或其他内容。
- 如果您尝试
def add（int a，int b）{a + b}

Groovy将忽略参数的类型。所以任何人仍然可以将Strings或其他任何东西传递给方法“add”。编译器不会抱怨。

所以现在你必须添加某种验证，如果你想确保参数是整数：

def (Integer a, Integer b) {
   assert a instanceof Integer
   assert b instanceof Integer
   a + b
}

据我所知，静态语言编译器的目的是避免编译时的错误，而不是在运行时。

如果方法调用能够“抛出”错误，编译器不会警告您必须放置try-catch或向main方法添加“throws”。如果您不知道某个方法可以抛出异常，您可以在不知不觉中编译Groovy程序而不会出现编译错误，直到它在运行时激活！
控制台并不是那么好，因为它不像Eclipse那样提供类似IDE的建议。因此，您需要打开浏览器或书籍以查看课程的可用方法。还有另一个小陷阱：您不需要使用'def'来在控制台中定义变量，但是您需要在程序中使用它们。因此，如果从控制台复制并粘贴到IDE，但不要忘记def。
在我看来，Groovy数量有限，但不适合大型项目。这是因为许多可能的错误仅在运行时被检测到，因此需要更多的单元测试和断言，这部分地打败了您编写Groovy程序的速度。
默认情况下，Groovy中的属性是公共的，并且会自动创建gets和sets。您可以覆盖默认行为，但这只是您可以忘记的另一件事，并且阻碍了类的封装。例如：
```
class Test { String a, b }

class Test2 {
  def t = new Test()
  Test2 (String s) { t.a = s }
  }
}

def t2=new Test2("I am public")
println t2.t.a
```

Answer 2

我的团队最近使用AtomPub（暗示，Groovy）实施了一项小型Grails服务。总的来说，这是一次很棒的体验。我们简要地将纯Java和JRuby视为替代品，而不是Jython或Clojure。该团队使用Groovy，因为它比JRuby更熟悉，但提供了比Java更多的灵活性。

以下是我们遇到的一些问题：

比我们大多数人习惯的工具支持少（这个交易有多大取决于你问的个别开发人员）
令人毛骨悚然的堆栈痕迹（这可能比Groovy的更多是Grails的错误）
在整个团队动态学习语言的情况下，很难达到一致的，受欢迎的风格
Grails不太理想的文档（再次，不是Groovy的错）;文档正在迅速变化，所以现在情况可能有所改善

Answer 3

我目前正在使用Grails开展一个小型的探索性项目。我以前没有使用Groovy的经验，只有Java。

到目前为止，我对能够快速获取可用内容的速度印象深刻，而Groovy的功能，特别是Gpath表达，在其中发挥了重要作用。我在Grails中遇到了一些错误，但在Groovy方面没有任何根本问题。

Groovy的主要缺点是（对我来说）调试比Java更不方便 - 堆栈跟踪因Groovy引擎盖下发生的反射魔法而膨胀，错误消息可能含糊不清 - 但这可能在很大程度上是因为我缺乏经验。

Answer 4

一种非常动态的语言，具有简单而美观的语法，适用于现有Java团队的扁平学习曲线，无与伦比的Java集成，并通过许多出色的方法增强现有JDK，从而带来巨大的生产力提升。它可以很容易地称为Java / JDK 2.0

Neal Ford在Groovy和JRuby之间做了很好的比较 http://nealford.com/downloads/conferences/Comparing_Groovy_and_JRuby(Neal_Ford).pdf

关于性能，它非常适合动态语言，而Groovy 2.0支持静态编译，使其真正飞行。

“使用@CompileStatic，Groovy的性能比Java快1-2倍，而没有Groovy，它的速度要慢3-5倍。（...）这对我来说意味着Groovy已经为应用程序做好了准备性能必须与Java相当。“

性能测试：Groovy 2.0与Java http://java.dzone.com/articles/groovy-20-performance-compared

如果您从未见过动态语言性能数据，那么在您遇到问题之前，请参阅实际用例中的其他动态语言和Web框架的基准测试（Groovy 1.8 - Grails 1.3.7）：http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/

表现永远与你想做的事情有关。我从2008年开始使用Groovy，在大型项目上取得了巨大成功。它只是按时完成工作需要。

希望有所帮助！

Answer 5

我在Grails（当然还有Groovy）完成了一个小型/中型项目并且很喜欢它。沿途有明确的障碍。它们包括：

缺乏良好的调试工具（我决定使用Netbeans，因为它主要支持Grails，但它缺少调试器......呃）
网络流功能中的错误。 Grails 1.1有一个更新版本的Spring的Web流程，它解决了很多这些问题。
弱jquery插件支持。我喜欢jQuery，但它并不像原型那样得到很好的支持（以及开箱即用的其他javascript库）。尽管如此，AJAXy的东西很高兴使用模板编写。
- 难以处理GORM中的枚举和多对多关系。 Grails 1.1将解决这些问题。

总的来说，我非常喜欢我的经验，并且在很短的时间内学到了很多东西。 Grails 1.1是一个重要的升级，可以使这个框架企业做好准备。我真的只是在等待好的调试工具。我想我可以停止这么便宜，只需购买IntelliJ。我听说这对Grails来说是最好的。

来自Java背景，通往Grails的道路似乎比使用Rails的全新语言和工具集开始更容易管理。

安德鲁

Answer 6

我们最近使用Groovy / Grails实现了一个中型项目，Groovy已被其他Java依赖团队选中。正如Java的普遍情况一样，所有事情都需要更长的时间。尽管Groovy提供了对Java冗长样式的急需，但它仍然足够相似，以至于人们不断地反对直观的语法。 HLL背后的想法是提供有助于人类思考的编程工具，而不是要求人类完全像计算机一样思考。来自略有不同的背景，虽然熟悉Java，但IMHO另一种语言选择，如Ruby，Python或Clojure，将为该项目提供更好，更快捷的基础。我和Thoreau一起建议“简化，简化，简化”，而不是疲惫的Java口头禅，“放大，放大放大”。希望纯Java而不是JVM将与COBOL一起加入编程尘埃堆。

你对Groovy有什么看法？

6 个答案: