生ける伝説Smalltalk

有名な割に使われてないってのは、まぁ、あるとしても、そんな、誰も使ってないってほどでは……。
自分の身の回りだと、

ほら、こんなに影響が！
……影響？　結局当のSmalltalk使ってないじゃん(^^;)。


えーと、なんだ。
私がSmalltalkをきちんと使い出したのは、実は結構最近で、umejavaさんのSqueak自由自在が一番の教科書だったりします。Squeak自体はちょっと方言の強めなSmalltalk環境みたいですが（他のをほとんど使ってないので何とも……）、その独特のプログラミングスタイルにかなり影響を受けました。
特に、ブロックとコレクションはかなり衝撃的でした。foreachなんか使い道がないと昔cshを使っていたときには思いましたが、いやいやとんでもない。ほとんどのループがコレクションの列挙だけで収まるということに気づいたときには（というか、そのときまで、コレクションの列挙ぐらいにしかループを使っていないことに気づかなかった）、今まで使ってきた環境がすべて貧弱に思えてきましたっけ。今はJavaでもC#でもforeach使いまくりです。
きっと、次期Javaでクロージャがサポートされると、これまた使いまくるんでしょうね。
クラスの設計も、Smalltalkerの人たちが結構いやがるbecomeにしても、デザインパターンにしても、Smalltalkの持っていたいろんなイディオムがそのままあちこちに当てはまり、どう考えてもそっちの方が効率的という不思議な感触があります。だったら直接Smalltalkでプログラムを起こせばいいのでしょうけど、そうも言ってられない渡世の仁義が(^^;)。
特にGoF本とか見ていると、デザインパターンとしてかかれているものの中で、そもそもSmalltalkでは言語自体がサポートしているか意味がないのでサンプルすらも載らないものがちらほらと。Smalltalkだけで過ごせるのならさぞかし生産性が上がるんだろうな、という感触は、確かに使っているとすごく感じられます。
なので最近は、Smalltalkならこう書けば一瞬でできるのに、とか、実際に組み込む前に検証だけやりたい、とか考えながらコーディングすることが増えました。


で、この間あった初心者向け言語を笠に着た宗教戦争ですが(^^;)、ものすごーく狭いドメインでならばSmalltalk最強と言い切る自信があります。
どんなドメインかというと以下みたいな感じ。

  • 習得者は、お金を稼ぐためではなく、自らの問題を解決するための手段としてプログラムを作成する
    • 納品という考え方はなく、逆に要件定義も外部からは来ない
  • 詳しい人に聞くためのコミュニティを当てにしない
    • 何らかの形で文書化されている。もしくは直接調べる方法があることを期待。
    • サンプルそのまま流用という思考停止は、問題が全く同じ時以外は行えないものとして（全く同じ時には平気で流用）
  • 可能な限り、問題解決のためのスキルは低く押さえたい
    • 問題解決のために苦労するのは本末転倒。
    • できることなら、解決のために必要な記述や約束事は最低限に押さえたい

