幻想のプログラマ

PCの前に座っているプログラマのみが開発をしている。
これは幻想です。PCの前に座っているのは、しようがなくコーディングをしているときだけです。基本的には遊んでいるように見えます。ええ、見えますとも。
別に会社に来なくても開発は出来ます。ただPCの前に座っているほうが効率がいいのは確かです。だからといって、仕事をしているわけではありません。精神的欠席って奴です。場合によっては精神的退社ですよｗ
熟練プログラマはどんな状況下でも開発が出来る。（ただしコークのない世界では無理かもねｗ）それでは非熟練プログラマはどうすれば開発が出来るのか？そりゃ、長くPCの前に座って、しかも集中できる環境でしょうよ。（それがベッドサイドかもしれないし、公園のベンチや喫煙所かもしれないｗ）
開発の経験のない人は、その姿を怠惰だという。まぁ、リラックスして仕事をしていると怠惰だといわれるならそれはそうかもしれない。でも首が絞まる紐を首にぶら下げて、窮屈な白い拘束具をきて腰の痛くなるイスに９時間座っていることが仕事というなら、それも良いだろう。まぁたいていの人は嫌がると思うが。（もちろん私も嫌だｗ）
本来重要なのは、生産物であり、その過程を評価するにしても、それは効率のよいやり方の追求に関してであり、高品質の生産物を生成する過程でリラックスタイムがいくらあってもそれは咎められることではない。それを批判するのは、「苦痛によっているマゾヒスト」が普通の人間に苦痛が快楽だと自分の性癖を押し付けるようなものだ。世の中には「苦痛を与えて苦しめるのが好きなサディスティックな上司」というものもいるが、私はそれも嫌だ。（もっともSとMの相性は抜群なので、そういう組み合わせは幸せになれるだろうがｗ）
もっともそのような苦痛でソースコードが洗練されることなどない。あるのは、みにくく、保守のしにくい奇形コードを納期に間に合わせるために生成することだけだ。プログラミングは知的生産であり、職業小説家のようなものだ。それも頻繁に合作をする作家集団だ。こいつらに早く書けといっても、書ける訳がない。売り物にならないものがほしいならDummyデータを葉注すればいい。みんなよろこんで、凝りに凝ったDummyデータを発明するだろう。

重要なのは、互いに強力や連携を必要としている事実だ。プログラマは生産を担当しているので、納期を極力守る。また守るのがよいことだと思っている。しかし明らかな短納期については、事情が違うが、頑張る。なぜならプログラマは自発的にはどこまでもマゾヒスティックだから。しかし他人から強制されることに対する拒否は強い。特に非開発者の無理解な注文や怒声には。
非開発者があせるのは分かる。彼らはなにも自ら作るすべを持たないからだ。もっとも持っているときには、よりあせるのだがｗ

本音を語る？

本音を語る。
そう語っている時点で嘘かもしれない。そのことを明言しなくてはいけないことが悲しい。


間接的利害関係にあるものには本音を決して語ってはいけない。本当に利害関係にあるものに対して、それを語ることは実に狭い中で物事が解決するので、いらない心配がいりません。でもほかの誰かが介入したときには、その発言は訂正や補足ができません。

いまさら気づかされました。

だから私は本音を語ると言って、語るもので「本音」であるものは何もないのです。もはやあるのは、本音を語ると言って、誰かを誘導するための言葉のみです。本当はそういう振る舞いをしたくはないのですが、意図しない局面で秘密を公開されることを防ぐには、公開されている言葉について管理するしかないのです。誰しもが、他人の利益を守るようには振る舞ってはないのです。秘密の共有は仲間を増やすためには必要ですが、それがアキレス腱や弱点になるぐらいならば、いっさいの不利な要素を公開する必要性はありません。

なにもこれが不誠実だとは思いません。もし誰かがそれを言うならば、「私の本音が意図しない形で他人に伝わるかもしれない可能性を考慮せずに他人の発言を引用する貴方の存在が不誠実だ」と言わざるを得ない。むしろこのようなことを考えもせずに生きているくせに不誠実を語るなと「本音」をぶちまけたくなります。そして何も考えていないからこそ、わたしの発言の真意は結局は伝わらず、頭の固いやつということになります。他人に自分の発言が理解してもらえると期待する私のありふれた期待はもろくも崩れ去るのです。
よく考える人は、よくよく自分から発言することを嫌うのだなぁと思います。他人に言質を取られる不測の事態を防ぐには、それが一番です。

もはや酒など飲んで自身の正体を失う価値もなく、他者と「本音」で語り合うなど無意味です。私はそれを語りませんし、相手がそれを語るからと言って、私が自身の本音を語るべき理由になりません。問題は相手が何を語るのかです。それを誰一人、相手ですら保証できないのですから、自身を守るためには誰かに何一つ本音を語る理由がありません。

