達人プログラマーを目指して

yukinori_nakata 2011/01/27 03:46 Groovyはほとんど知らないので、Javaに加えてわざわざGroovyを使う意義は何だろうと思って、紹介サイトを見たら、
「Groovy は Python と Ruby の力強さを Java プラットフォームにもたらします」
とありました。うーん、これだったら個人的にはRubyかPythonを使いますね（Pythonは勉強不足でまだ使えないですが）。

個人的には、Javaに比べてPerl/Ruby系（たぶんPythonも）が圧倒的に強いのは、大量のディレクトリ／ファイルツリーとテキストファイルを少ないコード量で自由自在に操れることだと思っています。
そして、この用途であればJavaとの相互運用性はほぼ要らないですし（どうしても相互運用したければファイル経由でやればよいので）、本番コードではなく便利ツールのコードであればバイトコードにコンパイルして高速化する必要もないので、Ruby/PythonではだめでGroovyだという話にはなりません。

また、それ以外の用途であれば、今のようにマシンも高速になって、Eclipseが入力補完でバリバリ補完してくれて、ちょっとしたツールぐらいのコード量ならば自動コンパイルで入力したそばからコンパイルが終わってしまうので、Groovyの「簡潔に書ける・動的言語でコンパイル不要」というところには、あまり魅力を感じません。

ちなみに、リフレクションからのメソッド呼び出しを非常に簡潔に出来るGroovyのメタプログラミング能力はすばらしいと思うのですが、メタプログラミングはやりすぎるとメソッドの呼び出し関係が追いきれなくなって保守性が下がるので、自分以外が読むソースではあまり多用しないほうが無難だなと思うと、そこもあまり食指が動きません。

まあ、結論としては、Javaで出来るところはJavaで、JavaではいまいちなところはRuby/Pythonでやればいいんじゃないかというありきたりな結論です。もちろん、それらを全部JVMの上で1つの言語でやりたいという人はGroovyを使えばいい訳ですが。

ただ、SIの現場では1プロジェクトで複数言語を混在して使うことは（保守プログラマ調達のハードルと人件費が上がるため）嫌われがちなので、世間的にGroovyが完全にJavaを置き換えでもしない限りは、広くは使われないだろうな...という感はあります。

私個人としては、実プロジェクトで使っている言語か、自分の知らないパラダイムを提示している言語でなければ新たに習得するモチベーションがわかないので、とうぶんGroovyは様子見でしょうか。

yukinori_nakata 2011/01/27 04:09 どうも、ブログの趣旨とややずれたコメントを書いてしまった感があるので補足します。

JavaからGroovyへの移行の話ですが、JavaとGroovyの文法の類似性から学習曲線がなだらかだという主張は必ずしも真ではないように思います。
文法だけならC++とJavaも相当似てますが、言語としての設計哲学やライブラリ群が別物なので、ハードルもかなりのものですし、それは極論としても、
JavaではなくGroovyらしいコードを書くにはやっぱりGroovyがJavaに足りないものとして取り入れたRuby/Python由来の部分を習得しないといけないでしょう。
場合によってはメタプログラミング技法も。

そうすると、JavaからGroovyの見かけ上の移行は簡単でしょうが、移行のメリットを享受できるレベルの真の移行は、そんなに簡単じゃないような気がします。
結局マルチ言語を使いこなせるレベルのプログラマがJavaに加えてGroovyも使っているというのが真相なんじゃないですか？

ryoasai 2011/01/27 20:37 ＞文法だけならC++とJavaも相当似てますが、言語としての設計哲学やライブラリ群が別物なので、ハードルもかなりのものですし、それは極論としても、JavaではなくGroovyらしいコードを書くにはやっぱりGroovyがJavaに足りないものとして取り入れたRuby/Python由来の部分を習得しないといけないでしょう。場合によってはメタプログラミング技法も。

この点については、Groovyの場合はちょっと特殊で、単にベターJavaとして気軽に使うだけでもかなり効果があると思います。リストリテラルなどはJUnit作成上便利ですし。必ずしも、パラダイムシフトを求めない言語なのかなと。
逆に、そういう間口の広さが、言語の専門家に人気のないところでもあるのですが。ただ、メタプログラミングとか実は奥が深くて楽しめるところもありますね。

