COBOL言語である ２

COBOL言語でない

コボラーにとっての黒船はまさにオブジェクト指向言語で、完全に飲み込まれた形となりました。適応しないと仕事が無くなりました。

私がCOBOL言語でない言語に初めてぶち当たったのが、オブジェクト指向言語としては中途半端な（クラスが作れない、後に作れる様になったが、その頃には作らない作法で固まってしまっていた）MS AccessのVBAだったので、余計感じ方が変な風に決定づけられたのかもしれませんが、

私がオブジェクト指向言語に対して、心の底から最高だと思った点は、

• インターフェースに内部のメソッドがある
• インターフェースにメソッドを複数持てる

点でした。モデルだとか設計だとか、インターフェース分離だとか依存性だとか、その様な事は私にとって瑣末でした。（個人の感想に過ぎません。）

COBOL言語では

少なくとも私が使っていたCOBOL言語では、インターフェース（LINKAGE SECTIONの事。プログラム毎に1つ。ENTRY（呼ぶ箇所を増やす）は規約で禁止。）は全て「公開」でした。

そして「公開」した以上、それらインターフェースは「不変」でした。

「不変」が絶対条件である為に、よっぽどの必要が無い限り、分割出来ませんでした。
内部的にまとまりが良いロジックでも、別のインターフェースから呼び出すなんて贅沢は出来ませんでした。
内部的なまとまりが良いロジックは、内部的であるが故に頻繁な変更が必要ですが、「公開」したら「不変」になってしまいます。その枷はキツ過ぎました。

オブジェクト指向言語では

• 「不変としなくても良い」プライベートなメソッドが有ること

が、変革を余儀なくされていたコボラーたる私にとって、数少ない喜びでした。

さらに、

• パブリックなメソッドを複数作る事が出来ること

も喜びでした。COBOL言語ではインターフェースはプログラムに1つで「不変」でしたが、オブジェクト指向言語では少し似たインターフェースを複数個持てるのです。後から互換性を保ったまま追加も出来ます。

初めからオブジェクト指向言語から入った人には、この喜びは伝わらないと思います。

一つだけの「不変」のインターフェースで何とかするために、

• 半角1文字（1バイト）で数字1桁を表していたのを（ゾーン10進）、半角1文字（1バイト）で数字2桁を表す様に変えて（パック10進）、数字の桁数を増やす様に再定義（REDEFINES）するとか、
• 文字の先頭1ビットのみを別のフラグにし、読む時分離する（マスクをかます）とか、

涙ぐましい虚しい努力をしなくて良くなった訳です。

結論

何処をどう考えても、これからも「COBOL言語である」事でプログラミングが嫌いになる人は存在し続ける事でしょう。

COBOL言語である １

どの様な話？

COBOL言語が人から嫌われる直接の原因は、

• 柔軟性が無い

為だと思います。ちょっとの仕様変更もしてもらえないとなると、嫌われて当然です。じゃんじゃんモダナイズすべきだと思います。

何で柔軟性が無いのか

私が小学生だった1970年代でも、食べ物など、肉はほとんどなかったものの、それ以外はかなり有り、逆にほうれん草などは現在、高い通販でしか買えない路地ものが食べられたりもして居ましたが、
根本的な違いとして、

• 良い袋が無かった、木を薄く削ったものが主な包装だった

事があります。家から5分（小学校低学年の体感で）の所に有ったお菓子屋で買ったカールを持ち帰る時に、雨粒が2､3滴付いただけで（それ位の空気の湿り気だけで）、完全に湿気り切っていました。

その時の絶望感は鮮明に記憶にあります。

その頃のカールの袋は湿気を通していたのです。そしてお菓子屋とは、密閉された何十個もの防湿庫を備えた、専門性を持った装置産業だったのです。

さて、COBOLの話ですが、COBOLはその頃のお菓子屋と同じ様に、その頃の状況に対応していました。それは、

• 仮想記憶は有ったのに、プログラム1実行当たり、メモリを千バイト程度しか使えない

事でした。

それに対応する為に、

• COBOLはメモリを1バイト単位（英数字）、あるいは2バイト単位（漢字）で個数指定

していました。

• メッセージを編集する為の変数には10文字20バイト、金額には10バイト

と言った感じです。

今のように、文字列型を定義すれば1変数当たり10万文字分とか（漢字1文字は2バイトとは限らず、6バイトだったりもするがそれも考慮の上）もらえるのとは、訳が違いました。

柔軟性があろうはずも有りません。

メモリを沢山使える時代に即した言語改良をすれば良かったのではないか？

千バイト程度をちまちま使う時に便利な様に、そしてそう言う風に使う時の書き方を最優先に文法が組まれていることで、それとの互換性を保ったまま、改良は出来なかった様です。

メモリジャブジャブ時代で便利な様な文法を最優先にする余地が、完全に無かったと言う事だと思います。

それにしては嫌われ過ぎているのでは無いか？

COBOL言語で書かれたシステムをモダナイズしたい人は、

• COBOL言語を読み解くのは目が腐る
• COBOL言語独立に、仕様を渡して欲しい
• COBOL言語の「入力→出力」と同じ動作を、新システムでも出来ればテストOKとしたい

と考えていても、

• 何のかんのでCOBOL言語で書かれたシステムは（各サイト個別事情の複雑怪奇な）業務知識の塊で、言語独立の仕様を渡せと言われても、「誰に言っているの？　自分にはその様な能力は有りません。」

