意味がわからない １

どの様な話？

• 「プログラミングの意味が判らない」からプログラミングが嫌いだ

について私見を述べます。

私にとっての意味

• プログラミングの意味は、プログラムの意味とデータの意味に分かれる
• プログラムの意味は、データの意味を担保する手段のみで
• データの意味は（プログラムや人間など）それを使う側の総意である

だと思います。この私見通りを納得してもらうなら、嫌いになる程、プログラミングが判らないという事態には陥らないと思います。

この考え方は昔から有り、再現性も有ると思います。

プログラムの意味は？

それに対して、「プログラム自体の意味」が有るという立場では、困難が待ち受けていると思います。

プログラムの意味には必ず、

• データの意味を担保する手段としての意味が含まれている

筈で、その制約だけでお腹いっぱいになる筈なのに、

• さらにプログラムの意味まで問う

と、負わなくても良いはずの負債を抱えてしまうからです。

いわゆる「技術的負債」ですが、それは、

• プログラミングにとって有利な原理原則（※１）を維持し続ける為には、プログラムの意味の一貫性を捨てないといけない筈で、
  （単体テストの自動化の破綻は、この為に起こると思います。）
• それなのにも関わらず、（現在取り組んでいる眼前に有る）プログラムの意味の、プログラミング全体から見た原理原則（※２）（見ている世界の次元が上がっていると思います）まで考えると、
• 人間業を超えた理解力が必要になる。
• これは誰にも出来ないのにも関わらず、やらないといけない、となると、負債に見える。

という仕組みだと思います。

何でそう思ってしまうのか？

データの意味の維持など、コスト０だから（分かりやすい、まともな名前を付けさえすれば、万人に対して相互理解が完了する（と思い込んでいる（そんなわけ無い）））
という、誤解からだと思います。

データの意味の維持だけで、人間業として全勢力を傾けないといけない筈なのに、プログラムの意味にまで色気を出すから、ダメなのだと思います。

結論

それでも、プログラムの意味まで希求する人を止めることは出来ません。それは個人個人の好みだからです。ですので、

これからも「意味がわからない」事でプログラミングが嫌いになる人は存在し続けることでしょう。

まともな名前を付けさせてくれない ３

どの様な話？

変数名などに、

• まともな名前（妙に一般的な、普遍的な名前）を付けたがり、
• 名前が同じなら、操作的意味も同じ（しかもその意味は自分が思っている通り）

（という様な非常にナイーブな（悪い意味で）態度で）としたがる事を始めたのは、パソコンサーバー（WindowsNTなど）上で、RDBを取り扱う前提のシステム畑の人間でした。

コボラーは言われるままの無関係でした。

コボラーは無関係な訳？

（より自由になったパソコンCOBOLで無い、昔の）COBOLの変数名は、

• 英大文字、数字8文字以内で、先頭に数字はダメ（ABC012 の様な）
• 「項目定義」なる手書きの（後にMS Excelの）資料が必須

となっていました。そもそも「まともな名前」をつける余地が有りませんでした。

ですので、その変数の操作的意味は、毎回毎回長い時間をかけて、一々「調査」して会得していました。（その事は非難の対象でした。）

もちろん

もちろん、1つの横断的に利用されるDBのみのシステムの場合では、正しかったのかも知れませんが、
ドメイン駆動設計を持ち出さないとならなくなる様な、複雑なシステム
（大規模とは限らない、複数DBやそもそもサーバーレスなどでは小規模でも「境界づけられたコンテキスト」が出来るかも知れません）
では、

• まともな名前を付けさえすれば、その意味は同じになる

といった言霊頼みの設計は成り立ちません。

そうなると、

そうなると、「境界づけられたコンテキスト」を超えた場合、別のユビキタス言語になるというのは、

• 名前では無く、一々「調査」しないと操作的意味を得られないなら、
• 「境界づけられたコンテキスト」を超えた範囲での、統一的な命名規約は優先順位が下がる（分かり合うのに努力が必要な前提なら、名前は多少違っていてもどうということはない）

という消極的な意味も有るのかも知れません。

結論

「境界づけられたコンテキスト」内では依然、命名規約は必要で、
（このブログの対象で有る）プログラミングの範囲では、矢張り勝手に、まともな名前を付けたいという要望は相変わらず満たされないので、

これからも「まともな名前を付けさせてくれない」事でプログラミングが嫌いになる人は存在し続けることでしょう。

関数型プログラミングである ３

少しはファクトも持っています

信じられない程、素晴らしい性質を持った、関数型プログラミングですが、それを吹聴しているリーダーに、

• 実際、それはどうやったら出来るのですか

と聞いたら、

• 何を言っているんだ、それを考えるのはお前たちだろ

と言われました。

これはファクトです。
*1

関数型プログラミングを期成していた人たちは、誰もやり方を知りませんでした。これもファクトです。

これが婚姻論や国の借金論なら

関心を持つ人も多く、より短期間におかしさが見つかるのでしょうけれど、単に知る人しか知らない次世代プログラミングの話では、永久に初期の「ほら話し」のまま推移するのかも知れませんが、

悔しいです。

結論

これからも少なくとも約1名は「関数型プログラミングである」事でプログラミング（の一側面）が嫌いになる人は存在し続ける事でしょう。

*1:なので「関数型プログラミングである　１」において「関数型プログラミングを期成するのがチャレンジだ」という奥歯にものが挟まった様な言い方をしました。

関数型プログラミングである ２

何で20年間以上も粘着するのか？

主に2つ有ります。

1. 嘘の手法が持ち上げられると、そうで無い手法を使っている専門家の価値が有意に下げられる。（チャレンジしていないとか）
   プログラミング技術は、レガシーと次世代という括りで考えるのが一般なので、これは冗談の話では無い。完全な事実である。
   これは私のみに限った事では無く、誰でもそうなる。
2. 嘘の手法を期成した人の職業人生が危うくなる。専門家の知見が必要になる中堅以降、使い物にならなくなる。大人にはキツすぎるリスキリングを強いる事になる。
   これは私には関係無いが、誰でもそうなる。

結論

これからも「関数型プログラミングである」事を知る事でプログラミングが嫌いになる人は多数増え続ける事でしょう。