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

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

懐疑論を持ち出す必要がある 1

どの様な話?

懐疑論懐疑主義 Wikipedia 日本語版)からたどっていくと、

と言う考え方が有り、ポストモダンは後者であるのに対し、前者では「基礎を公理としてそれ自体は疑わない」態度の数学が代表例として有ると思います。

しかし、ソフトウェアシステムでは、

  • 公理が常にゆらぎ続けている

状態に有ると思います。常に仕様に対して懐疑的になる必要が出ると思います。
だからかも知れませんが、公理型プログラミングは全く鳴かず飛ばずでした。

 

具体的には?

具体的には、

  • ソフトウェアシステムには「自動で動作する」という要求が有り、
  • プログラム1つ1つをいじると、
  • 自動で動作するという要求を満たす為に
  • 因果ダイアグラムの上限側が逐一変化して、
  • ゆらいだ公理状態になる

と言う塩梅です。

 

技術的負債とは

技術的負債とは、この考え方で行くと、

  • ゆらいだ公理に追従出来ていない

状態の事で、しかしながら、追従しようとしても、それにより更にゆらぎ、

  • やはり、ゆらいだ公理に追従出来ていない

状態のままになるのだと思います。

「自動で動作する」を諦めれば、問題は解決すると思いますが、更にたちの悪い「ソフトウェアロボット*1」に矛盾を押し付けただけとなると思います。

 

結論

ソフトウェアシステムでは「懐疑論を持ち出す必要がある」為、プログラミングが嫌いになる人は存在し続けることでしょう。

 

「高階関数」のおかしさ 2

プログラミング言語の関数は

プログラミング言語の関数は、その表現力の制限から、

  • 1階だけ

なのでは無いでしょうか?
プログラム言語で、「顔と視線は宙吊りに」なんて事を表現出来るとは、到底思えないからです。

ただ、プログラミングの世界では、身近な範囲に高階(2階)の論理が潜んでいるので、「高階関数」が無いと言って嘆く必要も無いと思います。

それは、

  • プログラムの全ての呼び方による動作が、所与の名前と合致するか?
  • プログラムの全ての呼び方による動作が、所与の仕様と合致するか?

などです。(追加開始 2024/5/17 PM8)「動作」に対して(追加終了)「全ての」が付いている述語なので、(追加開始 2024/5/17 PM8)少なくとも(追加終了)2階論理だと思います。

たとえ、
いくら関数に静的な型をつけた所で、プログラミング言語の範囲では(追加開始 2024/5/17 PM7)プログラミング言語の関数で量化可能な)「数字」よりも拡張された対象に対して、(追加終了)全ての」を表現出来ないので、1階に留まるのに対し、
名指しや要求と、プログラミングの動作との対比の議論や、テストは自然に2階になると思います。

(追加開始 2024/5/17 PM7)プログラミング言語の中には単なる

  • 引数に関数をとれる関数

の事を「高階関数」と呼んでいるそうですが、どの様な対象を量化出来ているのでしょうか? 関数を変数に収めた所で「全ての」は表現出来ないと思います。
この様な誇大な命名は単なる優良誤認にとどまらず、初学者に対する拭がたい毒だと思います。(追加終了)

高階先に立たずです。

 

特に名前は

特に名前はプログラミング言語では漢字50文字程度を超える事はあまり無く、

  • 短く、余りに簡潔なので、
  • 私的言語になり易く
  • 「合致するか」の議論については困難さを伴う

と思います。
私は、その様な困難に立ち向かうよりは、星座程度の、意味の薄い、他と区別出来さえすれば良いで十分なのでは無いかと、(前から)思っています。

やさしい名前を付けた人が必ずしも愛されやすいとは限らないのは、過去よりの定説だと思います。名前の意味を成就させるのは、非常な困難を伴うと思います。

 

結論

解像度の比較的落ちる、高階の議論をしつつ、事後の情報も踏まえた上で、システム全体で1階に出来る所を探して、そこは自動テストをすれば良く、
そうでなく、あくまで「高階関数」を求めるのであれば、そのせいでプログラミングが嫌いになる人は存在し続けることでしょう。   

「高階関数」のおかしさ 1

どの様な話?

また、別の哲学の本*1を書いました。

すると、例えば、

  • まるで絵画の中の人物のように、あらゆる顔と視線は宙吊りにされてしまうのだ。

とか書いて有りました。本の特定の一部では無く、全般的にこの様な感じです。

 

脱構築

これは脱構築の系統の言い方だと思います。そこで調べてみますと、
脱構築 Wikipedia 日本語版)

  • 形而上学の転覆にあるのではなく、むしろ真の意味での形而上学の新たな可能性を開くところと見るべきである

