ログインしてさらにmixiを楽しもう

コメントを投稿して情報交換!
更新通知を受け取って、最新情報をゲット!

Clojureコミュの質問など

  • mixiチェック
  • このエントリーをはてなブックマークに追加

コメント(15)

Javaの知識ってどれくらい必要なのでしょうか?

3日くらい前からあわてて「Java入門」系のサイト見てJavaを触り始めました。
基本的なプログラミングにはJavaの知識は必要ないと思います。
(.start (Thread. (fn [] hoge ))) のような、
よく使われているものだけお約束として
覚えてしまえば、なんとかなると思います。

と言いたいところなんですが、やっぱりあるにこしたことはないでしょうね。
自分は大昔にJavaをやった頃もあったのですが、
すっかりJava嫌いになってほとんど忘れてしまいました。
>すっかりJava嫌いになってほとんど忘れてしまいました。

Java嫌い(笑)。
いやあ、そうですね。ホント3日間くらい「Java入門」関係のサイト見ながらサンプルコード打ち込んでたんですが、正直、

「何じゃこれ?」

とか思っています(笑)。
コード量がクソ多くないか、とか(笑)。単純な事やってるだけ、なのに、と(笑)。

まあ、最近、JavaScript実装Rhinoってのも「動かしたい」とか思ってたんですが、Mozillaのサイトとか見てても

「初めにJavaありき」

って説明方法なんですよ。それで面食らってて。
ついでにClozure動かすんだったらやっぱJava必要なのかな、と。ボンヤリ感じて、って感じです。

Sunがオラクルに買われて、今後どうなるのか、ちょっと分かんないんですが、JVMベースってのは希望的観測だと今後も増えるのかな、と。Javaには取り立てて魅力がないんですけど(笑)、Lisp系のライブラリの貧弱さ(極論言うとそれはSchemeなんですが)カバーするには、Javaのライブラリを横から奪う、ってのはアリなのか、と(笑)。Clojureにちょっと光明見出しています。
>ついでにClozure動かす

Clojure、ですね。タイポです。
と言うかホンマ紛らわしい(苦笑)。
JVMやCLIベースの言語はこれからも増えるでしょうね。
-言語処理系の開発効率が高い
  ガーベージコレクタとかVMに任せられる
  ASM http://asm.ow2.org/ などのサポートツールも。
-いきなりマルチプラットフォーム
  AndroidやGoogleAppEngineでも動いたり
-ライブラリ
  いわずもがな。Terracottaとか面白そうですね。
あたりが利点でしょうか。
処理系の開発効率は、言語を作る側の利点、
ライブラリが豊富なのはユーザの利点ですかね。
Java嫌いなので、Javaの豊富なライブラリや
どんどん高速になるJVMを横目に見て歯ぎしりしてたのですが、
状況が一変してしまいましたよ。
>JVMやCLIベースの言語はこれからも増えるでしょうね。

そうですね。新方言じゃないですけど、Armed Bear Common LispとかBiglooとか、Kawaとか、SISCとか、結構あるんですよね。
どう考えてもJavaの利点、特にライブラリの魅力が一番なのかな、と。

>Java嫌いなので、Javaの豊富なライブラリや
>どんどん高速になるJVMを横目に見て歯ぎしりしてた

僕はホントくだらないんですが、例えば、

Javardry:
http://thu.sblo.jp/article/13717351.html

とか見てて、「こう言うの作れるならJavaって悪くないな」とか思ってたんですよ。あくまで見た目、なんですけど。
Tcl/tkとかMotifとかのソフトウェアって汚いじゃないですか(笑)?今の基準だと。
GTKとかwxWidgetとかになってだいぶ綺麗になってきたな、とは思うんですが、依然と「Lisp」ってカヤの外でしょ(笑)?Javardryみたいなゲームとか作れるんだろうか、と。謎だったんです。
色んな意味でJavaの人達って「軽やかに」「見た目が良い」アプリケーション書いちゃってて羨ましいな、と(笑)。
また、Javaってゲーム作成の入門書とか良書悪書込みで豊富ですし。Lispは8クイーンズパズルばっかですし(笑)、それってゲームなのか、とか(笑)。ファミコンのドラクエIVのAIっぽいネタばっかなんですよね(笑)。「ソフトウェア工学」的には面白いネタなのかもしれませんが「命令させろ」が無いわけですし(笑)。ちょっと素人目にはあまり面白くないな、と。仮に作れても大変そうだし。
Clojureがその手のある種「敷居の高さ」を解消して、Javaのライブラリを横からブン捕って(笑)、「初心者にも易しい」Lisp方言として成長してくれれば楽しみ、なのです。結構くだらない「Java的な」入門書がたくさん出ればイイな(笑)。
たしかにライブラリの魅力1番なのはいうまでもないでしょうね。
>Kawaとか、SISCとか、結構あるんですよね。
ここらへんは本当に百花繚乱というかんじですよね。
ただやはりSchemeやCLをJVM上にポートしただけでは、
非Lisp系プログラマにはアピールが弱く、
Lisp系プログラマの限られたパイを、SBCLなどの既存の処理系と
取り合ってしまうだけで、いまいち盛り上がりに欠けるかもしれませんね。
ClojureのMLを見ていると、Javaやってました、みたいな人が
けっこう食いついてきてる感じがあるので、そこらへんが
Clojureの盛り上がりを支えているのでしょうね。

