嫌われプログラミングの代弁者

「何で頭ごなしに嫌う人間が居るのか」を色々考える

ごきぶりの雌と研究者 5

今更何が悪いのか

  • 厳密で
  • 分かりやすい

は、それを信奉する人が「ナンバーツー」までの間なら、それ程問題にはならないと思いますが、「ナンバーワン」になった途端、

  • 周りの旧人困るルールを作り、
  • それを新しい

とする行為の問題点が、自分(と部下・配下全員)に容赦無く降りかかるのです。

 

小さい所ならすぐ、「ナンバーワン」にもなれるでしょうけれど、そこで問題が起きても、そこが潰れるだけで、大した社会的影響は起きないけれど、

面壁20年とかで、社会に大きい影響を与える所の「ナンバーワン」になった途端、その「弱い毒」は、自らを炎上させる原因になる訳です。

コンビニで書類を出し損なうとかも、厳密で分かりやすい(=旧来の問題意識自体が大袈裟だ)という考えの結果かも知れません。
(ロックを単なるマイクロ秒単位のタイムスタンプだけにしてしまったとか?)

 

 

何で厳密が悪いのか、分かりやすいが悪いのか?(厳密側)

「厳密」側は、プログラミングではいじり様が無いと思います。プログラミング言語である限り無条件に「厳密」です。

名前を分かりやすくする程度は出来ますが、

  • 分かりにくい部分を分かりやすくする

のは出来ても、

  • さらに分かりやすくする

のは出来ません。原因が無い結果は不純です。多分これをやろうとする衝動は、「科学の宿痾」かも知れません。
原因が無いのに無理やり分かり「やすく」する事は不可能です。

COBOLシステムで、

  • 項目名が変で、全く意味が通らないのに、読み替えて使っている

とかは、逆に分かりやすさを追求した結果だと解釈すべきです。

厳密な中で分かりやすさも追求すると、後の少しの変化で壊滅的に分かり難くなるのは、理屈が通った話で、事実でも有ります。

 

 

何で厳密が悪いのか、分かりやすいが悪いのか?(分かりやすい側)

逆に「分かりやすい」を厳密にする方向は、今まで無かったと思います。

誰もが心の中ではやるべきだ、と思っている事かも知れませんが、現実には今まで無かったと思います。

プログラミングの分野では、束構造の因果ダイアグラムは、これに向いていると思います。

  • システムを作ろうとする発端を上限とし、
  • 原因→結果を積み重ねて、詳細化され、
  • プログラムの各部分に対して、(最も詳細化され、プログラミング中も更新される)原因たちからの有向グラフが付き、
  • 「上限から最も詳細化されたグラフ」のどこにも無い原因を根拠にした、結果としてのプログラムは、お宅の考え過ぎとして排除・修正する根拠ともなる

からです。

 

