Talk:Worse is better
|WikiProject Software / Computing|
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)
- That's the point--there are two schools of thought on simplicity. The MIT way is all about doing what's hard to code but delivers a better product, while the New Jersey way is all about doing what's easy to code correctly, even if quality suffers as a result. He's arguing that C beat Lisp in terms of language popularity not because C is a "better" language or because it was a "better" way to program--it's just really easy to write a compiler for C, so every platform architecture had a C compiler built for it -- hence "UNIX and C are the ultimate computer viruses."Jthemphill (talk) 09:15, 7 December 2011 (UTC)
- Respectfully, you have it wrong.
- The New Jersey Style is not about "Easy to code".MIT style means that its better for the system to be "correct", from the point of view of business requirements, even if those requirements make you add extra complexity or break some design constraints. Extra complexity != simple = hard to maintain / enhance.
- The New Jersey style is about striving for the "Quality" of the system, in terms of simplicity, even if that means cutting some business requirements that would require excessive complexity (ie Hacks). It is said that, over time, the simpler system will be so easy to maintain and enhance that it will eventually cover more use cases than the correct one.
- Experience will tell (surely some naive people will disagree, but is so overwhelming true ), that the New Jersey Style is actually much more difficult to achieve.
- 1 "More is Less"
- 2 Historical context
- 3 Non-sequitur paragraph
- 4 Only SCCC
- 5 Consistent AND complete?
- 6 MIT approach or "MIT approach"
- 7 New Jersey Style?
- 8 Weird sentence in quotation.
- 9 uhh what about MSDOS? original name: 'quick and dirty OS'
- 10 Notability
- 11 Merge / Expansion
- 12 Multics / Unix as exemplars?
"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)
- Perhaps it is When More is Less: Controlling the Market for Computer Software Enhancements ? 220.127.116.11 (talk) 18:04, 28 June 2011 (UTC)
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)
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)
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)
Consistent AND complete?
- Godel has nothing to do with this, nor does the Halting Problem; and you should be ashamed of yourself for even thinking they might. --Gwern (contribs) 17:54 10 September 2008 (GMT)
MIT approach or "MIT approach"
To me first indicates that guys at MIT do it this way. The second is it's called that way for some reason. Shouldn't it be changed to "MIT approach" ?? 18.104.22.168 (talk) 00:48, 7 December 2008 (UTC)
New Jersey Style?
Weird sentence in quotation.
"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." I'm not a native English speaker but the last part of that sentence strikes me as grammatically incorrect. I also could not find a source for that quotation.
I'd change it to: "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 there are those who want to make Lisp compilers better." —Preceding unsigned comment added by Niels.bom (talk • contribs) 22:16, 10 September 2009 (UTC)
- The fact that you are not a native English speaker, as you said, does not preclude you being 100% correct! What an awful sentence that is! Unfortunately, it is attributed as a direct quote to Richard Gabriel in his article. I will look again to see if I can find a source for the quotation, no disrespect intended, as I realize you tried to do that, but that was in 2009.
This is just a symptom of a larger problem with this article, it really needs some tidying up and context, particularly as time passes and memories of what was fresh in 1990 become less so. Alternatively, this could be merged into one of several other articles, as other comments on this talk page suggested. Eventually, something should be done, as it is a shame to lose it, but it is difficult to understand as is.
Without reading the talk page, I would have lacked the necessary context and background to comprehend the article. --FeralOink (talk) 13:58, 19 April 2012 (UTC)
uhh what about MSDOS? original name: 'quick and dirty OS'
one of the most successful software products of all time... was originally called 'quick and dirty os' (QDOS) and was a mishmash of other ideas.
and while we are at it? what about x86 vs the various dead RISC machines?
While this may be notable, the article at present does not provide the reliable secondary sourcing which would make it so. Further, it is lacking both in historical content as well as reception, the latter of which would not necessarily proof its notability, but which would go a long way toward doing so. --Izno (talk) 20:31, 11 February 2010 (UTC)
- There: http://scholar.google.com/scholar?q="worse+is+better"
- Now let's go spend our time on something productive. --Gwern (contribs) 22:25 11 February 2010 (GMT)
- No need for the "-_-". I note them as I see them. Your assumption is that I want to actually edit the article, which is a poor one indeed. It holds no interest to me whatsoever. Further, "something productive" is subjective, and I know that it has been hashed out prior to me hashing it with you and with an even larger amount of uselessness produced.
- Also, a "lmgtfy" style response is poor form. If I had wanted to, I would have looked. But as I didn't… The note was just a friendly reminder. I'm not here to try to get the article deleted; if I wanted to do that, I would have prod'ded and summarily (likely) AfDd. For which I would have been shouted down. Instead, I'm placing the note here for others more interested in the article to fix said problem. --Izno (talk) 23:21, 11 February 2010 (UTC)
- It is related with the KISS principle. Consider merging them, or not ... Rursus dixit. (mbork3!) 12:01, 9 July 2010 (UTC)
- Izno, Gabriel's maxim and the paper where it originated have been highly influential and are certainly notable within the software industry. Rursus, it is a distinct concept and is completely different from KISS. —Preceding unsigned comment added by 22.214.171.124 (talk) 18:52, 14 September 2010 (UTC)
Merge / Expansion
This article is essentially RPG's essay...apparently a fan decided that it would make a good page, and a Wikipedia editor allowed it in a moment of weakness? Keeping it as a single article isn't very helpful for an outsider trying to understand why this essay was written and how it fits into its context. It should be merged / expanded into an article covering the history of software development philosophy. I'm fairly skeptical that Worse is Better deserves any more than a section or subsection in such an article. 126.96.36.199 (talk) 06:26, 19 November 2010 (UTC)
Multics / Unix as exemplars?
The original Multics project history and Bell Labs dropping out, then creating Unix story should be presented here - it's another example of "functionally complete" vs. "ship it and fix issues with after you have a working code base" — Preceding unsigned comment added by 188.8.131.52 (talk) 12:30, 5 August 2011 (UTC)