>とか見てて、「こう言うの作れるならJavaって悪くないな」とか思ってたんですよ。

それはわかります!
僕ももともとゲームプログラミングから入った口なので、
(ちなみに最初の言語はFM Towns上のLogoでした)
そういうのはすごくポイント高いです。

そもそもいま仕事のメインになっているPythonをやってみるきっかけのひとつが、
http://www.unixuser.org/~euske/doc/pygame/index.html
にある「Python によるゲームプログラミング実況中継」というFlash
をみて、Pythonだと簡単にゲームつくれそうだなー
と思ったことですから。

> 結構くだらない「Java的な」入門書がたくさん出ればイイな(笑)。
そうなったら本当に素敵ですね!
Scalaでさえ翻訳も和書もない現状では、ずいぶんさきに
なってしまいそうですが。。。
もうすこし普及してくれればClojureの本でも書きたいとおもってるんですがね。
>ライブラリの魅力1番なのはいうまでもないでしょうね。

そうだと思うんですよ。こんな事書いて黒板の人が見たら怒るでしょうが(笑)。
まあ、プロの人は違うんでしょうけど、プログラミング言語勉強して「さて何作ろう」とか思うと、これがまた意外と「何も無い」んですよね(笑)。そうなると、ゲームが割に「良さそう」なんです。どんな形であれ。練習としては。
ところが・・・・・・。僕もある程度Scheme覚えた後、「いっちょ何か作ってみるか」と思って、Python界隈ではwxWidgetがイイ、って感じになってんでSchemeで使えないか?ってんで探したんですが……これが無い(笑)。この辺、Schemeって「手詰まり」なんです。
CLにしてもwxCLは開発中ですし、SDLへ繋げるライブラリもドキュメントが全然無いんですよね(笑)。「準備中です」とか書かれていて(笑)。
明らかに「ライブラリ」としてはCLもSchemeもスクリプト系言語に負けてるな、と。これじゃあ新規参入者はLisp系言語に魅力感じないでしょうし、また、「プログラミング言語を学びたい」と言う潜在層にも「Lispって面白いよ」とか言えないです(笑)。逆に悲しいですよね(笑)。

>Lisp系プログラマの限られたパイを、SBCLなどの既存の処理系と
>取り合ってしまう

いや、慧眼ですね。
プログラマの人達って「パイ」ってあんま考えないのかな、とか思ってたんで(笑)。

>ClojureのMLを見ていると、Javaやってました、みたいな人が
>けっこう食いついてきてる感じがある

これは強そうですよね。Lispってプログラマにとっても「今まで覚えた技術が無駄になりそう」と言う恐怖がある言語だと思うんですよ(笑)。全部壊してフルスクラッチで学ばなきゃいけない、みたいな。関数型言語が人気がないのはその手の「恐怖」がどっかあるんじゃないのかなあ。
(これは言語のデザインに於いてスタイルを「Cから借りてくる」のが多い理由ですよね。それが「良い/悪い」関係無しに、「恐怖を薄める」と言うのは事実でしょうし。)
その点、Clojureってデモとか上手いんですよね(笑)。Java知らない人にはワケワカメですが(笑)、「あ、俺これ知ってる」的なコード例とかになってるんでしょう。

>Python によるゲームプログラミング実況中継

