バグがでるはず。出なきゃいなん。てゆうか、出せ

「なんちゃってＰＭ」の条件 - kなんとかの日記さん経由、自分の書きたいコードを書け - 脱職業プログラマのすすめ のコメント欄

（１２）いまどき「バグ密度」とか、小学生でも使わないような言葉を真顔で口にして、誇らしげに、

「ステップ数が○○行なら、標準的なバグ密度からいって、××個のバグが出るはず。出なきゃいかん。てゆうか、出せ」

みたいなことを言って、まるでバグが無いことがイケナイことみたいなことを吠えまくって、開発者を唖然とさせるのが得意。

自分の書きたいコードを書け - 脱職業プログラマのすすめ - yvsu pron. yas

あはっ。そのまんまを聞いて、そのまんま唖然としたことがあったりw

Linusさんにdisられている

tabesugi.netさん より。

ぼくは C よりも C++ をプロジェクトに使いたがるようなプログラマーは、みな *本当に* ムカつかせておきたいようなプログラマーだという結論に達した。

やば。わたしだ。

わたしは、C++は利用者の精神に重大な欠陥をもたらす、そんな COBOL や BASIC と同様の効能を持っているのは本当の事だと思います。でも、C++って、妙に心地よいんですよね。

真のソフトウェア工学は存在していない

と、いうのは単なる釣りタイトルで、本当はJava Lightweight仮説について。タイトルに窮して斜め横にずらしてみたり。

* * *

「簡潔さは力なり」の通り、やっている内容（意味）の複雑さに関わらず、「その表現が如何に簡潔であるか」が 「力」になるのがプログラミング言語です。その裏付けを与えるのが「脳力」です（エーテルみたいね）。

静的型付けOOPLは、脳力の一定量を「コードに型情報を埋め込む作業」に費やします。これは C プログラマが常に頭の片隅でメモリのことを考え続けるのと同じで「脳力」を消費しつづけ（書いている時の「脳力」浪費）、またコードの簡潔さも損ない読みにくい（読んでいるときの「脳力」消費）という、人にやさしくない言語です。

なのに、このどうしようもない言語が表通りで大手を振って歩いているのは、静的型付けのメリットはこの無駄(?)な消費脳力に見合った見返りがあると考えられているから。「急がば回れ」「トータルで考えればコッチのが楽だよね」ということ。凪瀬さんのエントリーはこれを持ってJavaをLightweight としている部分があります（大局的にはLightweight論）。

ようするに「脳力」を「労力」に置き換え可能か、という問題ですが、これは、以前紹介したまつもとさんのLightweight Language の第三定義

• 消費脳力の総和が少ないことももちろん重要だが、瞬間最大消費「脳力」が大きすぎるのもよろしくない

（強調はわたし）

