学術分野で無く商用分野でも
学術分野で無く商用分野でも、
正当なチャレンジをする若手に対しては、かなりの配慮はなされます。そしてそれは中堅の犠牲の上になされます。
もちろん、自分らもしてもらったから、同じ事をしているだけで、それ以上でも以下でも無いのですが。。。
ただ、学術分野と違い、「解が無い」で終わるのは禁忌です。それは、
- （レガシーであるにせよ）実際に出来ている手法を用いている人の手を払い除けて、自分がやるとしたにも関わらず、
- （レガシーなら出来た）結果が出せなかった
という事を意味するからです。
日本で高学歴の人の処遇がおかしいのは、それら人に割り当てられた論文の課題が水増ししゃぶしゃぶの、「解が無い」で終わる課題で、
それらの人は、「解が無い」で終わるのに全く抵抗が無い、商用分野ではあり得ない態度を取るのに慣れきっているからでは無いかとすら、疑います。
これも20年かかりましたが、
まともな名前を変数に付けさえすれば、操作的意味が自動で付くなんて解は、ほんの最高に単純な場合のみだと思います。
実用的には「解が無い」と思って良いと思います。
日付が1つあっても、
- その日付当日を表す
- その日付から翌月の同じ日付の最後までを表す
- その日付から翌月の同じ日付の前日の最後までを表す
- その日付から翌月の同じ日付の指定時刻の前までを表す
- その日付から翌月の同じ日付の前日の指定時刻の前までを表す
- etc.
- etc.
意味は数限りなくあります。
解だと言われているものは
解だと言われているものは、
- 「横目いっぱい」のパターンで、
- 少し問題が変わると、操作的意味を維持する為に、プログラムを破壊的に変更する必要が出る（正面の視座の解なら少し問題がずれても、解にも相応した程度のずれしか無いが、横目いっぱいの視座の解の場合、破壊的なずれが生じる）
ものばかりだと思います。繰り返しのfor構文を「簡単にする」と称するmap関数など、まさにこのパターンだと思います。
データの意味のみならず、プログラムにまで意味付けをして「分かりやすく」してしまったが為に、破綻する（必要な問題に対する解がなくなる）のです。
酷い話です。
結論
トニカクこのブログでは、肯定的な話は出ません。その様な話があるなら、20年も待たずに、次世代論議に加わる事が出来たからです。
自分より若手である、パソコンサーバーでリーダーをやっていた人にもその事は言い、それら弱点はその通りだという回答を得たことがあります。
ただ、DBサーバーを広めるのが責務で、弱点を今言う訳には行かないとも言われ、なるほどと思い、そのまま時間が経ちました。
これからも「意味がわからない」事でプログラミングが嫌いになる人は存在し続けることでしょう。