あ、これ見ました(笑)。途中で終わってて残念だったんですけど。
これが日本じゃ唯一、ですよね。多分。「Pythonでゲームつくろうぜ」と言うノリは。
先ほどの「パイ」の話じゃないんですけど、日本のPythonコミュニティって割に「クソマジメ」って印象で(笑)。割にパイ縮小の戦略取ってるな、って印象なのです。
いや、Webアプリって魅力的なんでしょうね。分かるんですけど、実際問題「サーバーで使えない」と意味が無い、と言うか(笑)。日本でPython使えるレンタルサーバーなんて3つくらいなんじゃないのか、とか踏んでるんですが。あるいは、自宅サーバー立てるしかない、んですが、自宅サーバー立てる方が危険なわけですよね?
そうなると、やっきになって「マジでPerl置き換えようぜ」と言う戦略取ると「パイ縮小」にしかなんないのです。日本のPython陣営がそれに気づいているのかいないのか。ここで「教育用言語で初心者にも学びやすい」ってのがひっくり返っちゃうんですよ(笑)。「(自宅サーバーを持てるくらいの)高度な知識がある人向けの」マニアックな言語になっちゃってるんです。そして、全くのプログラミング初心者は「食いつかない」ってなってるんですよね。
あるいは、それこそJava経験者か、Perl経験者しか食いついて来ないんで、パイが広がらないし「奪い合い」にしかなりません。殆どプログラミング言語のユーザーの推移ってのは「生命保険の勧誘」状態なんですよね(笑)。全く新規参入者が増えないでお互いパイを奪い合ってる(笑)。
それじゃダメだろ、とか思っています(笑)。

>そうなったら本当に素敵ですね!
>Scalaでさえ翻訳も和書もない現状では、ずいぶんさきに
>なってしまいそうですが。

ClojureはLispで言うと光明なんですよね。「色々出来そう」だし。
そう言えば、Erlangって割に名前の認知度高そうだな、とか思ってるんですが、最初やっぱり「ゲームプログラミングが簡単」とか言う宣伝が効いたんじゃないのかしら?恐らくそうだ、と思うんですけど。
Haskellもこんなのがあって、

Monadius :
http://www.geocities.jp/takascience/haskell/monadius_ja.html

ひっくり返りました(笑)。まあ、全然Haskell知らないんですが、魅力的ですよね。こう言うデモ見ると。「出来るんじゃん!!!」とか思って(笑)。
Lisp系の人ってPython以上に「コンピュータ科学してます」ってんでクソマジメだと良くない、ですよ(笑)。多分「実践Common Lisp」って本がある意味衝撃的だったのは、上の「Monadius」的な薫りがどっかにあった、んですよね。まあ、作者もPerl/Java出身、ってんで「何が求められているのか」と言うのを肌で感じてたんでしょうね(個人的にはもっと崩しても良い、とか思ってますが)。

>もうすこし普及してくれればClojureの本でも書きたいとおもってるんですがね。

いや、もう書いちゃった方が良いですよ(笑)。K&R的な「リファレンス」の薫り取っ払っちゃって(笑)。
Webで草稿公開して、見てもらって、修正加えつつの完成品に持っていく、って形の方が良いのではないでしょうか。日本の出版社だと「持ち込み」で粗製濫造の薫りがするんで、あんまそう言う意味では期待出来ないんですがね(ソフトバンクとか工学社とか・笑)。ただ、「作成スタイル」としては割にイケるのでは、とは思います。
んで、Lulu辺り使って本にしちゃえば意外と売れるのでは、と(笑)。

Lulu:
http://ja.wikipedia.org/wiki/Lulu

最近、Lisp界隈で「Let over lambda」の話題良く見かけるんですが、あれってLulu使った一種「個人出版」なんですね。これでオーケーならそれで良いわけですし、またそれがアングラであるLispっぽいかもしれません(笑)。
日本のPythonのコミュニティは、歴史的にZope/Ploneを使うためにPythonを始めました、というような人が多くて、現在でもDjangoとかWebフレームワーク中心で、
純粋に言語としてのPythonにフォーカスしてる人たちは、コミュニティにあまり関わらずに勝手にやっている、というように感じています。

あとは出版業界のほうでも、PythonはWeb用という位置づけになってしまっているので、
どうしても偏ってしまうのではと思います。
で、ゲームプログラミングならC/C++かActionScriptかという。
出版社が安全に売れる本を狙って、同じようなものばかりになっているっていう
ことですかね。

Monadiusはたしかに影響が大きかったですね。
海外でもけっこう取り上げられてましたし。

>日本の出版社だと「持ち込み」で粗製濫造の薫りがするんで、あんまそう言う意味では期待出来ないんですがね(ソフトバンクとか工学社とか・笑)。

これには、まあ言い訳っぽくなってしまうのですが、
日本で技術書を書いても売れる絶対数が少なくて儲からないので、
現場の技術者が片手間に書くか、大学の教授が書くか、というのが多くて
技術書書くのが本業のライターは多分少ないですよね。
日本で「実践Common Lisp」 のような良書を書いても、著者は
元が取れないんじゃないですかね。
あと、ベータ版をWebで公開しながら本を作っていくって言うのは
すごくいいと思うんですが、日本のある出版社では
PDFなんか公開して売れなくなったら困る、という感じじゃないですかね。

