I Language Homepage/history

｛｝ I言語が出来るまでの経緯

◎私はコンピューターで生産管理システムをCOBOLと呼ぶ言語を使って、開発と維持を行っていました。
◎情報処理システム開発、特にプログラミングは非常に面倒であると感じていました。
◎面倒な事は目の前にあるコンピューターにやらせれば良いと考え、何とかしたいと考えていました。
◎どうすれば何とかなるのか分からないので、取り合えず現物のプログラムを眺めていました。
◎まず最初に思いついた事は、２個の少し仕様の異なるプログラムではプログラムはほとんど同じである事でした。
◎そこで、この同じ箇所はプログラムしないでコンピューターに作らせる事を考えました。
◎そうするためには、新たな言語を作る必要が出てきたので、COBOLの先頭にINSTANTのIを付けてICOBOLと命名し、COBOLを開発言語として開発を開始しました。
◎まずは、規約を作り、極力自動でプログラムが出来るように考えました。
◎IDENTIFICATION　DIVISONはプログラム名が異なりましたが、記憶するモジュール名（メンバー名）と同じとする事でコーディング無しとしました。
◎ENVIRONMENT　DIVISONは同じマシンのためINPUT-OUTPUT　SECTION以外は同じでコーディング不要としました。
◎INPUT-OUTPUT　SECTIONはデバイス名は入力（２個までトランザクション用とマスター用）、出力、入出力、印刷、の区別が出来る命名規約を作り、ファイル名はデバイス名からの自動設定で、プログラム上はどのデバイス名を使用するかを指定する仕様としました。
◎DATA　DIVISIONはレコード名はファイル名から決定、ブロックサイズもレコード長からの自動計算としました。
◎PROCEDURE　DIVISIONはファイルのOPEN、CLOSE、READ　WRITE,繰り返し処理の基本フローは全て自動で作る事としました。
◎ただし、その時点では、どのような文法で実現すれば良いのか全く見当もつきませんでした。
◎初心に帰って、なぜ、面倒なのか再度自問自答していました。
◎COBOLではDATA　DIVISINでデータ名を定義し、PROCEDURE　DIVISIONでデータ名を使用します。データ部と手続き部が分かれている事がCOBOLの利点と言われていましたが、面倒と言う意味では最低でも２箇所にデータ名が登場する事は、面倒であると感じました。
◎そこで考えた事は、手続き部でデータ定義を含めたコーディングが出来るようにする事でした。
◎考えた結果は、データ名の前に定義情報を付加する仕様とする事でした。
◎定義は英字１文字で入力データの種類、次は数字でデータの先頭バイト位置、次は英字１文字でデータの型、最後が数値でデータのバイト長にデータ名を括弧で囲む、たとえば,W5X11(NAMAE)と書くことで作業領域（W)の５バイト目(5)から文字(X、P=PACK,U=UNPACK,N=符号無しU等、U,P,Nの場合更にV＋小数点以下の桁数が付加できる)で11バイト(11)と表現する方法でした。
◎一方、出力ファイルも同じ仕様でデータ部に書く事で、逆に手続き部での転送処理が不要となり、この仕様の採用だけで面倒さがかなり解消されました。
◎更に印刷する場合も、同じ仕様で書く事で、数値の編集、項目間の空白の追加、改ページ、グループトータル（集計キーにはデータ定義の最後にK（KEY)を付加、集計値にはデータ定義の最後にS(SUM)を付加）等が出来るように改善しました。尚、見出し行はJCL(ジョブ制御文内)で外部から与えるようにしました。
◎バッチ処理系では更にマッチング処理が結構面倒ですが、２個の物理ファイルをマッチングする概念ではなく、２個の物理ファイルのマッチング方法を定義部で指定し（キーの位置と長さ、対象範囲、重複キーの有り無しの指定）、1個の論理ファイルと見なして扱う方法で（ただし、物理ファイルの有る無しをスイッチで判定、複雑なマッチングも想定しスイッチで次の物理ファイルの読み込みも制御）、面倒な部分を解消しました。
◎時代が変わり、オンラインリアルタイム処理が主流になったため、今までの仕様では全く効果が出せなくなってしまいました。
◎オンラインリアルタイム処理の場合は、画面を設計し、そこから、COBOLで使うデータ定義情報を使ってプログラムを作ります。そこで、この画面の設計に対し規約を作って、作られた画面定義情報からCOBOLのソースプログラムを自動で作る方法としました。
◎このプログラムの仕様が現在のI言語の始まりです。プログラムは更新か検索か、どのVSAM（インデックス付の特別なファイル、I言語ではこれをテーブルに変更）を使うかだけ指定しただけでも動きます。
◎このプログラムが完成するまでにフローチャートを１００回以上書き換え、使いやすさと品質の向上を確立しました。このフローチャートが現I言語の基本ロジックの原型です。
◎汎用機のオンラインリアルタイム処理はプログラムだけではなく、画面もそうですが、それ以外にも、たとえば富士通の場合、JCL、MED、PED、PPROCEDURE等々プログラムが簡単でも実際には面倒な作業が沢山あり、ICOBOLが有っても面倒な日々が続いていました。
◎今までの方法ではもう無理と感じていた時、出合った言語が実はSQLでした。
◎SQLは非常に簡単な仕様であり、面倒さを打開してくれる救世主であると直感しました。
◎そこでSQLでシステムを作る事をしてみましたが、SQLにはデータベースを扱う機能しかなく、実際のプログラムを作る場合、やはり面倒な事が多く存在していました。
◎SQLでシステムを簡単に作れる言語を新たに開発する必要があると考え、今度はIPROGRAMと命名してUNIXサーバー、DOSおよびUNIXクライアント（DOSはエスケープシーケンス、UNIXはカーシスライブラリを使ってCUI上に文字を位置決めし表示し入力位置も移動させる）にカナダのEMPRESSと呼ぶデータベースを載せてC言語（最終的にはC++も部分使用）で開発を開始しました。
◎最初はGUIは無くCUIでしたが、実用には十分耐えました。これがI言語の原型ですのでI言語もGUIは殆ど使用しない、非常にシンプルな構造になっています。
◎開発開始時UNIXサーバーが約１千万円、EMPRESSが約500万円で企業にとっては安いですが、結構導入費用が高いと感じていました。
◎高いと感じている時に安いものが登場しました、WindowsNTサーバー約200万円、SQL　Server約20万円（金額はうる覚えです）です。
◎問題は、価格ばかりではなく、DOSクライアントのLAN環境にもありました。DOSの場合LANのソフトはOSが持っていないため、メーカ毎に別のプログラムが必要でした、更にLAN環境が頻繁にバージョンアップし、その都度ソフトが動かなくなる問題が頻発しました。これに対しNTはOSにLAN環境を持っており、この問題が起きない環境になっていました。
◎そこで、早速NT（サーバー、クライアント共）に移植しました、安い分遅い事は覚悟していましたが、結果は10倍も早く、思わぬ誤算でした。
◎私の定年退職が近づき、IPROGRAMのツール開発を凍結し,IPROGRAMで作られたシステムも廃止する方針が出たので、会社でのIPROGRAMツール開発を凍結しました。
◎IPROGRAMはそれなりに良いものが出来ましたが、時代は進んでおり、その意味ではまだ改善の必要がありました。
◎最大の改善が必要な点はコード体系の変更です、IPROGRAMはシフトJISで動いています、一方インターネットはUNICODEを基本としたUTF-8が主流となりつつあります、そこで、UNICODE化が避けて通れないと考えました。
◎UNICODE化を目指し、会社では作れないので、自宅でI言語として２００２年から開発し始め現在に至ります。
◎IPROGRAMは初期のプログラムも動いていたので、互換を重視しながら新規機能を追加したため文法に統一性が有りませんでした、そこで、I言語は文法を全て０から再設計して、分かりやすくし「誰でも」「早く」出来る事を目指しました。
◎互換の問題ではSQL　Server6.5が7.0にバージョンアップした時、SQL自体に大きな非互換が発生しました。
◎幸いにもSQLの非互換をIPPOGRAM側で殆ど吸収出来ていたので、解決できなかった部分のみソースプログラムを簡単な変換プログラムを作って変換する事で、SQL Serverのバージョンアップも短期間で問題なく行う事が出来ました。I言語はバージョンアップにも効果がある事が分かりました。
◎定年退職の日が近づいたので、IPROGRAMで作られたシステムはほぼ無くなっていると考え調査した結果、なんと１万本以上のプログラムが有り、止めるどころか、どんどん増えている状況でした。
◎そこで、IPROGRAMのツールサポート要員を教育しました。C言語を既に習得していた人でしたが、教育は１週間で終える事が出来ました。ツール自体も何度も作り変えて改善していたので、教育を受けた本人の努力も認めますが、短期間で教育が出来た事は非常な驚きでした。ツール自体がシンプルである事が証明された結果となりました。
◎I言語の開発言語はCではなくC#としました、理由はJIS規格になった事と、Linuxでも動く.NET Framewok互換ツールのMONOが開発されており、将来WINDOWS以外でもI言語が動かせるようになる可能性が有るからです。(IPROGRAMはWIN32APIで動いており、これをUNIXのX-WINDOWS上で動かすソフト開発を試みましたが、完成までに至りませんでした）
◎現時点でI言語はほぼ当初の目的を達成した完成品となりましたが、まだまだ、コンピュータの世界は進歩が止まったわけではないので、今後も、改善の必要はあると考えています。
◎I言語はパソコンさえあれば、SQL Server2012 Express EditonもI言語も条件付ですが無償ですので、導入の敷居がかなり低くなりました。I言語をみんなに使ってもらう事が私の夢ですので、開発は死ぬまで止めません、是非使って下さい。