您對Groovy有什麼看法？

7

我的團隊最近使用Grails（並且暗示，Groovy）實施了一項小型AtomPub服務。總的來說，這是一個不錯的經歷。我們簡單地將純Java和JRuby視爲替代品，但不考慮Jython或Clojure。該團隊使用Groovy是因爲它比JRuby更爲熟悉，但提供了比Java更大的靈活性。

下面是一些我們遇到的問題：

減少刀具的支持比我們大多數人使用（交易這是多麼大的取決於個人開發者你問）
可怕堆棧痕跡（這可能比Groovy的更多Grails的錯誤）
隨着整個團隊在飛行中學習語言，很難達到一致的，很受歡迎的風格
文件不理想對於Grails（同樣，不是Groovy的錯）;該文檔正在迅速改變，所以現在情況可能已經改善

來源

2009-02-18 20:31:35

5

我目前正在使用Grails進行一個小型探索性項目。我以前沒有使用Groovy的經驗，只有Java。

到目前爲止，我對於如何快速破解一些可用的東西印象深刻，而Groovy的特性，特別是Gpath表達式在這方面起着重要作用。我在Grails中遇到了一些bug，但在Groovy方面沒有遇到任何根本性的問題。

Groovy的主要缺點是（對我來說）它比Java更不方便調試 - 堆棧跟蹤由於Groovy引擎蓋下發生的反射魔法而變得臃腫，並且錯誤消息可能是神祕的 - 但這可能在大部分原因是我缺乏經驗。

來源

2009-02-18 20:32:14

2

我在Grails（當然還有Groovy）中完成了一箇中小型項目，並且很享受它。一路上有確定的障礙。它們包括：

缺少好的調試工具（我決定使用，因爲它的Grails的大多是原生支持Netbeans的，但它缺乏一個調試器......啊）
錯誤的網絡流量的功能。 Grails 1.1有更新版本的Spring Web-Flow，它解決了很多這些問題。
弱jquery插件支持。我喜歡jQuery，但它不像原型（以及支持的其他JavaScript庫）那樣得到很好的支持。儘管如此，AJAXy的東西很高興使用模板編寫。
- 難以處理枚舉和GORM中的多對多關係。爲了解決這些問題，Grails 1.1將會有很長的路要走。

總的來說，我真的很喜歡我的經驗，並在短時間內學到了很多東西。 Grails 1.1是一個重要的升級，將使這個框架企業做好準備。我真的只是在等待好的調試工具。我想我可以停止這麼便宜，只需購買IntelliJ。我聽說它對Grails來說是最好的。

從Java背景來看，走向Grails的道路似乎比用全新的語言和Rails的工具集開始更容易管理。

安德魯

來源

2009-02-20 02:42:42 anschoewe

2

我們最近實施的中型項目使用Groovy/Grails的，Groovy中已經由Java的依賴團隊的其他選擇。正如Java的普遍情況一樣，一切都花費比它可能的更長的時間。儘管Groovy從Java的冗長風格中提供了一個急需的緩解，但它仍然足夠相似，以至於人們不斷髮現違反直覺的語法。 HLL背後的想法是提供便於人們思考的編程工具，而不是要求人們像計算機一樣思考。來自稍微不同的背景，儘管對Java很熟悉，但恕我直言，另一種語言選擇，如Ruby，Python或Clojure將爲該項目提供更好，更快捷的基礎。我與Thoreau一起提出「簡化，簡化，簡化」，而不是厭煩的Java口頭禪，「放大，放大放大」。希望純Java，而不是JVM，將與COBOL一起加入編程垃圾堆。

來源

2011-01-20 15:26:48 totochto

10

我喜歡

瓶蓋
的吸水劑
即沒有必要在通常的冗餘聲明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)}"

它會在運行時失敗。

很難維護別人的代碼。考慮到您可以將屬性注入對象，您突然發現自己的變量不知道它們來自哪裏，或者它們是什麼類型。
的類型問題可以「緩和」與更多的單元測試，但隨後的時間通過編寫以下方法保存：
- 您需要決定是否可以接受'a'和'b'是您創建的字符串，整數或矩陣類，或其他。
- 如果您嘗試
高清加（INT A，INT B）{A + B}

Groovy中會忽略的參數類型。所以任何人仍然可以通過字符串或其他任何方法「添加」。編譯器不會抱怨。

好，你現在如果你想確保參數是整數添加某種驗證：

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

據我所知，靜態語言編譯器的目的是爲了避免在錯誤編譯時間，而不是在運行時。

如果一個方法調用能夠「拋出」一個錯誤，編譯器不會警告你必須放一個try-catch或者添加一個「throws」你的主要方法。如果您沒有意識到某種方法可能會拋出異常，那麼您可以在不知編譯錯誤的情況下在不知不覺中編譯Groovy程序，直到它在運行時激增爲止！
控制檯是不是很大，因爲它沒有提供像Eclipse這樣做的IDE建議。因此，您需要打開瀏覽器或書籍才能查看課程的可用方法。還有另一個小陷阱：你不需要使用'def'來在控制檯中定義一個變量，但是你需要在程序中使用它們。因此，如果從控制檯複製並粘貼到IDE，但不要忘記def。
在我的感覺Groovy是在有限數量很大，但不適合大項目。這是因爲許多可能的錯誤只在運行時才被檢測到，所以更多的單元測試和斷言是必需的，這部分地損失了編寫Groovy程序的速度。
默認情況下，在Groovy的屬性是公共的，並得到並自動創建集。你可以重寫默認行爲，但這只是另一件你可以忘記的事情，並且阻礙了你的類的封裝。例如：
```
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 
```

來源

2011-03-18 15:48:43 luiscolorado

3

一個真正的動態語言，它具有簡單和漂亮的語法，對現有的Java團隊，無與倫比的Java集成和提升以極大的許多方法在現有JDK，帶來巨大的生產力收益平坦的學習曲線。它可以很容易地被稱爲Java/JDK 2.0

尼爾福特做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

如果你從來沒有見過的動態語言的性能數字，你就會得到stucked之前，請參閱與在真實的使用情況等動態語言和Web框架基準（Groovy的1.8 - Grails的1.3.7）：http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/

性能永遠與你想要做的相關。自2008年以來，我一直在使用Groovy，並在大型項目上取得巨大成功。這只是讓工作按時完成業務需求。

希望有幫助！

來源

2012-09-02 05:26:49

您對Groovy有什麼看法？

回答

相關問題