>Lulu
知りませんたが、これは面白そうですね!
Clojureについては、いますぐ何か書くほど理解できていないので、
まずはWebベースで情報をだしてくことから
がんばろうと思いますよ。

>Let over lambda
これも知りませんした!これは読んどかなきゃいけなそうですね。
ありがとうございます。
なんか出版業界の話になってしまったので、
技術的な質問も。
Clojureではlet-matchみたいな
パターンマッチして束縛するマクロ無いのでしょうか?

あと、([k1 v1] [k2 v2] [k3 v3] ... )
のようなキーと値のペアのシーケンスからマップを得る関数ってないでしょうか?
(hoge (seq {1 2 3 4}))
=> {1 2 3 4}
になるような。

よろしくお願いします。
>>10

おっと時間が開いちゃいましたね。
パソコン修理出してたのと、Java弄ってました。
ってかJavaマジ分からん・・・・・・(苦笑)。
Javaのパッケージ理解するならCLのパッケージ理解する方がラクだ、と言う事を発見しました(笑)。
JDEEで「パッケージ丸ごとコンパイルする」ってどうやんだろ?
Web上の情報見ても動作が違ったりするんで耐えられません。
凹んだ(涙)。

と言う話はさておき。

>で、ゲームプログラミングならC/C++かActionScriptかという。

C++でゲームプログラミング系の本を買って、絶賛挫折中のワタシが来ましたよ(謎)。
ってかC++の知識無いのに「何とかなるだろ」と思ってたら「何ともならない」事を発見しました(爆)。
ホント、C++って異世界だな・・・・・・。

>出版社が安全に売れる本を狙って、同じようなものばかりになっているっていう
>ことですかね。

まあ、それもあるんですが、無制限に持ち込み企画出しすぎ、ですね。
去年ですか?九天社、って出版社が潰れましたが、「当たり前だろ」とか思ってましたから。
殆ど編集がノーチェックで本を出す、までになってたんですよね。索引とかデタラメでしたし。
ああ言うのが「Web時代の出版形態」ってんで持ち上げられ過ぎだろ、と言う懸念があります。
いまだに、です。

>日本で「実践Common Lisp」 のような良書を書いても、著者は
>元が取れないんじゃないですかね。

あとは、割にプログラマの人って・・・・・・まあ、印象批評ですが、「舶来品珍重主義」っぽい部分が見えますね(危険発言?)。つまり、「外人が書いて外人に評判が良い」のは無制限に褒めるけど、「日本人が書く」と割に簡単に叩いちゃう、と言うか・・・・・・。
例えば、個人的な観点では、アスキーから出てる「プログラミング言語Lisp」って本は割にコンセプトとしては「実践Common Lisp」に近い、んですよ。結構な意味で良書なんじゃないのか、と思います。
ただ、対象が「Macintosh Common Lisp」だったんですよね。読んでくと分かるんですが、殆ど「Common Lispで実践的な"みんなが求めるアプリケーションを作りたい"」と言う発想がまずあって、それで「Macintosh Common Lisp」と言う著者の選択だったんです。それで例えばMacintosh Common LispでGUIとかやるわけですよ。
ただ、これは「実践Common Lisp」だけじゃなくって殆どのLisp系の本が避ける話題でしょ?ところが「プログラミング言語Lisp」の著者はそれを敢えて実装依存でも「挑戦した」わけです。この野心、ってオーケーなんじゃないか、とか思うんですが、まあ、Amazonの書評とか見るとみんな責める責める責める(笑)。こう言う変り種の本が一冊くらいあっても良いとは思うんですけどねえ。
そもそも「最初が急勾配」ってのはこの本に限らず、どのLisp系の本でも大体似たりよったりだと思います。「プログラミング言語Lisp」だけの特徴じゃない、と。じゃあ、エエんちゃうの?とか思うんですけど。
ホント、「意欲的な本」を下手に貶しちゃうと「定番で」「ありきたりの」構成の本しか出なくなっちゃうでしょ?言語もフツー、構成もフツー、じゃ、どのみちK&Rの「焼き直し」しか残らないのです。そうなっちゃう。

いずれにせよ、そう言うのもあるんで、「Clozure CL」が早くマトモに動くようになって欲しいな、と思ってるのです。Clozureがあれば、「プログラミング言語Lisp」って化けるかも(化けないかもしれませんが・笑)。

