Worse is worse
Mon May 29 17:20:56 CEST 2006
Bengt Kleberg wrote:
> On 2006-05-29 10:59, Vlad Dumitrescu wrote:
>> I don't know if that's what Richard was aiming at, but my belief is
>> that a tool should make life easier foremost for the end users.
>> Otherwise they won't use it...
> i agree, but then we have this: Worse is Better
Sometimes worse is just worse.
I could not agree more with Gabriel a.k.a. Bourbaki's conclusion:
# But the real quarrel with the ["worse is better"] paper I have is about what
# it teaches people. The paper states that a good strategy to adopt when trying
# to make things better is this:
# ...it is undersirable to go for the right thing first; better to get half
# of the right thing available so it spreads like a virus. Once people are
# hooked, take the time to improve it to 90% of the right thing.
# This advice is corrosive. It warps the minds of youth. It is never a good
# idea to intentionally aim for anything less than the best, though one might
# have to compromise in order to succeed. Maybe Richard means one should aim
# high but make sure you shoot -- sadly he didn't say that. He said "worse is
# better," and though it might be an attractive, mind-grabbing headline seducing
# people into reading his paper, it teaches the wrong lesson -- a lesson he may
# not intend, or a lesson poorly stated. I know he can say the right thing,
# and I wish he had.
About the PC-losering example: there is an obvious "third way", where
a retry loop for each call is abstracted in a user-mode library, so that
applications never have to deal with retries, and the kernel does not have
to deal with the complexity of PC-losering.
This approach, of hiding implemenentation complexity by use of abstraction,
is clearly better than WIB or TRT in almost all other cases, too -- as you
would expect, since WIB and TRT are just caricatures.
David Hopwood <>
More information about the erlang-questions