壁についてつれづれ

(思いついたままメモ/まだ整理していない)

区画整理について、仕切られたことによる解りやすさだけでなく、しきい により守られることを期待する向きがあります。これをとりあえず「壁」と呼びます。

「壁」は安全を保証するか、(実際に保証しなくても)「壁」により安全を保証してほしいと願われます。隔てることによって安全を保証するため、カプセルは心理的(強制力のない壁/実質は高いハードル)、もしくは実際の障害物(強制力のある壁)とならねばなりません。

このような壁の例:

  • 一般ユーザはプログラミング出来ない(または「しないのが普通」という空気)
  • 一般開発者はクラスを作らない
  • 言語ライブラリを通常の開発者は書き換えられない
  • コードを開示しない
  • 手で操作するのとスクリプトで操作するので難易度がかなり違う(自動化のコスト自体がとても高いから自動化したがらない)

心理的な壁について

Smalltalk が目指したのは「壁のない世界」です。例えばSmalltalk ユーザは、リファレンスのノリでソースコードを閲覧し、自分のちょっとしたアプリの為に 標準ライブラリを書き換えてしまうのが「普通」の接し方ですが、これは残念ながら今のところ「普通」の感覚ではありません。

現在一般的な 環境では、システムと、システム上のプログラムの間には壁があります。Windows は置いといて、Linuxのような 自由なソフトウェアなOS であっても心理的な敷居の高さはあると思います(「壁の向こう側の特別な人達」という感覚)。この場合「壁」を挟んだ(コミュニケーションの)インターフェイスとしてリファレンスとかが在るような気がします。

同様に 「PC を使うこと = プログラミングすること」となっていない現状、プログラミングとは「開発者」という特別な役割の人間が行うもの・・という風になってしまっています(やっぱり「壁の向こう側の特別な人達」な空気)。この場合は手取足取りのマニュアルとか、「直感的なUI」とかが壁を挟んだコミュニケーションのインターフェイスになります*1

壁のメリット

壁を設けるメリットですが、第一に、他人が信用できない場合そのヘマの責任が自分に波及するのを食い止めます。また壁がハードルになることで、乗り越えたことが中に入るに足る人物かの「足切りテスト」として働くことも期待されるケースもあります。

わたしは壁のない世界が素晴らしいと思いますが、一方で、そんな世界は危なっかしくて不安で仕方が無いと思う人もいっぱいだと思います。

でも、例えば Python のメンバのアクセス制限のないクラスに対して、「みんな大人なんだから」というスタンスや、動的OOPL のダックタイピング、Subversion のロックを(デフォルトで)行わないこと。これらの不安は根強いですが、使ってみればたいてい払拭されます。

だから、次第に壁のない世界に成っていくのは「ありうる」と思うのですが、実際どうなるのでしょうか。

情報隠蔽と壁

「内側を隠す」に注目した場合の話。

encapsulate には「カプセルに封入する」の他に「要約」というニュアンスも含まれる..みたい。だから「カプセル化(encapsulation)」には抽象化のニュアンスも含んでいると思います・・というか思いたい*2。なので「カプセル化」は「壁」とは似て異なるものだと思います。

「壁」と「カプセル化」は、情報隠蔽(infomation-hidding) の別の側面(利用法)に思えます。抽象化の要件では「見えなくなれば」いいだけなのですが(「石ころ帽子」的)壁の要件では「触れられる」はNG。「壁」を求めると「アクセス制限」を付与したりします。勿論、アクセス制限はカプセル化がコンピュータによって保証される仕組みが欲しいだけ(つまり静的型付け)のケースもあるのだけれど、それ以上(=壁)を求められるケースもあるかも、みたいな。

以上、まったくまとまっていません。

*1:Smart UI 的なモノや、エンドユーザが妙にUIに固執した仕様を吐くか、あたりが絡められるかな?

*2:ホントの所はよくわかりませんが、とりあえず「ここではそうしたい」ということで / ホントの所→ カプセル化、情報隠蔽、データ隠蔽 - ぐるぐる~