杉山利幸のプログラミング言語史

このページは、プログラミングというものを1度は経験したことのある方を対象にしています。

目次
1.FORTRAN、COBOL の時代
2.C、Lisp の時代
3.Visual Basic の時代
4.C++ Builder の時代
5.Visual C++ の時代
6.おわりに


1.FORTRAN、COBOL の時代

私の最初のプログラミング言語は FORTRAN だった。大学時代に汎用コンピュータを使ってネタを探しては自由にプログラミングしていた。会社に入ってからも暫くは FORTRAN でプログラミングしていた。この FORTRAN により私のプログラミングの基礎ができたといっていいだろう。FORTRAN77 により ENDIF が使えるようになりプログラムの作りやすさと読みやすさが格段に増したことを覚えている。
それから異動により COBOL を覚えた。COBOL は FORTRAN に比べただ凄くめんどくさいだけの言語という感じだった。読みやすさも最悪である。この読みやすさを阻害している最も大きな原因はレベル番号の下位の変数に裸でアクセスできることにある。明示的に示すには "OF" "IN" を使えばいいが省略できてしまう。他の言語では".(period)"を使えばいいがそれを省略はできない。
そもそも COBOL はファイル処理用に設計された言語であり、その中で使っている分には悪いは悪いが我慢できない程ではなかった。IF 文のネストができない(今は END-IF で可能)という欠点も PROCEDURE DIVISION の部分は少ないということでよかった。ところが事務計算の中に手続き的に複雑でさらに画面を作成しなければならないオンライン処理が含まれるようになってしまった。更に当時の事務計算の技術者は COBOL しか知らなかった。そのためコンピュータメーカーは画面のための独自の拡張を COBOL に対してしてしまい、ただでさえ無い COBOL の移植性も更に全く無くしてしまった。PROCEDURE DIVISION の全体的割合も増加して読みにくくなってしまった。
結果 COBOL は世界中に広まった史上最悪の言語となってしまった。COBOL の悪口はそろそろ止めよう。横道に逸れ過ぎた。


2.C、Lisp の時代

C でバックトラックのアルゴリズムを使ったプログラムを作らなければならなくなった。数学の時間に樹形図というのをかいたことがある人もあるかと思うが、バックトラックというのはそれをプログラミングすると思えばいい。樹形図をたどっていってうまくいかないときは元に戻って他の場合でやりなおすというアルゴリズムである。場合分けがきれいに行く場合を除いては、このプログラミングは FORTRAN では作れない。というのはリカーシブコールというサブルーチンから自分自身を呼ぶというプログラミングが必要である。
かなり熟知してもらわないと実際に理解してもらうことは難しいが、実はこのリカーシブコールができるとできないとではプログラミングに雲泥の差ができる。
a! Reg Analyzerはリカーシブコールを多用しているし、またそうしないと作れない。このときリカーシブコール以外に C のポインタ(概念的には理解できるが慣れないとかなり難しい、ここでつまずく人が多い)と構造体について学ぶことができた。
私が C のポインタを使うときは ptr + n(ptr:ポインタ、n:整数)というコーディングは決してしない。必ず &prt[n] という書き方をする。その方が理解しやすいからだ。皆さんにもお勧めする。
Lisp も学ぶ機会を得た。Lisp はリカーシブコールのかたまりのような言語だ。Lisp はリスト構造という構造のみを使い、それは非常に多くの括弧対によって表現される。もうひとつの Lisp の特徴としてプログラムもリスト構造、データもリスト構造ということがある。このため「プログラムを作るプログラムを簡単に作れる」。どういうことかというと Visual Basic の Print 文で Visual Basic のソースを作るようなものである。この場合出来上がったソースをもう一度コピー&ペーストしてきて実行するとことになるが、Lisp はその必要は無い。データに対して Eval を行なうだけでそれがプログラムとして動く。これは他の言語に無い特徴である。
このときオブジェクト指向プログラミングの C++ も少し学んだが、実際にはテストプログラムを数行書いただけであった。オブジェクト指向の本も読んではみたが、眠くなるだけで全然わからなかった。本のタイトルは忘れたが、きっとこんな本を書くやつは実際はわかっていないのに知ったかぶりをして書いているだけなんだ。しかし C++ の仕様を勉強してなんとなくわかった。「要するにサブルーチンと変数を合体すればオブジェクトになるのだ。」


3.Visual Basic の時代

