ちょっと思ったことがあるのでメモ書きのみ。
ちなみに、思いつきのメモなので、内容の正しさなどを要求しないように。むしろ、誤っていると思って読むのが健全な態度でしょう。
今日、たまたま見た記事 §
この記事そのものは、いろいろと突っ込みどころが多くありますが、それは全て見なかったことにします。
ここで述べるのは、プログラムの複雑さという観点から見た「プログラムの簡潔さ」です。
プログラムの複雑さとは何かについては、前に書いたプログラムの複雑さとは何か?を参照。
小さいプログラムは複雑度を減らす §
一般論から言えば、小さいプログラムは大きなプログラムよりも複雑度が小さい可能性が高いといえます。なぜなら、プログラムを構成する構成要素の数が少なければ、構成要素間の関係の数も減ることになり、それは複雑さが小さいと見なしうるからです。
しかし、これは常に成り立つ真実ではありません。
短いソースがより大きな複雑さを持つ事例 §
たとえば、等価なプログラムをモジュール化プログラム言語と、今時の(多重継承をサポートしない)オブジェクト指向プログラム言語で作成したとします。(それ以外は全て等価な記述量でソースコードを記述できると仮定します)
このとき、オブジェクト指向プログラム言語には、モジュール化プログラム言語において使用されるimport宣言に相当する記述が存在しないため、ソースコードの量はモジュール化プログラム言語>オブジェクト指向プログラム言語という大小関係になります。
では、ソースコードが小さい方が複雑度が低いのかというと、そうではありません。import宣言は、あるモジュールから参照しているかもしれない対象を明示的に制限することによって、可能性として存在する関係性の数を減らし、複雑度を下げる効能を持ちます。
従って、このケースにおいては、短いソースがより大きな複雑さを持つといえます。
ソースコードの複雑さの明示的な制限を行う構文 §
これを一般論に拡大します。
プログラム言語の構文に含まれる多くの機能は、自らが関係性の主体になるという理由で、使用すると複雑さを大きくします。しかし、一部の機能は、関係性を制限するための用意されていて、使用することで複雑さを低減します。
たとえば、変数の型宣言とは、その変数によって発生しうる関係性を制限する効能を持ちます。従って、変数の型を宣言しているソースコードと、していないソースコードを比較すると、文字数では後者の方が少ないものの、複雑度は前者の方が低いと見ることができます。
このような特殊事例が存在するために、ソースコードが短いこと、プログラムが小さいこと、簡潔であることは常に複雑度を下げるとは言えない……と考えることができます。
冒頭の引用文は…… §
冒頭の引用文は、この特殊事例そのものに見えます。従って、好ましい事例として認識することが適切ではない可能性があり得ます。
宿題・Javaのthrowsは関係性を制限する構文であるか? §
以上のように考えたとき、1つ検討課題として浮上するのが、Javaにおいてメソッド宣言時に記述するthrowsです。これは、あるメソッドが発生させうる例外の種類を明示的に宣言します。
この宣言は、Javaが持つ構造的な欠陥の1つ(今ひとつ役に立たない割に手間が掛かる)として指摘されることが多い機能ですが、はたして関係性を制限する構文と言えるでしょうか?
もし、言える場合には、それがもたらす具体的な効能は何でしょうか?
もし、具体的かつ有益な効能があるとして、それにも関わらず「役に立たない機能」扱いされる理由は何でしょうか?
これを真面目に考えると、ソースコードの複雑さとは何か……ということについて、ちょっとだけ進歩があるような気もしますが、時間がないのでここまで。
