dotkuwaの日記： プログラミング的思考を学ぶべき理由 8
日記 by
dotkuwa
１．プログラミング的思考を学んでいない人は、
プログラミング的何か（ソフトウェア開発とか）
に関わる際、自分のメンタルモデル無制限押し付け
をする。
２．なぜならば、全くの初心者が出来る、初めに思いつく
事は必ずそれだから。
３．プログラミング的何かについて、それなりに経験を
積んだ組織は、そういうメンタルモデル無制限
押し付けに対処するには、ゼロトレランスしかない
と達観する。なぜならば、最終的にたどり着くのは
必ずそれだから。
４．その段階に達しない組織では、
・特定の人間のオタクの権力志向のままに振舞わせ、
結局、その権力構造が強固でない（その人間が
飽きたらお終い）事に気づき、
・次の段階として、全員が見に回って、一人情シスや
ゼロ人情シスになってしまい、
・その結果、「少し妥協すると、さらに踏み込んで来る
相手には、何の妥協もすべきでは無い」と組織と
して経験する
事になります。
＃なにか、別の社会科学的分野でも、同じことが有った
＃様な。。。
汎用コンピュータを取り入れる様な分野では、自分が
仕事に入った30年前以前から、最終的段階に有ったの
かも知れませんが、
（なので、初めにテストを思いつく事に対して、ずっと
前から拒否感を経験として覚えていた。）
現在、大抵の組織で、その段階に達したから、
学ばないと、必ずゼロトレランスの憂き目に合うが、
それでは、新人全員が終わってしまい、組織の存続に
良くないから、
では無いでしょうか？
＃この段階に達していない組織でペアプロをするのは、
＃洗脳の様に思える。（個人的意見ですが）
コボラーを責めるべきでは無かったのでは無いか (スコア:1)
ソフトウェアに絡む組織の極相がコボラーの世界だった
のでは無いか？
それなのに非難してしまった人間が居る組織は、
その人たちが居なくなるまで、最適化にたどり着けない
事になっているのでは無いか？
コボラーとして一番こたえた非難は、
・大げさなコード化
で、次が、
・連番の名前（対応表を引かないと意味が解らない）
でした。
今から考えると、これらは、
・列挙と管理の分離
をやろうとしていたのだと思います。
まずマイナンバーを付け、それとの対応表を作り、
対応後のキー項目で管理をするやり方は、非難されまくった
コボラーの世界だと思います。
直感的には、管理する名前＝列挙する名前とすれば、
もっとも「判り易い」ですが、長い時間が経ち、
違うメンタルモデルを持った人が管理者となった時、
その人の「判り易さ」を担保するために、
また初めからやり直し、過去との継続性が失われる事
でしょう。
コボラーを責めた人間に兵無し！
長い目で見た時に、判り易さ、管理し易さは、制限されざるを
得ません。そうなるのが極相ですし、どうすればそうなるか
を突き詰めていくと、コボラーの世界になると思います。
Re:コボラーを責めるべきでは無かったのでは無いか (スコア:1)
一度整理してみたいと思います。
ここで、「コボラー」だと言って非難する人間の事を
（怪獣つながりで）「移行星獣」という事にします。
（なんでかは後述）
COBOLがだめになったいきさつは、
１．大きいPC（サーバー）で、情報処理が出来る事に
なった。
（これだけなら、COBOLもサーバーで動く様にしさえ
すればよかっただけですが、そうはなりませんでした。）
２．RDBが流行るようになったが、COBOLにNull項目など無く、
各基本項目の直前に1バイトのNullか判定する項目を置け
だの、頭が痛くなる事ばかりだった。
３．COBOLで無いVB4とかDelphiだとかは、何十万か出しさえすれば
無制限にRDBアクセス環境をインストール出来た。
Null項目（As Variant含む）も有った。
４．しかも新しい言語はオブジェクト指向対応だった。
メモリ直アクセスが原則のCOBOLと違い、
オブジェクト指向言語は、インターフェースを介さないと
メモリにアクセス出来なかった。
これは大違いで、言語を移行するに足る進歩だった。
ですが、
成員全体のメンタルモデル（別名お気持ち）から見て、
何とか納得するモデルは、
既にCOBOLで有りました。
ですので、コボラーから破壊的に奪い取って、新システムを
成し遂げた人間は、移行しかしていません。
だから「移行星獣」です。そう考えると、それからの彼ら彼女らの
行動に納得が行きます。
－－－－－－－－－－－－－－
成員全体のメンタルモデル（別名お気持ち）から見て、
何とか納得するモデルを作り上げる事は、非常に難しく、
ill condition で有ると言っても過言では無いと思います。
MT装置数台とカードリーダとLP装置（と大量の汎用用紙とカード）
だけで、マージソートをしたり、マージをしたり、マッチングを
したり、帳票に出したりする様な、
非常に小規模な頃から、試行錯誤を経た末のモデルです。
すぐに思いつく手法が有る訳でも何でも有りません。
（これも、プログラミング的思考の一つだと思います。）
－－－－－－－－－－－－－－
なにが言いたいかというと、
★移行星獣たちは、モデルを思いついた事が無い。
★移行星獣たちは、モデルを思いつく事がコボラーの専売特許だと
思い込んでいる。
★移行星獣たちは、モデルを思いつく事が困難なのは、コボラーのせい、
あるいは、コボラーが簡単に思いつく方法を隠していると思い込んで
いる。
★だから移行星獣たちは、コボラーを非難する。
のでは無いでしょうか？
もし、そうだとしたら、その非難は的外れです。だれがやっても
それを思いつくのは困難で、初めに正しい事を思いつくのは不可能で、
コボラーにそのill condition をなすりつけるのは不当です。
さらに、別のより新しい言語、フレームワークでまた移行をしようと
考えた移行星獣たちは、
★オブジェクト指向とPCサーバー
という新規性と同程度以上の新機軸を見つける事が出来ず、
COBOLより昔で有るに違いない、単なる欠落に過ぎない関数型プログラミング
だなんていう物を持ち出し、移行出来るだけの成果を上げられない
のです。
もうその轍を踏んではいけません。心よりそう思います。
移行星獣の今後 (スコア:1)
自分は大学時に家でいじっていたマイコン（MZ-80C）の
SP-5030とSP-4010とHu-Basicの知識だけで、会社に入り、
オフコンのコボルプログラムをいじれ言われて、いじった
ら出来てしまったという経緯でコボラーになったので、
伝手とかが有った訳でも無く、ゆえに、
伝手の無い人に対して優越性を持てた事も無かったのですが、
何故かコボラーとして非難される側になったのです。
それは今でも続いています。
ただ、現状は変わってきています。
本当にコボルを別の言語に移行するのが流行っていた時期は、
★説明・説得が不要
でした。まるで携帯電話か何かの様に、「明白なる運命」として
広まっていきました。
しかし、現在、例えば「Forを排すべきだ」とか、迅速かつ適応的に
ソフトウェア開発するのにこのやり方にそろえろとか、
年中説明・説得がなされています。
それだけで、移行星獣の現状が理解できます。間違いなく
追い詰められています。
移行星では、テストにおいて特異な事実（良い事実）が有ります。
同じ入力をして同じ処理をして同じ結果が出れば、テストOKと
出来る点です。
しかも、モデルは既に与えられていて、考える必要が無いのです。
これらの事から、移行星獣は、（ハマれば）大儲けが出来ます。
特に移行星獣の内でも、最高にハマっていた時期に、功績から
大学などに進んだ個体はまずいと思います。
移行後のシステムを保守していれば、自分で成員間のメンタル
モデルの再調整を求められたりして、星獣が星人にスキルアップ
出来たかも知れませんが、
現場を離れた移行星獣は、獣のまま、次の移行のネタを探してる
のでしょう。
しかし、本当に移行が誰からも望まれる状態では、
★説明・説得が不要
なのです。だから望まれてもいない状態で、第二のどじょうとして
PHPをやり玉に上げようとしてしくじったのだと思います。
今後は、時代から取り残された移行星獣の言う事は聞かず、
現行のやり方でもかまわず、小さい事から積み重ねて行き、
成員全員が納得できるメンタルモデルを導き出すのが
肝要だと思います。
テストドリブンとは移行星の流儀？ (スコア:1)
ソフトを開発していると、小前提は頻繁に
（結合テストをしている時ですら）変更が
有ります。
変更のマネージャーがテストのマネージャーと
連携を取らず、全部こちらのせいにもされたり
しますが、それが実態でした。
そして、オブジェクトのインターフェースは、
小前提単位に切り分けられ、すげ替え可能に
なる様になっている筈です。
中前提を変えるなんてなったら、トップレベルの
仕切り直しになるでしょうし、大前提を変えると
なったら、開発側が裁判で勝つでしょうけれど、
その様な事は、自分らとは関係が無いレベルです。
そういう背景の元、
・小前提を固定する「テスト」を初めに書く
事を推奨しているのはなぜでしょうか？
それは、
・それが移行星の風土に合っている
からでは無いでしょうか？
移行星では、
・モデルは所与で、移行元のシステムも実行可能
です。
そういう風土での最適な手法を、新規開発に持ち
込もうとした結果だとするなら、
理屈に合います。
しかし、その様な事は移行星の外では成り立たない
事が多く、特に、初学者が自分で自分のメンタルモデル
と向き合おうという時には、猛毒となるでしょう。
無い、顕在化されていないメンタルモデルから直接テスト
を書こうとするのですから、本当に有害です。
Re: (スコア:0)
COBOL という言語の弱点は、他の言語なら簡潔に書けることを記述するのに冗長な表現を要求することや、予約語が多すぎて全体を把握するのが困難であることなど、開発者の負担が大きいところにある。
それでいて用途が金額計算に特化しているので他分野の応用が広がらず、使い勝手が悪い。
歴史的経緯で COBOL を使うところがあるのはわかるし、進んで COBOL を選んだ人ばかりでないのもわかるから、業務で COBOL を使う人を責めている人はいないと思う。
お勤めご苦労様です。
表に出る id と内部で参照する id を分けるのは COBOL の専売特許というわけではない。
後発のくせにマイナンバーという住民番号のしくみがしょぼいのはまったく別の話。
Re:コボラーを責めるべきでは無かったのでは無いか (スコア:1)
>開発者の負担が大きいところにある。
>しくみがしょぼい
というのは、「お気持ち」だと思います。
COBOLは、
・NATIONAL項目と言いながら、2バイト文字しか扱わない
・NATIONAL項目で無い項目は、内部コードのBIT単位の操作を
容認し、後で本当に困る
・（速度を本当に重視する目的での）C言語や、FORTRAN言語
などと同様に、一直線のメモリをなめる事を許容しており、
オブジェクトなど、それを許容し得ないやり方と共存が
困難
だったり、どうしようも無かったですが、それであっても
「お気持ち」で非難されるいわれは有りません。
開発者の負担が大きい根拠はなんでしょうか？
特定の開発者のメンタルモデルと合わないから、合う物に比べて
負担が大きいとしたら、それは当然ですし、ほかの多数の
開発者のメンタルモデルと合っているのでしたら、それで
十分だと思います。
マイナンバーも「しょぼい」という「お気持ち」で非難される
べき対象で有るいわれは無いと思います。
特定のアプリケーションの極相として、大多数の開発者から
みて、メンタルモデルに合わない事になってしまう事は、
有り得ます。それを一言、「しょぼい」で切り捨てるのは、
一種のお気持ちやくざだと思います。
Re: (スコア:0)
もともと COBOL とマイナンバーという別のネタを混ぜていたので、そういう言葉遊びだと思ったのですが、違いましたか。
失礼しました。ごゆっくりお楽しみください。
Re:コボラーを責めるべきでは無かったのでは無いか (スコア:1)
元レスに戻り、整理しなおしてみます。