アウトローのアウトドア(579)：コンピュータの話#215：プログラミング「技術」の話(22)：猫も杓子も「構造化」（笑）その12

C言語は、汎用の高級（高水準）プログラミング言語なんだよね……。
一応ね（笑）
ところが結構多くの人が、Cのことを

なんて言うんだよ（笑）
俺もね……気持ちは分かる。
というか俺の場合は、

「高級アセンブリ言語」
みたいなものだと思ってる (^o^)
ナンジャそりゃ？
……と素直に反応するのは、今どきの若い人たちだろうなぁ。
俺と同世代なら、割と納得してくれるかもしれん（笑）

まず、今どきの若い人はアセンブリ言語なんて使わんだろ。
というか、見たこともない人が多いんじゃないかな（笑）
「それ何？」
だよね。
俺の周囲では、たいていそうだよ。
下手すると、「コンパイルする」ということ自体をあまり意識していなかったりする（苦笑）
だって、最初に覚えたプログラミング言語が Python とか JavaScript だったりするでしょ。
Javaをやればコンパイルするけれど、IDE（統合開発環境）の中で「ビルド」ってやるから、
その裏側でコンパイルして、必要なものをまとめて……という作業をしていることを、あまり意識していない人もいるかもしれない。
俺はむしろ、そっちの経験が少ないんだけどね（笑）
俺らは、

だったからねぇ。
Makefileを作るのが「ビルド」だった、みたいな感覚なんだ（笑）

いずれにせよ、アセンブラを知らない今どきの世代にとっては、

というのが当たり前なんだろうね。
だから、
「変数というものがあります」
「定数というものがあります」
くらいから始まる。
これが当たり前だと思うわけだ。
俺らの頃みたいに、

から始めたりしない（笑）
メモリ上に領域を確保して、そこに名前を付ける。

DC    （Define Constant）
DS    （Define Storage）

なんてやって、
「ここが定数の領域」
「こっちが変数として使う領域」
なんてところから考えたりしないから（笑）

もっとも、今のアセンブリ言語には、それなりの守備範囲がある……と俺は思ってる。
大昔はいざ知らず、今どき一般的なアプリケーションを丸ごとアセンブリ言語で作ろうとは、普通は考えないでしょ。
OSなどの基本ソフトのごく低レベルな部分とか、
デバイスやハードウェアを直接扱う部分とか、
特殊な制御ルーチンとか、
性能を極限まで追い込むようなところとか……。
そういう、

がアセンブリ言語の得意分野になっている。
つまり、アセンブリ言語と高級（高水準）プログラミング言語には、それぞれ役割があるんだよ。
そして、高級言語の中にも役割分担があるんだ。

昔は、その辺がものすごく分かりやすかった。

• 数値計算プログラムなら FORTRAN

• 業務アプリケーションなら COBOL

• 大型計算機上で「どっちもできます」と豪語する PL/I（笑）

• システム寄りの低レベルなところはアセンブラ

大型計算機の世界は、割とそういう世界だった。
ところが、パソコンやワークステーションが現れ、構造化プログラミングが広がってくると、
BASIC
ALGOL
Pascal
C
……
なんやらかんやら、いろんな「汎用プログラミング言語」が出てくる。

さて、それでC言語だ。
Cも分類上は、

だから、何でも書けるんだよ。
普通のアプリケーションも書ける。
シェル上で動かす単体のプログラム――いわゆるコマンドも書ける。
ところが、それだけじゃない。
シェルもカーネルも書ける。
つまり、OSそのものまでCで書ける（笑）
コンパイラだって書ける。
リンカだって書ける。
デバイスドライバだって書ける。
（もちろん俺はOS書けんよ。一応言っとく。相棒が勘違いするからな（笑））

つまりCは、

ここが面白い。
他の高水準言語では扱いにくいような、ハードウェア寄りのプログラムまで書ける。
それって……
アセンブラみたいでしょ（笑）

でも、
if
for
while
関数……
ちゃんと構造化プログラミングの道具（制御構文）も持っている。
ほら。

低水準なのか高水準なのか、どっちを狙っているのかよく分からん（苦笑）
だから冗談めかして、

なんて言いたくなる気持ちも分かるんだ（笑）

俺の感覚では、この辺の立ち位置にいる言語として馴染み深いのはCとC++かな。
もちろん現在なら、システムプログラミングに使える言語は他にもある。
でも、少なくとも俺が現役でCを書いていた頃は、

という感覚だった。
俺自身もCを書くときは、

という感覚が結構強かった。

もちろんCで、もっと複雑な業務アプリケーションやシミュレーションプログラムを作ることもできる。
実際、昔はCでいろんなものを作った。
ただ、今なら、用途に応じてもっと抽象度の高い言語を選ぶことも多いだろう。
まだプログラミング言語の選択肢が今ほど多くなかった時代だから、

という面もあったんだと思う。

さて。
ここからが、今回の記事で言っておきたかったことなんだ。
俺の経験では、Cでプログラムを書いていた頃は、一人で作るか、せいぜい数人くらいで作ることが多かった。
大規模業務アプリケーションみたいなものを、Cで大人数で作った経験はない。
もしやったら……
結構大変だっただろうなぁ（苦笑）
そこをC++なんかが、いくらかカバーしていったのかもしれない。
……なんて話を始めるとオブジェクト指向の話になりそうだから、ここでは端折る（笑）

俺が言いたいのはね、

ってのがあるんだよ、ってことだ。

それはね、
Unix とか Linux とか。
MS-DOS でもいい。
つまり、

ような世界だ。
この世界をイメージすると、
「なぜCはこんな作りになっているのか」
「なぜポインタなんてものを使うのか」
「なぜ標準入出力がこうなっているのか」
「なぜファイルをこう扱うのか」
みたいな、

が、結構しっくり理解できるようになる。
『プログラミング言語C』に書かれている内容も、
「ああ、なるほど。こういう世界でプログラムを書くための言語なんだ」
と思って読むと、ずいぶん納得しやすい。
その辺を、これから記事にするかも・・・（笑）

そして、もう一つ。
Cで何かのプログラムを作ろうとするとね……
俺の経験では、

という感覚が強かった。
もちろん「設計」はするんだよ。
でも、
設計が全部終わって、
「はい、ここからプログラマさん、実装してください」
という感じじゃない。
つまり、

そんな感じなんだ。

大型計算機の世界では、
設計は設計、プログラミング（実装）はプログラミング（実装）
と、もう少しはっきり分けて考えていた。
ところがCで小さなシステムやプログラムを作っていると、その境界が少し曖昧になる。
というより、

と言った方がいいかもしれない。
気が付けば、

俺にとってのCの構造化プログラミングって、そういう感覚なんだよね。
ということで……
この感覚を前提にして、
次からCの構造化プログラミングについて、もう少し突っ込んだ話をしていくな (^o^)
（2026-08-27）

ps.
最近、マジメにプログラミングとか話してるからか・・・なんか一つの記事が長くなってる（苦笑）
どしたものかなぁ・・・（笑）