私が語れる本音とは、まったく業務に関係ないことや、自身の趣味の話、プログラミングの手法、設計や言語特性しかありません。他人はこのような私を「面白みのない人間」と評するでしょうけど、それを説明しても理解されると思えないので、またわかったとしても、本当の意図、「誰にもしゃべらずに墓場までもっていけ」を解してくれるとはまったく思えない。
だから私は他人が心底どうでもいいです。
だから「ファミリー」と自分が認めるものへの協力や援助は、無尽蔵です。
私はXXXxの人を「ファミリー」だとはいっさい思いませんけど。。。

C++における所有権

どうもJudaです。
今回はC++の所有権の問題について。この話は開発者にとってはもはや古典的であり、解決策も見つけられた基本的な事象です。
そのことについて、少しだけ反省交じりの後日談を書きます。

C++における所有権の問題というのは、アロケーションに関する問題である。つまりは動的領域確保によってヒープ領域に作られた領域を誰が所有して、それを最終的に開放するのかという問題である。
これに関しては、C++は特に何もしてはくれない。ただnewとdeleteをキーワードとして提供しているにすぎず、管理してはくれない。
大規模プログラムになるとこの問題はソースコードのモジュールごとの凝集性や普遍性の問題のなかで爆弾となる。誰がその領域を開放するのか。
この問題に対する解決策はすでにあり、BoostのSmartPointerなどを参照してみるのが、一番よいだろう。
この問題に対して、どのように考えるのかということを少し提起したい。
領域の開放をしないと、いつまでその領域が使えないという特性をもっているので、そのような領域でないという前提を排して、誰がという点に焦点をあてて考える。

・明示的にプログラマ
・暗黙的にプログラマ
・明示的にアプリケーション
・暗黙的にアプリケーション

軸を明確にすると設計者か実行環境か？あるいは言語特性か、特性ではないか？

C++という言語に話をあわせると、言語特性として、確保された領域を管理はしていないので、特性ではない。また実行環境でもこの開放をサポートしているのか、していないのかは、不明確だ。故に、プログラマに任されている、現状は。
しかし、この明示的にという部分は確かに多くの制御の自由が与えられているので、それはとても助かる。しかしこれは煩雑さの元でもある。抽象度の関連で、この領域の開放はより機械よりのアプローチである。期待される動きは、誰も使わなくなったら解放する、である。
そうであるので、このためには言語特性ではないので、ポインタをクラス化して、一枚層をかませるのである。これがスマートポインタにあたる。これによって、生のポインタと実際の使用している局面をつなぐクラスの必要性が理解される。また、この中間層の発明によって、より柔軟な解放シーケンスを提供できる可能性を提示する。
Boostの優良なライブラリの機能であるSmartPointerを知っておくことは実に重要だ。どこでも好きにつかえるライセンスだけど、中身を知っておく、使い方を知っておくことはとても有意義だ。まぁ、それが意外に大変です。なぜ基本的に与えられていないのだー。

