かなり個人色の強い, 偏見チックな思想です.

1 マウスオペレーション

##岸田がマウスオペレーションを嫌うワケ

マウス操作のコストは、「マウスを狙いのポイントに持って行くためのコスト」に近似的に等しくなる。 マウスを狙いのポイントに持って行くには、収束のアルゴリズムと似たプロセスを経るが、この操作は以下のようになる。 0. 目的地に向かってマウスを動かす 0. その結果として得られるポインタ位置と目的地の間には大抵は幾許かの差が生じるので、その時の「現在のポインタ位置」から「目的地」を狙ってポインタを動かす 0. 1,2 の操作を目的地近傍に来るまで繰り返す

「1ステップのマウス操作で得られた現在値と目的地の間のズレの大きさ」は元のポインタ位置から目的地までの距離に概ね比例するので、マウス操作のコストは対数に比例することになる。

キーボード操作で1つの文字を入力するコストは 1 (M の0乗)のオーダーであり、そこに入力する文字数 N を乗じるので、すなわち O(N) のコストがかかる。 一方マウス操作は1回のマウスオペレーションに対して log M のオーダーのコストがかかるので、マウスオペレーションの回数 N を乗じて O(N log M) のコストになる。

1.1 じゃあ全てをキーボードで操作するのか？

先の議論では漠然とした「操作」というものを考えたが、より具体的に「ある点をポイントするという操作」の際にかかるコストを考える。

マウスオペレーションでは先に議論したように、log M のオーダーで到達できる。

ではキーボードオペレーションについてはどうか？ カーソルキーでは速度という因子を操作できないため、M の距離を動かすにはカーソルキーを M 回叩かねばならない。 すなわち、ある点に到達するには M のオーダーのコストがかかることになる。 (正確には2次元なので 2M のオーダー)。

ということで「ある点をポイントするという操作」では、マウスの方がかなり有利になる。 vim などではキー操作の回数を減らすための工夫が随所になされているが、それでも「ポイントする」という操作ではマウスには及ばないだろう。

1.2 マウスオペレーションのまとめ

つまるところ、どっちも不可欠なデバイスというつまらない結果なんですが。

アプリケーションの広告とかで「クリックするだけで簡単操作！」みたいな題字が踊っているのが不愉快だ、というだけですね、結局。 キーボードオペレーションは操作を覚えさえすればどんどん作業が早くなっていくのに対し、マウスオペレーションはそういうことが殆どない。 使うほどにかったるくなってくる。

勿論操作性というのは作り手次第で大きく異なるので、マウスオペレーションでもショートカットを組み合わせて快適に入力できるような設計はできますし、キーボードオペレーションでも使い勝手の悪いアプリケーションは幾らでも作れます。 ……「然るべきヘルプがないキーボードオペレーション」なんて目も当てられません (考えてみるとシェルはほとんど、「然るべきヘルプがないキーボードオペレーション」ですね)。

「OK」を押すのにマウスを使うことを強制するのではなくキーボードからもできるようにするとか、キーボードショートカットを用意しておいてそれをポップアップ表示するとか、色々やりようはあると思います。

私の場合、アプリケーションを嫌いになる理由は、「機能が足りない」ことよりも「対人インターフェイスが良くない」である場合が多いです。 だから、正確には「マウスオペレーションが嫌い」というよりは、「マウスオペレーションを強要するアプリは大抵対人インターフェイスの使い勝手が良くない物で、そういうアプリが嫌い」というべきなんでしょう。

2 オブジェクト指向

「オブジェクト指向というのは再利用性を高めるための技術」というのは間違っていない。 しかし、その本質は物事を見る視点だと思う。

解決すべき問題がある時に、「手続き型」では問題を解決するための処理の流れで考える。 例えば「10個の要素の平均値を求める」という問題を考えてみよう。 この時手続き型では以下の「手続き」を考える。 0. 全ての要素を加算して総和を求める 0. 総和を要素の数で割る

対して「オブジェクト指向」では、問題に関係する「物(オブジェクト)」同士の関連を洗い出し、物同士を作用させて問題を解決する。 例えば、先の「平均値を求める」という問題では、「要素」という10個のオブジェクトと「集合」という1個のオブジェクトが関係している。 これを使って問題を解決するには、以下のような手順(手続き？)用いれば良い。 0. 「要素」オブジェクトを10個、「集合」オブジェクト1個を用意する 0. 「要素」を順番に「集合」オブジェクトに作用させる 0. 「集合」オブジェクト内で加算する(「集合」オブジェクト内で総和と要素数という変数を保持する) 0. 「集合」オブジェクトから「総和/要素数」の値を取得する

この程度の問題ではオブジェクト指向の方が手順が増えてるが、問題が扱う領域がもうちょっと大きくなると、すぐにオブジェクト指向の方がラクになる。

(続く？)

3 シェルスクリプトは簡単か？

単純にコマンドを順次実行するだけならば確かにシェルスクリプトが一番ラクだろう。 しかしそれ以上のことをさせたい場合は、どんなに単純な事でもより高機能な言語を学習する方がラクだし汎用性も高い。

例えばテキストを操作したいとしても、シェルは自身でテキストを操作する手段を持ち合わせていない。 多くの場合、このような目的には grep や sed といった外部コマンドを使うことになる。 すなわち、外部コマンドの使用方法に精通しなければシェルからテキストを操作できないわけだ。 シェルスクリプトで自由自在に処理を行うためには、UNIX システム、特にコマンド群に関する幅広い知識が必要になる。

一方 perl や ruby といった高機能言語ならば、一定統一された方法でそれらに関する操作を行えるように設計されている。 記述のフォーマットも柔軟で、書き易く読み易いものが出来るだろう。