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