このドメインにおいては、プログラムを組むこと自体を楽しみたいのでは決してなく、読み、書き、そろばんの延長線上としての実用行為としてコンピュータと、そのプログラムがあるという前提です。
Smalltalkは習得がかなりたやすい環境です。これは、約束事が少なく、少ない割に人間の直感に即した抽象化がなされている為です。オブジェクト指向という今となっては珍しくもない設計手法を使っているのも、この直感的な抽象化のためといっていいでしょう。直感的な抽象化のために、様々なところで似たようなメタファが使い回されますが、この使い回され方も、約束事を少なくする方向で使われています。
また、Smalltalkはちょっとした作業をする際にも、問題の本質に近づける方向で抽象化がなされます。あ、いや、これはSmalltalkの手柄じゃないな。人がSmalltalkでさわれる形に問題を分析しようとすると、結果として問題が人から見たときにどう見えるのかがコードの形になります。それも、かならずあちこちで使い回されるメタファがからんで。
その上で、Smalltalkでコードを書く際に、試しにちょっとだけ動かしてはその結果が想定していたものかどうかをその場で調べられます。間違っていれば何度でもやり直せます。問題解決のために、一気に最後まで見通しを立てられなくてもあまり困りません。
このとき、環境の持つ強力なコーディング補佐機能や、デバッグ補佐機能を、きちんと筋道立てた設計やコーディング以外の所でも大体使い倒せます。オブジェクトインスペクタや、メソッドの補完などは、特定のモードではなく、いつでもすぐにさわれます。なので、絡まった、うろ覚えなプログラムも割合見通しよく進めます。
そして、何よりも重要なこととして、こうしていろいろと細工を駆使すると、問題を解決する際にかかる総手順や手戻りの量、人間側の一時記憶の消費量が非常に少なく済みます。
つまり、どちらかというとプログラム専門職の人が啓示や発想に依存してエレガントに問題を解決するよりも、専門職じゃない人が自らの手作りで必要なところだけを解決するのに適した環境として設計されているのが露骨に見えるのが、Smalltalkの最大の利点だと思います。
そして、重要な点として、Smalltalkでこうして問題解決をした経験や、そのときに得られた知識は、かなり劣化させながらでも他の環境で割合応用が効くのです。
Smalltalk以外の環境は、Smalltalkに比べてユーザーにすり寄った部分は多くないです。それは、実行環境の効率であったり、言語としての足かせだったり、自由にさせないことで特定の状況下での安全性や開発効率を上げるためだったり、まぁ、理由はいろいろです。
ただ、Smalltalkを前提として問題解決を習得しちゃった人は、Smalltalkを懐かしみながらもその環境でそこそこ問題解決できてしまうような下地を結果として得られるだろうと思えるのです。


ちなみに、Smalltalkだけではなく、先の限定的なドメインであれば、いろんな言語が役に立ちます。同じような意味合いでは（開発効率はちょっと落ちますが）、

何てのもいい感じです。
ただ、Smalltalk以外のこの辺のお手軽に問題解決できる環境は、その後に別の環境に行ったときにSmalltalkほど応用が利かないと思います。
これは、たまたまSmalltalkがメタファ（オブジェクト指向、と言った方がいいでしょうか）を問題を解きほぐすための手段として使い、先に挙げた３環境は具象を直接よしなに扱うような方針をとったという違いだと思います。


オブジェクト指向そのものは設計のための銀の弾丸では決してありません。銀の弾丸だと思う人からすると、オブジェクト指向という手段をなりふり構わず手に入れようと努力したり、逆にオブジェクト指向なんてストレスを排除しようとしたりします。
あくまで、Smalltalkにおけるオブジェクト指向は人間側の認識を楽にする手段でしかなく、楽な認識だけで世界がほどけるのなら、それに越したことはないだろうという雰囲気に、環境自体が満ちあふれています。
問題解決のための、思考の記号化自体が人の頭脳にとってストレスであるのはこの際どうにもならないものとして、可能な限り楽に記号化するためにはどうすればいいのかという答えのうち、かなり最良に近いなにかがSmalltalkにはあると思います。
そしてなにより、Smalltalkは結果的にそうなったのではなく、わざわざそこを指向して作られていたという歴史的事実が非常に重いと思います。


Smalltalk でこんなすごいことができるっていう話もあんまり聞いたことがないしね。

ハッカー的には何もすごくないです（念のため、 Florian もハッカーですので、ハッカーの視野の狭さを責めるつもりはないです。偏見上等！）。
今から勉強する価値も、実用性という一点においてみれば、ハッカーには全くありません。だって、ハッカーは自分のホームグラウンドで生き生きとハックする方法論をすでに持ってるので。現代のSmalltalk自身の実用性はさておき。
ただ、自分自身に対する実用ではなく、未来に対する思索をする分には、Smalltalkはまだまだ現代より先の何かを提示し続けていると思えるのです。一般的な世界はまだ、結局Smalltalkに追いつけてないというか。


生ける伝説としてのSmalltalkを理解するためには、言語とか、ハックとかいうレイヤーではなく、その出自から来る未来像の想像が必須なのではないかと思う今日この頃です。