
The Rise of "Worse is Better" - wslh
http://www.jwz.org/doc/worse-is-better.html
======
RyanMcGreal
_A complex system that works is invariably found to have evolved from a simple
system that worked. The inverse proposition also appears to be true: A complex
system designed from scratch never works and cannot be made to work._

\-- John Gall

------
baguasquirrel
You know, this almost reminds me of the ML vs. Haskell debate. I remember
fondly, hearing the 15-312 kids talk about how ML is right and everything else
is wrong. The CMU PL dept was kind of adorable that way.

One of the classic examples is Haskell's typeclasses. Haskell's typeclasses
are kinda kludgy because there's no way to provide more than one instance of a
typeclass. ML's functors are way better.

But as it turns out, most of the time, we just need one instance. It's much
simpler to invoke, and much easier to understand. If you need more than one
instance, then use newtype.

In the end, we wouldn't be where we are in PL without the crazy folks at CMU
and Bell labs. So I feel no small amount of sadness that ML didn't win. I
concede the notion that ML may have made better design choices. But what
matters more to me is that elements of FP get into the mainstream. Here,
Haskell has done a better job of showing what is good with FP.

~~~
gfodor
You have to concede it's a bit funny that you're pointing to _Haskell_ as an
example of the 'worse-is-better' approach that leads to viral adoption of
dirty solutions over the endless pursuit of perfection.

~~~
cageface
Haskell is _much_ more "MIT approach" than "New Jersey approach". For a better
example, consider how the quick & dirty hack that is Javascript is now far,
for more commercially important than the entire FP language family combined
(although, it's worth noting, somewhat inspired by FP).

~~~
thesz
As of importance, I boldly compare JS to Middle Ages' plague.

It is very important but not the way it helps.

~~~
tmp43522
So one of the first languages with closures to get _huge_ mainstream
popularity hasn't helped? right...

~~~
thesz
Closures are too small an addition comparing to huge step back in semantics.
Side effects in JS are irrepressible.

------
william42
Richard Gabriel's thoughts on the whole thing:
<http://www.dreamsongs.com/WorseIsBetter.html>

~~~
justincormack
I think this _is_ Richard Gabriel's thoughts, it is signed rpg@lucid.com at
the bottom... which certainly isn't Jamie.

~~~
william42
Well, yes, but what I linked is more recent.

------
rwmj
This precise issue in Unix/POSIX causes a huge headache. I wonder how many
thousands or millions of "xread/xwrite" loops have been written in user code
to retry failed read and write calls, and how many of those loops have bugs?

Look at gnulib to see how hard it is to get these loops right:

[http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=li...](http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/full-
write.c;h=b94f95fbb1f576cbde541e0fc4f965a624eb7028;hb=HEAD#l51)
[http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=li...](http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/safe-
read.c;h=d9cb3308d0cc887320d33b1c8b609fc59492b9b6;hb=HEAD#l52)

In the case of a partial read/write followed by an error, I don't believe it
is possible to recover at all using just POSIX-defined calls.

------
walrusty
Regarding how "the right thing" stacks up to the worse-is-better solution, the
author writes:

> How does the right thing stack up? There are two basic scenarios: the ``big
> complex system scenario'' and the ``diamond-like jewel'' scenario.

> The ``diamond-like jewel'' scenario [Scheme] goes like this:

> The right thing takes forever to design, but it is quite small at every
> point along the way. To implement it to run fast is either impossible or
> beyond the capabilities of most implementors.

This doesn't sound like it's actually the case, is it? There are, of course,
many different Scheme implementations; they seem to get implemented in
reasonable amounts of time, and some execute code very quickly indeed.

~~~
sethg
Scheme is over thirty years old; over those years, a lot of research and
experimentation has been devoted to making Scheme more efficient.

When Scheme first came out, its use of lexical scope was controversial,
because _everyone knew_ that dynamic scope was more efficient.

------
fomojola
Cute. This is the same screed that was delivered in Structure and
Interpretation of Computer Programs at MIT back when it was still taught (in
Scheme, and this was in 1996!). I guess it is a balm for all the Scheme-heads
that perhaps wondered why their language lost, and is still out there.

~~~
ernestipark
This is one of the first papers gone over in Computer Systems (6.033) so it's
not totally gone.

------
agentultra
The funny thing is that Common Lisp can be used to deliver working systems
just fine. In fact, there's nothing "perfect" about it. It has warts. But it
is actually quite practical.

"Worse is better," is thankfully a philosophy that is pretty unique (afaik) to
software development. It is only really applicable to a sub-set of software
development as well. I cannot imagine how "worse is better" would work in
mission critical systems where human lives are at stake. Or lab equipment,
embedded systems, and other scenarios where failures can result in huge
headaches.

I don't think there was a battle that was won by any side really. Either
approach could be considered for any given problem. Practicality is important
and zealotry should be avoided at all costs.

~~~
nknight
If you substitute "practicality" wherever you see "worse is better", you'll
have a much clearer idea of what the "philosophy" really is, and realize it in
no way conflicts with critical systems.

All software design and development is done to a set of requirements. The more
disastrous a failure would be, the stricter the requirements will be, and the
more rigorous the processes will be.

Like almost all other developers, my software does not run nuclear reactors,
therefore I am not going to expend the resources to achieve the safety
necessary for a nuclear reactor. It would be both unnecessary and economically
infeasible.

Do I care if a client makes a call to my IPTV webservice and gets back corrupt
data? Well, yeah, but I'm not going to step through the entire software stack
to mathematically prove it's impossible, nor am I going to encase the servers
in a lightyear of lead to protect them from cosmic rays. I'm going to follow
general best practices, let some testers play with it for a few days (while
thousands of other lines of code in the client and server get exercised at the
exact same time) and ship it.

Why? Because the small risk of a user not being able to watch their favorite
movie in some weird corner-case has less economic significance than me
spending days making 100% sure everything is perfect in my new API call.

At the same time, I recognize components of my systems that can have serious
economic consequences, and accordingly invest more time in getting them closer
to "right" (or avoiding them entirely -- e.g. not so long ago I ripped out all
the C-style string/buffer handling from what was ostensibly a C++ library (not
mine, originally) and replaced it with std::string and std::vector, which I
knew were right, because people smarter than me had made sure they were,
because everyone knew they had to be, and time was invested accordingly).

This is a _continuum_ , not a pigeonhole.

------
blumentopf
There's an interesting analogy in network protocols: OSI (the right thing)
versus IP (worse is better).

------
jamesrcole
I've always felt that calling this "Worse is Better" is misleading.

It's more that "Worse leads to more mind-share" (a kind of economic argument)
and "Worse tools can lead to better design of system's built using them".

Neither of which actually mean that worse is necessarily better.

------
mooneater
that totally left me hanging -- I want to hear more about the diamond!

------
AnthonBerg
Best is the enemy of good.

------
nknight
MIT == Academia, New Jersey == Real World. That's all this debate has ever
truly been about.

"The right thing" in any particular situation is whatever results in a working
system. Economics dictate that perfection rarely wins. There's a reason Unix
came out of Bell Labs.

