--[ XREF INTRO

"The Rise of Worse is Better" written by Richard Gabriel is a well known essay
in the technical circles and I had also read it quite early in my career but
something that not many people know is that the author himself wrote a criticism
of the same under a pseudonym. The more interesting thing is that Richard wrote
further three papers each either in favor of or against worse is better.

All the papers are worth reading for various reasons but the sum is more than
the parts. Reading all the papers together, I feel, is the right way to read
them. From kind of a justification for why C and Unix won over the Lisp and Lisp
systems to how worse is not actually worse but the right thing for the time to
the fear of worse systems and languages actually sidelining the better ones to
finally talking about how the systems he decried as being worse are actually
better. This is all to say, read the whole thing, if nothing else, you will get
to appreciate some Vietnamese poetry.

All the papers in their chronological order are given below, presented as a
single piece.


--[ The Rise of Worse is Better

Richard P. Gabriel Lucid, Inc

[an excerpt from "Lisp: Good News, Bad News, How to Win Big." ]

2.1 The Rise of Worse is Better

I and just about every designer of Common Lisp and CLOS has had extreme exposure
to the MIT/Stanford style of design. The essence of this style can be captured
by the phrase the right thing. To such a designer it is important to get all of
the following characteristics right:

* Simplicity -- the design must be simple, both in implementation and interface.
  It is more important for the interface to be simple than the implementation.
* Correctness -- the design must be correct in all observable aspects.
  Incorrectness is simply not allowed.
* Consistency -- the design must not be inconsistent. A design is allowed to be
  slightly less simple and less complete to avoid inconsistency. Consistency is
  as important as correctness.
* Completeness -- the design must cover as many important situations as is
  practical. All reasonably expected cases must be covered. Simplicity is not
  allowed to overly reduce completeness.

I believe most people would agree that these are good characteristics. I will
call the use of this philosophy of design the MIT approach. Common Lisp (with
CLOS) and Scheme represent the MIT approach to design and implementation.

The worse-is-better philosophy is only slightly different:

* Simplicity -- the design must be simple, both in implementation and interface.
  It is more important for the implementation to be simple than the interface.
  Simplicity is the most important consideration in a design.
* Correctness -- the design must be correct in all observable aspects. It is
  slightly better to be simple than correct.
* Consistency -- the design must not be overly inconsistent. Consistency can be
  sacrificed for simplicity in some cases, but it is better to drop those parts
  of the design that deal with less common circumstances than to introduce
  either implementational complexity or inconsistency.
* Completeness -- the design must cover as many important situations as is
  practical. All reasonably expected cases should be covered. Completeness can
  be sacrificed in favor of any other quality. In fact, completeness must be
  sacrificed whenever implementation simplicity is jeopardized. Consistency can
  be sacrificed to achieve completeness if simplicity is retained; especially
  worthless is consistency of interface.

Early Unix and C are examples of the use of this school of design, and I will
call the use of this design strategy the New Jersey approach. I have
intentionally caricatured the worse-is-better philosophy to convince you that it
is obviously a bad philosophy and that the New Jersey approach is a bad
approach.

However, I believe that worse-is-better, even in its strawman form, has better
survival characteristics than the-right-thing, and that the New Jersey approach
when used for software is a better approach than the MIT approach.

Let me start out by retelling a story that shows that the MIT/New-Jersey
distinction is valid and that proponents of each philosophy actually believe
their philosophy is better.

Two famous people, one from MIT and another from Berkeley (but working on Unix)
once met to discuss operating system issues. The person from MIT was
knowledgeable about ITS (the MIT AI Lab operating system) and had been reading
the Unix sources. He was interested in how Unix solved the PC loser-ing problem.
The PC loser-ing problem occurs when a user program invokes a system routine to
perform a lengthy operation that might have significant state, such as IO
buffers. If an interrupt occurs during the operation, the state of the user
program must be saved. Because the invocation of the system routine is usually a
single instruction, the PC of the user program does not adequately capture the
state of the process. The system routine must either back out or press forward.
The right thing is to back out and restore the user program PC to the
instruction that invoked the system routine so that resumption of the user
program after the interrupt, for example, re-enters the system routine. It is
called PC loser-ing because the PC is being coerced into loser mode, where loser
is the affectionate name for user at MIT.

The MIT guy did not see any code that handled this case and asked the New Jersey
guy how the problem was handled. The New Jersey guy said that the Unix folks
were aware of the problem, but the solution was for the system routine to always
finish, but sometimes an error code would be returned that signaled that the
system routine had failed to complete its action. A correct user program, then,
had to check the error code to determine whether to simply try the system
routine again. The MIT guy did not like this solution because it was not the
right thing.

The New Jersey guy said that the Unix solution was right because the design
philosophy of Unix was simplicity and that the right thing was too complex.
Besides, programmers could easily insert this extra test and loop. The MIT guy
pointed out that the implementation was simple but the interface to the
functionality was complex. The New Jersey guy said that the right tradeoff has
been selected in Unix -- namely, implementation simplicity was more important
than interface simplicity.

The MIT guy then muttered that sometimes it takes a tough man to make a tender
chicken, but the New Jersey guy didn’t understand (I’m not sure I do either).

Now I want to argue that worse-is-better is better. C is a programming language
designed for writing Unix, and it was designed using the New Jersey approach. C
is therefore a language for which it is easy to write a decent compiler, and it
requires the programmer to write text that is easy for the compiler to
interpret. Some have called C a fancy assembly language. Both early Unix and C
compilers had simple structures, are easy to port, require few machine resources
to run, and provide about 50%-80% of what you want from an operating system and
programming language.

Half the computers that exist at any point are worse than median (smaller or
slower). Unix and C work fine on them. The worse-is-better philosophy means that
implementation simplicity has highest priority, which means Unix and C are easy
to port on such machines. Therefore, one expects that if the 50% functionality
Unix and C support is satisfactory, they will start to appear everywhere. And
they have, haven’t they?

Unix and C are the ultimate computer viruses.

A further benefit of the worse-is-better philosophy is that the programmer is
conditioned to sacrifice some safety, convenience, and hassle to get good
performance and modest resource use. Programs written using the New Jersey
approach will work well both in small machines and large ones, and the code will
be portable because it is written on top of a virus.

It is important to remember that the initial virus has to be basically good. If
so, the viral spread is assured as long as it is portable. Once the virus has
spread, there will be pressure to improve it, possibly by increasing its
functionality closer to 90%, but users have already been conditioned to accept
worse than the right thing. Therefore, the worse-is-better software first will
gain acceptance, second will condition its users to expect less, and third will
be improved to a point that is almost the right thing. In concrete terms, even
though Lisp compilers in 1987 were about as good as C compilers, there are many
more compiler experts who want to make C compilers better than want to make Lisp
compilers better.

The good news is that in 1995 we will have a good operating system and
programming language; the bad news is that they will be Unix and C++.

There is a final benefit to worse-is-better. Because a New Jersey language and
system are not really powerful enough to build complex monolithic software,
large systems must be designed to reuse components. Therefore, a tradition of
integration springs up.

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

The big complex system scenario goes like this:

First, the right thing needs to be designed. Then its implementation needs to be
designed. Finally it is implemented. Because it is the right thing, it has
nearly 100% of desired functionality, and implementation simplicity was never a
concern so it takes a long time to implement. It is large and complex. It
requires complex tools to use properly. The last 20% takes 80% of the effort,
and so the right thing takes a long time to get out, and it only runs
satisfactorily on the most sophisticated hardware.

The diamond-like jewel scenario 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.

The two scenarios correspond to Common Lisp and Scheme.

The first scenario is also the scenario for classic artificial intelligence
software.

The right thing is frequently a monolithic piece of software, but for no reason
other than that the right thing is often designed monolithically. That is, this
characteristic is a happenstance.

The lesson to be learned from this is that it is often undesirable to go for the
right thing first. It is better to get half of the right thing available so that
it spreads like a virus. Once people are hooked on it, take the time to improve
it to 90% of the right thing.

A wrong lesson is to take the parable literally and to conclude that C is the
right vehicle for AI software. The 50% solution has to be basically right, and
in this case it isn’t.

But, one can conclude only that the Lisp community needs to seriously rethink
its position on Lisp design. I will say more about this later.


--[ Worse is Better is Worse

Nickieben Bourbaki

[Nick wrote this one afternoon while watching the snow spiral down into the
swirling Merrimack River, past the deadly inviting Rocks Village Bridge—while
looking out his back window]

In June 1991, AI Expert published a paper by my friend Richard Gabriel entitled
“Lisp: Good News, Bad News, How to Win Big.” One of the nice things about the
article—really the only nice thing— was that it was an attention-grabber. I hate
to say it, but Richard was dangerously wrong to publish that paper. Here is the
story.

In the Spring of 1989, he and I and a few of his friends were chatting about why
Lisp technology had not caught on in the mainstream and why C and Unix did.
Richard, being who he is, remarked that the reason was that “worse is better.”
Clearly from the way he said it, it was a slogan he had just made up.  Again,
being who he is, he went on to try to justify it. I’ve always told him that his
penchant for trying to argue any side of a point would get him in trouble.

A few months later, Europal—the European Conference on the Practical
Applications of Lisp— asked him to be the keynote speaker for their March 1990
conference, and he accepted. Since he didn’t have anything better to write
about, he tried to see if he could turn his fanciful argument about
worse-is-better into a legitimate paper. He produced the paper and presented it
to the conference. As he finished his speech there was a stunned silence
followed by strong disagreement from such people as Gerry Sussman. The local
press took his speech as an affirmation of the widely held belief that Richard
thought Lisp was dead. Several headlines proclaimed it.

So Richard buried the paper in his directory at work until one day about a year
later—hackers being hackers—a young, new employee found it and sent the
worse-is-better section of it to his friend at CMU, who sent it to two friends
of his at Bell Labs, and so on. Pretty soon people all over the net were reading
it and Richard was getting 10 requests a day for the full paper. Larges
companies (with 3-letter names) were using the paper as a talking piece for
discussions on how to design software for the ’90’s.

Richard got the urge to publish it more widely, and AI Expert went along.  This
is a bad paper, and since no one else has stepped forward to refute it, I feel I
must, despite Richard being a long-time friend—the friend who talked AI Expert
into letting me write these columns.

There are two parts to my criticism. The first concerns the argument about worse
is better itself, and the second concerns the effect of his argument and
conclusions on people who are just entering a career in software design or who
are students.

I’ll start by recapping his argument. There are two constrasting software design
philosophies, called the right thing and worse is better. With the right thing,
designers are equally concerned with simplicity, correctness, consistency, and
completeness. With worse is better, designers are almost exclu- sively concerned
with implementation simplicity, and will work on correctness, consistency, and
completeness only enough to get the job done, sacrificing any of these other
qualities for simplicity.

He gives an example of the two philosophies: how to handle user interrupts in
system calls. Normally when there is an interrupt, the program counter (PC) at
which to resume is stored somewhere so when the interrupt is dismissed,
execution can resume, and in this case the PC plus a few state bits can
accurately capture the state of the program so that the interrupt can excecute
essentially arbitrary code. When the program is in a system call, however, the
PC and the few state bits are not enough, because, for example, temporary
resources might have be allocated by the system, and the state of these
resources must be saved as part of the program state. The right-thing solution
is to either press forward or back out of the call. The worse-is-better solution
is to always return a flag that tells whether the system actually did the system
call. A correct program, then, would test this flag.

The right-thing code for the solution takes a hundred or so pages of assembly
language to accomplish, and usually the code is littered with places where some
small mistake in the coding can cause serious errors. The worse-is-better code
is hardly anything at all, and the user is required to be part of the solution.
Have you ever hit control-C while a Unix program is running and notice that if
you resume it, the program crashes? This is because the program does not test
that some system call failed.

Now, offhand the worse-is-better solution seems stupid, because this means every
system call should look like this:

try-again system-call
		  when-failed
		   go try-again

More on how stupid this really is later.

The argument, though, is that programs designed and implemented using worse is
better will be written more quickly than right-thing versions, will run on a
wider range of computers, will be easily portable, will be accepted more quickly
if good enough, will be eventually improved, and will, generally, demonstrate
better survival characteristics than right-thing programs. Worse-is-better
programs are like viruses that spread quickly and are soon pervasive.

Ofcourse, the two examples are Unix and C. Richard goes on to call the worse is
better approach the “New Jersey” style, and I have heard him on many occasions
say “what do you expect from an operat- ing system designed and implemented in
New Jersey!”

Before I launch into my rebuttal, let me point out the context of the argument.
It is presented in an article about Lisp and its ups and downs.  The real point
of the article is to try to see where Lisp went wrong, as if that were a valid
exploration. The worse-is-better argument seems to be a sour grapes look at the
perceived villain in the fortunes of Lisp. There is no such villain, and the
worse-is-better argument is just so much vitriol poured onto the page.

My first rebuttal is that there really isn’t a worse-is-better design
philosophy. The caricature of what this philosophy is so ridiculous that no one
would ever express, espouse, or follow it. There are programs that appear to
have been designed on the fly or whose designs have been subject to certain hard
limits—like the size of the target machine or resources available to do the
coding—but no one has ever used this philosophy per se. The dichotomy that might
exist is that of right-thing design versus no design. This is very different.

Second, can anyone really ever achieve the goals of the right thing? Right thing
is pie-in-sky and is to be put in the same drawer with apple pie and mom. There
are always tradeoffs in design and imple- mentation, and no project (except
Algol 68?) ever really tried to be pure right thing. Therefore there cannot be
pure examples, only examples of varying degrees of tradeoff, almost always
dictated by out- side constraints, such as machine size.

Third, the best understanding of what is meant by worse is better and the right
thing is presented in the PC-losering example that I described above. What is so
right about the right-thing solution and so worse about the worse-is-better
solution?  The right-thing solution is lengthy and therefore likely to have
mistakes in its implementation. Computer hardware is generally not designed to
manipulate interrupts in multi-level programs—programs like a user program
calling system routines—so there is a mismatch that must be bridged with
software. If there is a bug in the PC-losering code, is this a better solution
than handing the problem off to the user? The complexity of the right-thing
solution is so great that many consider it nearly impossible to get it right.

And, if the user program is simple and can be preceeded with the advice to not
hit control-C, what’s wrong with sprinkling it with unprotected system calls?
And what is so bad about writing protected system calls? Perhaps the interface
to a worse-is-better system is not uniform because some system calls require
protection and others don’t, but certainly this is a small inconsistency whose
correction requires heroic efforts. Perhaps a good tradeoff is what it is.

Buried under implication in Richard’s paper is the thought that there is or was
a choice between a right-thing and a worse-is-better solution in some area of
computing important to a large group. The next few points argue that there has
never been such a competition, and that within the context of the
worse-is-better systems, these system were the right thing.

Fourth, how bad is Unix? We need to look at it in its historical context. Unix
was written for the PDP-11. The primary alternative operating system on the
PDP-11 was RT-11, which was vastly worse than Unix. For this machine, Unix was
the right thing solution.  The other, better operating systems that Richard is
talking about were on the PDP-10 which did not compete with the PDP-11.  Later
the PDP-11 was replaced by the Vax, which also ran Unix. The people who used
PDP-10’s who needed to move to Vaxes had no other choice in machine or operating
system. Therefore, there was never a head-to-head competition between a
right-thing solution and a worse-is-better one.

Fifth, C is coupled with Unix in the worse-is-better scenario, and can anyone
seriously propose Lisp as the right-thing alternative?  Lisp, face it, is used
for advanced research and development in AI and other esoteric areas. It has
weird syntax, and almost all other computer languages share a non-Lispy syntax.
Syntax, folks, is religion, and Lisp is the wrong one.  Lisp is used by weirdos
who do weirdo science.

Sixth, the role of the host computer as determiner of success has been
conveniently ignored in the worse-is-better argument.  The successes of the
operating systems on the PDP-10 versus the PDP-11 were more directly influenced
by the success of their host machines. PDP-11’s were cheap and easy to buy with
small research grants or with small development budgets. Vaxes were more
expensive, but still 5 times cheaper than the PDP-10, which had an address-space
limitation never really fixed (though the PDP-10 had 36-bit words, the address
space was limited to 18 bits).

The PDP-10, which hosted a right-thing operating system, was primarily used by
the same high- end, weirdo crowd that would use Lisp. PDP-10’s were expensive,
and machines like them pretty much died out after the PDP-10 disappeared—would
you invest in a mainframe or minicomputer company today? These machines died out
because there was no large population to sustain them.

The part of the argument about Unix being a virus is inacurate: Unix spread from
the PDP-11 to the Vax, each of which was popular for other reasons. Unix was a
parasite on these machines or a symbiot. Unix would have been abandoned for any
better alternative, but it was the right thing at the time.

Seventh, as Unix had no rival on the PDP-11 and Vax, neither did C. C is very
good for system pro- gramming, and that is a lot of what was done on those
machines. C provides a good avenue into the system libraries and Unix utilities.

Eighth, C is not obviously a worse language: it has all the usual data types,
modern control structure, and has a strong lineage—Algol 60, Cambridge CPL,
BCPL, and B.

Ninth, there has never been a true, important worse-is-better/the-right-thing
faceoff, and so no one can point to an actual example of the theory that one has
greater survival characteristics than the other.

These arguments put the entire argument of worse is better into shadowy light.
But the real quarrel with the 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 Rich- ard 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.


--[ Is Worse Really Better?

Richard P. Gabriel

In 1989 I gave a keynote speech in Europe in which I lightheartedly presented a
design philosophy called worse is better, which I contrasted with another called
the right thing. Since then, I’ve been thinking more seriously about the
worse-is-better philosophy and its application to object-oriented programming.

With the-right-thing, designers are equally concerned with simplicity,
correctness, consistency, and completeness. With worse-is-better, designers are
almost exclusively concerned with implementation simplicity and performance, and
will work on correctness, consistency, and completeness only enough to get the
job done, sacrificing any of these other qualities for simplicity.

The argument, though, is that programs designed and implemented using
worse-is-better can be written more quickly than the-right-thing versions, will
run on a wider range of computers, will be easily portable, will be accepted
more quickly if good enough, will be eventually improved, and will, generally,
demonstrate better survival characteristics than the-right-thing programs.
Worse-is-better programs are like viruses that spread quickly and are soon
pervasive. And over time, if they are suc- cessful, they will be improved. The
argument is an evolutionary one—a system that establishes a large territory and
molds its environment before rivals show up has the advantage over those rivals.

Here are a few other arguments for the validity of worse-is-better:
the-right-thing advocates have chosen incorrect metrics to judge their
systems—the-right-thing systems aren’t better; free-market philosophy favors
incremental over radical improvements; worse-is-better languages have simpler
performance models and so “better” (better performing) programs can be written
by low-talent pro- grammers; and worse-is-better systems happen to be more
habitable to programmers than the-right- thing ones—they have the right balance
of abstraction and concreteness, they have a simple imple- mentation and
performance model, and they are ready for piecemeal growth.

Examples abound: DOS, Basic, UNIX, and C in the computer world, and automobiles,
stereos, and TV’s in the world of consumer goods. In the computer world, the
example of interest to JOOP read- ers is C++. Many would concede that languages
like Smalltalk, Eiffel, and CLOS are vastly “better" in some sense than C++,
but, because of its worse-is-better characteristics, the fortunes of object-
oriented programming probably lie with C++. Unlike Smalltalk, C++ is not
object-oriented down to its roots, and, like C, C++ is a low-level
language—almost an object-oriented assembly language.  Many C++ users are
surprised by the quick mass of interrelationships that grows in their programs,
making them difficult to understand, but often only those who have used better
behaved object-ori- ented languages can see the degree to which a better
language could simplify things. Object-oriented programming works best with
complex programs rather than with simple ones, and with C++ one can still manage
a more complex program than one could in pure C, but only a polyglot would know
that an even more complex program could be handled with, say, CLOS. But,
performance is perhaps the primary design goal of C++ (“not one extra
instruction"), and programmers from the large C community will probably
appreciate C++ for its performance and adopt it if its object-oriented fea-
tures help them succeed.

There is a real chance that some form of worse-is-better is valid, and that
because of its compelling force, C++ will be elevated to the role of premier
object-oriented language. And for us who are con- cerned with the success of
object-oriented programming, this is chilling—the future will be in the hands of
the worst of our fruits.


--[ Back to the Future: Is Worse (Still) Better?

Richard P. Gabriel

	Spring-Watching Pavillion

	A gentle spring evening arrives
	airily, unclouded by worldly dust.
	Three times the bell tolls echoes like a wave.
	We see heaven upside down in sad puddles.
	Love’s vast sea cannot be emptied.
	And springs of grace flow easily everywhere.
	Where is nirvana?  Nirvana is here, nine times out of ten.

								—from the Vietnamese of Ho Xuan Huong


Technology, art, popular media including network TV, and just about every aspect
of our lives and probably life itself follows a disappointing pattern: worse is
better, the good drives out the excellent, and the most popular is least good.

You can look at it like this, perhaps: To appeal to the majority of people, an
artifact must appeal to something that those people have in common; as we
increase the set of people we consider, the less those people have in common,
and that which they do have in common becomes more base. For example, network TV
is flooded with adolescent humor, sex, and violence because these are the most
basic drives people have in common, while an interest in Vietnamese poetry—which
is a very refined poetry—is quite rare. I call this the intersection effect.

More surprising, the phenomenon of worse is better occurs at all levels of
scale, so that even within a relatively esoteric subfield like object-oriented
programming and languages—a subfield of program- ming languages within the
subfield of software within the fields of computer science and computer
engineering—we see that the good drives out the excellent and worse is still
better: C++ is still the language of choice though its kissing cousin, Java, is
gaining popularity. CLOS (an advanced OO language with metaobjects and
tremendous power), Smalltalk (perhaps the purest form of OO), Eiffel
(well-thought-out and elegant), and Self (simplicity embodied) all sit on the
sidelines while all the starters are C++ and Java.

We see the same thing in other languages. Common Lisp is a wonderful, dynamic
language which happens to include CLOS. It runs roughly the speed of Java or
better, its runtime is smaller than Java by a lot, it has a programmatically
portable executable format for code, and yet it is not only not pop- ular, but
it is not even taken seriously as a programming language by just about everyone.
As we look at Web programming where version skew is a key problem, where
statically defined interfaces cannot really work well—as common sense tells us—
and where intelligent agents make a lot of sense, Lisp is not even on the junior
varsity. Never mind that Yahoo Store and parts of Orbitz are written in Common
Lisp and that NASA’s Deep Space 1 space probe was written in Common Lisp.

This second example is illustrative of a devastating point: It is not simply
that worse programming languages prevail through a reduction of quality by the
intersection effect, but the perpetuation of worse programming languages, once
they become popular, are argued for and acted on stridently. All planning for
running experiments and autonomously navigating the Deep Space 1 probe is done
using Common Lisp code executing on the spacecraft. It is possible for
controllers to bring up a Lisp prompt on Earth and to debug and patch running
code somewhere in space. Last year, this Common Lisp code was selected by a NASA
panel for NASA’s software of the year award. Despite this and despite the fact
that the software works well in space, one of the high officials at NASA blocked
the award and declared that it would not be given unless the system were
re-coded in C, in which lan- guage it would be obviously better because . . .
um, because . . . ?

We have seen the same thing happen to Prolog, Smalltalk, Self, ML, and Haskell
(despite the rumors of a Microsoft Haskell environment). Speaking of Microsoft .
. . .

More disappointing is witnessing this same effect at work in the patterns
community. Christopher Alexander’s ideas of patterns has as its smallest part
the pattern form—the concept of patterns really has to do with pattern languages
and QWAN (the Quality Without a Name). It is not about con- struction tricks. It
is about building artifacts not only suitable for human habitation, but
artifacts that increase their human inhabitants’ feeling of life and wholeness.
Alexander is all about beauty and quality, not about how to stick things
together cleverly.

Yet, the most popular form of software patterns is exemplified by those found in
“Design Patterns,” by Gamma, Helm, Johnson, and Vlissides, which contains little
more than techniques for coding in C++ constructs found in other programming
languages—for example, 16 of the 23 patterns repre- sent constructs found in the
Common Lisp language. There is no pattern language involved, and there is
nothing about QWAN. Interest in patterns is coagulating around the so-called
Gang of Four style, and it looks like things could get worse. In fact, I would
say that patterns are alive and well as a form of documentation and a quest for
clever solutions to common programming problems, and pat- tern languages, QWAN,
and the quest for a better future are now on their way to the sewage treat- ment
plant—the same place they went to in the world of architecture. Down with
quality, up with clever hacks. Why worry about what makes a user interface
beautiful and usable when you can won- der how to do mapcar in C++.

How could this come to be? Are there good reasons—like it is better to release
something initially that is not so good but on the right track and then let a
community of inhabitants repair it using piecemeal growth? Or maybe it’s that
lower cost, otherwise less effective technologies eventually push out overpriced
and over-engineered competitors? Or is it that quality is like Vietnamese poetry
and thus rarely appreciated? Is it really the statement of the base nature of
human taste?  Read the Vietnamese poem at the start of this piece; didn’t you
like it?

--[ Back to the Future: Worse (Still) is Better!

Richard P. Gabriel

Many people find the worse-is-better philosophy rather funny, more of a parody
than anything else.  It is a fascinating philosophy because it sounds silly
while at the same time it works. The problem with The Right Thing—the
anti-worse-is-better philosophy that most people tout as best—is that it can
work only if luck is on your side, and then rarely even when it is.

In this position paper I will focus on programming languages, but the argument
works in many other contexts.

Alexander explained it best when he talked about how living, whole, QWANful
designs are ones that are developed over time by their inhabitants while paying
attention to the smallest details. He talks about details down to 1/8" as being
the scale you need to pay attention to in something the size of a house. In
houses, to work at that level you need appropriate tools—tools that can work at
that level of scale comfortably. Modular parts don’t work because they have set
those details in ways you cannot modify.

Many high-level programming languages hide detail by providing big abstractions.
This means that you are working with modular parts and not with small pieces
constructed by hand. For the right level of close detail you need a low-level
language like C, assembler, or C++. With these languages you can control data
layout and design very precise and exact algorithms. With Lisp and Smalltalk,
for example, you are working with their big abstractions in a ham-fisted
way—just fine for prototyp- ing and understanding larger issues, but not good
for minute algorithm and data structure design.  For these we need craftsmen,
not storyboard designers.

The only problem that the so-called high-level languages solve is being able to
put large things together quickly.—this produces mock ups. The real problem is
thinking that you can build whole, alive software fast. Alexander never says
great buildings are built quickly; in fact if anything he says the opposite. You
need to built, inhabit, feel, then build some more, over time.  Habitable
software means nice interfaces and all that, but it also means a reasonable size
for the soft- ware and good performance. Size and performance mean a lot to
usability, and for these you need control. The ability to work at small scale
and to control size and performance comes from low-level languages. It does not
hurt that programming in such languages is difficult, because there is merit in
going slowly.

I get a little impatient with people who confuse Alexander’s concepts of
aliveness, wholeness, and QWAN with someone’s aesthetic: Face it, languages like
Lisp and Smalltalk are just someone’s idea of elegance and prettiness. They
might have some wholeness and aliveness to them, but that does not mean they can
be used to build things that are alive and whole. They are themselves modular
parts.  Come on. Alexander says, pay attention to the details and do things
slowly according to feelings, not according to abstract aesthetics.

--[ 	Index	 ]--