今日、5月1日はコンピュータ言語として有名な「BASIC言語」の誕生日だそうだ。
このBASICでコンピュータ初体験した人も多くいると思うが、小生の場合は学生時代にFORTRANから入ったので、BASICについては後から必要に応じて習得した。必要に応じてというのは、当時小生が在籍していた会社が、TK－80というNEC製マイコンボードにBASICを載せたTK-80BSというドーターボードの開発を請け負っていたからだった。
このBASICというのは「Beginner's All-purpose Symbolic Instruction Code」の略で、つまり初心者向けの高級言語の低級版という言語。コンパイラではないからオブジェクトコードを生成するわけではなく、いわゆるインタープリタである。
それまでマイコンを使うと言う場合には機械語やアセンブリ言語でプログラムを作ることを余儀なくされていたので、このBASICが簡単に使えるということは画期的なことだった。実際、マイコンの入門機であったTK-80についても、機械語でのプログラム入力を余儀なくされていた上に、直接接続できる周辺装置は全くない状態だったから、TK-80を買ったはいいが、「その後どうすればいいの？」状態だったので、そこへのソリューション提供としては極めてタイムリーだったわけだ。因みにこのTK-80BSには、モノクロモニターや外部記憶用としてのカセットレコーダ用インターフェースが装備されていた。TK-80BSを開発した当時の仲間達、その後は全く音信不通状態なのだが、今も元気でいてくれればと思う。
さて、このBASIC、実は様々なネガティブ意見も多い言語でもある。
その意見の最右翼者は、オランダのダイクストラだったと聞く。このダイクストラは構造化プログラミングの提唱者として有名で、小生もその著書を読んだことがあったが、その本が下の写真。因みにこの本、絶版となって久しく、ヤフオクあたりで高値がついているらしい。。。モチロン売らないけど。
サイエンス社発行 ダイクストラ他著「構造化プログラミング」
この構造化プログラミングと言う手法、とにかくプログラムというのは、大枠を定めてからその大枠に内包される核の部分のコーディングを行うべきだと主張するものであった。段階的詳細化法というやつである。つまり、絵を描く時の様に、キャンバスに向かっていきなり端の方から書くのではなく、まずは対象物を大まかに描き、数々の段階を経て細部を描いていくというやり方が段階的詳細化だ。特に「巨大」なプログラムを作成する際にはなおさらその手法が必要であると説く。
これは正しいと思う。
ともすればBASICやFORTRAN言語は、JUMPやGO TOが入り乱れることを許す構造となっているが故、出来上がったプログラムとしては分かり難い構造となってしまうことが多い。いきおい、バグも出やすいし、修正するにしても構造の定義がはっきりしていないからデバッグ作業が難儀することは確かだ。まして他人の書いたプログラムコードの解析など、至難の業。だから、
そういう構造を許さないというのが構造化プログラミングの原点なのだ。
つまりBASICやFORTRANは人海戦術を許す言語と云えるかもしれない。しかしながら、そもそもプログラム全体の構造があやふやになりがちである上、例外処理O.K.の構造となっているから、パッチを当てるには便利ではあるもののパッチだらけの目も当てられないプログラムとなってしまう危険性は大きい。
言い換えれば、プログラムというプロジェクトの定義や構造が、後から幾らでも変更することが可能ということであり、見かけ上は柔軟性があるように見えるものの、メインテナンス性は甚だ低いものになりがちだ。あれこれ例外が発生し、そのつどパッチのようなサブルーチンへと、ドロナワ的に分岐させることが多く発生することになる。ただし、臭いものにフタをするようなものだから、指し当たってと言う意味での問題解決は早い。
一方、構造化プログラミングというのは、「プログラムを作成するに当たっては、まず机の上を片付けましょう」という提案でもある。その上できっちりと構造を定義していくプログラミング方法だから、プログラムコードが出来上がった暁には一発で通るということになる（現実はそうは行かないが）。
BASICが生まれて、今年、この5月1日でちょうど50年だそうだ。この50年間に、プログラムは子供でも出来るようになってきた。今後、更に「初心者がとっつきやすく、バグが出難く、メインテナンスし易い言語」が開発されていくのだろう。
確かに構造化プログラミング手法は堅実性が高いと思う。しかし、初心者にとっての壁が高い。
小生、近年はプログラミングとは疎遠なので最近の傾向は理解していないが、今でもこういう議論は続いていることと思う。