どうすれば良いのか(私見

  • 厳密優勢記述

  • 分かりやすさ優勢記述

を分けるべきだと思います。

前者は、プログラム+テストで良いと思います。ただし分かりやすさは程々が良いです。
後者は、束構造の因果ダイアグラムが良いと思います。自然言語でかつ「半構造」より、"全"構造的に近い記述です。

ただし、後者はその実施方法に特許がかかっている可能性がある為、20年とは言わなくても、10年は先になると思います。それまでは、学術的に調べるのが良いと思います。

 

 

結論

これからも「ごきぶりの雌と研究者」の例えの通りの毒が回り、プログラミングが嫌いになる人は存在し続けることでしょう。

 

ごきぶりの雌と研究者 4

「弱い毒」が出来る理由

私は、「普通の」コボラーより10歳は年下になります。「COBOL言語である 5」で書きましたが、たまたまCOBOL言語をいじったら出来たのでなっただけで、

その点では、一般に言われているコボラーでは無いと思います。なので、「弱い毒」が出来た過程も見てきました。

 

  • パソコンサーバー(平べったくて動作音のうるさい奴)でRDBなどが使える様になり、
  • 汎用コンピュータでの新規開発がなくなっていった

頃、コボラーに依らない開発が求められ、全くの新人にリーダーとしての役割が与えられました。

全くの新人に、リーダーの役割を与えられると、する事は決まっています。

  • 周りの旧人困るルールを作り、
  • それを新しい

とする事です。必ずそうです。

 

 

「弱い毒」が残った理由

その様な新人は、かなりが嫌気が差して居なくなりますが、太親で無給で研究者になってもやっていける人は、研究者になったと思います。

研究をするにしても、(この様なブログと違い)領分があるでしょうから、好き勝手な分野の研究は出来ないと思います。

因果推論などは、例えば公衆衛生の分野では死活問題の研究対象だと思います。オタ分野のCSとかがクチバシを挟める物では無いと、素人考えでも分かります。

 

何を研究すべきでしょうか?

 

  • 厳密さとは問題をダイレクトに表記に反映

させます。分かりにくい問題は、厳密な表記もわかりにくくなって当然です。

では「厳密で分かりやすく」するにはどうすれば良いかと言えば、

  • (分かりにくい)問題そのものが誤りである

とすべきです。現行システムの面倒を見ている旧人困らせるに足るルールです。

とうとう、学術的なニッチにたどり着いた訳です。

 

 

結論

これからも「ごきぶりの雌と研究者」の例えの通りの毒が回り、プログラミングが嫌いになる人は存在し続けることでしょう。

 

ごきぶりの雌と研究者 3

私が大学4年だった頃

蒸留塔だとか吸着だとかを差分計算でやる研究室で、そこに有ったPC-9800(文字通りのバッファーロー付き、5.25inchフロッピー2台)で、「なんかやれ」と言われ、

横浜の下町に有ったサザンパシフィックで98で使えるターボパスカルを買い*1、サザンパシフィック版の線画ツール(2枚目のフロッピー)で蒸留塔の線画を描き、

「関数の引数の座標を変えて、関数を2回呼べば、蒸留塔が2基になります。」とか言ったら、それで卒業論文はいい事になりました。

学部の研究なんてその程度だとは理解しています。

 

 

しかしながら、

しかしながら、

  • 厳密で
  • 分かりやすい

学んで来たと思われる学部卒の人で、学部卒なので、自分で手を動かす訳にも行かず、結果として先輩に対して、

  • 考えるのはお前だろう

状態になった人の末路は、押し並べて /dev/null 行きになりました。

まだ、そういった事を学んでいない、他学部(私もそうでした)の人間の方が先に進めました。

 

 

何が悪いのか?

徹頭徹尾、学用の課題なのだと思います。

厳密で分かりやすい、を現実世界で突き詰める事は、神経衰弱まっしぐらだと思います。

 

 

何で悪いのか?

関数だけで書ける様な、1面的な見方固定で、時間発展しない様な課題の場合は、まだやれたかも知れませんが、2が3になるだけで、百発百中破綻する様な考え方となっていたのだと、外部から見て想像しました。

私は御免です。

 

結論

これからも「ごきぶりの雌と研究者」の例えの通りの毒が回り、プログラミングに関する世界からいなくなった人は何人も居るのです。

これは事実です。

*1:造り酒屋か蚕関係か何かだったのか、店の調度(机とか、荷物置き場とか)が全部石を切り出した物で出来ていて、そこに座った人が、石の机の上に有った98でフロッピーをコピーし、シールを貼って売ってくれました。

アプリの総代理店だったので、それは合法との事です。

ごきぶりの雌と研究者 2

「弱い毒」とは具体的にプログラミング分野では何になるのか?

歴史的に見て、

  • 名前の接頭語
  • 継承

で「弱い毒」が発生し、絶対ダメなやり方となりました。

結論から言いますと「弱い毒」とは具体的にプログラミング分野では、

  • 厳密で
  • 分かりやすい

だと思います。プログラミング言語は大抵厳密で、ちょっと間違えるとするエラーになりますし、名前の工夫は分かりやすさの第一歩だと思います。

一つづつなら何の問題もなかったはずですが、

ただ、その2つを結びつけると「弱い毒」になります。

「弱い毒」とは、

  • 初学者の学習には役に立つ
  • 何かやりにくさが有るが、学習を進める上の有益な困難だとも取れる
    (若い雄のごきぶり)
  • しかし、実用的なプログラムを作ろうとし始めると、とてもやっていられない毒になる
    (雌のごきぶり)

という問題が発生し、数学的にも根拠があり(順序関係とか)、誰が見ても良いやり方だとされていた手法が、絶対にダメなやり方に成り下がるのです。

 

 

実例1:名前の接頭語

コボルでは手続き(関数みたいなもの)の名前は英大文字数字8文字(先頭に数字はダメ)でしたが、

私のやっていた所では、先頭3文字はシステムの接頭語として固定でした。
ただし、その接頭語は全部で1つでした。

もっとも、手続き全部で50〜100個程度だったので、3文字を(ほぼ)無駄に使っても問題は有りませんでした。

 

MicrosoftVisual BasicVB.NET含む)は、

  • Dim int何ちゃら As Integer
  • Dim str何ちゃら As String
  • Dim dte何ちゃら As Date

とか型の接頭語をつけるのが通例でした。そしてその頃は別にこれで何も言われる事は有りませんでした。

 

さて、接頭語の工夫くらい、

  • 言語の改造も
  • 国際規格も

不要です。勝手に色々試せるはずです。単なる名前の先頭文字の工夫に過ぎないのですから。。。

もっと内容に踏み込んだ、きちんと考えた分類に基づいた接頭語のセットを設計しなかったはずはありません。絶対にそう思います。

しかし、その様な工夫について、何か公開された記事・書籍等、全く見たことがありません。

名前の分かりやすさに加えて、厳密さも付け加えた、先頭文字の工夫には「弱い毒」が出来途端に絶対ダメなやり方に格下げになる為では無いでしょうか?

 

 

実例2:継承

継承だって、一番の親からの順序関係とか有って、数学的根拠も十分有る手法だったはずです。数年前までは、推奨されこそすれ、これで何か言われる事は無かったはずです。

それは、多分、

  • あるクラスを継承するとき、継承元と継承先のクラスの振る舞いを同じにしよう

とか、書き方の分かりやすさに加えて、厳密さも付け加える試みが、継承に「弱い毒」をもたらし途端に絶対ダメなやり方に格下げになる主要なきっかけを与えたとしか思えません。

 

 

将来予想:静的な型

今は、内容には触れず、素晴らしい素晴らしい、としか言っていないので、問題は起きような無いのですが、

  • 厳密で
  • 分かりやすい

に踏み込んだ途端、継承と同じ理由で、途端に絶対ダメなやり方に格下げになると予想出来ます。

 

結論

これからも「ごきぶりの雌と研究者」の例えの通りの毒が回り、プログラミングが嫌いになる人は存在し続けることでしょう。