アカウント名:
パスワード:
> そしてトピとは関係ないですがソフト面でのデザインミスを1つ。> かつてのコンピュータで、年の値を西暦の下2桁でしか保持していなかったこと。「致命的」という点ではむしろこちらのほうこそトピにふさわしいと思います。みんな「致命的」のハードルが低すぎ。
のちのちそれが大きな問題になるわけですが、そのうちそのソースは更新される/置き換わると考えて設計されていたとしても、不思議ではありません。 メモリの占有率や実行速度の為にバイト単位のチューニングをしたりしていたのはそう遠いむかしではない気がします。 そういったことをガリガリやって性能を出すように日々頑張っていた方々のお陰で今があるようにわたくしは思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
デザインミスなのかどうかは知りませんが (スコア:1)
そしてトピとは関係ないですがソフト面でのデザインミスを1つ。
かつてのコンピュータで、年の値を西暦の下2桁でしか保持していなかったこと。
Re: (スコア:0)
> そしてトピとは関係ないですがソフト面でのデザインミスを1つ。
> かつてのコンピュータで、年の値を西暦の下2桁でしか保持していなかったこと。
「致命的」という点ではむしろこちらのほうこそトピにふさわしいと思います。
みんな「致命的」のハードルが低すぎ。
Re:デザインミスなのかどうかは知りませんが (スコア:3, 興味深い)
西暦の下2桁になっていた理由は、ミスというより当時の状況がそうさせた、と考えると理解し易いと思います。
現在のようにUSBメモリが数千円で16GBなどという状況ではなく、
一部屋埋め尽くすような、汎用コンピュータ(IBM 370-165)ですら、主記憶最大3145KB、磁気ディスク装置800MBです。
データのバイト(Byte)単価を考えると、生年月日や、決済日などに出現する19xx,19xx,19xx……は、最も削りたい冗長なデータであると考えられます。
もちろん当時のJIS規格(わたくしの持っている資料が古いのですが)C6262-1970でも、
日付のコードは「YYMMDD」「YYYYMMDD」の両方を規定しています。
のちのちそれが大きな問題になるわけですが、そのうちそのソースは更新される/置き換わると考えて設計されていたとしても、不思議ではありません。
メモリの占有率や実行速度の為にバイト単位のチューニングをしたりしていたのはそう遠いむかしではない気がします。
そういったことをガリガリやって性能を出すように日々頑張っていた方々のお陰で今があるようにわたくしは思います。
/* Seeds */