そして実にC++という言語は、自由だ。（ｗ
自由すぎて、涙でる(ｗ

C++というものが如何なるものであるのかということに対して、最近の私は一つの信念をもっている。それは、C++は荒れた大地を提供するもので、そこで利用するものは神であるプログラマが多くを提供する必要があり、それを用いて構築物を作るしかない。
C#は、森を提供してくれている。だが荒地を使うには、煩雑で一度森を焼かなくてはならない。
この違いの表現は使ったものなら分かってもらえると思う。C++も神としてのプログラマが世界構築になれているなら、多くのものははじめから持ってこれるが、それは本当に万人と共通なのかどうか、という点では無理でしかない。

洗濯

洗濯という行為すら奥が深い。

クリーニング屋という専門職の存在を人々は軽視している。洗濯という日常の作業の専門家ということで大したことがないと思っているのだろう。でももっとも洗濯に精通しているのはクリーニング屋だ。
洗濯は汚れを落とすことが重要である。汚れを落とす。これは簡単なように見えて難しい。たとえば、ワイシャツの汗じみ。地味な例であるが、これほどクリーニング屋の技術の高さを知ることはない。あの黒い線のシミ。洗い上げの洗濯にあの線が残っているときの敗北感を理解いただけるだろうか。別のものでいうと血液のシミ。このシミもただ洗い流すだけでは黄色のまだらが残ってしまう。洗濯後に汚れが落ちていないときの失望は計り知れない。
日常的な洗濯という行為も満足に出来ないことは非常に不満だ。この問題を解決するために私たちに出来るのは、さまざまな洗剤や方法を試して汚れを落とすことである。もう一つは専門家に頼むことである。
いかな主婦主夫といえどもクリーニング屋に匹敵する洗濯テクをもつものはそうはあるまい。掃除も然り、料理も然り。
だから、これが出来る人が好まれることは本来必定であろう。日常におけるささいな行為のそれぞれを正当にやって見せること。これほど本来は賞賛させるべき行為はない。あるべきものがあるべき姿であるということは、それが日常的であるほど、行為の価値に対して反比例して評価されない。
仕事が出来るということはそれによって社会によりよく貢献しているという程度の意味しかない。本来的に全体的なパイの絶対量は変化しない。人々はそれをただ切り分けているだけだ。金銭はそれに付帯する評価と渾然一体の対価である。だからそれが普遍化すれば、評価は落ち、対価として手に入れられる金銭は目減りする。
だからこそ人は常に目新しいものを探していく。しかしここで忘れてはならないのは、評価の下がったそれが不要にならないことである。誰か何らかの形で代替していくものである。日常に溶け込んでいったものの中にもそれは多い。正しい評価ということをいうのであるならば、日常品の有用性やその価値、その意義を何度も語るべきである。それは不当な評価というものだ。しかし評価の本質は不平等だ。AがBより優れているという形でしか評価は成立しない。絶対の基準など一切役に立たない。そんなことを語っても、一向に「等しく」評価されていることにはならない。
もし仮に誰かが正義や等しさを語るなら、語られなくなったものについても語るべきである。語られているもののみで世界は出来ているのではない。AとBの対立軸では単純すぎるのだ。A、Bと変則的な非ABがあるのだ。A、Bにうまくはまらない物事一般という第三領域が。そしてA,Bよりもそれははるかに大きい。

洗濯という行為は、掃除という行為は、尊いのだ。またここで語られない多くの業も尊いのだ。だが遍く尊いということは、何一つ特別なものがなく、どれも尊くないのだ。でもここで注目すべきは、その尊いのだとおもう傾向性だ。これだけが前者と後者を分断する。なにも定点的な考えが全てではない。時系列的な「厚み」を持った判断というものも重要なのだ。

自分を捨てることの大切さ

他人の構築したライブラリを読んでいると、
どうしても
「どうしてこんなに効率の悪いアルゴリズムを採用しているのだろう」
「このアルゴリズムはすげーかっこいい」
とか価値判断が含まれてしまいます。

価値判断というのは、
このコードのほうが正しいという感覚を持たせてしまいます。

しかし他人のコードを読むときにはこの感覚は危険です。
正しくそのライブラリの意図するところを理解できないし
自分のもっている尺度のせいで
正しくアルゴリズムを理解するときの障壁が多くなります。

このときには、進んで自分というものを押し殺す必要が出てきます。
他人の考えを推測するというのも読解を早める効能がありますが、それが間違っていたときの代償が大きすぎます。
だからとりあえず自分を捨てて、没入することが必要だと考えます。

んでもって、学生さんは他人のソースコードを読むことになれていないので、
他人の読みやすいコードを書くという感覚がない。
これに関しては、日本の様々な技術者が言っていると思いました。

んで、一人でもできる他人が書いたように感じるソースコードの用意の仕方。
単純に自分が書いた古いコードを最後まで読んでみる訓練をすればいいと思う。
そのときに、つけたコメント基準が自分の欲しいと思うコメント基準だし、
たぶんそれをくりかえず度にソースコードのまとめ方もわかると思う。
ただしこれには時間がかかるので、学生の学習向きではないのかもしれないけど、
効果的なやり方だと思います。

時間差レビューマジおすすめ！

C++におけるカプセル化

C++はカプセル化することはまったく考えられていない。としか思えない。
Headerにprivateなものを記述してしまうとそれは内部に持っていることを宣言しているのと変わらない。ただアクセスは出来ませんという意味しかない。
C++のHeaderを渡さないと変数のMapが分からないという性質から、仕方がないけど、privateなものの宣言にははなはだ向かない。
ということは、C++はデータの構造をさらすことを重要と考えるほかない。基本はstructでしかないので、そのことを念頭において考えると、データの凝集性と抽象度が重要に思える。そして何よりもPropertyなどのカプセル化に関して重要なパラメータのためのインターフェイスはおいておかれているので、片道的なアクセス方法以外を宣言する必要性がない。そして、あまりにプロパティの宣言が煩雑なので、関数の内部で、自身が使う変数が妥当であるのかということを調べる共通の関数を作っておくべきであろう。
あとは関数についてはあいまいさがないようにすべきである。内部を全て知ってもらうつもりでないならば、なおさらである。関数の動詞部分と修飾部分で動詞と判断できるものが重複していると混沌を極めるのでこれに留意したい。

また別件だが、TextEditorを買った。
MIFESというMEGASOFT社製の製品である。DOSの時代からの古参である。
従来のポータビリティとライセンシングとの関連上フリーのテキストエディタに比べて使いにくいかなぁと思う。しかし強力な検索機能やカスタマイズ性があるので、トレードオフかなぁ。
ただ表示の美しさは驚きに値する。
正直な話、Editorとしての機能をVSが開放してくれるといいのですけどね。

足りない。

全ての努力が水泡と化していく感覚が私を苦しめる。ただ、走り続けることでしか、保てない。