とにかく「対象者が誰なのか?」ってのが大事で、これはこのまま行くと、日本のプログラミング関係の書籍は「内輪受け」しかあり得ない状況になるのでは、と。一家言持ってる「プログラマ」や「情報処理技術者」から文句を受けない書籍ばかりになっちゃうと、本来の意味での「入門書」ってのがなくなっちゃうんですよね。
ホントだったら「多少不正確でも良いから」楽しい本、ってのが必要な筈なのですが。このまま進むと全部岩波書店の数学の本みたいになっちゃいますよ(笑)。先生は薦めるけど、読んでる生徒の立場だと「クソ面白くない」本ばっかになって(笑)。それじゃマズいだろ、と(笑)。

>日本のある出版社ではPDFなんか公開して売れなくなったら困る、という感じじゃないですかね。

これ、あり得るんですよねえ(笑)。
リチャード・ストールマンも初め、「無料で公開している」GNU Emacsのマニュアルを「本の形式で」出版する、って出版社を説得するの、かなり大変だった、とかどっか書いてましたからね。
まあ、いずれにせよ「前例」が必要なんでしょうね。
(その点、割にピアソン・エデュケーションなんか大らかで太っ腹だよなあ・笑。今、一番好きな出版社かもしれません。)
だから、逆手に取って、Creative Commonsとかにしちゃえば良いんですよ(笑)。原著作者表示はキッカリとやってLuluで出すんだけど、ライセンスを「商業利用OK」「改変OK」にしちゃって(笑)。

「PDF置いとくけど出版したかったらすればあ?」

みたいに(笑)。逆に「上から目線」を貫き通す(笑)。そうすれば一石投じられるんじゃないでしょうかね。
C++は大変ですよね。
もうあちらこちら罠だらけの言語なので、
Effective C++あたりをがっつりと読み込んでから、
やっとなんとかプログラミングできるってところがあって、
それは、言語の問題だと思ってます。
さらにゲームとなるとDirectXなりOpenGLなりのお作法も覚えて、
ということになってしまうので、なかなかPygame入門のようには
いかないですよね。
僕はLogoというタートルグラフィックスが基本の教育用言語から入ったので、
限られた環境の中だけれどシンプルにゲームが作れたりして、
その点はラッキーだったと思ってます。

初心者にはやはり、言語処理系の実装、ライブラリ、エディタなどの
環境がそろったところで、はいどうぞ、というのが一番いいと思います。
内容はわかりませんが、「プログラミング言語Lisp」は、
そういった良い意味での実装依存の本で、良い本だったのだろうと思います。

JavaにもOpenGLラッパーやprocessingのようなものもあるので、
Clojure in a boxのような環境をもう少し強化して、
Javaの知識がなくてもClojureからprocessingなどのライブラリが使えるような
ドキュメントがあれば、「プログラミング言語Lisp」のように、
Clojureでプログラミング入門ていうのも熱いですね。
ただ、自分もEmacsを使っているのですが、本当の初心者に
Clojure in a box のEmacsを使わせるっていうのはどうですかね。
そこで引かれてしまうのが心配です。それは些細な問題ですが。

出版業界の問題に関しては門外漢ですが、自分としては、技術の変化に、いろいろな仕組みの変化が追いついていく過渡期なんだと思っています。
活版技術が確立されてから、著作権が法で認められるまでに100年以上かかったわけですよね。既存の出版社、取次ぎ、編集者、本屋、著者、読者、著作権という仕組みから、Webが登場した事で新しい最適値の仕組みへと自然に移行していくわけですが、それにはやっぱり時間がかかるものなんだと思います。

そういう全体の流れとは別に、ある情報を人に発信したいなぁ
と思ったときには、今あるものを使うしかないわけで、
Webなり出版社なりというものと、自分の目的と折り合いを付けながら
つきあったり選択したりしていけばいいんじゃないですかね。

話がそれるかもしれませんが、「猫でもわかるプログラミング 」なんてのも多分Webが先にあって本ができたんですよね、きっと。読んだ事はないですが。
停滞しているようなので、挨拶がてら話題でも。

iBATISをClojureから使いたいと思うのですが、ドメインクラスをClojureでどう実装すると良いでしょうか。
いや、まだClojure初心者なので、あっけない方法があるのかも知れませんが、今のところわからないので。

getter/setterだけしかない、POJOクラスが作れれば良いだけなんですがね...

ログインすると、みんなのコメントがもっと見れるよ

mixiユーザー
ログインしてコメントしよう!

Clojure 更新情報

Clojureのメンバーはこんなコミュニティにも参加しています

星印の数は、共通して参加しているメンバーが多いほど増えます。