と有りました。

総じての現代日本人よりデリダ等の人の方がバカだったなら別ですが、多分そうでは無いと思うので、
階位の高い、形而上の議論をする場合には、この様に、

  • 1階の議論に比べて解像度が落ちる
  • のは、人類の限界と言って良いのではないか?

と思いました。

 

それに比べて、

それに比べて、プログラミング分野での「高階関数」は、(私が出会った解説記事などの、実例の範囲ですが)

  • 全く解像度が落ちていない(単に無名関数を変数にセットしただけ)

例以外、見た事が有りません。

これで「高階」と言えるなら、このやり方を哲学分野に輸出してやれば、非常に喜ばれるのでは無いかと思いますが、
そうなっていない所を見ると、単におかしいだけなのかも知れません。

 

理が無く、もしおかしいだけならば

理が無く、もしおかしいだけならば、影響は更に広がります。

  • (少なくとも40年前からやっていた)単体の自動テストはともかくも
  • (単体を超えた)自動テストが書けるかも知れない、と言う期待は、
  • プログラミングの分野で高階関数」が有る(有り得る)
  • と言う事に依存していて、
  • それが偽となると、
  • (単体を超えた)自動テストなど、単なる詭弁でしか無い
  • 可能性も出ると

思います。

何故、解像度を全く落とさずに、「高階」の記述が出来ると、世に吹聴しているのか? 本当に疑問でしか有りません。

 

結論

これからも「高階関数」のおかしさにより幻惑されたせいでプログラミングが嫌いになる人は存在し続けることでしょう。 

 

V字モデルのおかしさ 2

合う・合わない

ソフトウェア開発は、時空を扱う自然科学とは違う系統の科学で、

  • 「きっと起こる」と信じるような観念、すなわち「信念」こそが、
  • ソフトウェア開発(コーディング開始後の相転移としての因果ダイアグラム)の本質だ

とすべきで、ウィトゲンシュタイン好みの名前の「一義的で明確」さを優先すべきであるか、私は非常に疑問に思います。

自然科学が(観測機器の未熟により)「新しもの好きのやる、あやふやなモノ」とされていた頃に主流だった哲学こそ、ソフトウェア開発に合う、取り上げるべきモノだと思います。

マッハやウィトゲンシュタインの哲学は、時空を扱う自然科学には向かいこそすれ、ソフトウェア開発の科学とは縁もゆかりも無い様に思います。

 

ただし、

ただし「信念」で全てが何とかなる世界では、そこではそこで、

  • 相容れない「信念」のどれかに統一出来るとは限らない
  • むしろ、実用的ソフトウェアでは、出来ない方が普通

では無いかと思います。「信念」が全てを支配する世界では、それによる争いが生まれるのは道理です。

 

因果ダイアグラムの上限付近の、

  • (要求分析の)どうとでも取れる『原因』から導き出される
  • 『結果』としての相容れない「信念」たちが、
  • 下限方向に向かっての、詳細化された新たな『原因』として鼎立(足の数は3本とは限らない)し、
  • 矛盾含みのまま、新たな『結果』をもたらし続ける

のが、ベクトルV字モデルでのソフトウェア開発となるに違いありません。*1

 

それにより、

それにより、当然、

  • 相容れない「信念」の帰着である所の負債が
  • 必ず生じる
  • 負債無しのソフトウェアシステムは動かない

となると思います。

  • 相容れない「信念」を統一すると、
  • 上限側の要求を満たせなくなる

のであるならば、負債を一掃すれば動かなくなって当然です。

 

誰がベクトルV字モデルでの因果ダイアグラムを書くのか?

設計側の人間だと思います。プロのプログラマーなら、自分が書いたプログラムが、

  • 何を『原因』としているのか?

明確に意識しているはずです。

それを吸い上げる文書が(今まで)無かっただけで、(本当に書けるのか不明な、永続的に使えて、変化にも対応する)テストを書けと言われるより、
よほど書きやすと思います。(もちろん別途料金は取られるとは思います。)

 

それらを集約して、因果ダイアグラムにするのは、当然設計側の人間になると思います。

始原の粒子が相互作用を起こして観測され、この世界が始まったのかも知れませんが、仕様がコーディングで観測され、相転移を起こして因果ダイアグラムになるのは自然だと思います。

 

結論

ベクトルV字モデルが一般化するまでは、これからも「V字モデルのおかしさ」でプログラミングが嫌いになる人は存在し続けることでしょう。 

 

 

 

*1:なお、因果ダイアグラムはコーディングの末、出来上がるモノで、「因果ダイアログを見てコーディングをする」のは無理だと思います。その辺は誤解なきよう! 単体テストより後の、各テストの為には使えると思います。