「ソフトウェアにはまず最初に変わらない仕様がある死んだソフトウェアと、際限なく修正される生きたソフトウェアがある。前者ならドキュメントがソースに先行すべきであり、後者ならソースがドキュメントに先行すべきだ。」
(via atm09td)
風速25ｍがどれだけやばいのか？
平均風速 20m/s以上25m/s未満
●人への影響
しっかりと身体を確保しないと転倒する。
●屋外・樹木の様子
小枝が折れる
●車に乗っていて
車の運転を続けるのは危険な状態となる
●建造物の被害
鋼製シャッターが壊れ始める。風で飛ばされた物で窓ガラスが割れる
プロセッサの機能を物凄く端折って言うとメモリ（ポートも含む）操作とレジスタ操作の2つしかない。 どんなシステムでも結局はその2つの機能のバリエーションを如何に組み合わせるかってことに帰着する。 凄く単純な話だ。 構造化もオブジェクト指向も人間側の都合で語られるおまけでしかない。 プログラムは何のために書く？ もちろん目の前にあるプロセッサを思い通りに動かすために書いているのだ。
私はこのシンプルさが好きで（間でいろいろ寄り道しながらも）制御系の世界に16年以上もしがみついている。 そういう私から見ると Ruby や Perl 等の言語は想像を絶している。 というかプログラマとプロセッサの間が透過的でない言語（もちろん言語屋さんにとってはどんな言語も透過的なんだろうけど）をみんながごく自然に受け入れていることに脅威を感じてしまう。
[鏡] しっぽのさきっちょ 2006年03月 — Spiegel’s Trunk
若さ溢れる記事。つってもこの時点で既に40歳超えてるけどw
当時は車載用の組込みプログラムをバリバリ書いてた時期なのでこんな内容になっている。リーマンショック以来組込みエンジニアはあぶれていて（最近は少し回復ムードだけど）私のような辺境の流しのプログラマはそれだけでは食っていけないので PHP なんかやってたりするわけだ。
PHP や他の「今時」の言語を使ってて思うのは，これからのプログラマはコードの文脈（context）が読めないと使いものにならないんだろうな，ってこと。たとえばあるオブジェクトが特定の処理の中でどのように振舞っているのか，といったことだ。
「な～にアタリマエなことを言ってるんだ」と思うだろうが，組込みでは，あるオブジェクトが複数の状態を持ち文脈によって振る舞いを変えるという設計はあまりしない。バグを発生させるもとだからだ。 “a” というオブジェクトが時に真偽値だったり時に文字列だったり時に数値だったりはしないのだ（ステータスエンジンのようなインタフェースとして働くオブジェクトは別だよ。ステータスエンジンはオブジェクト指向以前からあるけどね）。それは悪い設計と呼ばれる。でもアプリケーションの世界ではあるオブジェクトが唯一の文脈しか持たないなんてまどろっこしいことの方が逆に珍しい。
プログラムは「ロジックを組む」タイプと「振る舞いを記述する」タイプに2極化していくのかも知れない。と，解釈し直すのなら，上述の日記もそれほど外していないのかも知れない。
実は「記述する」ことには「記述しない」ことも含まれる。振る舞いを記述しないことも「記述」なのだ。こうなってくるとバグの意味が変わってくる。「ロジック」が重視されるプログラムはそのロジックからの逸脱がすなわちバグだけど，「記述」に依存するプログラムはそれがバグかどうかはにわかには分からない。それは使われてみて初めて分かる。使用者が満足する振る舞いが「良い記述」であり，使用者がよしとしない振る舞いはバグと呼ばれるようになるだろう。（たとえば先日「はてな」がブログパーツに Web Bug を仕込んでいたことが発覚した件だが，ユーザから見ればこの Web Bug はバグなのだ。ええい，ややこしいw）
もう一歩話を進めてみるなら（それが正しいかどうかエンジニアだけで決められないのなら）「正しいコード」というものにも意味がなくなる。それが正しいかどうかは作り手と使用者の関係の中で決められるからだ。同じコードでも時に正しく時にバグだったりするわけだ。逆に言うならどこまで「機械の間違い」を許容出来るかがその製品の善し悪しを決めるといっていいかも知れない。
(via spiegel-im-spiegel)
(via atm09td)
