I have a theory that the worse is better approach begets an environment where the worse is better approach is better.<p>At least hypothetically, I think there's an approach which is not "the right thing" or "worse is better" but rather more like "the right foundations".<p>Most interface complexity in my experience seems to be inherited from underlying interface complexity, and it takes a lot of work to fix that underlying interface complexity. This, I think is where "worse is better" shines. If you try to apply a "the right thing" approach to a system where you're dealing with shitty underlying interfaces (i.e. every popular operating system out there including every unix, and NT system) you end up with endless complexity and performance loss. So obviously nobody will want to do "the right thing" and everyone who takes the "worse is better" approach will end up way ahead of you in terms of delivering something. People will be happy (because people are almost always happy regardless of how crap your product is).<p>On the other hand, designing something with "the right foundations" means that "the right thing" no longer needs to involve "sacrifice implementation simplicity in favour of interface simplicity" to anywhere near the same extent because your implementation can focus on implementing whatever interface you want rather than first paving over a crappy underlying interface.<p>But the difficulty of "the right foundations" is that nobody knows what the right foundations are the first 10 times they implement them. This approach requires being able to rip the foundations up a few times. And nobody wants that, so "worse is better" wins again.
I'm always happy whenever this old article goes viral. For two reasons: First, learning to accept the fact that the better solutions doesn't always win has helped me keep may sanity over more than two decades in the tech industry. And second, I'm old enough to have a pretty good idea what the guy meant when he replied, "It takes a tough man to make a tender chicken."
> 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.<p>> Unix and C are the ultimate computer viruses.<p>The key argument behind worse-is-better is that an OS which is easy to implement will dominate the market in an ecosystem with many competing hardware standards. Operating systems, programming languages, and software in general have not worked this way in a long time.<p>Rust is not worse-is-better, but it's become very popular anyway, because LLVM can cross-compile for anything. Kubernetes is not worse-is-better, but nobody needs to reimplement the k8s control plane. React is not worse-is-better, but it only needs to run on the one web platform, so it's fine.<p>Worse-is-better only applies to things that require an ecosystem of independent implementers providing compatible front-ends for diverging back-ends, and we've mostly standardized beyond that now.
I remember when I had a lesson about OSI layers, where the teacher has carefully described all the layers in detail<p>and then said something like "most of this is not important, these layers don't really exist, TCP/IP got popular first because it's just much simpler than OSI was"
> 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++.<p>And 30 years later they show few signs of letting go.
Isn't "Worse is better" just a restatement of "Perfect is the enemy of Good", only slanted to make better\Perfect sound more enticing?<p>>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.<p>A deer is only 80% of a unicorn, but waiting for unicorns to exist is folly.
The critical point of the article holds true of everything in human social networks (be it religion/culture/philosophy/apps/industry...).<p>If you don't achieve virality, you're as good as dead. Once a episteme/meme spreads like wild-fire there's very little chance for a reassessment based on value/function - because the scope is now the big axis of valuation.<p>It's actually worse because humanity is now a single big borg. Even 30-40 years back, there were sparsely connected pools where different species of fish could exist - not any more. The elites of every single country is a part of the Anglosphere, and their populations mimic them (eventually).<p>This tumbling towards widespread mono-memetism in <i>every single</i> sphere of life is deeply dissatisfying about the modern human life, not just for PL/OS/... but also for culture etc.<p>Anthropocene of humanity itself.
"Worse is better" has become like "move fast and break things". They're both sayings that reveal an often-overlooked truth, but they have both been taken far too far and result in worse things for everybody.
I've read this a few times over the years and I think the argument is sound. But I wonder if it is sound in the same way this statement is:<p>"It is better to go picking blueberries before they are fully ripe, that way you won't have much competition."
I feel like we're seeing a bit of push-back today against worse-is-better in the area of languages. Rust in particular feels more like the MIT approach, albeit with an escape hatch via the explicit keyword "unsafe." Its type system is very thoroughly specified and correct as opposed to C's YOLO typing.
I assume that 'worse' often means find adequation with average and mass. This ensures a longer existence, later you may absorb the "better" you didn't have early on. Look how dynamic languages started to have better data types, various traits (generators, closures..), jit .. all things they could pluck out of old "glorious" languages that were .. somehow too advanced for the mainstream. It's a strange schizophrenic situation.
I think the worse-is-better philosophy is not well encapsulated with the 4 priorities given. Perhaps it is 4 completely different priorities. Here's a strawman.<p>1. Minimal -- the design and implementation must be the smallest as possible,
especially the scope (which should be deliberately "incomplete")<p>2. Timely -- the implementation must be delivered as soon as feasible, even if it comes before the design (get it working first, then figure out why)<p>3. Relevant -- the design and implementation must address important, unmet need, eschewing needs that are not urgent at the time (you can iterate or supplement)<p>4. Usable -- the implementation must be integrated with the existing, working and stable infrastructure (even if that integration causes design compromises)<p>The other dimensions, simplicity, correctness, consistency, and completeness are very nice to have, but they are not the primary drivers of this philosophy.
The distinction between the set of five "right" principles and the five "worse is better" principles is known as compromise in design.<p>It's the opposite of what marketers want you to think of when they say "uncompromising design."
I know this is an article about Lisp and the specific usage of this term in the context of software acceptance, but when you use a title that provocative I want to speak specifically about the idea of "Worse is Better" with respect to a more literal idea of "sometimes things get worse overtime but you are told they have improved"<p>For example, why is it that central vacuums are more rare in 2024 than they were in the 1980s, despite them being superior in every way compared to regular ones?<p>"Worse" vacuums are "better" for the economy? (because Dyson makes jobs and consumes resources?)
EINTR's design is one of computing's absolute classics. To MIT and New Jersey, we should add the McDougals approach: "I cannot work under these conditions." When faced with the PC loser-ing issue, just don't implement the code in question.<p>McDougals resolves the apparent conflict between the other two. It blames the interrupt hardware as the root cause. It produces non-working, incomplete software. It's kind of a modest proposal.<p>However, it also produces no ripples in the design fabric. With MIT, the OS source is a maintenance nightmare. With NJ, modern software still has to deal with archaic idiosyncrasies like EINTR. With McDougals, all the "conflict-free" portions of the software advance, those that write themselves.<p>The result is likely immediately shelved, perhaps as an open source PoC. Over time, someone might write some inelegant glue that makes interrupts appear to behave nicely. Alternatively, the world might become perfect to match the software.<p>If nothing else, the software will have mimicked the way we learn. We use imperfect examples to draw the idealized conclusion. Even if it never gets to run, it will be more readable and more inspiring than either MIT or NJ.
For another discussion on this <a href="https://wiki.c2.com/?WorseIsBetter" rel="nofollow">https://wiki.c2.com/?WorseIsBetter</a> which starts out with:<p><pre><code> RichardGabriel makes this observation on the survival value of software in the paper Lisp: Good News, Bad News, How to Win Big. See http://www.jwz.org/doc/worse-is-better.html for the section on WorseIsBetter.
For those seeking the first node, see http://web.archive.org/web/19990210084721/http://www.ai.mit.edu/docs/articles/good-news/good-news.html.
For even more context on WorseIsBetter see http://www.dreamsongs.com/WorseIsBetter.html. My favorite part is RichardGabriel arguing with himself.</code></pre>
what's the old saw about "unix design prioritizes simplicity over correctness, and on modern hardware simplicity is also no longer considered necessary"
Ironically, the main feature that separates LISP from other modern languages is homoiconicity/macros(now that features like garbage collection are mainstream).<p>And this leads to an easier implementation - parsing is easier(which is why code transformation via macros becomes easy).
These look to be the interesting threads on Gabriel's worse-is-better essays:<p><i>Lisp: Good News, Bad News, How to Win Big (1990) [pdf]</i> - <a href="https://news.ycombinator.com/item?id=30045836">https://news.ycombinator.com/item?id=30045836</a> - Jan 2022 (32 comments)<p><i>Worse Is Better (2001)</i> - <a href="https://news.ycombinator.com/item?id=27916370">https://news.ycombinator.com/item?id=27916370</a> - July 2021 (43 comments)<p><i>Lisp: Good News, Bad News, How to Win Big (1991)</i> - <a href="https://news.ycombinator.com/item?id=22585733">https://news.ycombinator.com/item?id=22585733</a> - March 2020 (21 comments)<p><i>The Rise of Worse Is Better (1991)</i> - <a href="https://news.ycombinator.com/item?id=21405780">https://news.ycombinator.com/item?id=21405780</a> - Oct 2019 (37 comments)<p><i>The Rise of Worse Is Better (1991)</i> - <a href="https://news.ycombinator.com/item?id=16716275">https://news.ycombinator.com/item?id=16716275</a> - March 2018 (44 comments)<p><i>Worse is Better</i> - <a href="https://news.ycombinator.com/item?id=16339932">https://news.ycombinator.com/item?id=16339932</a> - Feb 2018 (1 comment)<p><i>The Rise of Worse is Better</i> - <a href="https://news.ycombinator.com/item?id=7202728">https://news.ycombinator.com/item?id=7202728</a> - Feb 2014 (21 comments)<p><i>The Rise of "Worse is Better"</i> - <a href="https://news.ycombinator.com/item?id=2725100">https://news.ycombinator.com/item?id=2725100</a> - July 2011 (32 comments)<p><i>Lisp: Good News, Bad News, How to Win Big [1991]</i> - <a href="https://news.ycombinator.com/item?id=2628170">https://news.ycombinator.com/item?id=2628170</a> - June 2011 (2 comments)<p><i>Worse is Better</i> - <a href="https://news.ycombinator.com/item?id=2019328">https://news.ycombinator.com/item?id=2019328</a> - Dec 2010 (3 comments)<p><i>Worse Is Better</i> - <a href="https://news.ycombinator.com/item?id=1905081">https://news.ycombinator.com/item?id=1905081</a> - Nov 2010 (1 comment)<p><i>Worse is better</i> - <a href="https://news.ycombinator.com/item?id=1265510">https://news.ycombinator.com/item?id=1265510</a> - April 2010 (3 comments)<p><i>Worse Is Better</i> - <a href="https://news.ycombinator.com/item?id=1112379">https://news.ycombinator.com/item?id=1112379</a> - Feb 2010 (5 comments)<p><i>Lisp: Worse is Better, Originally published in 1991</i> - <a href="https://news.ycombinator.com/item?id=1110539">https://news.ycombinator.com/item?id=1110539</a> - Feb 2010 (1 comment)<p><i>Lisp: Good News, Bad News, How to Win Big</i> - <a href="https://news.ycombinator.com/item?id=552497">https://news.ycombinator.com/item?id=552497</a> - April 2009 (2 comments)
For me this is just utopia vs real world.<p>What is better, a perfect design or one that exists?<p>Our mind tries to trick us into thinking that the choice is between perfect and not so perfect.<p>No, in real-life it is common that aiming for the perfect ruins everything else, even the existence of that idea in real form due to other constraints.
This... Honestly the first lines seemed I thought this was an arrogant take, but he made _really_ good point and now I tend to agree with him.<p>Still I am a bit bothered, does a counterargument exist?
I don’t get the name New Jersey approach, is it just the general association of New Jersey and poor quality? When I think of New Jersey and CS, I think of Princeton, which has a pretty good program IIRC.<p>—<p>Anyway, I wouldn’t put simplicity on the same level as the other things. Simplicity isn’t a virtue in and of itself, simplicity is valuable because it helps all of the other things.<p>Simplicity helps a bit with consistency, in the sense that you have more trouble doing really bizarre and inconsistent things in a simple design.<p>Simplicity helps massively with correctness. You can check things that you don’t understand. Personally, that means there’s a complexity prove after which I can’t guarantee correctness. This is the main one I object to. Simplicity and correctness simply don’t belong in different bullet-points.<p>Simplicity could be seen as providing completeness. The two ways to produce completeness are to either work for a really long time and make something huge, or reduce scope and make a little complete thing.<p>It’s all simplicity.
There was an article posted on here[1] a while back that I only just found again, introducing the term "expedience." The idea was that we think we live in a world where people have to have "the best" sweater, be on "the best" social network, drive "the best" car, etc. But when you look at what really WINS, it's not the best, it's the most "expedient" - i.e. sufficiently good, with built-in social proof, inoculated of buyer's remorse, etc.<p>Is Amazon "the best" place to go shopping? No, you might find better prices on individual items if you put a little more work into it, but it's the most expedient. Is Facebook/Instagram/Tiktok/insert here "the best" social network? No, but it is the most accessible, easy-to-use, useful one. Is a Tesla (perhaps outdated example since X) "the best" car - no, but it is the most expedient.<p>There is a tangent here that intersects with refinement culture as well. Among the group of society that (subconsciously) care about these "expedient" choices, you see everyone and everything start to look the same<p>[1]<a href="https://tinaja.computer/2017/10/13/expedience.html" rel="nofollow">https://tinaja.computer/2017/10/13/expedience.html</a>
I'll never understand the obsession with LISP. My guess is it just appeals to a certain type of person, sort of academic in my view. I'm not convinced that LISP was ever the-right-thing. The author didn't express anything about LISP vs C except to assert that C was a 50% solution and LISP was better.<p>I agree though that for practical purposes, practical solutions are just going to be more successful.