メッセージ。 - diary

いままでたくさんGaucheでプログラムを作ってきたが、あまりテストコードを書いたことがなかった。だけどここ数日、ちょっとテストを書く機会があって、けっこう勉強になっている。なかでも、値を返さないような関数のテストをどう書けばいいか分からなかったので、メールでshiroさんに尋いてみた。

そうすると親切に教えていただけたので、せっかくの情報が共有されていないのはもったいないので、ここで公開してみます（shiroさんには許可をもらっています。ありがとうございました）。#<undef>を返す関数のテスト方法とか、valuesを引数なしで呼んだらどうなるかとか、あまり考えたことがなかったので勉強になった。テストの書き方（シンタックスではなくセマンティクス的なもの）って、案外ネットとかを調べても載っていないような気がする。

fujisawa:

 基本的なことを質問しちゃって恐縮ですが、

 s3-bucket-create 等で(values)を返しているのは、

 どういう意図があるんでしょうか？ valuesを無引数で

 呼んだとき、どういう挙動をするのかよく分からず、

 テストをどう書こうかなーと思案中です。

 #<undef>を返すわけでもないんですよね…。

shiroさん:

 「戻り値が無い」ことを示すためです。まあ別に#tとか適当に返しといても

 いいのですが。valuesは渡された引数の数だけの値を返しますから、

 無引数で呼ぶとゼロ個の値を生成します。call-with-valuesの形で

 考えるとわかりやすいかも。

 

   (call-with-values (lambda () (values)) list) => ()

 

 テストについてですが、こういう副作用だけに意味がある操作の場合は

 そもそも戻り値を見る意味がないので、(1)操作実行後にその効果を

 別関数で確かめるか、(2)操作の実行が完了したことだけを、別の値を

 返すことで確かめるか、ということになります。

 

 (1)の場合の例:

   ;; まずバケットがavailableであることを確認

   (test* "bucket-availability" 'available

          (s3-bucket-availability "test-bucket"))

   ;; s3-bucket-create!する。戻り値は見ない。

   ;; 直後にもう一回availabilityを見て、確かに変化したことを確認する

   (test* "bucket-create" 'taken

          (begin (s3-bucket-create! "test-bucket")

                 (s3-bucket-availability "test-bucket")))

 

 (2)の場合の例:

   ;; まずバケットがavailableであることを確認

   (test* "bucket-availability" 'available

          (s3-bucket-availability "test-bucket"))

   ;; s3-bucket-create!して、そのあとで適当な値を返す。

   ;; s3-bucket-create!がfailすれば#<test-error>になるはずなので、

   ;; #tが返ってくれば少なくともエラーにはならなかったということがわかる

   (test* "bucket-create" #t

          (begin (s3-bucket-create! "test-bucket") #t)

   ;; 改めて操作の完了を確認

   (test* "bucket-availability after create" 'taken

          (s3-bucket-availability "test-bucket")> )

shiroさん:

 関連して、一般に「戻り値が未定義である」という手続きをテストするのにも、

 戻り値を比較したらだめですね。「現在のバージョンのGauche」では

 たまたま#<undef>を返すかもしれませんが、もともと未定義なんですから

 将来どうなるかはわかりません。

 意味のない戻り値として最後の式に(values)を使う作法は他の処理系のソースで

 見たんですが、「戻り値を使わないでね」というメッセージにはなると

 思います。

 

 ちなみに(values)で戻ってくるゼロ個の値 (という言い方も変ですが) を

 無理やり変数に代入したり引数に使ったりするのはSchemeとしては不正な

 プログラムです。Gaucheではいちいちエラーにしませんが、その時得られる値は

 でたらめです (通常、直前の計算でVMのレジスタに残ってる値がそのまま見える)。

んー、これ前に書いたっけかな？

先日、といってもだいぶ前だが、親戚一同が集まる法事があって、食事の席でおじさんから「どうしてあなたは結婚しないの？ 最近の若い人は結婚しないの？」と尋ねられた。例によって、そのときはうまく説明できなかったのだけど、でも答えはボンヤリと頭の中に浮かんでいた。

結論としては、若い人が結婚しないのは当然だ。たとばぼくの場合でいうと、ぼくの親父は家を継がなかった。親父の実家は商家をしていて、親父はそこの長男だった。ならば（彼らの価値観で言うと）当然親父は家を継ぐべきだった。なのにどうして継がなかったのか？

それがまさに、「どうして若者は結婚しないのか？」に対する答えだ。「どうして彼らは家を継がなかったのか？」、自分で考えてみればいい。考えてみて答えが分かるなら、「どうして若者は結婚しないのか？」も分かる。というか、当然そのぐらいは彼らも薄々考え、結論に至っているだろう。

「どうして彼らは家を継がなかったのか？」と「どうして若者は結婚しないのか？」は、ある程度同じ意味を持っていると思う。どうして彼らが家を継がなかったのかというと、それはやはり、「家」という制度が時代の中で合理性を失ってきていたからだ。若い人たちが都会に移り住み、小さな商家というものが、大きなスーパーや郊外型のお店に飲み込まれていくことが見えていたからだ。

だから親父は商家を継がずサラリーマンになった。質問をしてきた当のおじさんも、実家の店をもう畳んでしまっている。彼らは、頑ななまでに「家」を守ることをしなかったのだ。ならば、家がないのに、どうして結婚する必要があるのか？ 彼らの言う「結婚」というものは、「家を守る」ことを含意している。旧来の「結婚」は、ベクトルとして「家（家系）を守る」ことと一致している。だから、彼らがやってきたことと、ぼくらがやっていることは、そう違いがない。

ここ数十年（あるいは百年以上？）人々は都市に移り住み、その過程で家を捨てさった人も多い。守るべき家を捨てたものが、「どうしてあなたは家を捨てるのか？」と尋ねても仕方がない。彼らだって分かっているだろう。そういう流れなのだと。「家（家系）」という価値観、「結婚」という価値観は薄れつつある。それらは合理性や文化という点で解体され続けている。若者が結婚をしなくなったのは、突然始まった断絶によるものではない。

最近、就職活動をしている。でもなかなか仕事が見つからない。どうして見つからないのか。就職活動をしてみて感じたことは、「企業は即戦力を求めている」ということだ。たとえば、モバイルサイトの開発会社なら携帯サイト開発経験者を募集してるし、組込み機器の開発会社では組込み開発の経験者を募集している。だから、ぼくのように「ジョブチェンジしたい」という人は、なかなか要らないようなのだ。（とくにぼくの場合は、歳がいっているということもある。書類選考で落ちることも多い）。

まぁたしかに、企業の立場に立って考えてみれば経験者が欲しいというのも分かる。自分の経歴書を見て自問自答をしてみても、「いったいこの人は何ができるのか？ この人を雇ってペイするのか？」と感じる。しかし、時代は変化しているのだから、「ジョブチェンジしたい」という人もそれなりに存在すると思うんだよなぁ。たとえば今はSEをやってるけどこの先不安だとか、パン屋をやってるけどもう疲れたとか。でもこの不況の時代、「ジョブチェンジしたい」と思ってもなかなかうまくいかないのだろう。厳しい。

ぼくの場合も前職が雑誌の編集職で、しかし編集職なんてこの長い出版不況の中で募集があるわけがない。というかぼく自身が、雑誌の編集をしたいとか「自分は雑誌の編集をしている」とかそもそも思っていないのだが。前にどこかで読んだ、「Googleで働いているオフィス清掃の人は、自分の仕事が掃除夫だとは思っていない。彼は自分の仕事が世界中の知識を整理する仕事を手伝うことだと思ってる」みたいな意見があったけど、それに近いことをぼくも思っている。あれ？ 話が脱線した。要するに、「新しい仕事」を求めている人って、今の時代多いと思うんだよなぁ。それはあたかも、新しい未来を求めるように。

何年か前に梅田さんのWeb進化論で、「インターネットのおかげでこれからは仕事や雇用というものが流動化する」ということが書かれていたけど、ああいうのは本当に実現するのかなぁ。まぁそもそも、そういう働き方ができるのはピラミッドの上のほう一部だけで、ぼくみたいなヘッポコには関係ないのかもしれないけど。ただ、あの本が書かれた当時を振り返ってみると、アメリカが好景気で中国とかBRICsとかが今ほど力強く感じることはなかった時代で、いまのような「少ない仕事とお金を奪い合う」みたいな状況が想定されていなかったのではないかなぁ、とか思う。

ぼく自身のことを言うと、関数型言語が割と好きで、SchemeとかHaskellとかを勉強してきたけど、でもそういう技術要素で募集をかけている企業は、就職情報サイトを探してもぜんぜん見つからない。技術者として募集されているのはたいてい、PHPかJavaかせいぜいRuby on Railsができる人で、しかも最近だとそれらのうち、何らかの（メジャーな）フレームワーク経験者ばかりが求められている。まぁそりゃあ分かるのだ。分かるのだが、自分からすればあまりにも遠くに来てしまった感があり、困ったなぁ、と。Web上ではたまに、Joelの文章で「どんな技術者を採用すべきか」というのがコピペされているが、そこには「ポインタを真に理解している技術者を慎重に見分けるべきだ」みたいなことが書かれていて、ちょっと腹立つ。ポインタの理解なんて、どこの企業が求めてるんだべ？ ポインタを理解しているからって雇ってくれる企業ってあるのかな？

まぁいい。いいのだ。就職活動しているといっても、まだそれほど動いているわけじゃないし、いろいろ勉強になっている。ある程度苦労したほうが、現実世界を理解するのに役立つとも思っている。だからまぁ、いいのだ。しかしこの先、どうなるのかなぁ。なんとかお金を手に入れなきゃいけないのだが、お金を稼ぐというのはとても難しいものだと実感する。UK STUDIOさんが「プログラマという職業は「ふつう」の人には厳しくないか」と書かれていたが、お金を手に入れるのは「ふつう」の自分には厳しいのかもしれない。いや、自分が普通以下の可能性も高いか。

普通以下という話でいえば、ぼく自身がSchemeやHaskellの分野でとくに優れた業績を出せていないというのも厳しい話だ。それらの言語が好きだと言ってもたんなる下手の横好きで、extremeなプロダクトを開発するなんてところには全然手が届かない。まぁなんとか新規性のあるものを作りたいと思っているが、「新規性があるかどうか」を把握すること自体が難しい。ソフトウェア開発には研究的な要素があり、そういう非労働集約的なR&Dがしたいと思ったらそれはそれなりのコストセンターというかビジネスエンジンが必要だ。逆に労働集約的なビジネスならそういったビジネスにも、それなりのビジネスエンジンが必要である。そしてぼくは、そのどちらにも引っかからない中途半端に位置にいるのではないか、とか。

いったい自分には何ができるのか？ 以前テレビで『人生が変わる1分間の深イイ話』で、奈良で刀鍛冶をしているという人間国宝の人の意見が紹介されていた。「一生をかけるに足る仕事の見つけ方とは？」というもので、その人はこう答えていた。「一生をかけるに足る仕事を見つけるというのは難しくて、どうすればよいのか自分にもよく分からない。でも、一生をかけるに足る師匠を見つけるのなら、できるのではないかと思う。仕事を探すのではなく、人を探してみてはどうか」と。まったく同感で、自分もそういう風に働けたらなぁ、と思う。そういう風に働きたい。でも具体的には、どうすりゃいいのかなぁ。

あれ？ でもなんか、そもそも自分は、「一生をかけるに足る仕事」を探しているのではなかったかも。いまでもなんとなく、やりたい仕事、やらなければならない仕事のようなものはボンヤリと見えている気がする。でも、そこに辿り付く方法が全然想像つかないのと、「これ」という具体性を帯びていないように感じる。あと、自分にそれをする能力があるのか？という問題。それとそれと、やっぱり師匠みたいな人がいたらなぁと思うんだよなぁ。なんというか、道が欲しいというか。道が欲しいなんて贅沢なのかなぁ。まぁとにかく、なにか仕事があったらどんな仕事でもいいから声かけてください。という状況に、だんだんなりつつあります。

ちょっと人と会ってHaskellについて説明する機会があって。そのときはうまく説明できなかったのだが、帰り道に「ああ言えばよかったなぁ」と後悔した。そういうことはよくあるのだが、とりあえず今日の件をここに書き下しておく。

Haskellは、ほかのプログラミング言語と比べて一段抽象的にプログラミングができますが、逆に言えば一段抽象的にしかプログラムが書けないということでもあります。ここで「一段の抽象化」と言ったのがまさに「遅延評価」です。

Haskellでは一段抽象的にプログラムを書けるので、つまりコーディングが簡潔になります。コードの可読性は高くなりますし、「Cで書くよりRubyで書くほうが簡単」なのと同じように、「Rubyで書くよりHaskellで書くほうが簡単」になります（少なくとも理論上は）。

しかし一方で、基本的にHaskellでは一段抽象的にしかプログラムが書けません。これは、Haskellのプログラム内で具体的なこと、たとえば関数の実行順序やメモリ使用量などをコントロールしたい（減らしたい）といったことが、（ほかの言語でできるようには）自由にできないことを意味します。

たとえばC言語でプログラムを書いていると、ところどころでインラインアセンブラを使いたくなることがあるかもしれません。そういうとき、もし、「このCコンパイラではインラインアセンブラが使えないんですよ」と言われたらどうでしょうか？ 不便に感じるかもしれません。まぁそれはそれで仕方がないかと思うかもしれません。

Haskellにもそういうところがあります。普通の言語がアセンブラだとしたら、Haskellは「インラインアセンブラが使えないCコンパイラ」みたいなものです。Haskellは一段抽象的なため、プログラムが書きやすくなります。ですが一方で、メモリ使用量や実行効率、デバッグ方法などの面で、ちょっと手が届かないところがでてきます。

百貨店の業績不振を伝えるニュースを見たりして思ったこと。

最近、食材や服なんかを見ていると、外国産が増えたなと思う。うちの親父なんて、酢豚を初めて食べたのは社会に出てからだとかなんとか言っていたが、そう考えると、ぼくらの暮らしは戦後からずっと国際化したり物が豊富になったりしているんだろう。昔は国産がほとんどで、外国産の服も食べ物も憧れの的だった。ぼくらは海外のことを知らなかった。しかしそのバランスはどんどん一方向に傾いている。

かつては、日本という国の中に物がなかったのだ（あるいは物の多様性が低かった）。その意味で、かつての百貨店は珍しくて高級な物が買える場所として国民に受け入れられたのだろう。昔は、家族で百貨店に出かけ、ショッピングをし、レストランでお子様ランチを食べることがステータスでありレジャーだった。しかし時が過ぎ、いま百貨店は長らく不振を続けている。なぜか？ それはやはり、百貨店の中に、憧れるに足る商品が少なくなってしまったからではないか。

百貨店だけではない。もはや、珍しく憧れるに足るような商品は、日本という国の中では見つけにくくなってしまった。原因の1つは物や価値観の「多様化」であるだろうが、別の側面から見ると物が「豊かになった」ことにあるのではないか。食材も服も文化製品も、もはや国境を容易に越えてやってくる。気が付けば否応なしにそこにある。それらが希少資源であった時代には、輸入して店先に並べるだけでお客の好奇心を満たすことができたが、現在ではそういう時代を過ぎ去ってしまった。

つまり日本人は、どんな物を持ってこられてもそう驚かなくなっているのではないか。価値を感じにくくなっているのではないか。そういう意味で、日本では戦後からずっと物の価値が下がり続けていて、逆に貨幣の価値が上がり続けていた、ということなのかもしれない。だとしたら、そりゃあビジネスも難しくなるはずだ。