2010/03/16

言語の強み

ネタメモ。

ある言語の強みって何だろう、とか、他の言語と比べてどうだろう、 ということを考える際には、いくつかの要素が絡んでくる。

1. 言語そのものの素性。例えばLispなら、S式を使うこと、 プログラム=データであること(homoiconicity)、 マクロの存在、read-write invarianceなど。 その言語のaxiomやそれに近い定理、みたいなもの。
2. 具体的な言語仕様。ANSI CLがどうだとか、RnRS Schemeがどうだとか。
3. 実装。Allegro CLの機能や性能がどうだとか、Gaucheはどうだとか。
4. 対象。どこまでの範囲を相手と考えているか。Lispなら "Turtles all the way down" とか。

("Turtles all the way down" は言語界ではしばしば、言語自身の実装が上から下まで全てその言語で書かれていることを指す。参考)

「言語」の比較をする場合、あくまで理屈の上では1と2の範囲に絞って 考えるべきだ、という議論があるだろう。

また、「今、実際に使えるのか」という議論になる場合、1と3が議論の中心になりがちだ。 というのは2と4は、議論する人の中では暗黙の前提になってる場合が多いから。 (実装＝仕様な言語なら2と3を区別する必要はないし、4については 暗黙のうちに自分が使う分野を想定している)。

現実にはこれらの要素は相互に関連していて、 一つの要素での選択が別の要素での選択に意味を与えているので、 分離して考えるのには無理がある。

例えばLisp族言語は、外から見るとみんなカッコだらけで一緒くたに 見えるけれど、中では互いにdisり合う殺伐とした戦場である。 素人にはお薦めできない。 これは、上の要素のうち見ている部分が違うということで説明できる。

Eric RaymondやPaul GrahamがLispを語る時は、主に1の話が中心だ。 一般にも、LispのLispっぽさというのは1の要因にあるように受け取られているように思う。 だから、S式とマクロを持った新たな言語を作れば、それはLispの方言だということになる。

一方、現場で長年Lispを書いてきたプログラマにとっては、 4の要素の存在が大きいようだ。 つまり、必要とあらばベアメタル上にGCやOSが実装できるとか、 出力されるネイティブコードをソース上からチューニングできることが前提であって、 それができない言語は最初から対象外なのである。

また、実際に商用システムを動かして何年もメンテしてゆく立場のプログラマに とっては、安定した言語仕様と処理系の存在は欠かせない。 数年ごとに仕様改訂があるSchemeですら、CLerにとっては信頼するに足らない 言語であって、ましてや実装のバージョンアップで仕様がころころ変わるような 言語はとても使えないということになる。

そんなわけでLisperの中だけでも様々の流派がひしめいているのだ。

• 哲学派 - S式は宇宙だよ
  • 博愛主義 - Lispの哲学は他の言語にも浸透してる。 RubyもPythonもPerlもLispの亜種にすぎないぜ！
  • 理想主義 - 修行を極め真理を悟れば理想の言語に到達するはずだ。 それは4ページの仕様で全てが語り尽くされ、 また全てのプログラムは100行以内で書かれることになるであろう。
  • 冒険主義 - JVMで走るLispつくったよ。 Flashで走るLispつくったよ。ニコスクリプトで走るLispつくったよ。…
• 安定派 - ANSI CLは100年後でも戦えるぜ。
  • バンドワゴン主義 - 実装はJVMでもCLRでもいいよ。 どうせハードとランタイムは速くなるし。
  • 泥団子主義 - この超抽象DSLは自作の汎用DSL構築フレームワークと 意味記述検証フレームワークの上に乗っかってて、それらのフレームワークは 自作のグラフ最適化ライブラリと作者の名前を冠したユーティリティライブラリ の上に乗っかってて、それからcomp.lang.lispに流れたライブラリとか どっかのサイトで見つけたライブラリ(今はもうサイトがないけど、 必要ならソース送るよ)とかあれやこれや50くらいの モジュールに依存してるけど、全部Common Lisp上で走ります。