Excel で表の処理のプログラミングをする事になった。このマクロ言語を学んだときはプログラミングの革命かと思った。画面は対話的に作成できる。ビジュアルプログラミングという。またオブジェクト指向している。オブジェクトのサブルーチン(正式名称はメソッド)と変数(正式名称はプロパティ)には".(period)"でアクセスできる。もうひとつ新規の概念にイベントというのがあった。これは例えばボタンをクリックしたときとかチェックボックスをチェックしたときに発生するものらしい。そいつに対してどのような処理を行なうかを記述する。その結果以前のプログラミングでは考えられないプログラミングになった。通常のプログラミングはメインプログラムとサブルーチンがあり相互につながりツリー構造になるのだが Visual Basic の場合はメインプログラムがあったりなかったりする。更にサブルーチン(正確に言うとイベント処理ルーチン)がメインプログラムと全然つながっていない。つなげる何かがあると感じてはいたが、それを本当に理解するのは Visual C++ の時代まで待たなければならなかった。
Visual Basic に関してはある程度達人になった。C++ は知っていたので、この頃 Visual C++ を1週間ほどかけて勉強したことがあった。全くわからなかった。チュートリアルの Scribble の例題をその通りにやることはできるが中身を全然理解できない。暫く経ってもう一度1週間かけて挑戦してみた。ダメだった。よってあきらめることにした。「私の会社はソフトを専門につくる会社じゃない。こんな言語で開発しても、開発費を回収できる訳が無い。」
Visual Basic でどうしてもできないことがあったら Declare 文を使って Windows の API(Application Programming Interface)を呼ぶことを知った。API とはマイクロソフトが用意した Windows のサブルーチンライブラリのことである。自宅にパソコンを買い、最初はゲームでもやっていたのだがそれにも飽きてしまって、オンラインソフトを開発して公開することにした。初めて公開したのが
Screen Saver Stopperである。当然 Visual Basic で作った。
この頃「Inside Windows」という雑誌が出ていた(今は廃刊になってしまった。残念!)。中身はほとんどわからなかったが見栄で1996年9月号を買ってみた。その中に Windows Programming Tips というコーナーがあり、ほんの4頁だけれどもタスクトレイにアイコンを出す Visual C++ のプログラムが出ていた。Shell_NotifyIcon という API を使えばアイコンが出るのだなと考え Visual Basic から呼んでみると、なんと出た。しかし当然のことながらアイコンをクリックしても何の反応も無い。
他方 Visual Basic のマニュアルの中に「ウィンドウズのサブクラス化」というのが出ていた。この例題も打ち込んでやってみていた。メッセージフックみたいなことをするらしい。メッセージフックというキーワードはあちこちで聞いていたのだが、全然わからなかった。例題はその通りに打ったのでもちろん動いた。
ここでピンときてしまった。「2つの例題をくっつけてみよう。そうすればタスクトレイのアイコンのクリックを感知できるのではないか!」いとも簡単に成功してしまった。Windows というはメッセージがウインドウ間をいろいろ飛び回っているものらしい。マウスクリックも1つのメッセージでそれを感知するようにすればいいのだ。ここでメッセージという言葉とイベントという言葉が結びついた。「そうか!イベントとはメッセージと考えればいいのか」。この技術を用いて第2段のオンラインソフトMulti Function Alarmと第3段Deeper Folder Opener(今の名前は a! Menu Filer)ができた。


4.C++ Builder の時代

Deeper Folder Opener はその名の通り深いフォルダを開けるソフトだったが、作成してみると API の呼び出しのお化けのようになっていて Declare 文がソースの3分の1をしめるという異常な状態であった。このままでもよかったのだが将来的にもっとお化けになるのもいやなので、次のプログラミング言語を考えることにした。条件としては2つあった。(1)API が呼べること(これは当然)(2)ランタイムがいらないこと(Visual Basic のランタイムはどこにありますかというメールばかり来ていた。)このときボーランド(今はインプライズ)社からダイレクトメールが届いた。そもそもダイレクトメールは嫌いなのだが、このときだけは運命的なものを感じた。上記条件に当てはまるものとして C++ Builder と Delphi 2つがあったのだが C++ を少しかじっていたのと Delphi が1万円高かったという理由で C++ Builder Standard Edition を買うことにした。
私のオンラインソフトの全て(まだ3つ)を Visual Basic から C++ Builder に移行した。特に違和感は無かった。VCL(Visual Component Library)という優秀なクラスライブラリがあり、完全な機能の移行はできなかったが大きな問題はなかった。Visual Basic のコントロールにあたるコンポーネントは種類も豊富でプロパティもたくさんあった。しかも憎らしいほどよくできている。こういうことしたいなと思うプロパティがあったり、これは開発経験から作ったなと思える便利なメソッドがあったりした。
ボーランド社から次のダイレクトメールが届いた。世の常バージョンアップのお知らせである。いろいろ迷ったが締め切り間際になって C++ Builder 3.0 Professional Edition へバージョンアップすることにした。この頃
Before Power Offという新規ソフトも公開していた。Screen Saver Stopper Multi Function Alarm Before Power Off は問題無く移行できた。ところがである。Deeper Folder Opener を改名したDeeper File Opener のファイルをクリップボードへコピーする機能が働かない。いろいろ試してボーランドにサポートをお願いするFAXを送った。返ってきた返事は「ボーランド社の範囲外の仕様変更があるようです。」との事。その中身までは教えてくれなかった。というよりはサポート側が知らないんだと感じた。「ボーランドの馬鹿やろう。お金返せ!」と思った。実はかなり後になってそれは正しいことがわかった。CoInitialize 関数ではなく OleInitialize 関数を呼ばなければならない。当時はそれがわからず2つのバージョンの違うコンパイラを1つのパソコンに入れたくなかったので泣く泣くScreen Saver Stopper Multi Function Alarm Before Power Off を前の C++ Builder Standard Edition へと戻した。