と言われるだけだったからだと思います。

何で言語独立の仕様を渡せないのか？

言語独立の仕様は、

• いくつかの必要とする点を指定したものに過ぎず
• それにふさわしい滑らかな曲線を描いた結果であるプログラムから、点の指定を復元したとしても、現行プログラムの動作を再現出来るだけの情報にならない

からだと思います。

これはCOBOLに限った話では無いと思います。柔軟性の乏しいCOBOLであっても、動かない1つの問題の解決の具としては十分で、柔軟性に乏しいとは別の話で、

（多分自然言語で書かれた）言語独立の仕様などよりも「いかにも些細な詳細な零細なレベル」で記述出来たからです。

ただ、その代表格（モダナイズしても良いと思われるだけの旧システムが有る）としてのCOBOLだからなのでしょう。

結論

これからも「COBOL言語である」事でプログラミングが嫌いになる人は存在し続ける事でしょう。

常識が通じない １

どの様な話？

歴史的に有る時点まで（普通に動くコンピュータが10万円以下で手に入る様になるまで）、プログラミングが主な手段であるシステム開発は、SIerの様なコンピュータの側面からのみ突き詰めるプレイヤーによってなされて来ました。

しかし、コンピュータが安くなった結果、

• 他分野の常識を基礎にして、システム開発を根本的に見直す
• それにより、コンピュータハードが安くなったのに呼応して安くする事を目的とする

考えが（当然ですが）沸き起こって来ました。

しかしながら、見た限りでは上手く行っていません。もっと言うなら「常識が通じない」様に見えます。

根本的な誤解があるのでは？

常識のみで考えると、

• プログラムを本番実行すると、原因不明の理由で動かない

のが絶対的な通常で、そうで無いのは、

• 必ず、何か非常識な事をしているから

では無いでしょうか？

何が「非常識」なのでしょうか？

化学反応は、多数の原子分子が体験するさまざまな可能性の中から、圧倒的に大きい確率で起こる事を、さも一直線に起こる様に表記しますが、「常識」もまた、似た様な原理で発生するものだとしますと、

「非常識」とは、

• 多数の人間が体験するさまざまな可能性の中から、起こりにくい事
• しかし全歴史の中で1回しか起きていないとかでは無く、もう少し頻度の高い事

だと思います。あまりに頻度が低すぎると「非常識」とすら認識できないからだと思います。

テスト実行をしなければいけない理由

プログラムはテスト実行をしなければいけない理由も、そこに有るのかも知れません。

要件に応じて複数の「非常識」を過不足なく表記する時、

• 本当に過不足無いのか

は「やってみないと分からない」からだと思います。そしてそれらテスト表記により、

• このプログラムで「必要な」「非常識」とは何か
• プログラム内では陰に表現されているのみ（苦労して読み解かないと見えない）

なのを陽に表現できるのかも知れません。

ただ、現時点ではテスト表記についての研究は途上だと思います。

結論

ですので、これからも「常識が通じない」事でプログラミングが嫌いになる人は存在し続けることでしょう。

より簡単な手法にさせてもらえない ３

なぜ手法により、解くべき「問題」を変えるのか？

「より簡単な」手法を成立させるための秘訣とは、具体的には、

• 解きたい問題をある動かない物体に例えた時、
• ある手法をその物体に対する視座に例えると、
• 正面からの視座よりも、わざと横目ギリギリの視座の方が、
• 解きたい問題に例えた物体が単純に見える

という性質を利用しているのだと思います。歴史的に見て、最終的に妥当だろうとされたものとよりかけ離れた手法だと、自然と（所与の）問題が単純に見えるのです。

これによりダマす意志なしに、実質的にダマすことに成功しているのです。

なぜその様な破滅的な秘訣を許すのか？

プログラミングの手法とは、乱数のアリゴリズムと同じで、（少なくとも文脈内で）一貫していることが求められるからでは無いでしょうか？
（乱数のアルゴリズムをさらに、実行中にランダムに切り替えると乱数が良くなるかと思ったら、実際にはより悪くなるという話があるそうです。）

• 臨機応変に視座（手法）を変えるより、一貫性を求めた方が、問題を解くのに有利

というのは動かし様が無く、

• 大きなプロジェクトで、プロジェクトの成員に対して、一貫性を強要してしまう
  （原理原則を無理偏に拳骨よろしく強要してしまう）

事実に対して、PMなど、権力勾配的に上の人間が恒常的に引け目を感じており、そのPMなどが優位性を感じていないプロジェクトでガス抜きをさせたいと感じるからだと思います。

根本原因は

その様にガス抜きをさせないといけないとなる根本原因は、

• より簡単な手法に対し、大勢の非専門家が賛意を與える

ことだと思います。ほめられるのは嬉しいのは確かです。

根本解決は

現在はプログラミング的には末世で有るとし、例えば100年後位に、
よりプログラミングが普及し、普通のお母さんが普通に子供に教えられる程度になり、
泰斗により標準的な教科書が何冊も（誰々の何々分野の教科書だ、みたいな）発行される
様な、来世に期待するしか無いと思います。

皆が知れば、皆が妥当とされない手法に賛意を與えることも無くなります。

その頃には化石燃料は使い尽くされているのかも知れませんが。。。

結論

少なくとも現時点では、これからも「より簡単な手法にさせてもらえない」事でプログラミングが嫌いになる人は存在し続けることでしょう。