日々の破片

_ なんとなく注文

動物の森でも買おう（飼おうになるのか？）と思ったけど、WiFiのコードを見てもなんだか良くわからなくてその気が失せてしまった。

で、

ファミコンミニ スーパーマリオブラザーズ(-)

突然、こんなのでお茶を濁したり。というか、CDもそうだが昔やったものを買うというなんの発展性もないばかな消費行動に自分でもうんざりしてみる。

それで、なんとなく眺めているうちにこんなのも買ってみたり。

不思議な数πの伝記(Alfred S. Posamentier)

_ 参考になる+1

航海日誌のコメント欄。

nminoruさんが書かれていることは実感としては正しく思う。最初なんでCじゃないのかと思ったけど、アプリケーション開発のコストを考えるとCは無理で確かにCOBOLということになるのかな、というのは納得しないでもない(*)。またCafebabeさんの冷水を浴びせかけるようなコメントもまた納得がいくものだ。とは言え、僕のスタンスはkeisukenさんの「後は運用でなんとかするしか」に近い（というのは意味するところが違うかも知れないからだが）と思う。(追記：TBどうもありがとうございます。ソース直修正はさすがに考えてませんでした。ちょっと難しいかな。で、とりあえず運用として再起動をスケジュールしておきまずくならないようにするは賛成です。あと僕はイリーガルなケースの範囲設定とリカバリーの手順化といった本当の運用対処の体勢作りも含めたほうが良いかなと。ではなぜそれでもJavaかと言えば結局は(当初はそういう発想はあまり無かったけど)量を解決するためですね。

*)たとえばすべてCならば完全に追いきれるのだが、間にVBScriptが入った場合には追いきれずに参ったことがある（それからなんかすごく複雑なAPI経由のコールバック先で死んだ場合とか）。とは言えCOBOLもコンパイル言語だから、コアと一致する-Sの世界があるから後の解析は楽だとは思う。とは言うもののランタイムがオープンでないと追える自信は無いな……。っていうか枯れているから追いかける必要がないということかも。

そういうレベルで考えると、RubyのほうがJavaより死んだ場合の解析は楽だからより望ましいかも知れない（スタックやフレームがのっぺらぼうにならなければ）。と思ったらCafebabeさんが「組み込み系ではインタープリタしか使わなかったり」と書いているから、最後の手段は同じことなんだろうなとか(でも続くところで最適化を抑制する例があるから違うかも。というかコンパイルしたコードを自由に追える人ならどっちでも良いのか)。

#追記：つまりSunのeverything is openってことか。