5.Visual C++ の時代

私はDeeper File Opener をファイラにまで高めたかった。フォルダの中のファイルの操作を直接メニューから行ないたいとずっと思っていたが、その方法がようやくわかった。コンテキストメニューハンドラという DLL を作ればできるらしい。その例題は Visual C++ 2.0 で書かれてあった。ところが C++ Builder にどうしても移行できなかった(当時のバージョンではできなかったかもしれないが今の最新バージョンならできそうである)。結局そのとき持っていた Visual C++ 5.0 で DLL を作ることにした。この頃は C++ Builder のおかげで色々な知識も増え Visual C++ がなんとなくわかるようになってきていたのだ。
この際 MFC(Microsoft Foundation Class)を使わないことにした。MFC というのはマイクロソフトが提供しているクラスライブラリである。かつて API はサブルーチンライブラリであると述べた。イメージ的には C で作られているライブラリが API で C++ で作られているライブラリが MFC と思えばいい。しかし MFC を使うとなんとランタイムの配布が必要になるのだ。更にこのランタイムが Visual C++ のバージョンによって異なるなんてとんでもない話だ。DLL Hell の状況を自ら作っているのだから。Windows 2000 では「DLL Hell の終焉」といって欠点を宣伝文句にしてしまうのだからマイクロソフトの商魂はたくましい。私は既にそれを回避するために、ずっとランタイムが不要なソフトを作っているのだから。じゃあ API もランタイムがいるのではないかと思われた人もいるかもしれない。実は API は Kernel32.dll, User32.dll, Gdi32.dll 等の Windows で最も基本的な DLL を直接呼び出している。従って MFC を使わず API だけでプログラムを作ったとしてもこれら DLL だけは必要である。但しこれらの DLL がひとつでも欠ければ Windows 自体が動かない。ランタイムとはこれら DLL との仲立ちをして使いやすくするものである。これを一般にラッパー(包むもの)という。
MFC を試験的に使ってみたのだが C++ Builder の VCL と違って API 他ウインドウズプログラミングをかなり熟知していないと作れない。つまり MFC プログラミングでは MFC に加えて API、ウインドウズプログラミングをも覚えなければならない。これでは全然ラッパーになっていない。MFC のクラスを見るとその中をどう作ればいいのか私でもすぐにわかってしまう。他方 VCL はそれらが隠れていて Visual Basic 程度の知識があれば作れてしまう。また Visual C++ のコントロールのプロパティを見るといかに貧弱かわかる。「ラベルコントロールの色や大きさやフォントはどうやって指定するんじゃ!」これは Visual C++ のプロパティは CreateWindow(Ex) 関数の引数を生成しているだけで、色や大きさやフォントは別の処理が必要である。これがまためんどくさい。
C++ Builder には欠点もある。ランタイムが不要な代わりに exe ファイルが異常に大きくなってしまう。VCL の中身は私にはよくわかっていないが、いくつか余計な処理をしていて邪魔になることもある。本当に効率を追求するなら Visual C++(MFC なし)の方が早い。 よってDeeper File Opener は
a! Menu Filerに改名され Visual C++(MFC なし)に書き換えた。また C++ Builder も 3.0 に上げた。
他のソフトもいくつか作成したが、今は画面がいっぱいある場合は C++ Builder、効率を追求する場合は Visual C++(MFC なし)という使い分けを行なっている。


6.おわりに

昔とはプログラミングのイメージが全然変わった。システム設計とテストを除くと昔の作業は机に向かってのコーディング・デバッグがほとんどであったが、今はパソコンに向かってコーディング・デバッグにそれほど時間が取られているという気はしていない。調査の時間がほとんどである。ウインドウズプログラミングは深い。私なんぞはその10分の1も理解できているとは思っていない。こういうことをするためにはどうしたらいいのかを研究したり、プログラムがうまく動かない場合は(自分のコーディングミスの場合ももちろんあるが)ライブラリの使い方がまちがっているとか、ヘルプが間違っているとか、きちんと書いていないのでいろいろ試しているといったことで時間をくっている。このとき便利なのがインターネット上に載っているプログラミングノウハウ集やそれ関係の掲示板である。私も何度も助けられた。この場をかりて情報提供を行ってくれた方々にお礼を言いたい。「本当にありがとうございました」


なんとなく書きなぐってしまいました。時間があればソフト単位でこのような歴史をまとめるかもしれません。プログラミングの初心者は今後どの言語を勉強していくべきかの指標になるか、道を踏みはずすかのどちらかでしょう。プログラミングの達人は「うんうん」といってくれるか「いや違う」と思われるかどちらかでしょう。どちらにしても御意見・御感想等ございましたら、お気軽に私宛にメールをください。

E-mail:CZQ00116@nifty.com

戻る