PL/I - 大きいことは良いことだなんてありえない
その昔、プログラミング言語といえば、理系はFORTRAN、文系!?はCOBOLという時代、複数のプログラミング言語があると、プログラムを書く人も大変だし、計算機メーカも複数のコンパイラを作るのも勘弁して欲しいと考えたのか、IBMが提案して大型機ではそれなりに使われたPL/Iという言語がありました。
PL/I
構造化されたコードを書くことが出来る手続き型の言語で、FORTRANにCOBOLのような入出力機構を付けた、イイトコどりを狙ったのですが、何せ言語仕様が肥大化し実装ごとに微妙な方言や制限があって、書いたコードを走らせるには、それなりに苦労があったようです。聞いた話なのですが、ある計算機で動いていたコードを他の計算機に移植すると、同じ言語なのにエラーが出るところがたくさんあって、処理系ごとの制限をうまく回避する修正ばかりしていたそうです。コードとしては、ちょっとFORTRANの匂いがするPASCALチックなもので、細かいところを忘れれば、言語を知らなくても読むことは出来るでしょう。
プログラム言語について -PL/I-
ちなみにPL/Iは、programming language one と読み、最後のIはローマ数字の１です。複雑と言っても最近の言語の仕様と比べれな、どうということも無さそうにも見えますが当時としては複雑で、大型機で動かすのがやっとでした。とはいえミニコンにも移植されUNIXを生み出すきっかけとなったMulticsは、この言語で書かれたのですが、これが複雑すぎて駄目だった故にC言語が作られ、UNIXが書かれたというのが皮肉です。一応、マイコン向けにもCP/Mで動く処理系も用意されたのですが、あまり効率の良いコードを吐かなかった記憶もあり、あまり使われませんでした。
Enterprise PL I for z OS
https://www.ibm.com/docs/ja/SSY2V3_5.1.0/com.ibm.ent.pl1.zos.doc/pg.pdf
とはいえ、この言語はまだ現役でCOBOLと同様に勘定系システムでは使われているとのこと。まあCOBOLに「比べれば」今流の言語に近いところもあるので、まだメンテは出来そうですけどね。
80年代の頃はアルゴリズムを記述するのに、ALGOLや、このPL/Iが良く使われていました。言語仕様が大きいということは、いろいろな機能が使えて便利そうにも見えるのですが、それだけ処理系が複雑になり、CPUにとって都合の良いコードを吐くのが難しくなります。まだバグが発生した場合の解釈も困難になりがちです。CPUがどんなに高性能になっても、ループの一番奥にあるような高頻度に実行される部分が非効率な処理になっていれば、全体のパフォーマンスを大きく劣化させます。やはり最終的に実行されるマシン語と大きく乖離するような文法は、コンパイラを書く人の苦労を増やすだけではなく、その言語を使うプログラマからも敬遠されるところがあるようです。
過度の複雑さがよろしく無いのは、ハードウェアとしてもiAPX432の失敗もありRISCプロセッサが登場しましたし、何でも出来るAdaが結局、何も出来なかったという反省も産んだように思います。最近は充分に高速なハードウェアが使えるからと、ソフトウェアが複雑になる傾向が顕著ですが、人間の脳みその方は相変わらずなので、あまり複雑な処理を書くとバグが取れません。プログラミング言語の歴史の中で、どうやら人間が得意なことと不得意なことが見えてきつつあるので、何でも言語に任せるのではなくて、上手に分担する方向に進むのではないでしょうか。アルゴリズムの選択や静的な処理は、どうやら人間のほうが上手なようですが、並列処理や競合の判定、オブジェクトの寿命管理などは人に任せて良いことはありません。
まあ、この言語でまともなコードを書いたことが無いので、詳しくはわからないのですが、そろそろお蔵入りにしていい言語だとは思います。現役で書ける人がいないのにコードだけが残っている言語なんて、恐ろしいことこの上ないです。
ヘッダ画像は、BingCretorに作って貰いました。
#プログラミング言語 #PL /I #IBM #コンパイラ #大型機