namazu-dev(ring)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
worse is better? (Re: abolishing ja_JP.ISO-2022-JP support)
余談です。
Kenji Suzuki <kenji@xxxxxxxxxxxxxxxx> wrote:
>> いかがなものでしょう? ご意見くださいませ。
>
>EUC でいいと思います。
>実際問題として文字化けしたことはありません。
>
>実装が複雑になる方が好ましくないと思います。
The Rise of "Worse is Better"
<http://cl.aist-nara.ac.jp/~daiti-m/text/worse-is-better-ja.html>
| "悪い方がよい"原則はこれと少しだけ異なる:
| * 簡潔性
| デザインは実装と使用法の両面において単純でなければ ならない。このと
| き、実装が単純な方が、使用法が単純なことより重要 である。
| 単純さがデザインにおいて最も重視されるべき事柄である。
| * 正当性
| デザインはすべての点において正しいものでなければならない。 ただし、
| どちらかといえば、正しいことよりは単純なことの方が重要である。
| * 一貫性
| デザインは一貫性を大きく欠いたものであってはならない。 単純さを保つ
| ために、一貫性は犠牲にされることがある。しかし、 あまり起こらない状
| 況に対応しようとして実装を複雑にしたり一貫性を欠いた ものにするより
| は、それを捨てる方がよい。
| * 完全性
| デザインは実際に起こる重要な状況にはすべて対応できなければ ならない
| 。普通に起こると思われる場合はすべて扱えるべきである。ただし、 他の
| 条件のためならば完全さはいつでも犠牲にしてよい。さらに、 実装の単純
| さが失われる場合には完全さを犠牲にしてもそれを守るべきで ある。単純
| さが保たれるならば、完全なものにするために一貫性を犠牲に してもよい
| 。
| 何より意味がないのは、使用法の一貫性を守ることである。
を連想しました。:-)
最近は eXtreme Programming <http://www.xprogramming.com/> な
る方法論が流行っているみたいです。本が売れています。
<http://www1.fatbrain.com/bestsellers.asp?currsubcode=TOP&vm=c>
-- Satoru Takabayashi