• 性能派 - Cより速くなきゃ意味ないでしょ。
  • 自作主義 - 組み込みのGC遅いから自分用のGC書いちゃいました。もちろんLispで。
  • 最適化原理主義 - その無意味なmovを俺に削らせろぉぉぉ。

言語論争が平行線をたどるのはこのへんのウェイトの置き方が違うという 理由もあるかも。

Tags: Programming, Lisp

2010/03/15

DST

月曜朝5:30はカンファレンスコールの時間。

• "good morning, this is shiro"
• "hi shiro"
• "hi"

……しばらく待ったが、うちとヨーロッパ組しかいない。あれ?

• "... isn't US in summer time from this week?"
• "aha. so, are we 1 hour early, or 1 hour late?"
• "late. they're already done an hour earlier..."

ありゃりゃ。

けどヨーロッパは月末から切り替えで良かった。一斉切り替えだったら 自分だけ一時間遅れで「ナゼダレモイナイ…」となるところだった。

Tag: 生活

2010/03/14

Financial Core

ローカルの役者のコミュニティでちょっと話題になっていたのでメモ。

SAGのようなユニオンが力を持っているのは、 「メンバーはノンユニオンの仕事をしてはいけない」という縛りがあるからだ。

ところで、もともとの連邦労働法では、組合と雇用者が 「組合加入を雇用の条件にする」場合、その組合加入というのは 組合費を納めてさえいればよい、というふうに決まっているらしい。

従って、「組合費は払うけど、ユニオンの規則には縛られないよ」という人を ユニオンは拒めない。そういうメンバーの状態は financial core (FiCore) statusと呼ばれる。 FiCoreを選ぶと、ユニオンの規約改正や代表者を選ぶ投票権はなくなるが、 ユニオンの仕事は完全な組合員と同等にすることができ、 さらにノンユニオンの仕事もできる。

SAGとしてはしかし、FiCoreな人が増えるとユニオンとしての交渉力が 弱まってしまう。雇用者側がユニオンの条件を呑む理由は、 そうしなければノンユニオンでしか雇えない →業界内の主要な役者・スタッフのほとんどが雇えないことになる、 というものだからだ。

なので、FiCoreについては色々風当たりも強いらしい。 ノンユニオンな友人の自主映画製作に参加するためにFiCoreになることを 考えたJon Voightはバッシングを受けたそうな。

• Open Letter by Jon Voight

ハワイではユニオンの仕事が不定期にしかこないこともあり、 FiCoreを選ぶ人も珍しくないそうだが。

他の資料。

• Financial Core
• The Mystery of Financial Core

Tag: 芝居

2010/03/06

小さな会社ばかりでも困る

「会社に人が属する」のではなく、「人に会社が属する」時代 - Zopeジャンキー日記

産業の中心が知識や情報のほうにシフトしていくにつれ、会社の規模が大きいことのメリットは薄れていく。

会社もそれと同じように、だんだん小型化して、気軽に作ったり、消したりするようになるだろう。金融などで使われる「SPC（特別目的会社）」のように、会社は「行き先（目的）」の決まった「乗り物（ビークル）」になるのだ。

あるいは、映画の製作のような「プロジェクト」に近いものになる、といってもいい。そこではあくまでも、プロジェクトに参加する「個人」が主役であって、会社という仕組みは脇役だ。そして、プロジェクトにはつねに「目的（ゴール）」があり、「締切（期限）」が区切られている。目的の「成果物」ができたら、それでプロジェクトは解散になり、参加者はまた別のプロジェクトに散っていくのだ。その「成果物」は出資した人のものになり、それが成功すれば出資者は儲かって、プロジェクトの参加者は栄誉と実績を得る。映画の世界は、まさにそういうふうに動いている。

