2009-08-24
とりあえずSICPに没頭する。
これは損がない。最低でも、英語の勉強にはなる。洋書を読まないやつは人間のクズだ。
研究的な期限は迫っている。遅くても９月の２〜３あたりまでにはプログラムを書ける心構えを作っておかないと手遅れになる。その後には手術が入るし、おれに協力してくれてると言ってくれている先生もいるので、あまり伸ばし伸ばしには出来ない。最悪ケース、今回は理想を追い求めるのをやめて、強引に作って、そしてすべて捨てるというのも選択肢に入れるケースがある。再利用出来ないソフトウェアは存在価値がない。
おれは常に理論高い男だ。すべての問題の解法手順には、根源的、基底的な手順があるものだと信じているし、だからおれは高校生のときにポリヤの本を読んだ。あれを読まないやつは死ななければいけない。ソフトウェアの世界に入ってから、あの本がよく紹介されていることに気づいた。ソフトウェアに携わるものは全員あれを読め、読まないならば、ちんこ切って死ね。それがルールだ。常に高みを目指さなければいけない。
お前らは幸せだ。何にも気づかない。何の真理に気づく直感も得られないし、何の音も聞こえない。バカだから、何の責務も帯びていないし、言ってみれば、常にヤリ逃げしてるようなものだ。お前らの人生はヤリ逃げの人生なのだ。ソフトウェアを作るのは簡単だ。ソフトウェアを作れないやつは完全なる論外人間であり、知能指数が１００ほどあれば、ソフトウェアというものは作れてしまう。しかし、その上を目指そうとするのはごくごくわずかの人間だ。使いやすいソフトウェア、再利用とは何か、インターフェイスはどうあるべきかという問いに答えられるエンジニアは、少なくとも日本には存在しない。アメリカにはいると思うし、フィンランドにもいると思うけど、日本にはいない。
レベルの低い戦いに巻き込まれたくない。とりあえず先生に、SICPを読む権利は与えてもらっているはずだから、雑音に惑わされず没頭する。おれの悩みはおれにしか理解出来ないことになってしまっているし、誰に相談しても絶対に解決出来ない、また、自分自身、他人に説明することが出来ない。おれの頭の中で高度に抽象化されすぎていて、人間の作り出した言葉では説明出来ない。SICPを勉強することで気が紛れるならばそれは良いことだ。気が紛れるといった。そう、おれはSICPに何の期待もしていない。この本がおれに与えられるのはいいとこ、英語の勉強と、プログラミングの楽しさくらいだろう。おれの苦悩を解き放つ方法なんかない。
バカの方が幸せ
天才すぎたら幸せではない。天才は常に不幸だ。
バカなら何も気づかなくて生きていけるし、苦悩することもない。悪いということに気づかないというのは素晴らしいことだ。
お前らは幸せだな。幸せになれよ。おれはふつうの人生は送れない。不可能だ。
お前らは幸せだ。
逆に、それは不幸だ。
その差は、頭の良さだ。
ほどほどに頭が良いのが良く、おれのようにぶっ飛んでる人間は常に不幸になる。
悪いことを悪いと気づいてしまった途端に、ソフトウェアは苦痛になる。唯一、おれに真理を与えてくれるのは、関数型言語だ。これには自由がなく、常に一貫性のある設計が出来る。オブジェクト指向は人類の失敗であり、優秀な人間は手を出してはいけない。これは警告なんだ。結局、イライラすることになる。
精神病を患った天才の朝は早い
正直、眠れない。
ソフトウェアに手を出したのは、失敗だった。
これは頭の悪いやつのやることで、天才のやることではない。
お前らのように、極めて知能指数の低い池沼がすべきことであって、おれのような天才はこういう分野では生きていけない。おれはこだわりすぎる。悪いところが見えてしまうから、こだわる。お前らはバカだからそれに気づかない。お前らは本当に幸せだし、その幸せをもっと大事にした方がいい。
どこかの拍子に自殺するかも知れない。
天才は美しさを求める。ものごとの対称性、一貫性、歪みなさを求める。ソフトウェアにおいて美しさを求めることは苦痛だ。
バカは気楽でいいな。
お前らは全員気楽だ。
何も分からない。何も見えない。だから悩むこともない。
他人を批判することもないだろうし、教授に楯突くこともない。
それならば、何も苦しみはないし、悩むことはない。さぞ楽しい人生だろうな。バカは気楽でいい。
バカならば、ソフトウェアは容易に書けるし、何も悩むことはない。可変性が危ないということに気づくこともない。それは非常に幸せなことだ。
手続き型パッケージのソフトウェア境界
おれは、頭に来ている。何にって、おれの頭の良すぎさにだ。学生の分際で、しかもソフトウェアについて研究しているわけでもないのに、なぜここまで気づいてしまうのか、おれは自分が頭が良すぎるゆえに苦悩している。これは事実だ。多くの天才がそうだったように、おれも特定の分野に取り憑かれ、ノイローゼになってしまっている。あぁ、バカは気楽でいいな。何も分からなければ、それだけで幸せになれる。ほどほどに頭が良いのがもっとも良い。飛び抜けて頭の良い人間は、社会不適合になるし、おれのように悩むことになる。
手続き型というのは非常に不自然だ。突っ込んだものが変わるというのは不自然以外、何ものでもない。しかし、仮に手続きを否定すると、オブジェクトを否定することになるのだ。おれは、オブジェクトは良いが、手続きはダメだと思っているのかも知れない。まったくもって、意味が分からない。
手続き型の設計として、一つのポイントは、継承を許すか許さないかということだと思う。継承を許せば、ほとんどの問題は解決する。しかし、一般的に、継承はリスクでしかない。
コピーは一つの方法だ。
copyvalue(myobject, procedureobject); procedure(procedureobject); copyvalue(procedureobject, myobject);
あほかと。
理由は２つある。
- コピーでパフォーマンスやメモリ効率の劣化がある。
- （もっとも重要）なぜ入れたものをまた返すようなコピーをクライアントが２回書く必要があるのか？
前者は、現代の優れた最適化技術でどうにかなるかも知れない。しかし、後者はどうにもならない。後者は、どうしても開発者が書かなければいけないコードだ。
単純なリスト処理であれば、これは大した手間ではない。しかし、木構造であれば、これは結構な手間になる。ファクトリを抽象化したコピーメソッドを実装しておくという手はある。しかし、それでも手間ではないか？おれは手間だと思う。
だから、手続きに必要なデータは抽象化した方がいい。これは、手続きが依存するデータを公開するということはすなわち、オブジェクトが自分のデータをパブリックにするのと等しいということを考えるとそう言えると思う。
だが、それでもおれには分からないことがあるのだ。
JTreeの設計とJava3DやPiccoloの設計思想
ともに、データありきで可視化するというものだ。
JTreeが仮に、TreeNodeを使ったインターフェイスしか提供していなかったら、おれは、両方に差は感じなかった。
これらは手続きではなく、作っているのは、可視化のためのモデルなのだから、何の文句もなかった。
しかし、JTreeはTreeModelを公開している。これによりJTreeが使いやすくなっているのは確かだが、なぜJTreeはこのようなインターフェイスを公開出来て、Piccoloは違うのか。これが全く理解出来ない。
JTreeは必要としているものが簡単であり、正確にいうとモデリングではない。木の構造のみを見ているだけだ。それが違いだろうか。大して、Piccoloなどはシーングラフというモデルの作成を行い、そこには座標値や色などのデータを必要とする。立派なモデリングだ。
早く手術したい。
手術すれば、おれは神になれる。
その結果、悩む悩まないという領域を越えて、すべて分かってしまうという領域に達することが出来る。
手術をしたら、おれの性格は変わるから、恋人も出来るし、より絶倫になるから、毎日10回はいける。
早く手術がしたい。何もかも変わるはずだ。
ソフトウェアは苦痛すぎて、もうダメだ。
大体の話だが
C言語では手続きを
void procedure(src, dest);
のような形で書くじゃないか。この時点で、メモリがダブってるじゃないか！！！出力用の箱を用意してるんだから。え、なんでこんなことになってる？
手続きと生成が、実は同じ関数としてまとめられるのではないか。
つまり、この世にはデータと、関数しかない。
例えばだが、JSONを読み込む。そしたら、gsonでは、JSONObjectというものが出来る。一般的には、これを自分領域にコピーする、それから処理を実行する。
しかし、これはメモリのロスではないかっ！！！読み込んだ時点でメモリが割かれてるんだから、それを使えばいいじゃん！！！
でも、一般的にこれはされない。
この形は、
JSONObject jsonObject = function(jsonData);
という形だ。手続きというのは、
procedure(data);
という形だ。これを
data procedure(data);
と書き換えると、dataというものを種にして、問い合わせたら、dataというものが返ってきた、ということになる。これは、サーバへの問い合わせなどと変わらない。例えば
data request(url, proxy, requestMethod);
としたらたまたまデータが返ってきたから利用しようぜ、って感じだ。これにガチで依存する神はいない。
よって、一般型として
結果 function(種);
という構造が導ける。
つまり、不変の種をあげたら、不変のデータが返ってきましたが何か？ということにすれば、すべては万事解決に違いないのだ。
Schemeのような言語では、この返ってきたデータすら関数にしようとするので意味不明になるが、それによってネストが深くなりすぎているので、データは分離すべきだ。
いあ
無理だし＾＾；
あぁ、どうすればいいんだ。
もっとバカに生まれたら良かった。
実装に依存しても平気だお＾＾くらいのあんぽんたんに生まれていれば、何の悩みもなかった。失敗した時に、なんでだろとも考えずに、こんなもんだろと割りきれるくらいの頭の悪さだったら、おれは何も悩まなかっただろうし、いちいち致命的な欠陥に気づくこともなかった。
やっぱ、値のコピー、処理、値を戻す、というのが現実的なのかな。なんかうまい方法が見つからないし、この方法は、もっとも設計者の心を癒してくれる。依存は局所化されるし、失うのはパフォーマンスだけだ。ただし、百万個のリストをコピーするとかいったらどうするんだろうか、もう耐えられない。しかし、たかだかメモリが2倍になるだけだ。線形じゃないか。理論的にいえば、何の問題もない。コピーも、リストの長さnに対してたかだかO(n)だ。初期条件として確かに同じようなリストに値を与えていることを考えると、これは絶対にオーダを悪化させないことが保証される。パフォーマンスの劣化はありえないし、メモリ効率も劣化もありえないという結論に至れる。
本当か・・・？うさんくさすぎる。うさんくさいにもほどがある。また、これでは、中で使っているライブラリの挙動を変えることが不可能になる。つまり、そのライブラリに直依存の抽象を設定することになって、一つのパッケージに違う概念が２つ存在することになる！！！信じられない・・・。ソフトウェアの欠陥だ。これは動的言語だろうと同じだ。
寝てた。
頭が痛くて。
そして、気づいてしまった。
パッケージの内部実装の層を使いやすい抽象でラップして、内部実装をその抽象に依存させて、外から抽象にアダプトさせたのち、抽象を内部実装に流し込むという設計をおれは、最強の設計だと思っていた。少なくとも手続き型としては。
しかし、おれは、致命的な欠陥を発見してしまった。それは、この設計では、内部実装に対する戦略が定義出来ないということだ。
- ユーザは内部実装にどのような形で抽象を流し込まれたのか知らない。
- よって、抽象を変化させても、どのように内部実装に響くか分からない。
- さらにいうと、そんなことは、そもそも実装不可能。
ということから、不可能という結論に至った。例えば、以下のような設計をしよう。
Transformer t = new Transformer(); List<AbstractShape> abstractShapes = new ArrayList(); // lに適当なAbstractShapeたちを突っ込む。 t.transform(abstractShapes);
この内部ではこのようなことが行われている。
t.transform(abstractShapes){
// 流し込む List<AbstractShape> to List<ConcreteShape> 一つずつ
t.transform(concreteShapes);
}
これで、外のabstractShapesに内部での操作が響くというわけだ。
この実装はうまくいく。少なくとも、戦略性のない、おれのpackingパッケージについてはうまくいった。
さて、このTransformerについて戦略を定義したい。
interface HowTransform{ void transform(AbstractShape as); }
これをどうやって中のConcreteShapeに響かせればいいのだっ！！！くそがっ！！！
これはかなりファッキンな話だ。今気づいた。そして絶望した。
手続き型のパッケージの再利用方を間違ってしまったのだと思う。いや、まだはっきりと確かめたわけではないからなんとも言えないけど、おれが何ヶ月か前に言ったとおり、手続き型はやっぱり継承によって使うべきだ。あるいはコピーをすべきだ。そのためのコストはもう我慢するしかない（瞬間的に同じようなオブジェクトが２つ存在してることになり、メモリは爆発する）。
多くの手続き的なクラスがそうだ。例えばマトリックスクラスなどはガチで依存するか、あるいは値を流し込んで、計算したものを、自分プロトコルで返してもらうかしかない。
ん・・・もしかしたらパッケージの境界でさくっと切ろうとするからやばいのであって、少しこちら側に侵食させるくらいのバランスをとれば、ノーダメージで済むのか・・・？
あなたはかわいそうですね。
琵琶湖に沈めるぞコラ
http://ja.wikipedia.org/wiki/%E6%A1%82%E5%B7%9D_%28%E6%B7%80%E5%B7%9D%E6%B0%B4%E7%B3%BB%29
短時間？