#http://bit.ly/7xz9Io のせい？とのこと(<)。 相当前だが"lisp は強力ですが、シェアが低いので業務で使えない-->引継や大規模開発ができないため"には自分も腐心した > @nitro_idiot なんでハッカーと画家が上位に… #ツイッターの規則を未だに良く把握できてなくて、2度同じメッセージ流して失礼しました(> )。 腐心した云々は古くは15年ほど前のことで、当時の制約の多くは今はないと思います。
#まあ、使う人が少ない→人が集められない、という循環については、地道に使用実績を積んで行くしかないんじゃないかと思いますね。周辺の作業としてwebや本で記事書いたりチュートリアル書いたりってのはあるけれど、結局「使われてます」を既成事実にしてしまう以外にない。
#「もう何十年も使用実績をつみかさねてきたのに流行ってないじゃないか」というのは外野の発言としてはありですが、中の人としては「あきらめた方が負け」なので「Lispが流行るまでは地味に頑張る」しかない。
#言語の選択は勝負というより適材適所と思いますが、時代はLispに追いついたと感じます。言語に限らず、若い人が、流行に流されない目を養うことを願います。 > 中の人としては「あきらめた方が負け」なので「Lispが流行るまでは地味に頑張る」しかない。
#くだんのG社の中の人は釣り発言をしているので真に受けるのもどうかと思いますが、Gの連中がLisp使えないなら使えないでいいよ、とも思います
#先日, 数百人規模の現場でLisp使いたい, という話をされて, その規模だとLispの良さ(マクロによる抽象化とか)がうまく発揮できないんじゃないかなぁとか思っちゃいました. Lispを使うマイナス要素はないと思いますが
#まぁあれだ、「使えるよ」「使えないよ」は子供の水掛け論にしかならないので、使って見せるしかないんでしょうね
#そういう意味で、「Lispハッカーの大規模チームを編成して実際に動かしてみせる」というのこそがチャレンジングではないかと
#そうですね。私自身は今、真に受けている訳ではありませんが、触れ方が適切ではありませんでした。(個人的には、何故 Python を、などと思わないでもありません。マーケティング的な意図を感じます。)
#>garaemon CLならとりあえずパッケージの割り振りとおおまかな依存関係さえ決めとけば、自分のパッケージ内ではかなりフリーダムでもいいんじゃないでしょうか。効率良くやりたい人はローカルにマクロなり何なり使うと.
#「人のコードが読めなくなる」みたいな話は、コードレビューをシステマティックにやるとか。
#あと、そもそも数百人が1枚岩のチームとも思えないので、サブチーム間のインタフェースだけしっかり設計しとけば、サブチーム(せいぜい7〜8人)内はけっこうぬるぬるべたべたでもよさそうな気が
#というか、他の言語だったらそうやらなくてもできるのか? という疑問もあるので
#現在ではテストとかレビューみたいなノウハウがずいぶん広く受け入れられてきたので、そういうのとどんどん組み合わせれば難しくはない気がする。ただ全体のトレーニングとか割り振りを含め、立ち上げようっていう張本人は分かってないとならないので、そういう立場の人間が何が何でもLispでいこうと決めるかどうかだよなあ。
#「人のコードが読めない」というのが克服できたとして、あとポピュラーな言語に対して不利な点は「ライブラリ」と「処理系の性能」かなあ。後者については、多くの最近の動的言語に比べればCLはけっこういけると思うんだけど、C++/Java/C#みたいな金持ちが開発資源突っ込んでるやつに対抗するのは大変。
#マクロに関してはどういうユニットテスト食わせるのかむずかしいなぁという感じはします
#そこでClojureみたいに「金持ちが資金を注ぎ込んで磨き上げた技術をインフラとして流用する」って戦略が出てくるわけですね
#>garaemon evalすればいいだけじゃない?
#あとmacroexpandしてパターンマッチかけるとか。
#> あとmacroexpandしてパターンマッチかけるとか。
なるほど. コンパイラマクロとかどうするんだろ...
#コンパイラマクロに関しては「そのマクロを呼び出す関数を定義してcompileし、呼び出して確認」かな。on-the-flyでコンパイルができるのだからそういう点ではむしろ他のコンパイル言語よりもテストがやりやすそうだけど。
#bcrypt (password hashingの方) をちょっと調べてたんだけど、オリジナルのOpenBSDの実装って宣伝条項付きBSDなんだね。 http://www.openbsd.org/cgi-bin/cvsweb/src/sys/crypto/blf.h?rev=1.6 ##修正BSDじゃないとGaucheには入れづらいな… こっちのはPublic Domain実装かな http://www.openwall.com/crypt/ #あれ、crypt_blowfishは一昨年にもソースを手元に落としてるぞ。どうやらその時に一度bcryptを組み込もうとした模様。すっかり忘れてた。
#gauche.testのprim-testって、一応exportされてますけど、使ってもいいもんですか?
#and-let* の test* 版みたいなのを作りたいなと思ってるんですが
#test* の and-let* 版か
#あーでもprim-test使っても、テストした式の値を成功した時のみ取り出すようなことはできないですね
#スクラッチから作った方がよさげ
#prim-testは、test*に使われている高度な機能がテストされる前に、それらをテストするための最低限の機能を実装したものです。なので使って悪いことはないですが不便極まり無いのではないかと。
#それはそうなのですが
#Gauche-dbd-mysqlのテストを書いていると、何かAPIを呼んで、それが正常にopaqueなオブジェクトを返すことをテストして、それが成功だったらそのオブジェクトに対するAPIを呼ぶテストをずらっと並べる、というのがわりとイディオムになってて
#まぁ、そういう依存のあるテストはユニットテストとは言えないのですが
#そういう一連のテストを書きやすくするのに、どうするのがいいのかなぁ、と思案中なのです
#testを実行すると#<undef>が返るので
#これが成功した時はテストした式の値を返してくれると、そういうand-let*的なマクロを書くのが楽になりそうなんですが
#こういう考え方って、ひょっとしてCL的?(笑)
#外しているかもしれませんが、すべてtest*で書かなければいいんじゃないでしょうか。
#(let* ((obj (get-object))
(correct? (check obj)))
(test* "obj check" #t correct?)
(when correct?
(test* "test 1" ...)
...))#こんな感じで、頻出するならマクロを定義するとか。
#それだと、get-objectが失敗した時(例外を上げた時)、testの恩恵を受けられないんですよね
#まぁ、guardで囲ってごにょごにょすればいいんですが
#わりとよくあるイディオムだと思うので(特に他のライブラリを呼ぶ拡張なんかのテストの場合)、何かスマートな方法があるかな、と思って
#テスト結果の集計の仕組みなんかはgauche.testからexportされてないので、そのあたりには手が出せないのですよね
#なので、prim-test以上のレイヤを組み合わせてやりたいな、と
#うーん、私だと、guardで囲ってごにょごにょするかな。testはあくまで集計するためのAPIと割り切ってしまう。
#ふむ
#まぁ、今のgauche.testのAPIだと、それが真っ当な方法ですね
#(び)さ
#しまった、変なところで送信してしまった。(び)さんが言うように「テスト結果の集計」みたいな低レベルなレイヤもいじれるとうれしいかも。
#テスト関係のイディオムをまとめているような資料ってないのかしらん。
#そっか、依存性のあるテストで、途中がfailしたためにその後がずらずらっとfail、というのは時々あるんで、何とかしたいなとは思ってました。
#ただ、途中でfailした後をskipしちゃうと、skipされたテストの数が最終集計に出てこないので、それもちょっと嫌ですね。最初の方でこけて残りがテストされてなくても、集計で1 failedだと「ああ、ひとつだけfailか、悪くないな」とか思っちゃう。
#Maybe monadみたいに失敗/成功をimplicitに持ち回ってしまうと良いかも。(test-sequence (test* ...) (test* ...) ...) とか書いとくと、シーケンスの途中でfailしたら残りはskipするんだけどskipした数は集計される、といった具合で。
#ふむ
#skipは別カウントというのはどうでしょうね
#あ、勘違い
#skipとしてカウントするってことですよね
#それがいいな
#そうです。2 failed, 42 skipped みたいに出す。
Gauche > Archives > 2010/01/04