私自身は実際、プロジェクト毎に参加する形でソフトウェアの仕事をしてるし、 そういうプロジェクトに集まってくる連中もだいたいそんな感じだ。 そういう連中は自分のビジネス用に会社を持っているし、 かつ会社を作ったり畳んだりした経験もあることが多い。 だから、ソフトウェアの世界は既にそういう方向にかなりシフトしているとは思う (会社を作るのは簡単だ。たぶん最も難しいステップは 会社名を考えることだ。)

ただ、その方向が加速化するかどうかと考えると、 全部が全部そんなふうにはならないだろう。 一部の個人プレーヤーに関しては、おそらく今よりももっと 小回りの効く仕事形態が最適化されてゆくだろうし、 それに伴う新たな専門職も産まれるとは思うが、 全員がそうなれない理由がある。

まず、映画やコンソールゲームなら作ってしまえばチームは解散できるけれど、 普通のソフトウェアというのはユーザがいる限りメンテナンスしていかないとならない。 メンテナンスは瞬発力よりも継続性が必要で、かつその継続性をユーザに 信頼してもらわないとならないので、継続する組織が必要とされる。

それに、「産業の中心が知識や情報にシフト」することが可能になったのは 現在のインフラあってのことだ。毎日ヨーロッパと米国東西海岸とハワイで テレカンファレンスをして仕事を進められるのも、ネット越しに分散開発できるのも、 インフラがリーズナブルなコストで機能しているからこそ。 そしてインフラ業界は逆に「規模の経済」が強く効く業界である。 (なお、ここでも映画とのアナロジーが成立する。映画製作が単発の「プロジェクト」 の形を取れるのは、完成した映画を供給して売って行くインフラがあるからだ。)

さらに言えば、一番金が回っているのはインフラなのである。 小型化してゴールに特化した会社が、 直接コンシューマ相手に収益を上げて行く方法で、 スモールビジネス以上に成長するのは難しい。 できない、と言うわけではないが、コンシューマだけを対象にして 収益を上げられるまで成長できるベンチャーの率は低いだろう。 ベンチャーの多くはむしろ、新しいチャレンジによるプロダクトを作って、 大きなプレイヤーに買収されるという結末を迎えるはずだ。

大所帯ながら技術を追う必要があるインフラ業界と、 身軽にチャレンジできる小さな会社とはここでメリットが一致する。 つまり、新しいアイディアを試したい人間は大会社を離れベンチャーでそれを実践し、 成功すれば大会社に買われる、という生態系だ。 実際、そういう循環はGoogleに買われたベンチャー等に既に見られる。

というわけで、今後は、

• 規模の経済で押すインフラ大企業
• 継続性を担保する中規模企業
• 個人プレーヤの一時的な集結によるプロジェクト

みたいな分化がよりはっきりしてくることになるんじゃないかなあ。 で、それぞれのカテゴリでずっと過ごす人もいれば、 間を行き来する人もいるだろうと。

で、私が属する最後のカテゴリだけど、 これについては確かに映像業界は参考になる。

映像業界でプロジェクト毎に個人が集まって仕事ができるのは、 ひとつには業種が細分化されて各々が専門職として確立してるから。 例えばキャスティングディレクターなんて個人かスタッフ2〜3人って所帯だけれど (LAとかだともっと大きなところがあるかもしれない)、 ディレクターが求める役に当たりそうな役者の候補を責任持って見つけてくるって 仕事に特化してて、欠かせない存在になっている。 役者のエージェントもまた、小所帯の専門職だ。 CMの仕事ではフリーのプロデューサというのにもよくお目にかかるが、 彼女らはネットワークを通して必要なスタッフを素早く集めてチームを作ることに長けている。

ソフトウェアの世界で、プロジェクト毎に効率良く個人プレーヤが集まって何かする、 という形態が今後伸びて行くなら、そういう専門職もまた必要とされ、 確立してゆくんではなかろうか。 今は、フリープログラマ業界のプロジェクトは口コミで人を集めることが 多いと思うけれど、それではスケールしないからね。

