第1回
なんでいまさら「C言語」なのか?――C言語よもやま話

もう少し昔話を

昔話をもう少し続けます。昔はよかった、あの時代に戻ろう……なんて言うつもりはありません。ただ、何でもあっさり流してしまうような今のやり方をちょっと横に置いておき、少しこだわった『モノ造り』を試すのも悪くないと思うのです。

手間暇かけたDOSの時代

昔……今から15年ほど前のお話です。Windows 3.1が登場する以前のパソコンは、MS-DOS(以下「DOS」) ※2 というコンソールモードのシングルタスクOSで動いていました。その頃、既にApple社のMacintosh(Mac)ではグラフィカルなOSが動いていましたが、実務系ではAT互換機や懐かしのPC-9800シリーズが中心でした ※3

Macはデザイン分野など、ビジュアルでクリエイティブな作業で使うもの……といった捉え方をされていた時代です ※4

さて、そんな時代のDOS環境では、プログラミングもコンソールモードでエディタを起動してソースコードを入力し、コマンドラインでコンパイラやリンカといったプログラムを起動していました。コンパイラ(compiler)はソースコードを中間言語に変換するプログラム、リンカ(linker)はコンパイルされた複数の中間言語ファイルを結合し、1つの実行ファイル(プログラム)にするプログラムです。

この辺の手順について、詳しくは回を追って紹介します。まぁ、とにかくそんな具合にかなり面倒だったわけです。

DOSはDisk Operating Systemの略で、元々はIBM社のパソコン用に開発されたPC-DOSを汎用OS化したものです
当時の米映画を観ると、Macで事務処理をしている場面も結構出てきます。サイコサスペンスの「ルームメイト」(1992年、米、バーベット・シュローダー監督)では、ブリジット・フォンダ演じる主人公がMacで経理のプログラムを作っていたりします
今でもMacはそういった用途のパソコンだと思われていますが、Intel製CPUを搭載してWindows XPやLinuxまで動くようになった現在のMacを見ると、そういったイメージも変わってくるような気がします。米国では、Windows XPを使うデザイナーやフォトグラファーも結構います

人に近付けば機械は複雑に

Windows 95が登場した1990年代の半ばあたりから、一般には「パソコンが使いやすくなった」 ※5 と受け止められています。折からのインターネット・ブームにも煽られてパソコンユーザーが増え、「パソコンという機械は、マウスでアイコンをカチカチすれば何でもできる」といったイメージで受け止められるようになってきました ※6

かつては「コンピュータとは専門の知識を持つ一部の人(専門家やマニア)が使うものだから、操作が面倒でも仕方がない」と受け止められていたのですが、一般ユーザーが増えてくると、そんなことは言っていられません。

速度とエンジンの回転数とギアの関係を知り、クラッチをうまく合わせなければ運転できなかった自動車(MT車)が、アクセルを踏むだけで走る(AT車)ようになったのと似ています。

何でもそうですが、外(ユーザー)から見て便利な機械の中身は複雑です。昔は素人でも少し勉強すれば触ることのできた自動車のキャブレター(燃料気化器)やポイント(点火進角装置)も、今ではコンピュータ制御のため中身がさっぱり分かりません ※7

同じようにプログラム(OSやアプリケーション)も昔はシンプルでしたが、現在では非常に複雑で、多少勉強した程度ではその中身を理解することが難しくなっています。

正確には、パソコンではなくOSが使いやすくなったのですが……。「Windows 95を買えばインターネットができる!」というふれこみの影響で、パソコンショップの店頭で「インターネットください」というお客さんも結構いたそうです
1990年代半ば頃のパソコンとOSは、実際にはそれほど簡単ではありませんでした。ハードウェアの相性によるエラーも多く、異常終了することも結構ありました。それでも、過去のMS-DOSに比べればユーザーインターフェイスは格段に親切になったのです
コンピュータ制御(EFI)のトヨタ ソアラが登場したとき「ハンドルを左一杯に切ってから1/3回転戻してサイドブレーキを引き、エンジンを3200回転に保ってワイパーを3回作動させたときにブレーキを素早く5回踏むとコンピュータが暴走し、その場で車体が360度回転する……」とかいったジョークが囁かれました(一部マニアの間ですが)。任天堂のファミコンでバグ技・裏技が話題になった時代です

道具を作るための道具を知る

プログラムは「道具」です。あなたの作ったプログラムを使って、誰かが仕事や趣味をこなしています。そしてプログラマーも道具を使ってプログラムを作っています。

「籠に乗る人担ぐ人、そのまた草鞋を作る人」という言葉がありますが、まさにその通り。絵を描く人は筆や絵の具を作った人のお世話になっているし、写真を撮る人はカメラやレンズやフィルムを作り、現像やデジタル処理の仕組みを作った人のお世話になっています。

プロの画家や写真家は、自分の使っている筆や絵の具、レンズやフィルムに対してシビアです。過去の技術の発展に関しても学んでいるでしょう。音楽でも文学でも、その他何でもかんでも、モノを作る人たちは道具や技術の発展史を理解し、その上で自分たちの仕事ができるということを知っています。

さてプログラミングです。果たして現在のプログラミング環境で、プログラマーは自分の作っている道具や使っている道具のことをどこまで理解できているでしょう? もちろん、道具とはプログラムのことです。

自分の書いたソースコードが、自分の貼り付けたアイコンやボタンが、どのような形で機械語となってハードウェアを制御しているのかを、一体どの程度理解できているでしょう?

知っていることが力になる

もちろん、必要以上につぶさに理解する必要はありません。やりすぎると作り手ではなく研究者やマニアの領域に入ってしまいます。

実際の開発作業で、機械語レベルの仕組みを使うことはないでしょう。また、そんなことで深みにはまっていたら納期に間に合わない、という現実もあるでしょう。しかし、根底のメカニズムを知っているのとそうでないのとでは、イザというときの対応に差が出ます。

Visual C++やVisual BasicでWindowsアプリケーションを作る技法は、書籍や雑誌で多数紹介されています。それをある程度マスターすれば、Windowsアプリケーションを作れるようにはなるでしょう。

しかしそれだけでは、C++やWindowsというOSを理解したことにはなりません。Windowsの統合開発環境の下には、Windows API(Application Programing Interface)やC言語、オブジェクト指向プログラミングなどたくさんのメカニズムが隠されています。

統合開発環境によるプログラミングだけを知っているというのは、自動露光・自動焦点のカメラで写真を撮っているようなものです。露出やレンズ効果など原点の仕組みを知った上で、自動機構を使いこなせることが大切です。

プログラミングでも同じこと。普段は一見必要ないと思えるような事柄を知っていることが、モノ造りの力になると思います。