2012/02/13
やりたいことかどうかって、やってみないとわからない
最初は下手だし失敗続きだろうけど、 我ながらひでぇ出来だけどとにかく作れたことにちょっと誇りを感じちゃったりとか、 自分の下手さに直面した上でそれでもああもっと上手くなりたいなあと切に願ったりしちゃうかもしれない。 あるいは、作る前には予想もしなかった障害に次から次に出会って、 そこまでしてやりたいわけじゃないや、と気づくかもしれない。
本当に、モノづくりがしたい人は、ひとりで作り始めています。絵を描いたり、曲を作ったり、ゲーム作ったり、映画を撮る人も居る。これは衝動であり、技術がないからやらない、仲間がいないからやらないとかそういうものではないです。
つまりこの学生は、ほんとはモノづくりなんかしたくないんです。ただモノづくりに憧れてるだけ。それを憧れのままにしててモヤモヤ諦めきれずに、なんとなくそれっぽい業界に入りたいと思っている。はっきりいって迷惑です。
至極当然のことが書いてあるなあと思って読んでたんだけど、 はてブを見たら、全然違うふうに取ってる人がいてちょっと驚いた。 曰く、育ててる余裕がないから即戦力が欲しいだけじゃないかとか、 大学や専門学校では会社で必要なスキルは学べないんじゃないかとか。
いや、「学生時代に何か作って得たスキル」が即戦力になることなんて期待してないと思うよ。
もちろん学生時代からプロで通用するすごい人は時々いるけど、 そういう人は業界が放っとかないのでこの話の対象外。
それ以外の人は「特別な実績もスキルもない新卒学生」でいいんだよ。 「仕事のスキル」は現場で教えられるし、「実績」は仕事でしか積めないんだから。 多くの人は、やりたい人に教える気は持ってるし、教えたいと思っているはずだよ。
だけれど、「これがやりたい仕事である、と本当に思っている」ってことは、 応募にあたっての最低限のラインじゃないかな。でなけりゃ教えたって無駄になっちゃう。
一度も何かを完成させたことがないってことは、 これをやりたいって心底思ってるのか、 それとも単にこれもいいかもしれないなとぼんやり夢見ているのか、 自分自身にだって判断する術が無いってことじゃん。
もちろん、それをどう判断するかっていう方法は業種によって違う。 現場に入らないと経験が出来ないって業種もあるだろうし、 そういうところでは「受ける前に経験積んでこい」ってのは無茶な話だ。
ただ何かを創作する業種なら、現場に入る前にやってみることができるし、 本当にやりたいかどうかの適性判断テストとして他の方法はないと思う。 (それにパスしたうえで、なお「自分はこれを仕事としてやるよりアマチュアでやってゆく 方が向いている」と気づくことはあるけれど)。
言い方が偉そうで気に入らないって人もいるみたいだけど、 別に理不尽な要求してるわけじゃない。本当にやる気がないのは (あるいは「やる気がある」と自己暗示をかけてるだけの一時の気の迷いは) 「ひやかし」だ。ひやかしは勘弁して、っていうのがそんなに偉そうかな。
★ ★ ★
ちょっと似た構図だなと思ったのが、最近あった、 岩波書店の「応募には社員か著者の紹介が必要」という要綱への賛否両論。
否定派は「この慣習が広まったら就活のハードルがさらに上がる」って心配してるみたいなんだけど、 自分はこの業種でこの会社だから意味を持つ条件であって、広まる必然性が無いと感じた。 編集者さんと付き合いがあるだけで、出版業界の中はよく知らないから 外しているかもしれないけれど。
ある出版社の本を読んで著者と意見交換したくなったら、その方法はたくさんある。 そういうことを、就職なんて関係なしに、既に自分からしちゃってる人と、 岩波が採りたいと思っている人の適性とがかなり一致してるってだけじゃないかな。 今まで一度も著者と連絡を取りたいと思ったことが無かったとしたら、 そもそもどうして自分が出版業界に向いてるって思ったのだろう。
ジェネリックな適性検査や筆記試験、 あるいは曖昧な「やる気」や「コミュニケーション力」を要求する面接の方が ずっと非人間的な、ひどい選考方法だと思うけど。
★ ★ ★
まあこういう条件を明示することで、こんどはコネを作るのがテクニック、みたいに なっちゃう可能性はある。最初の話にしても、「就職に必要だというから とりあえず学校の課題で作ってみました」みたいなポートフォリオを揃えてくる人はいるだろう。 そうなっちゃたらまたその時に考えればいいことで。
2012/02/10
コードの適者生存
金谷さんの『プログラマへの誤解』に対して小飼さんもエントリを書いてて、私と議論が逆方向でおもしろい。
プログラムの書かれる背景をどう設定するかで違いが出てくる。Google+での議論参照。
私も、汚くても遅くても動くものをまず出すって点が重要で、ベストな解を求めるあまり頭で悩んで書けなくなってしまったら逆効果だっていうのには同意する。
ところで上のGoogle+の議論で私はあまり考えずに「淘汰」って言葉を使ったんだけど、 コードの栄枯盛衰は案外生存競争に似ているかもしれない。 性能要求がシビアなところで適者生存則が働いて、 「書かれたけど残らなかったコード」が大量に産まれる、というところだけじゃなくて、 哺乳類の眼の網膜の配線が逆になってるように、 たまたまある環境で「他よりマシだった」だけで定着したけどよく考えると効率悪いよね、ってコードが残ってることもかなりあるなあと。
特に仕事で書くソフトの場合、あーあそこ直したいなあと思ってても、 お客さんの要求に応える方が優先されて手がつけられないところは多い。 特定の場合に性能が悪くて、どう直せばいいのかも分かってるんだけど、 運用で回避できるのでとりあえずそうしてもらってる、というような。
そういう意味では「いろいろ試してベストを取る」というコーディングが出来るケースってのは 作り手にとっても恵まれた環境かもしれない。 ましてやそれが仕事上の要請と一致するなら、それはとてもラッキーなことなのかも。
Tag: Programming
2012/02/09
simple-vector
simple-vectorがよく分からない - conjの日記
Clozure CL や Steel Bank Common Lisp で以下のような挙動になった.
(subtypep 'fixnum 'integer) ;=> t (simple-vector-p (make-array 10 :element-type 'integer :initial-element 0)) ;=> t (simple-vector-p (make-array 10 :element-type 'fixnum :initial-element 0)) ;=> nil最後の式が nil を返す理由が分からない.
コメントを書こうと思ったら長くなったのでこちらで。
まず教科書的な答えを言うと、simple-vectorは「ジェネリックなLispオブジェクトを格納できるsimple-array」と決められているから。型表記で言えば (simple-array t (*)) ならsimple-vector。上の二つのarrayをdescribeしてみると、前者はジェネリックだけど後者はfixnumに特殊化されているだろうと思う。下はAllego CLでの実行結果。
cl-user(7): (describe (make-array 1 :element-type 'integer :initial-element 0)) #(0) is a new (simple-array t (1)). There are 1 elements cl-user(8): (describe (make-array 1 :element-type 'fixnum :initial-element 0)) #(0) is a new (simple-array fixnum (1)). There are 1 elements
(simple-array fixnum (*)) はfixnumに特殊化されてるから、simple-vectorになれない。
でも、これだけだといくつか疑問が浮かぶんじゃないかと思う。
上のarrayも:element-type 'integerしてるのになぜintegerに特殊化されてないの?
Common Lispでの型情報はあくまで最適化のためのヒントにすぎないので、処理系は型情報を全て無視して全部ジェネリックなLispオブジェクトとして扱っても構わない。なので:element-type 'fixnumしてるarrayが(simple-array t (*))になる(したがってsimple-vectorにならない)可能性だってある。ただ、普通の処理系では要素がfixnumの配列は特別扱いすると有利なことが多い。数値を保存しておくのに型情報をつけなくてよいとか。
一方、要素がintegerの場合はbignumも格納しないとならないんで、そうすると特殊な配列を使うメリットがあまりない。bignumは普通ヒープに置かれて型タグもついたLispオブジェクトになるから。だから処理系はえいやっとジェネリックな配列を使っちゃうわけ。
そもそもsimple-vectorって何のためにあるの?
効率のため。Lispの配列は高機能で、要素の格納形式が指定できたり、動的に大きさが 変えられたり、他の配列の一部分を別の形の配列としてアクセスしたりできるんだけど、 その場合、アクセスの度にいろいろ確認したり変換したりというコードが必要になる。
でもsimple-vectorなら、それはC言語でいう配列 LispObj x[] と同じものと
みなせる。(declare (optimize (safety 0))) すればインデックスの範囲チェックも
省かれるので svref はCで書いた配列アクセスと同等のコードになる。
というわけで高速なLispコードを書くときにはsimple-vectorとsvrefは強い味方。
(subtypep 'fixnum 'integer) => tなのに前者の配列が後者の配列のsubtypeにならないのはなぜ?
これはCommon Lispに限らずパラメタライズされた型に一般的な性質。
型Sが型Tのサブタイプでも、パラメタライズされた型X<T>は型X<S>のサブタイプになるとは限らない。
SがTのサブタイプである (S <: T) ということは、Tを期待してる文脈に実際はSであるオブジェクトを渡してもいいということ。例えば Fixnum <: Integer ということは、Integer のインスタンスを期待してるところに Fixnum のインスタンスを渡せる、ということ。
ここでもし Fixnum <: Integer だからといって Array<Fixnum> <: Array<Integer> であることを許すと、Array<Integer> を期待している文脈に Array<Fixnum> を渡せることになる。例えば次の式ではiarrayがintegerのarrayであることを期待して、bignumを代入しているが:
(setf (aref iarray 0) 47874827583458281495927465923753928)
このiarrayにfixnumのarrayを渡したらまずいでしょ、という話。
もっときっちりした話はTAPLの15章あたり参照。
Tags: Programming, Lisp
2012/02/09
ピアノレッスン35回目
- スケールとアルペジオ M=144。直前に家で弾いた時はなんかうまくいかなかったんだけどレッスン室のピアノではなんとか弾けた。家では日によってM=152で指が回ることもあるし144できついこともある。
- Bach: Fantasia in C minor。M=120で。難しいところで集中すると、そのあと気が抜けて簡単なところでミスる。来週はきめられるかなあ。
- Kapustin: Op40-7。M=72。このくらいのスピードでようやくリズムがいい感じになってきた。
Tag: Piano

Comments (2)