yukinori_nakata 2011/01/28 01:44 いやはや、やっぱり自分で触ってみないと良さやら効果の程はピンとこないです。残念。
まあ、ryoasaiさんがそこまでGroovyを評価しているのであれば、きっと効果があるんでしょうね。
本当に勉強することが多すぎて困ってしまいます。

Kei Takashima 2011/01/28 17:48 去年、うちのプロジェクトでもgroovyとeasybを使って、インテグレーションテストを書いてました。テストの内容の性格木曜日あって、あまり可読性の良い物になりませんでした。
ろくに勉強しないで使ったからかもしれませんが、groovyは依存してる他のクラスをgroovycしとかないといけなかったような覚えがあります。なんかインタプリタっぽいとことコンパいら言語が微妙に混てて混乱しました。

ryoasai 2011/01/28 21:21 私自身は2年くらい前にGroovyインアクションを読んで、これは便利な言語だと思い、いろいろと試してみた時期があったのですが、当時はeclipseのプラグインが不安定で、importの自動化や入力補完もできない状態で結構苦労しました。
コードの記述量は激減したれど、生産性は向上しなかったという思い出があります。現実はなかなか難しいですね。最近はIDEやビルドツール関連など充実してきているようなので、再度チャレンジしてみようと思っています。
あと、Groovyは敷居が低いというのと矛盾するようですが、コードの可読性という意味では、余分なコードがない分、どうしてもプログラマーのスキルが必要になってしまうところはありますね。

yukinori_nakata 2011/01/28 23:26 > コードの記述量は激減したれど、生産性は向上しなかったという思い出があります。現実はなかなか難しいですね。

あれま、ちょっと待ってくださいよ。それじゃあ、ブログ中の以下の記述は完全に言いがかりじゃないですか。

「Groovy言語やAspectJといった本来エンタープライズ系でもっと積極的に使われるべき技術の人気がどれも今ひとつなのは、技術面で世界の進歩から相当の遅れをとっている日本のSI業界（特に軽蔑・軽視される下流工程のプログラミング関連技術）を象徴しているからなのだろうかと思えますね。つまり、本来の技術自体がダメなのではなく、新しい技術を積極的に使おうとしない業界の体質によるものではないかと思います。」

ちなみに、もともとつけたコメントは、別にGroovyにダメだしをしたかった訳ではなくて、以下のような点を指摘したかっただけです。

・「Javaを使っているのにGroovyを使わないなんてありえない」というほどの圧倒的なメリットはないですよね？
・どのプログラミング言語を使うかはそのプロジェクトの自由（or 非機能要件）で、今現在Groovyを使っていないからといってダメだしされるいわれはないですよね？

なんだか坊主憎けりゃ袈裟まで憎い、最後はとにかくSI業界が悪いというオチに無理やりつなげてませんか？

ryoasai 2011/01/28 23:53 ＞なんだか坊主憎けりゃ袈裟まで憎い、最後はとにかくSI業界が悪いというオチに無理やりつなげてませんか？

そう読み取れますかねw。確かに2年前まではメリットとデメリットの両面があったのですが、現在では再度トライする価値があると思われるくらい成熟してきてはいると思いますよ。

uehaj 2011/01/30 11:57 こんにちは。devloveの発表をしたものです。たいへん興味深い議論であります。

Groovyの学習曲線についてですが、「文法だけ」をとるのが誤りであるのに同意です。そして、だからこそ、Groovyは、Javaプログラマにとっては、Pythonやrubyに比べて学習曲線がなだらかなのです。たとえば(1)APIの共通性、たとえばコレクションライブラリの相違とか(2)実行モデル(同期モデル、スレッドモデル、セキュリティモデル、デプロイメントモデル)とか、(3)実行基盤(Webコンテナ、ライブラリ群、フレームワーク)とかを加味すると、「Javaプログラマーにとっては」習得が比較的容易である、というのが、自分以外の開発者につかってもらっての実経験です。

