言語の歴史 3 モジュール指向

言語の中*で* プログラムすることと、言語の中*へ*プログラムすることは、大きく異なる。(Gries 1981)
別に稿を書き起こす予定だが、ひとつの言語しか知らないと、その言語の仕様に限定された発想、思考しかできない。いくつかの言語を知っていれば、問題を解決するための最適な処理系の選択ができる。これは堅牢なアーキテクチャの確立のひとつの要素だ。

と、ぶち上げて、モジュール指向の言語の話だが、これ日本で全然、流行らなかった。好きな人の間で、「いいよねえ」「よさげだよねえ」と言ってたんだが、ビジネスベースでは、ほとんど使われてない。それだけ、cのインパクトでかかった。

モジュール=名前空間　として、抽象化されたデータ型を作る。

Ada やっぱりアメリカ国防省がからむ。データ抽象化と情報の隠蔽、パブリック、プライベートの考えなどをもつ。ちなみに、Adaさんという人は数学者で、世界で最初のプログラマと言われる。コンストラクションが難しい時、祈るといいことがあるかもしれない。

Mudula2 ごめんなさい、ほとんど知りません。ライフボード社で扱っていて、処理系売ってたんだけど・・・お小遣いじゃ買えませんでした。

撤退すべき時

もう時効なので。

付き合いの長い会社なんだけど、いかんせん組織が巨大で、セクションた担当によって、「アタリ」が異なり、トラブルこともある。

現場に来てやって欲しいという業務で、一人行ってもらった。
長期続くはなしだが、まずは契約１ヶ月でやって欲しい、と。

営業・収支上のPMはいるが、技術面のPMの働きまで、踏み込んでほしいとの希望で、たしかに、マッチしないと、プロジェクト自体が頓挫する重要なポジション。
慎重になるお客さんの気持ちもわかるし、行ってもらう本人にも納得してもらい、現場に入った。

１ヶ月が過ぎる、少し前。次も、1ヶ月で契約してくれ。
ゴタゴタするのもイヤなので、呑む。

そして、次、また１ヶ月と言い出した。
今まで、そんな話はしたことのないお客さんだったのだが、担当が不慣れだった。ダメならダメでいい、ミスマッチなら、早めに結論出して、次を考えるのが、お互いのためだろうに。
行っている本人がキレ、契約、更新やめましょう。と言い出した。
ごもっとも。オレも、この進め方おかしいと思う。フェアじゃない。

さて、それを言い出すと、
「いや、そんなことないんだ、残ってくれないと、困る」

だが、ここは、やはり引き上げるのが妥当と判断。
この行き違いそのものに、近い将来の問題の種を内包しているように思えた。
その会社全体とのツキアイはまだ続いているが、このセクション？この担当者は、ダメかも・・。

引継ぎやらなんやらで、けして、波風たてることは本意ではなかったし、いたずらにプロジェクトを困らせたいとも思わない。交代がくるまで、その後、２ヶ月は、やった。

バランスが、時に悩ましい。

言語の歴史 2 手続き型 構造化

オブジェクト思考の背景として歴史を知ることの他にも、コンストラクションの重要な決断をするためには、言語の種類、特色は理解しておくべき。どうしてこのシステム構築にあたって、PHP5を選択しているのだろう。いつまで、半人前のＰＧでいいなら知らなくても、考えなくてもいいけど。

COBOL アメリカ国防省向けに作られた。今でも大量に資産がある。
手続き型から進歩も続けていて、構造化COBOLや、最近では、オブジェクト指向の機能を持つCOBOLまである。不勉強で、オブジェクト指向COBOLの詳細は知らない。

Fortan 手続き型でスタートだが、Fortran77では、ブロック構造のIfが追加され、構造化への歩みもしている。

C 低水準に移植性の高いアセンブラとしても使えるし、構造化された制御、マシンからの独立（一応は）など、高級言語としての機能も。1980-1990年代、オープン系開発では、事実上の標準ともいえる。

手続き・構造化は、ずいぶん、がんばってイロイロなことを試みる人たちがいた。
同じようなところを、まとめて、サブルーチンとして使いましょうよ。
アセンブラまでは職人だけだったが、この頃から、プログラムが大衆化して、それこそ、ぐちゃぐちゃになって、コードの書き方何とかしましょうや。で構造化。

ちゃんとやれば、それなりに理解しやすいプログラムになる。でも、再利用できるのはあくまでも、コードのレベル。それ以前の、分析・設計の再利用性は、ない。勿論、コードと業務のつながりは直接的にはなく、ドキュメントのみが頼りになる・・が、このドキュメントが十分であることは・・マレだ。

言語の歴史 1 機械に優しい

オブジェクト指向の必然性を理解する上で、言語や処理系の歴史を、背景として知っておくことは有効だ。

まず、機械語やアセンブラの時代。
当時は、マシンもメモリも高かった。人が、機械様にスリスリしていく必要があった。人間はコンピュータの気持ちになって、0と1の羅列をする。（16進でもいいけど）
アセンブラのニーモニック。ちょっとだけ人にとって意味を持った。でも ADD はマシン語の010011だよね、とマッピング、紐付けしただけ。

長所は、マシンと環境と地球に優しい。エコだったんだな。早いし。
少しでも便利にしようと、歩み寄りもあって、マクロアセンブラとかも出たな。でも本質的には、普通の人には焼け石に水。もう職人芸の世界。
どうしても実行速度を負う、コードサイズを小さくする必要性があれば、今でも使われる。

そして欠点は、勿論、ふつ～の人は見てもわかんねえ。

化け物はいるもんで、16進をみてニーモニックに直せる人間逆アセンブラーとかいたなあ。尊敬されてた。でも俺はできません。