「ハッカー指向」のプログラマはついつい、 スタープログラマだけで世の中回して行きたい系の発言をしがちだけど (多分にポジショントーク要素が含まれてると思うが)、 看板役者と売れっ子監督だけでは映画で喰ってくことはできないのだ。

Tag: Career

2010/03/01

言語にこだわる場面

結局のところ、どこが (開発/検証/実行の) 律速になるかの違い、ってだけなのかもなあ。 ライブラリの少なさとか 実行環境のmaturityやavailabilityに縛られることもあれば、 言語が足を引っ張ることもある。どれが一番の障害かは応用次第、と。

Where programming language matters @ val it : α → α = fun

俺は「Lispの仕事をしたい」とか「Haskellの仕事をしたい」とかいったような、プログラミング言語で仕事をえらんだことはないですね。興味のあるところはプログラミングによって何をするかであり、それはたとえばIMEを作るにはどういう要素技術が必要でどういうことをする必要があるかとか、そういうことになるかと思ってる。結果的にLispが最善の環境になったらLispはやるだろうし、それだけのことでは、というのが正直なところ。つまりまとめてしまうと「first priorityの前提が違いますね」というだけの話なわけですが、みんなそこまでプログラミング言語が第一なのかなぁ。それは「機会を狭めている」し「もったいない」とやっぱり思ってしまうけど。

結局根底にあるのは好みなのかもしれないのだけれど、 なぜ私が「Lispの仕事をしたい」と思うかというと、 それが経験的に「言語に足を引っ張られることが一番少ない」からなんだな。

何が嫌かって、仕事を助けるべき道具が仕事の邪魔になるのが一番イラつく。 Lispに対しても不満はたくさんあるんだけど、 it sucks leastだから選んでるというだけ。 まあ、suckする箇所を自分で何とかできるから、という方が近いかもしれないが。

ただこれも、何が自分にとって邪魔かというところに主観が入ってきちゃうし、 この基準だけを考慮したらマイ言語を作るのが一番って結論になっちゃう。 現実的な選択に当たっては、マイ言語仕様、処理系実装、ライブラリ開発に 割けるリソースと、アプリそのものの開発に割けるリソースのバランスを 考えてどっかで妥協せざるを得ないわけで、そのバランスを算出する 重み付けは応用次第ってことになるんだろう。

Rich Hickeyは「GCだのOSインタフェースだのに自分のリソースを 割くよりは、言語機能とアプリケーションに割く方がいい」と重み付けして JVMを選んだんだろうし。

オブジェクトのメモリ上のレイアウトとか、メモリ管理のタイミングまで 制御する必要があるアプリ、って用途なら、重み付けも変わってくるわけだし。

その意味では、自分は「Lispが好き」っていうよりも、 そういういくつものレイヤにまたがる話が好きなんだろうな。 だからそれに合わせた言語を選んでると。

それはそれとして、これはすでにバズってたんだけど、JVMに対する感じ方にも違いがあるなと思いました。JVMはそれなりのプラットフォームとして確立した感じがある。ほかのVMと比べて普及もしているし、いろんなノウハウも蓄積しているしね。まー10年後とか20年後はしらんけど、しばらくこの情勢は続くんじゃないだろうか。

JVMに関しては、CPUのレイヤにおいて結局x86 ISAが生き残ったことに対するのと 同じようなことになるのかなあと思っている。CPUよりうんと上のレイヤに 関心がある人にとっては、CPUのISAなんて速くて安くてどこでも使えるなら 何だって良いってことになるのだろうと。

ただまあ、歴史を見てみると、レイヤの切り分けというのは一度分けちゃったら それまでよ、ということにはならなくて、かつて固定化して下層に埋め込んだ アイディアが、状況の変化によってアプリケーションに近い層で再び ソフト的に実現される、みたいに循環することが良くあるから、 ひとつの主流技術の影に埋もれて行った技術もそれなりに大事にしておくと 後でいいことがあるかもしれない。

Tags: Programming, Lisp