Talk:Worse is better

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.

"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 ? 144.32.48.87 (talk) 18:04, 28 June 2011 (UTC)

Too bad there's no paper available online (unless one wants to pay $30 for it?) --Gwern (contribs) 00:23 8 July 2011 (GMT)

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)

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)

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)

Consistent AND complete?

I can't be the first person to notice this, but...come on, hasn't this guy ever heard of Kurt Gödel? :P --Shay Guy (talk) 06:33, 10 September 2008 (UTC)

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)

Well, you see, I'm trying to figure out some axioms for this theory of arithmetic I'm working on. Should I just try to get a good first approximation, and push it out the door, or should I make sure my theory's complete? =) Tsoeto (talk) 16:50, 14 January 2009 (UTC)

Off course Gödel has to do with it!

A program is a [constructive] proof! Only very simple systems can be both consistent and complete. An inconsistent system is unreliable. Gödel proved that Arithmetic is incomplete, which means that there is no formal system capable to represent all the objects "existing in the abstract world of Arithmetic". He showed that there are formulas that can't be proved. Gödel's discovery, came from the discovery of a paradox in the naive set theory by Bertrand Russell. His incompleteness theorem showed that it is irremediably unfruitful to try to build a complete and consistent logic to model the arithmetic.

There are programs that can not be written in any programming language, because every programming language is based in a model of computation. And computing models are equivalent (interchangeable) with each other.

The Lisp language was originally based in a formal system called primitive recursive functions and later on the lambda calculus and C is based in the von Neumann machine or random access machine. Both are equivalent because there is a correspondence among them. i.e. it is possible to write an interpreter of C with Lisp and a Lisp interpreter in C.

Both programming languages are have the same inconsistency in the naive set theory, but can be avoided in the same way that it is done in common mathematics (calculus,high school algebra,geometry).

The main difference is that C is a [statically] typed language, while Lisp is "untyped" (really dynamic typed). "Untyped" languages are more liked by a very large amount of programmers. But programming should be done in [statically] typed languages.

The reason is that during the specification phase they can delay to understand the kind of objects that they are working with, and stating it in detail is cumbersome. On the other side, the [statically] typed languages are safer because they enforce type consistency at compile time. In know days, Lisp became a more typed language (see Racket), and the typed languages have incorporated type inference systems.

The MIT way, is better founded because it is less costly to think the problem well at the start of the project, because the cost to repair them later is more expensive. It is an illusion to do a bad engineered system to repair the bugs later. But is the prevalent practice and I can't help it.

To apply the MIT style one must be more educated, know logic, languages, automata, types. To do the things by trial and error, is more easy for the not educated. It is a fact that those programmers have changed the world being the support of the majority of (blessed) free software movement. Had it been better founded, then there would be less redundant programs, more reusable code, better quality and less abandoned projects. The things are not too different with proprietary software. — Preceding unsigned comment added by 201.124.221.207 (talk) 20:58, 1 November 2019 (UTC)

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" ?? 84.16.123.194 (talk) 00:48, 7 December 2008 (UTC)

The first mention of it does include quotes. --Gwern (contribs) 20:37 7 December 2008 (GMT)

New Jersey Style?

Why is "worse is better" called New Jersey style? What has New Jersey to do with it? —Preceding unsigned comment added by 77.191.28.30 (talk) 19:53, 22 June 2009 (UTC)

It's called the New Jersey style because Bell Labs is in NJ. Bell Labs is where the C language came from. In his original essay, C was the "worse."Jthemphill (talk) 09:10, 7 December 2011 (UTC)

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)

Passing by, 12 years later (damn!): strong agree! The current writing of this article is too contextual to understand the actual meaning of the essay, and its significance. I would not have guessed that there had existed a rivalry in the US computer science in the 1980s (Bell Labs with C and UNIX / MIT and Stanford AI with LISP and GNU), with such historical significance that it shaped the subsequent software world, and to which this “Worse is better” essay belonged. Shouldn’t there be an article on that rivalry, to start with? Maëlan 09:25, 25 April 2024 (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?

Notability

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. (^mbork³!) 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 64.46.5.230 (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. 98.210.157.185 (talk) 06:26, 19 November 2010 (UTC)

This is similar to the earlier complaint that it's not notable but... I don't know what role you think "Wikipedia Editors" play, but generally no one single person or entity is in charge of approving or disapproving of an article. YOU DO! WE'RE THE WIKIPEDIA EDITORS WHO DECIDE WHAT'S NOTABLE!!! If you don't think it is, put you're justification here, try to get feedback and delete it yourself!!! Good Grief! I find it hard to take you're argument seriously when you don't understand the basics of Wikipedia here. I'd also argue that it was particularly notable when and as Wikipedia was established, and the web technologies and I'd say Wikipedia itself was founded on the principles described in this essay. It had outsized influence on the software (particularly Open Source) and internet worlds at the time, and it's hard to discount such influences on Wikipedia itself. Therefore, I propose that we actually do include this essay, perhaps with the commentary already published here, as a major part of the article itself, so petty arguments about "sources" are eliminated. Cuvtixo (talk) 23:51, 26 February 2020 (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 72.248.107.194 (talk) 12:30, 5 August 2011 (UTC)

Removing "This article relies largely or entirely on a single source"

This is something of a ridiculous criticism because the SUBJECT IS IT'S OWN SOURCE. You can't really expect an article about an essay to have much source other than itself and related articles by the author, which indeed are cited. The other alternative is to include the entire article here. It's as short as many Wikipedia articles, and why should we dredge up citations when the essay in it's entirety be presented? No citations: the source article itself. Cuvtixo (talk) 23:52, 26 February 2020 (UTC)

Removing "may not meet Wikipedia's general notability guidelines"

I contest this by providing different secondary sources that I believe are unrelated to the author, such as a mention on Gangarz, Mike (2003-08-05), Linux and the Unix philosophy, pp. 122–125, ISBN 9781555582739, Graham, Paul (2004-05-18), Hackers and Painters, p. 220, ISBN 9780596803100, or Mayer, Christian (2022-08-02), The Art of Clean Code, pp. 117–118, ISBN 9781718502192 Santhy (talk) 10:55, 18 April 2024 (UTC)

I also believe the notability template was wrongly asserted on it, because even if the article does not contain the notes, they do exist in the real world, and Wikipedia:NEXIST. A quick search in Twitter reveals thousands of comments for the quoted search string "worse is better", including uses by fellow programmers who relate to the meaning of this article, and this Wikipedia page is often cited in their discussions, which futher increases the value of keeping it as a separate page and not a subsection of an article, as some have suggested in another topic above.

Consider that aside Twitter real-world usage by people in the industry, there are excellent secondary sources multiple books (the ones I mention are just a few I know or have read but a quick search on Google Books shows many more). I don't understand why this piece of information, valuable to some, can be of such interest in removing or hiding away in on a different topic, but if the original person who suggested it can provide an idea of why that would be of value to Wikipedia users and editors, please let us all know. So far, I believe this article belongs in Wikipedia according to the current policies. --Santhy (talk) 11:13, 18 April 2024 (UTC)