が微妙な表現だから、そうなっちゃうのかな？(なるほどbuzzword）

* * *

静的型付け言語では、静的な情報こそが「本質」とされます。そこから作られる動的なオブジェクトやコラボレーションは所詮影にすぎないと考える。プログラムは覆せない運命に似ています。オブジェクトは運命にしたがって生きるホログラムのようなものにゃ！そう言う考えがうけるのは、プログラムは作成フェーズと実行フェーズが明確にわかれるモノ、と考えるからです。

その場合、実行フェーズではそこにプログラマは居ません。だからプログラマは神様じみた万能さでプログラム（＝運命）を完璧なものにしなくてはなりません。「アカシックレコード」とか、「ティターンズの犬どもめっ！」とか言いたくなります。けれど、人は神のようにはなれないから、そこで「完璧さ」についてよりすぐれたコンピュータ様のお力添えを戴きたくおもい、日々セッセと型について記述します。

一方、動的型付け言語では、まず、「プログラマがユーザであること」からスタートします。「全てのユーザはプログラマである」のほうが伝わりやすいかな？すると神に近づく努力は不要になります。だって、完璧な運命を用意しておかなくったって、プログラムが窮したとき、その場に居合わせた「人」が助けてあげればいいから。（奇跡は自分で起こすもの♪ですよ。）

この場合、プログラムは運用中にチョコチョコ繕いつつ使うモノになります。必要なのは「完璧さ保証システム」じゃなくって、「クリティカルな局面で『姉さん、ピンチです』とユーザに報告するシステム」、つまり動的型です。

こういう風な「自分で使うんだから、自分が一番楽に作れればいい」の楽さ加減を Lightweight と呼ぶのだと思います。踏み台を作ったとき、作るのが楽であれば Lightweight で、極論を言えば、乗ったらぶっ壊れちゃってもいいのだ（大ケガさえしなければ）。

* * *

Lightweight な言語でも、「使い・繕い」を繰り返せは十分な品質を得ることが出来ます。ユーザ≠プログラマなモノを LL で作るのだって現実的です。そうしたとき、Lightweight を追求することが結局はプログラムの品質を上げるのか*1、それよりもコンピュータに正しさを証明させるのか、どちらが良いのかはわかんない。

現実には「静的型付けを使いつつ UnitTestも書く」というなんとも石橋なことをやっているわけで、つまりどちらもまだ「十分な品質」は遙か遠くにあるから、「Lightweight」と「正しさ事前保証システム」のどっちが結局楽なのかについて答えを出せてない。そのこと自体が「未だ真のソフトウェア工学は存在していない」の証なのかもね、と思ったり。（やった！タイトルにつながりました！）

もっとも「静的型付け＝重い」は嘘で、nominal subtyping が重いだけ。これは、コンピュータが人の意図を読み取る為の情報（型とか）と、人が人の意図を読み取る為の情報（名前とか使われ方とか）が一致していないのが問題で、二重記述は簡潔ではない、という単純なお話かも。なら型推論に希望があるのかしらん。

* * *

話がタイトルに引きずられてそれたのですが、元に戻して「Java が LL か」という話。「急がば回れで結局省脳力」は、Lightweightの意味からは外れると思うから、違うとおもいます。けれど、「統合開発環境込みで考えれば Lightweight」についてはよくわからなくって、「もしかしたら」と思っちゃう。だってわたしは Emacs厨でテキストエディタ万歳で、使ってないもののコトは良くわかんないのです。

*1:そういえば、「構造化プログラミング」 は、Lightweight的な嗜好ですね。というのも、構造化プログラミングは、人に頼る品質管理手法で、簡潔さが力を得るのは対象が人だから。そのための（見かけが）簡潔なコードを作るための技が構造化プログラミングであると言えます――とか思いついちゃったり。（今度コレを肴になんか書こう）

途中return問題

について書こうと思っていて、こんな（↓）ものまで用意してたのですが、

関数型言語になれてればguardやpattern matching使いたいよね！

C++とかにそんなもんないよね！

これだけでも関数内のreturn1つにしろとか言われて発狂する理由としては十分だよね！

http://d.hatena.ne.jp/uskz/20090123/p9

そういえば構造化プログラミングでの出口は１つルールは関数内にreturnが複数あるとかじゃなくてその関数の呼び出し側からみた振る舞い（戻ってくる場所が決まってる）のことだと思うんだけれど，ちゃんと勉強したことが無いので後で調べてみよう

http://d.hatena.ne.jp/uskz/20090123/p12

言いたいことを全部言われてしまいました...orz
長門さん恐るべしです。しくしく。

* * *

以下、完全な蛇足。

構造化プログラミングの目的は、可読性の向上によるプログラムの品質向上にあります。なら、心の中に描く制御構造の図に近い字面のコードを書く方が、構造化プログラミングの目的にかなっています。手段にこだわり目的を忘れるのはナンセンス。

あと、出入口一つづつルールについて、ダイクストラ先生の「構造化プログラミング論」の中では

これら流れ図は,頭で1つの入口,尻尾で1つの出口があるという性質を共通してもっています.点線で囲んだ箱が示すように,これらは,(点線の中を無視することにより,)順序的計算における単一の作用として解釈できるようになります.

（強調はわたし）

のように書かれています。カプセルを外から見たとき順序的計算の単一の作用に見えるように出来ることが目的なので、このルールについては「外から見たら」そうであればよい、と解釈して良いと思います。（ちと強引かしら(^^;）

あと、

「ステータスを変更する必要があるかどうか？」を判断しながら「遷移先のステータスを決め」ながら「ステータスを変更する」という。わかりやすく言えば、一輪車に乗りながら頭にボールを乗せてバランスを取りながら焼きそばを食べるという必要性がほとんど説明できないコード。

困った事にC言語系だとこれが普通なんですが、こいつが多くのメンテナンス不能なコードとバグを生み出しているフリーザ級の悪の親玉。

途中でreturnの続き - Return to Saisse’s Wiki

だって Cは手続き言語ですから。だから「ながら」を「て」に読み替えるべし。

パラダイム変われば価値観は変わる。手続き言語でも「ながら」は好ましくありませんが、手続き言語ではこの例は「ながら」に当たらないように思います。そもそも極論OOPの価値観だと、条件分岐は悪でポリモーフィズムせよ！（Stateパターンとか）になるんじゃ...。（Smalltalkを見よ！）

途中return はダメで途中throw はOK という話は、Java の様に例外がとても良く設計されている言語ですとか、Pythonのような「例外をバンバンつかって制御を書いちゃえ」宗な言語では、そういうの全部 throw に置き換えちゃえば OK なので、禁止の害がそれほどでも無いかもしれません。「途中returnを禁止したことにより強調されるコードの腐臭がリファクタリングトリガーに使える」は十分旨みがありそうです。

ですが、ファウラー先生の「リファクタリング」でも、「ガード節による入れ子条件記述の置き換え」で、条件記述のネストを途中returnに置き換えるなど、途中returnは肯定的に扱われているので、たとえOOPという文脈であったって、あんまり一般化するような話でもないと思います。

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)