【第10回】RPG Ⅳの歴史(part.5) 言語の進化 | IBM i 総合情報サイト

【第10回】RPG Ⅳの歴史(part.5) 言語の進化



2015/9/16 ジョン・パリス、スーザン・ガントナー
これは元々IBM Systems Mediaで公刊されたiDevelopという(今は閉鎖されている)私たちのブログに投稿したものです。

前回の話の最後に、未解決で最も多くユーザーから要望されている機能(サブルーチン用パラメータ)が決して実装されない理由について、このブログで説明すると述べました。そのような訳で、私が記憶する限りでのお話をします。

この機能の実装に関する詳細設計を初めて受け取ったとき、開発者がオプションとして戻り値をもったサブプロシージャ(つまり、関数)を定義できる機能を含めたのを見て私は喜びました。というのも、そのような機能は、実際私を全くワクワクさせないサブルーチン用パラメータよりも遥かに理に適っていたからです。本格的な関数は、単なるパラメータでなく、それらを必要とする機会は稀ではありますが、再帰呼び出しは言うに及ばずローカル変数のサポートをも提供していました。もちろん、結果として作られるルーチンがサービスプログラムに含まれるという能力は大きな利点でした。それは、RPGを使用している非常に多くの職場で一般的に行われていたコードの複製というおぞましい慣習を防ぐのに役立つものでした。私は本当にあの慣習を憎悪していました。

サブルーチンにパラメータを提供することは、少なくとも標準ルーチンを含めるために/COPYが使えることを意味する反面、実際にはRPGを前進させないと私は考えていました。私からすると、完全なサブプロシージャをサポートする路線で行くのは極めて簡単なことでした。

ですから、ある日開発チームとの会議に呼ばれ、推奨される解決策としてサブルーチン・パラメータが指定されているのに気付いて驚きました。驚いたと言うのは穏やかな言い回しです。いくつかの賛否の議論を聞いた後、私は開発部門の管理者にもし彼がその決定を進めるなら私はその提案に同意しないと告げました。当時IBMの開発プロセスでは、すべての階層で私を含む一連の管理職の承認が必要でした。私の異議を却下すると彼の開発計画が遅れることを知っていたので、彼はシニア開発者達に頼って私が間違っている理由と、完全な解決策は実装にもっと費用が掛かる等々の説明をするよう頼みました。彼は明らかにシニア開発者達が彼に同意して私を味方に付けると期待していました。しかし、彼らはそうしませんでした。彼が行った議論の1つ1つに対して、開発者達は彼のアプローチには優位点がないことを指摘し、彼らは本当にサブプロシージャを実装したいのだと態度を明らかにしました。

私は知りませんでしたが、その管理職は開発の素人でプログラミングについてほとんど知らなかったということが後で分かりました。その結果、彼はサブルーチン・パラメータが欲しいというユーザーの要求を文字通りに受け取り、それを全うするという決意で開発者達の意見を完全に無視していました。彼らは新しい管理者と争いになることを望まず、次々にある程度折れました。しかし、ひとたびチーム外の誰かが彼らの考えを受け入れると、彼らは喜んで元々の立ち位置に戻りました。

サブプロシージャの実装は、回り回ってプロトタイプの開発に繋がりました。そして、それはRPGにおけるC関数の使用に扉を開きました。

あなたは、その「機能」が計画されていなかったと知って驚くかもしれません。誰もその可能性を考えたことがなかったとは言いませんが、私が読んだいかなる設計文書にもその機能の事は確かに述べられていませんでした。私の記憶の限りでは、初めてRPGでC関数が使用されたのは、新しい乱数発生器を必要としていたお客様のために、私がソリューションを見つけようとしていたときでした。彼は元々IBM版のQUSRTOOLに含まれていたコードをずっと使っていました。問題は彼の超高速システムが重複した「乱」数を生成し、彼のシステムを完全に混乱させていたことでした。私はCライブラリにrand関数があることを知っており、それをどうやって彼に(彼はCコンパイラーをもっていませんでした)使わせることができるだろうかと考える中で、プロトタイプとEXTPROCキーワードを介してRPGでそれを使用できないかと思いました。私はすぐにバーバラ・モリスのオフィスに行きました。1~2分間彼女はキーボードを叩き、そして実用的なプロトタイプが出来上がったのです!

その後、私たちはアプローチの限界について調査を行い、続いて私はCOMMONの立ち見限定の聴衆に対しRPGでのC関数の使用に関してセッションでの発表を行いました。私たちが発見した1つの制約、そして本当に唯一の重要な制約は、システムが浮動小数点値を渡す方法が、文字フィールドを置き換えることで「騙す」のは不可能であることを意味していたことでした。多くのCライブラリ関数が浮動小数点値を使っていたため、それは問題でした。ですから、V3R7でIBMがRPGに浮動小数点変数を追加した理由を訝しく思った人たちは、今その答えを知ったことになります。Cライブラリ関数のすべてを利用可能にするために、浮動小数点変数が必要だったのです。

C関数を統合する機能は大変うまく行ったので、その後RPGにはプロトタイプとJavaメソッドの呼び出し機能が追加されました。これら2つの単純な変更によってその後RPGコミュニティが利用できるようになった追加機能の範囲は膨大です。Webサービスの統合からExcelスプレッドシートの構築に至るまで、RPGは近年この旅が始まったときには誰も想像し得なかった用途に使われてきています。

次回の第6話では、不幸にも使われなさ過ぎだと私がいまだに考えているRPGの機能(Open Access)について、そして将来RPGが何処に行くのか(そして恐らく何処に行かないのか) について簡単に述べるつもりです。

Copyright © IGUAZU