ごきぶりの雌と研究者 １

どの様な話？

私の住んでいるワンルームにごきぶりが出て、フィプロニル製剤の毒えさを5箱分置いたら、弱い毒の様で、皆すくすく育ってしまいました。

ただし、雌には効く様です。理由を考えましたが、

• 雌は雄を食べる。だから（アルコール噴射から逃れる為に）飛び降りて、金属製の棚にぶつかった際、「カーン」と良い音がする様な強固な体を作れる。
• 弱い毒を食べていた雄を複数食べると、調子が悪い量の毒になるので効く。

そして、

• 雌は間接的な体験しかしない為、ごきぶりが幾ら多様性を以て、様々な事態に対処するとは言っても、「弱い毒を食べた雄」という新しい事態には対処しきれない。

からだと思いました。

関数型プログラミングにも毒が？

関数型プログラミングは、

• バブル期に日本の研究者が導入したが、しかしそこにも「弱い毒」が混じっていた
• だから、幾ら研究しても大規模な結果に至る事が出来ない。
• トリビアルな例では問題無いが、複数重ねると調子悪い量の毒になる。

そして、

• 研究者は間接的な体験しかしない為、これに気づく事が出来ない。

とか対応が取れるかも知れません。

結論

素人はさらに研究者を通じて間接的に体験・判断するので、
これからも「ごきぶりの雌と研究者」の例えの通りの毒が回り、プログラミングが嫌いになる人は存在し続けることでしょう。

特定の側のみからの「ベストプラクティス」 ５

そう考えると、、、

継承を多用し、その機構を乱用するとダメだと考えると、

• リスコフの置換原則

や、

• 依存関係逆転の原則

がかなり危険に見えてきます。

継承のかなりの乱用をしない限り、上記議論は必要ないからです。
逆に、上記原則を考える事が、継承の乱用を誘発する可能性すら有ります。

結論

この文書に結論は有りません。

特定の側のみからの「ベストプラクティス」 ４

別の分野

ドメイン駆動設計をはじめよう　―ソフトウェアの実装と事業戦略を結びつける実践技法　Vlad Khononov　著、増田 亨、綿引 琢磨　訳　O'REILLY Ebook という本*1を読みました。

「区切られた文脈」といった用語が有りましたが、

• なぜ区切られるのか、について（全部では無いにしろ、一部分でも）因果ダイアグラムで説明が付くのでは無いか？
• 同じ原因のセット（似ている原因のセット）だから区切りの同じ側に居る？！

とかといった感想を持ちました。また「文脈の地図」でも、

• なぜこの図なのか？

についての説明に因果ダイアグラムが使えるのでは無いか？との感想を持ちました。

継承がダメで、関数・型は最高？？？

オブジェクト指向の継承はダメで、関数・型は最高だとする関数型設計の本を読みました。

確かに継承は、

• 手段として使う（サブクラス全部に共通の初期化メソッドを置くなど）

分には良くても、「簡単な」記述とかいって、

• 継承を多用し、その機構を誤用にとも言える使い方をし、設計を実現する

風になったらお終いな面は有ります。ただし、
もちろん、お終いのプログラムになる原因は有るはずです、

さて、静的な型も『手段として使う分には良くても、、』うんぬんが成立すると思います。そんなに良いなら静的な型で統一出来そうなものですが、動的な型の言語もかなりの勢力が有ります。

それも又、
統一出来ない原因は有るはずですが、

もし、それら原因が同じだとすると、まさに目くそ鼻くそのワールドです。そして、かなりの確率でそうなると私は考えます。

継承と型・関数の悪さの原因が同じかどうかという観点で物事を考えてみるのはいかがでしょうか？
もしそれが成った暁には、「関数以外不適当とゴリ押しするユニットテスト」という分野の見直しも成就するかも知れません。

結論

これからも『特定の側のみからの「ベストプラクティス」』を無理押しされる事でプログラミングが嫌いになる人は存在し続けることでしょう。

*1:PDF版をKindleのパーソナル・ドキュメントに入れて使っています。

特定の側のみからの「ベストプラクティス」 ３

「関数だ」との主張を好意的に解釈すると

もしかするとですが、

• 「関数」を持ち出した人間は、比喩のつもりだった

のでは無いかと思う様になりました。

数学畑でもソフトウェアシステム畑でも無い人が、です。

それなら、

• 全てを関数として扱う

とかが成立するからです。

不運１

数学では、比喩なんて有りません。比喩的なもっと抽象的な概念は、別の名前を付けるはずです。

そうすると、関数とは、（一貫して）地を這う存在の如く、俯瞰が出来ない存在になります。
曖昧で、厳密さに欠ける、自然言語が、鳥の視点を持つのと対照的です。

不運２

プログラマー（私も含めて）に関数と言えば、defunだとか、型定義だとかで記述されるアレら以外思いつきません。
また、職業人としては、特に、思いつくべきでは有りません。

関数とは、関数名が有って引数が有って、結果が有るアレに限られます。

プログラマーに、「考えるのはお前たちだ」と言っても、何も進みません。

不運３

関数や型は、オブジェクトと同じ欠点を持ちます。継承がダメ（その様な都合の良い共通性も無いし、インターフェースもちっとも不変で無い）なのと同じで、
型もダメ（その様な都合の良い共通性も無いし、インターフェースもちっとも不変で無い）のです。

オブジェクト指向をコケにした勢いで、関数や型を褒めても、全く意味が有りません。欠点を共有している点は（それこそ）不変だからです。

不運４

もちろん、比喩の存在としての関数が存在するならば、その様な不運は一挙解決だったのかも知れませんが、

• 比喩で有っても良いから
• 新しい、素晴らしい
• が全く無かった（10年経っても、20年経っても出てこない）

のが大きいと思います。「比喩の存在としての関数」は、形而上的存在ですら無い（もっと悪い）のだと、強く思います。

結論

もっとも好意的に捉えても、これですから、

これからも『特定の側のみからの「ベストプラクティス」』を無理押しされる事でプログラミングが嫌いになる人は存在し続けることでしょう。