Talk:Worse is better

From Wikipedia, the free encyclopedia

There is a discrepancy between simplicity rules?? Which one is right?

*"Simplicity: the design must be simple in implementation and interface. However, it is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design."

He argues that early Unix and C are examples of this design approach.

Gabriel contrasts this philosophy to the so-called "MIT approach" (also known as "the Right Thing"), which he describes as follows:

  • "Simplicity: the design must be simple in implementation and interface. However, it is more important for the interface to be simple than the implementation."
I see no descrepancy here- but say simplicity is good, but disagree with whether, when you make the tradeoffs, you should simplify the interface or the implementation. --Maru (talk) Contribs 17:37, 16 November 2005 (UTC)


Contents

[edit] "More is Less"

I can't find any reference to any paper by rob pike by the title of "More is Less", any references? Maybe you meant "Program Design in the UNIX Environment" AKA "cat -v considered harmful". Lost Goblin 14:17, 8 February 2006 (UTC)

I'll ask Rob about this, but I recall seeing the paper years ago. It was using the program "more" as a specific example of feature bloat. I'll double check this. DonPMitchell 19:49, 8 February 2006 (UTC)
I'm going to remove the quote, because Rob and I cannot recall who wrote "More is Less". The WIB article was written during the period of back and forth sniping between Bell Labs and the MIT/Stanford AI communities. It makes more sense to people if they realize its historical context.
I would still love to get a copy of that paper, I'm a big fan of "cat -v considered harmful" :) Lost Goblin 10:31, 10 February 2006 (UTC)

[edit] Historical context

There's a lot going on here historically (I was at Bell Labs while these flame wars were going on, mostly over "netnews" groups). This is just one of many flames that somehow became famous.

At MIT and Stanford AI labs, there was frustration about the popularity of C and UNIX, and the decline of interest in LISP. At Bell Labs, there was a strong distrust of AI, which they considered a source of fraud in the computer-science community. Also a distrust of "hacker" programming, which the Bell Labs UNIX authors thought was sloppy and verbose.

It's an important period because this contention is also part of the context for the creation of the GNU project, which originally had a strong anti-UNIX motivation (even though for a long time, it was largely a rewrite of /usr/bin commands from UNIX). —Preceding unsigned comment added by DonPMitchell (talk • contribs)

I remember that bit of GNU- RMS' original manifesto said the second most important (and eventually most important, I hear the plan was) language was going to be a Lisp. We all know how well that turned out; aside from Emacs, the only real Lisp stuff for GNU are the Guile extensions, which AFAIK are none too popular. --maru (talk) contribs 05:32, 10 February 2006 (UTC)
A big turning point for LISP was the failure of the VLSI design project at MCC. The managers basically said that the software-engineering characteristics of LISP were a big reason that the huge project ended up in a train wreck. We heard about this at Bell Labs because some of folks had left to join MCC a few years before. —Preceding unsigned comment added by DonPMitchell (talk • contribs)
Really? In all my reading, I've never heard of this project. Did they publish any papers or books I could get a hold of? --maru (talk) contribs 18:25, 12 February 2006 (UTC)

[edit] Non-sequitur paragraph

The following paragraph from the article, although it may describe what Gabriel wrote, does not fit the facts:

"Gabriel argues that "Worse is better" produces more successful software than the "MIT approach". As long as the initial program is basically good, it is easier to port to new machines and situations, and will take much less time and effort to implement initially. Thus its use will spread rapidly, long before a program developed using the "MIT approach" has a chance to be developed and deployed."

According to wikipedia, Lisp appeared in 1958 while C appeared fourteen years later in 1972. The paragraph appears to allude to the phenomenon of path dependence in programming languages; whether or not such path dependence exists, the phenomenon would favor Lisp, not C. Is there some other interpretation of this paragraph that jives with the facts? I think the facts should be clarified. Mistercupcake 02:16, 7 March 2007 (UTC)

I don't think it's a non sequitur, and I don't think it refers to path dependence (anyway, Lisp would not be favored by path dependence, since the early history of Lisp is a history of immense fragmentation and tiny site-specific communities, programs, and languages). It's simply referring to how if a program is portable, it can and will reach more people than non-portable equivalents, and those people (or a proportion thereof - same thing) will keep on improving it. Unix is often said to have a vastly inferior design to other OSs, but because it's somewhat portable and almost works well, people who have had to use it have plowed so much time into it that it actually works well these days (motivating more people to use it), even if mainframe OSs have a longer history or whatever. --Gwern (contribs) 02:24 7 March 2007 (GMT)
After going back and reading Gabriel's original article, I have to agree. The (Wikipedia) article, however, is less than clear on this distinction between path-dependence and what are genuinely "adaptive traits". Personally I find the common conception that Unix is inferior but it won "for the wrong reasons" strange; there are after all concrete "adaptive" traits (such as reliance on pipes and an emphasis on a multitude of small programs that do well-defined tasks) of Unix that we now recognize as major theoretical breakthroughs in the design of systems. Of course Gabriel does not mention them... Thanks for clearing this up.Mistercupcake 08:56, 7 March 2007 (UTC)

Getting back to the original statement quoted at the top, I find the abstract notion of "new situations" more relevant and conceptually important that "porting to new machines," which is a more concrete example of the previous abstraction. I've changed the order in the phrasing of that sentence, although I'd prefer to totally rewrite it. After all, such a problem is specifically addressed by efforts like JAVA, bypassing (however unsuccessfully) the principle. Easier to port or even the tendency to be easierto port should be subsumed in "more adaptive." Cuvtixo 19:05, 6 July 2007 (UTC)

[edit] Only SCCC

Only simplicity, correctness, consistency, completeness matters finally, the rest is wordplay. V4vijayakumar 05:32, 16 November 2006 (UTC)

At first sight, certainly, and even after some scrutiny, the lists of Simplicity, Correctness, Consistency, Completeness as presented are more confusing that elucidating. I wish these statements were parsed. Any publications that analyze them?
My questions are; firstly, in the "New Jersey Way," the categories seem to be hierarchical, they instead seem to be of roughly equal importance in "The Right Way." I wish this were reflected in their organization. 1,2,3, a,b,c. Although the explanations of interface vs implementation in Simplicity are OK, it would be more clear if the categories were divided, say into Interface Simplicity and Implementation Simplicity. In Gabriel's mind there may have been differences in Interface vs Implementation in each of the categories, but he didn't follow through. Also the presented order of each quality doesn't seem to have any relation to their relative importance, and the introduction of the words "inconsistant" and "complexity" really undermines the structure. I think perhaps this essay embodies the "New Jersey Style" better than it describes it!!!!

I find some of the ideas better expressed in the anniversary edition of The Mythical Man-Month by Fred Brooks- Basically, the idea of Simplicity trumping all seems to be far the most valuable insight from Gabriel. Interface vs impementation makes some sense, but everything else is jumbled.

Cuvtixo 16:04, 6 July 2007 (UTC)