開発のサポートツールやらなにやらで，こまごましたものを Groovy でちょいちょい書いて思ったことです．
Groovy で Web アプリケーションを書いたとかそういうゴツい話ではないのでそのあたりはよくわかりません．
なお本記事中に出てくる Java っていうのは Java 8 以降のことを指していると思ってください．
所感
- 楽にコードが書けるという点では良い．言語的にそういうところを重視している気がする．
- defとか．あとは DB 操作とか結構良い．楽．
System.out.println()とか書かなくて良いのは本当に良いですね．- とは言え，なんだかんだで補完の支援を受けないと記述コストは大きいと思う．賢い補完が要る．
- gradle は pom.xml 書くよりもストレスが小さい気がする．
- とは言え maven でもめんどいことは gradle でもめんどい印象．
- 結局なんか，適宜やっていきましょうという感じになる．
- つうか gradle はあんまモリモリやってないからよくわからん！
- 実行速度は特に感想無いです．チョイノリみたいなツールだと全く問題にならない．
- 重い処理するやつとか，Web アプリケーションとかだと色々あるかも．知らない．
- 書いたら LL 感覚ですぐ動くので，挙動を確認するための書き捨てのコードとかにはうってつけだと思う．フットワークが軽い．
- groovysh 便利．Groovy の REPL 的なやつ．挙動をパッと調べたいときに有益．
- Java と比較した時にコードが簡潔に書ける傾向にあるので，本質的な処理を理解しやすい．
- サンプルコードとかに向いてると思う．
- Groovy の便利記法結構あるけど，Java に似たようなのがちょいちょい入ってるから (lambda とか)，そこがマッシブな優位点になるかどうかという点．
- まあ Groovy の便利記法は便利は便利．
- Java でも8以降は戦えるのでは．
- 当たり前の話だが groovy の処理系が別途必要となってくる．
- Groovy のスクリプトを Java のプロジェクトの支援ツールとして配布するとなると，その利用者にGroovy のインストールを強制することになる．
- まあ入れれば良いですねという感じだけど，めんどいですよね．
- Java のプロジェクトの開発支援ツールに Groovy を含めるのはまま便利だ (った) と思うんですが，21世紀にはなんと CI ツールなどが存在していて，CI 回すたびに jar をパッケージできる感じになってきているので，Groovy のスクリプトではなくその jar を配布すれば良いのではという意識の高まり．
- 新たに処理系を入れる手間とか心理的なアレとかが消える．
- そういう jar のパッケージングが極めてめんどい時は Groovy 使うと良いのではという気持ち．
- ブックマークコメントで便利情報もらったので追記しました．
- Pivotal がスポンサーから外れるの心配ですね．
まとめ
- 挙動を確認したりするための書き捨てのスクリプトに使うのは良さそう
- ついでに言うと groovysh が便利
- サンプルコードに使うのは向いていると思う
- それ以外の用途で積極的に使う理由が積極的に無い……
- Java のプロジェクトの開発支援ツールみたいな用途だったら，Groovy じゃなくて (fat-packed) jar を配ってやっていく方が良いのではないか
という感じです．こういう意識になりました．書き味は気持ちのよい部類だと思われます．
gradle はちょっと評価できるほど使っていないので感想変わるかもしれないですね．
[追記]
Groovy 所感 - その手の平は尻もつかめるさGroovyのインストールを強要するのでなく、groovy-all.jarをクラスパスに含めるだけで良いのでは？
2015/01/28 22:12
なるほど．良さそう．ありがとうございます．
[追記]
Java のプロジェクトに Groovy のプログラムを含めるの，まあ自分は良いんですけど他の人にも Groovy の読み書きを強いる事になるので，そのへんはどうなんでしょうね．学習コストが上がるというか，些細なことでもお作法を覚えなきゃ駄目なのは面倒臭いのではと思ってしまう．で，結局 Groovy 読み書きできる人が永劫そのあたりを面倒見る，みたいな事になったら地獄っぽい．まあ普通に Java 読み書きできたら Groovy も読み書きできそうですけども．はい．
[追記]
別の処理系 (つまり今回の場合 Groovy) に依存すると，気を配る対象 (処理系の動向追ったりとか) が増えるためにコストが高まるという見方もあるので，そのコストを Groovy のメリットでうまく相殺できるのかどうか考えていく必要がある (Java も8とかはまあまあ書き心地が軽いのでそこが支配的なメリットになるかどうか．直接実行できるというのも，配布時にコンパイルしたパッケージを置くスタイルと比較した時にどうか．まあトライアルアンドエラーや修正は楽だけれど)．
依存が少なければ少ないほどメンテコストは低くなる傾向があるので，依存はバチバチ減らしたい．結局、ソフトウェアのライフサイクルを考えるとメンテフェーズが一番長くなるはずなので，そこでコストがかかるようになるとリソースをどんどん奪われてしまう．総じたコストを低く保つにはなんやかんやで単一の言語でやっていった方が良いのではないかという立場です．
我々はどうすべきか．
