dotkuwaの日記: 「歴史」としてプログラミング開発を見るための一助 1
・学校の先生が自分の経験から導き出した結論を生徒に教える
・しかし、20年30年経ってみると、その教えで得した人間も損した
人間も一致して、それは間違いだと判る
ことが有ります。
そして、この間違いは「学校の先生が自分の経験から導きだした」が
為に起こる間違いです。
学校の先生に見えないこととは、
・プログラム開発を実際に行っている実務者には「正しさ」が
見えない
という点です。その代わり、
・正しさの一部分を仕様文書という形で受け取り、それと経験
(形式的によりよくなるプログラミングの作り方)を合わせて、
動く形にする
をしているだけです。
なので、後から後付けの「正しさ」をぶつけられ、利益を失い、
立場を失うのです。
学校の先生は「正しさ」を一手に握っている存在です。それは
法律でも守られ、社会規範でも守られたもので、
その様に守られた人間は、このことが生得的に理解できない
のです。
彼らの、論文を見ると、
・「正しさ」を知った指導者
が必ず現れます。語るに落ちるとはこのことです。
-------
なぜ、「正しさ」が見えないかと言うと、
・動くようにならないと人間には正しさが見えない
からです。
よく、関数型プログラミングの優位性を言われ、議論になりますが、
・関数型プログラミングは歴史上、「大昔(人間の文明が起こってからすぐ)
から有る、デジタルコンピュータがブレークスルーを起こす以前の
技術で、関数型プログラミングは人間に正しさが見える反面、
それだけでは動きません。
・手続き型プログラミングこそが、ブレークスルーを生み出した根源であり、
関数型プログラミングは次世代でも何でもない過去からの遺物に過ぎない
であるのを、学校の先生等がねつ造している面が有ります。
手続き型プログラミングは、動くようにならないと、人間には正しさが
見えませんが、
プログラム開発を実際に行っている実務者の前には、動くプログラムが
有りません。彼・彼女の後にこそ有るからです。
言い換えると、
・上流工程・設計とは試作
に過ぎない、となるでしょう。上流工程・設計を思弁的に行っているという
考えも妄想で、その様な思考過程はなく、その様な思弁を表現する記法も
皆無だと強く確信します。
-------
その様な「正しさ」から疎外された条件で、「正しさ」からの疎外を
当たり前の様に受け止め、泥の様に働いても得るものは、気鬱・健康障害
だけだと思います。
そして、それに対抗するために必要なことは、
・プログラム開発を実際に行っている実務者には「正しさ」が
見えない
という正しい認識に基づいた、自分のテスト範囲の限定・責任範囲の
限定です。
(もちろん、その代わり、ソフトウェア開発は永久にプロフット
センターに成れないかも知れませんが、これは人間の限界だと
考えるべきです。)
関数型プログラミングについて殊更に言うの愚 (スコア:1)
関数の良さは、
・テストが出来る
ことも有りますが、
・f()、g()、etc.etc.と書いただけで忘れることが可能
であるのが第一です。
なにせ、容易にテストが可能なのですから、その中身について
深く考える必要は有りません。もし、その中身について深く
考えないとならないとすると、それはもう関数では無いと思います。
関数の悪さは、
・初めにその引数に値を持ってくる手段が無い
ことです。このことを軽く見るべきでは有りません。これの為に、
・ 必要な値(テストをする)⊇ 必要な値(計算をする)
となるからです。初めの引数を得るためには、その値を(必ず)
超えた値が必要になります。
その「超えた」値とは、
・計算を制御する
為の値で、
・関数を上から睥睨する
時に用いる値です。
--------
もちろん、関数を値として考えれば、関数を上から睥睨する関数も
可能ですが、何故か冒頭に述べた「関数の良さ」が無くなります。
関数を値として考え、しかも最大限に見通しを良く書ける様に
記法を工夫すると、なぜか、
・手続き型プログラミング
になってしまうのです。
POF(Pure Old Function)ならいいものを、余計なことをすると良さが
消え、悪さのみが浮き彫りになり、しかも不俱戴天の仇である、
手続き型プログラミングに似てきてしまうという、散々な話です。
ですので、関数型プログラミングについて殊更に言うのは愚という
ことになります。代わりに、
・制御を重んじ計算を軽んじ
・関数については書いただけで忘れる
のが最良で、しかも、そうしたならば、
・良い形の(POFの)関数を、悪さを補う形で得られる
という最良の結果になると思います。