ただし、もちろん、単に簡単だと言うつもりもありません。Groovyに特有の機能がJava開発者にとって簡単であるという根拠も必然性もありません。いいたかったのは、JavaとGroovyの間では、漸進的な移行パスが存在するということです。Groovyらしく書けなくても、とりあえずJavaっぽく書いておいて、おいおいに上達すれば良いのです。逃げ道があるということです。開発者のスキルレベル差が存在する、という事実を無視しないなら、このことは重要です。RubyやPythonにはその逃げ道が無いのです。極端に言えば、習得するか動作しないかの二択しかない。さらに言うと、C++の普及にも、「とりあえずbetter Cとして書ける」という性質が寄与したのではないでしょうか。

生産性については、慣れとか歴史的経緯とか、情報とか、あるいは価値観とかの擾乱要素が多すぎて、たいへん難しいですね。

ryoasai 2011/01/30 17:03 uehajさん。コメントありがとうございます。先日の勉強会では勉強をさせていただきました。

＞Groovyの学習曲線についてですが、「文法だけ」をとるのが誤りであるのに同意です。
ここがやはりGroovyの魅力ですよね。GDKなど、今までJavaプログラマーが日常使っているStringやListなど普通のJDKのクラスにいろいろ便利な機能が追加されているというところなどが実に良いと思います。

本家達人プログラマーはRuby好きのようですが、Pragmaticという意味ではGroovyは実用的な言語であると思っています。uehajさんのブログも今後参考にさせていただき、再度Groovy（あとGrailsも）に挑戦してみようと思っております。JGGUGにも何か貢献できたらよいですね。

ryoasai 2011/01/30 17:05 Groovyのワンライナー集を作成するhttp://d.hatena.ne.jp/fumokmm/20110130/1296357893も面白そうです。

kimukou_26 2011/02/07 12:19 JVM系の言語でいい処と思うのは、起動シェル(BAT)やサービス記述で
VMのバージョンを切り替えられるところかなと
.bashrcとかに export JAVA_HOME 書いたりの記述が多いのですが
依存の情報を制限できるのがいいです。

そういう意味だと、JRubyでもJythonでもいいじゃん
という話にはなるんですが
クロージャやMetaClass等の黒魔術を除けば
習得コストは結構少ないかなと＜Ruby畑の人もそれほど違和感なく入れるかなと

WinのPythonに関して言えば、
ちゃんとしたインストーラで入れなければいけないので＜レジストリをバリバリ弄る
他ベンダーが他のverのPython入れて誤動作したりとか面倒くさいんですよ。
そういうリスクも減らせるかなと。

AspectJに関しては、Spring系もそうなんですけど
「実装する方は楽だけど、動かすと遅い」
というイメージが根強いですね。
Groovyに関してもそこら辺を払しょくできないと
GrailsにしろGriffonにしろ普及が難しいかも・・。

PS)
Scalaが人気なのは
分散系の勉強会で「Scala実装がベストだよ」
という話が良く出ているからだと思う。
Scala：Actor が GPars：Actor
と置き換えられるのかがキーになりそうな話になる気がする
＜でなければGroovy+Scalaのコンボでつかうとか
　(Griffonで作られているScalaプラグインとか)
　http://www.jroller.com/aalmiray/entry/griffon_groovy_scala_working_together

ryoasai 2011/02/07 22:39 コメントをありがとうございます。
＞AspectJに関しては、Spring系もそうなんですけど
「実装する方は楽だけど、動かすと遅い」
というイメージが根強いですね。

確かに、AJDTは結構重いと思いますが、実際はAspect Jはコンパイル時に織り込むため、結構早いと思うのですけれどね。実際にSpring AOPのような実行時のProryを使ったAOPと比較していませんが。
それから、おそらく通常のWeb+DBなアプリケーションだと性能がCPUバウンドにならないというか、DBやネットワークIOで性能が決まるところがあると思いますね。
適材適所でマルチ言語でいくというのはレイヤーなどで明確に担当が分けられるとか、マルチリンガルのプログラマーを雇える環境ではよいのではないかと思います。