7 ms·

The "Unix Philosophy" is a bankrupt romanticized after the fact rationalization to make up excuses and justifications for ridiculous ancient vestigial historic

The "Unix Philosophy" is a bankrupt romanticized after the fact rationalization to make up excuses and justifications for ridiculous ancient vestigial historic baggage like the lack of shared libraries and decent scripting languages, where you had to shell out THREE heavyweight processes -- "[" and "expr" and a sub-shell -- with an inexplicable flurry of punctuation [ "$(expr 1 + 1)" -eq 2 ] just to test if 1 + 1 = 2, even though the processor has single cycle instructions to add two numbers and test for equality.

chubot 2y ago
??? This complaint seems more than 20 years too late Arithmetic is built into POSIX shell, and it's universally implemented. The following works in basically every shell, and starts 0 new processes, not 2: $ bash -c '[ $((1 + 1)) = 2 ]; echo $?' 0 $ zsh -c '[ $((1 + 1)) = 2 ]; echo $?' 0 $ busybox ash -c '[ $((1 + 1)) = 2 ]; echo $?' 0 YSH (part of https://oils.pub/ https://oils.pub/ ) has a more familiar C- or JavaScript-like syntax: $ ysh -c 'if (1 + 1 === 2) { echo hi }' hi It also has structured data types like Python or JS: $ echo '{"foo": 42}' > test.json $ ysh ysh-0.28$ json read < test.json ysh-0.28$ echo "next = $[_reply.foo + 1]" next = 43 and floats, etc. $ echo "q = $[_reply.foo / 5]" q = 8.4 https://oils.pub/release/latest/doc/ysh-tour.html https://oils.pub/release/latest/doc/ysh-tour.html (It's probably more useful for scripting now, but it's also an interactive shell)
- DonHopkins 2y ago
  20 years doesn't even get you back to the last century, it's more like 48 years since 1977 when Bourne wrote sh. As one of the authors of the Unix Haters Handbook, published relatively recently in 1994, and someone who's used many versions of Unix since the 1980's, of course I'm fully aware that those problems are hell of a lot more than 20 years old, and that's the whole point: we're still suffering from their "vestigial historic baggage", arcane syntax and semantics originally intended to fork processes and pipe text to solve trivial tasks instead of using shared libraries and machine instructions to perform simple math operations, and people are still trying to justify all that claptrap as the "Unix Philosophy". Care to explain to me how all the problems of X-Windows have been solved so it's no longer valid to criticize the fallout from its legacy vestigial historic baggage we still suffer from even today? How many decades ago did they first promise the Year of the Linux Desktop? The X-Windows Disaster: This is Chapter 7 of the UNIX-HATERS Handbook. The X-Windows Disaster chapter was written by Don Hopkins. https://medium.com/@donhopkins/the-x-windows-disaster-128d398ebd47 https://medium.com/@donhopkins/the-x-windows-disaster-128d39... Why it took THREE processes and a shitload of context switches and punctuation that we are still stuck with to simply test if 1 + 1 = 2 in classic Unix [TM]: [ "$(expr 1 + 1)" -eq 2 ] Breakdown: expr 1 + 1 An external program used to perform arithmetic. $(...) (Command substitution) Runs expr in a subshell to capture its output. [ ... ] In early shells, [ (aka test) was also an external binary. It took THREE separate processes because: Unix lacked built-in arithmetic. The shell couldn't do math. Even conditionals ([) were external. Everything was glued together with fragile text and subprocesses. All of this just to evaluate a single arithmetic expression by ping-ponging in and out of user and kernel space so many times -- despite the CPU being able to do it in a single cycle. That’s exactly the kind of historical inefficiency the "Unix Philosophy" retroactively romanticizes.
  - chubot 2y ago
    I'm aware it used to be that way, but it's long been fixed It's fine to hate Unix, but you should update your examples :)
    - DonHopkins 2y ago
      I'll update my examples when your examples of how it's been fixed don't use the same arcane syntax and semantics as the 48 year old Bourne shell. That's the whole point, which you're still missing. > $ bash -c '[ $((1 + 1)) = 2 ]; echo $?' Not even Perl uses that much arcane punctuation to test if 1 + 1 = 2. As if [] isn't enough, you've got to throw in two more levels of (()), plus enough grawlix profanity for a Popeye comic strip. And people complain Lisp has too many parens. Sheez. https://en.wikipedia.org/wiki/Grawlix https://en.wikipedia.org/wiki/Grawlix There's even an emoji for Unix shell syntax: https://www.compart.com/en/unicode/U+1F92C https://www.compart.com/en/unicode/U+1F92C
      - Datagenerator 2y ago
        What are good shells in your opinion?
        anthk 2y ago
        rc and 9front's philosophy. Unix, but better and removing all the cruft.
        DonHopkins 2y ago
        I prefer ITS DDT (aka HACTRN), with its built-in PDP-10 assembler and disassembler, that lets you do things like your login file customizing your prompt in assembly code to print the time by making system calls, without actually spawning any sub-jobs to merely print the time: https://gunkies.org/wiki/ITS_DDT_Guide https://gunkies.org/wiki/ITS_DDT_Guide ..PROMPT holds the instruction which DDT uses to type out a "*". You can replace it with any other instruction. To use "%" instead of "*", deposit $1#%$> in that location ($> to avoid clobbering the opcode without having to know what it is) If you have to use arcane syntax and grawlix profanity, you should at least have direct efficient access to the full power of the CPU and operating system. https://en.wikipedia.org/wiki/Incompatible_Timesharing_System https://en.wikipedia.org/wiki/Incompatible_Timesharing_Syste... https://en.wikipedia.org/wiki/Dynamic_debugging_technique https://en.wikipedia.org/wiki/Dynamic_debugging_technique https://web.archive.org/web/20061011004003/http://www.sigfs.org/its-reference/its-reference-1.5.html#tth_chAp7 https://web.archive.org/web/20061011004003/http://www.sigfs.... https://its.victor.se/wiki/luser https://its.victor.se/wiki/luser https://www.hactrn.net/sra/alice/alices.pdp10 https://www.hactrn.net/sra/alice/alices.pdp10 https://gunkies.org/wiki/Incompatible_Timesharing_System https://gunkies.org/wiki/Incompatible_Timesharing_System (I recognize that photo I took of MIT-MC at the MIT-AI Lab!) https://gunkies.org/wiki/File:Mit-mc.jpg https://gunkies.org/wiki/File:Mit-mc.jpg Even the Apple ][ Integer Basic monitor ROMs had a build-in mini assembler and disassembler. https://www.ldx.ca/notes/apple2-notes.html https://www.ldx.ca/notes/apple2-notes.html
verandaguy 2y ago
> TWO heavyweight processes If you're going to emphasize that it's two processes, at least make sure it's actually two processes. `[` is a shell builtin. > `eval` being heavy If you want a more lightweight option, `calc` is available and generally better-suited. > inexplicable flurry of punctuation It's very explicable. It's actually exceptionally well-documented. Shell scripting isn't syntactically easy, which is an artifact of its time plus standardization. The bourne shell dates back to 1979, and POSIX has made backwards-compatibility a priority between editions. In this case: - `[` and `]` delimit a test expression - `"..."` ensure that the result of an expression is always treated as a single-token string rather than splitting a token into multiple based on spaces, which is the default behaviour (and an artifact of sh and bash's basic type system) - `$(...)` denotes that the expression between the parens gets run in a subshell - `-eq` is used for numerical comparison since POSIX shells default to string comparison using the normal `=` equals sign (which is, again, a limitation of the type system and a practical compromise) > even though the processor has single cycle instructions to add two numbers and test for equality I don't really understand what this argument is trying to argue for; shell scripting languages are, for practical reasons, usually interpreted, and in the POSIX case, they usually don't have to be fast since they're usually just used to delegate operations off to other code for performance. Their main priority is ease of interop with their domain. If I wanted to test if one plus one equals two at a multi-terabit-per-second bandwidth I'd write a C program for it that forces AVX512 use via inline assembly, but at that point I think I'd have lost the plot a bit.
- DonHopkins 2y ago
  I was quite clear that this is HISTORICAL baggage whose syntax and semantics we're still suffering from. I corrected it from TWO to THREE and wrote a step by step description of why it was three processes in the other comment. That's the whole point: it was originally a terrible design, but we're still stuck with the syntactic and semantic consequences even today, in the name of "backwards compatibility". > they usually don't have to be fast since they're usually just used to delegate operations off to other code for performance Even now you're bending over backwards to make ridiculous rationalizations for the bankrupt "Unix Philosophy". And you're just making my point for me. Does the Unix Philosophy say that the shell should be designed to be slow and inefficient and syntactically byzantine on purpose, or are you just making excuses? Maybe you don't think YOUR shell scripts have to be fast, or easy to write, read, and maintain, or perform simple arithmetic, or not have arsenals of pre-loaded foot guns, but speak for yourself.
whatnow37373 2y ago
Shell != Unix (philosophy) as I’m sure you are aware. The unix philosophy is having a shell and being able to replace it, not its particular idiosyncrasies at any moment in time. This is like bashing Windows for the look of its buttons.
pjmlp 2y ago
The "Unix Philosophy" is some cargo cult among FOSS folks that never used commercial UNIX systems, since Xenix I haven't used any that doesn't have endless options on their man pages.
- anthk 2y ago
  Well, we are set by your "Windows philosphy", and forget NT being a VMS rehash, we would still be using the crappy W9x designs with DOS crap back and forth. Even Risc OS seems to do better even if it doesn't have memory protection too (I think it hasn't, I didn't try it for more than a few days).
  - pjmlp 2y ago
    Thing is there is no "Windows philosphy" cargo cult, and I don't worship OSes nor languages, all have their plus and minus, use any of them when the situation calls for it, and it is a disservice to oneself to identify themselves to technology stacks like football club memberships given at birth.
    - anthk 2y ago
      Neither I am a sole Unix user; I have Risc OS open (Apache 2.0?) on an RPI to experiment something else beyond Unix/C. But Windows it's too heavyweight, from 8 it has been a disaster. And the NT kernel+explorer can be really slim (look at ReactOS, or XP, or a debloated W7). The problem it's that Apple and MS (and RedHat) are just selling shiny turds wasting tons of cycles to do trivial tasks. Worse, you can't slim down your install so it behaves like a sane system for 1GB of RAM. I can watch 720p@30FPS videos under a n270 netbook with MPV. Something even native players for WXP can't do with low level direct draw calls well enough. The Windows > XP philosophy among RedHat and Apple it's: let bloat and crap out our OSes with unnecesary services and XML crap (and interpreted languages such as JS and C#) for the desktop until hardware vendors idolize US so the average user has to buy new crap to do the same task ever and ever. Security? Why the fuck does Gnome 3 need JS at first? Where's Vala, where it could shine here and Mutter could get a big boost and memory leaks could be a thing of the past?
eesmith 2y ago
I realized the hype for the Unix Philosophy was overblown around 1993 when I learned Perl and almost immediately stopped using a dozen different command-line tools.
- anthk 2y ago
  Ken Thompson and Unix folks agree with you. The point is... Perl was a solution to the former Unix (BSD/GNU) bloatings. When you have a look at Plan 9 (now 9fron) with rc as a shell, awk and the power of rio/acme scripting and namespaces among aux/listen... Perl feels bloated and with the same terse syntax as SH derived shells.
  - eesmith 2y ago
    I've been using Python almost full time since 1998 so, to misquote Dijkstra, I am mentally mutilated beyond regeneration.
  - bmacho 2y ago
    Is plan9 awk different?
    - anthk 2y ago
      Not much; what makes AWK shine it's the I/O in plan9; it's trivial to spawn sockets (literally from the command line), either plain text or encrypted. Also, rc it's much simpler than Bash.
- whatnow37373 2y ago
  I realized the hype for composing $thing$s was overblown around 1993 when I learned I could just have "A Grand Unified $thing$" and almost immediately stopped using a dozen different $thing$s. Then, a decade or two later, I realized the Grand Unified $thing$ was itself composed, but not by me so I had no control over it. Then I thought to myself, how great would it be if we decompose this Grand Unified $thing$ into many reusable $thing$s? That way we can be optimally productive by not being dependent on the idiosyncrasies of Grand Unified $thing$. And so it was written and so it was done. We built many a $thing$ and the world was good, excellent even. But then one of the Ancients realized we could increase our productivity dramatically if we would compose our many $thing$s into one Grand Unified $thing$ so we wouldn't have to learn to use all these different $thing$s. And so it was written and so it was done. Thus goes the story of the Ancients and their initiation of the most holy of cycles.
a-french-anon 2y ago
I don't see what crusty implementation details have to do with a philosophy. In fact, UNIX itself is a poor implementation of the "UNIX" philosophy, which is why Plan 9 exists. The idea of small composable tools doing one thing and doing it well may have been mostly an ideal (and now pretty niche), but I don't think it was purely invented after the fact. Just crippled by the "worse is better".

chubot 2y ago

??? This complaint seems more than 20 years too late Arithmetic is built into POSIX shell, and it's universally implemented. The following works in basically every shell, and starts 0 new processes, not 2: $ bash -c '[ $((1 + 1)) = 2 ]; echo $?' 0 $ zsh -c '[ $((1 + 1)) = 2 ]; echo $?' 0 $ busybox ash -c '[ $((1 + 1)) = 2 ]; echo $?' 0 YSH (part of https://oils.pub/ https://oils.pub/ ) has a more familiar C- or JavaScript-like syntax: $ ysh -c 'if (1 + 1 === 2) { echo hi }' hi It also has structured data types like Python or JS: $ echo '{"foo": 42}' > test.json $ ysh ysh-0.28$ json read < test.json ysh-0.28$ echo "next = $[_reply.foo + 1]" next = 43 and floats, etc. $ echo "q = $[_reply.foo / 5]" q = 8.4 https://oils.pub/release/latest/doc/ysh-tour.html https://oils.pub/release/latest/doc/ysh-tour.html (It's probably more useful for scripting now, but it's also an interactive shell)

DonHopkins 2y ago
20 years doesn't even get you back to the last century, it's more like 48 years since 1977 when Bourne wrote sh. As one of the authors of the Unix Haters Handbook, published relatively recently in 1994, and someone who's used many versions of Unix since the 1980's, of course I'm fully aware that those problems are hell of a lot more than 20 years old, and that's the whole point: we're still suffering from their "vestigial historic baggage", arcane syntax and semantics originally intended to fork processes and pipe text to solve trivial tasks instead of using shared libraries and machine instructions to perform simple math operations, and people are still trying to justify all that claptrap as the "Unix Philosophy". Care to explain to me how all the problems of X-Windows have been solved so it's no longer valid to criticize the fallout from its legacy vestigial historic baggage we still suffer from even today? How many decades ago did they first promise the Year of the Linux Desktop? The X-Windows Disaster: This is Chapter 7 of the UNIX-HATERS Handbook. The X-Windows Disaster chapter was written by Don Hopkins. https://medium.com/@donhopkins/the-x-windows-disaster-128d398ebd47 https://medium.com/@donhopkins/the-x-windows-disaster-128d39... Why it took THREE processes and a shitload of context switches and punctuation that we are still stuck with to simply test if 1 + 1 = 2 in classic Unix [TM]: [ "$(expr 1 + 1)" -eq 2 ] Breakdown: expr 1 + 1 An external program used to perform arithmetic. $(...) (Command substitution) Runs expr in a subshell to capture its output. [ ... ] In early shells, [ (aka test) was also an external binary. It took THREE separate processes because: Unix lacked built-in arithmetic. The shell couldn't do math. Even conditionals ([) were external. Everything was glued together with fragile text and subprocesses. All of this just to evaluate a single arithmetic expression by ping-ponging in and out of user and kernel space so many times -- despite the CPU being able to do it in a single cycle. That’s exactly the kind of historical inefficiency the "Unix Philosophy" retroactively romanticizes.
- chubot 2y ago
  I'm aware it used to be that way, but it's long been fixed It's fine to hate Unix, but you should update your examples :)
  - DonHopkins 2y ago
    I'll update my examples when your examples of how it's been fixed don't use the same arcane syntax and semantics as the 48 year old Bourne shell. That's the whole point, which you're still missing. > $ bash -c '[ $((1 + 1)) = 2 ]; echo $?' Not even Perl uses that much arcane punctuation to test if 1 + 1 = 2. As if [] isn't enough, you've got to throw in two more levels of (()), plus enough grawlix profanity for a Popeye comic strip. And people complain Lisp has too many parens. Sheez. https://en.wikipedia.org/wiki/Grawlix https://en.wikipedia.org/wiki/Grawlix There's even an emoji for Unix shell syntax: https://www.compart.com/en/unicode/U+1F92C https://www.compart.com/en/unicode/U+1F92C
    - Datagenerator 2y ago
      What are good shells in your opinion?
      - anthk 2y ago
        rc and 9front's philosophy. Unix, but better and removing all the cruft.
      - DonHopkins 2y ago
        I prefer ITS DDT (aka HACTRN), with its built-in PDP-10 assembler and disassembler, that lets you do things like your login file customizing your prompt in assembly code to print the time by making system calls, without actually spawning any sub-jobs to merely print the time: https://gunkies.org/wiki/ITS_DDT_Guide https://gunkies.org/wiki/ITS_DDT_Guide ..PROMPT holds the instruction which DDT uses to type out a "*". You can replace it with any other instruction. To use "%" instead of "*", deposit $1#%$> in that location ($> to avoid clobbering the opcode without having to know what it is) If you have to use arcane syntax and grawlix profanity, you should at least have direct efficient access to the full power of the CPU and operating system. https://en.wikipedia.org/wiki/Incompatible_Timesharing_System https://en.wikipedia.org/wiki/Incompatible_Timesharing_Syste... https://en.wikipedia.org/wiki/Dynamic_debugging_technique https://en.wikipedia.org/wiki/Dynamic_debugging_technique https://web.archive.org/web/20061011004003/http://www.sigfs.org/its-reference/its-reference-1.5.html#tth_chAp7 https://web.archive.org/web/20061011004003/http://www.sigfs.... https://its.victor.se/wiki/luser https://its.victor.se/wiki/luser https://www.hactrn.net/sra/alice/alices.pdp10 https://www.hactrn.net/sra/alice/alices.pdp10 https://gunkies.org/wiki/Incompatible_Timesharing_System https://gunkies.org/wiki/Incompatible_Timesharing_System (I recognize that photo I took of MIT-MC at the MIT-AI Lab!) https://gunkies.org/wiki/File:Mit-mc.jpg https://gunkies.org/wiki/File:Mit-mc.jpg Even the Apple ][ Integer Basic monitor ROMs had a build-in mini assembler and disassembler. https://www.ldx.ca/notes/apple2-notes.html https://www.ldx.ca/notes/apple2-notes.html

verandaguy 2y ago

> TWO heavyweight processes If you're going to emphasize that it's two processes, at least make sure it's actually two processes. `[` is a shell builtin. > `eval` being heavy If you want a more lightweight option, `calc` is available and generally better-suited. > inexplicable flurry of punctuation It's very explicable. It's actually exceptionally well-documented. Shell scripting isn't syntactically easy, which is an artifact of its time plus standardization. The bourne shell dates back to 1979, and POSIX has made backwards-compatibility a priority between editions. In this case: - `[` and `]` delimit a test expression - `"..."` ensure that the result of an expression is always treated as a single-token string rather than splitting a token into multiple based on spaces, which is the default behaviour (and an artifact of sh and bash's basic type system) - `$(...)` denotes that the expression between the parens gets run in a subshell - `-eq` is used for numerical comparison since POSIX shells default to string comparison using the normal `=` equals sign (which is, again, a limitation of the type system and a practical compromise) > even though the processor has single cycle instructions to add two numbers and test for equality I don't really understand what this argument is trying to argue for; shell scripting languages are, for practical reasons, usually interpreted, and in the POSIX case, they usually don't have to be fast since they're usually just used to delegate operations off to other code for performance. Their main priority is ease of interop with their domain. If I wanted to test if one plus one equals two at a multi-terabit-per-second bandwidth I'd write a C program for it that forces AVX512 use via inline assembly, but at that point I think I'd have lost the plot a bit.

DonHopkins 2y ago
I was quite clear that this is HISTORICAL baggage whose syntax and semantics we're still suffering from. I corrected it from TWO to THREE and wrote a step by step description of why it was three processes in the other comment. That's the whole point: it was originally a terrible design, but we're still stuck with the syntactic and semantic consequences even today, in the name of "backwards compatibility". > they usually don't have to be fast since they're usually just used to delegate operations off to other code for performance Even now you're bending over backwards to make ridiculous rationalizations for the bankrupt "Unix Philosophy". And you're just making my point for me. Does the Unix Philosophy say that the shell should be designed to be slow and inefficient and syntactically byzantine on purpose, or are you just making excuses? Maybe you don't think YOUR shell scripts have to be fast, or easy to write, read, and maintain, or perform simple arithmetic, or not have arsenals of pre-loaded foot guns, but speak for yourself.

whatnow37373 2y ago

Shell != Unix (philosophy) as I’m sure you are aware. The unix philosophy is having a shell and being able to replace it, not its particular idiosyncrasies at any moment in time. This is like bashing Windows for the look of its buttons.

pjmlp 2y ago

The "Unix Philosophy" is some cargo cult among FOSS folks that never used commercial UNIX systems, since Xenix I haven't used any that doesn't have endless options on their man pages.

anthk 2y ago
Well, we are set by your "Windows philosphy", and forget NT being a VMS rehash, we would still be using the crappy W9x designs with DOS crap back and forth. Even Risc OS seems to do better even if it doesn't have memory protection too (I think it hasn't, I didn't try it for more than a few days).
- pjmlp 2y ago
  Thing is there is no "Windows philosphy" cargo cult, and I don't worship OSes nor languages, all have their plus and minus, use any of them when the situation calls for it, and it is a disservice to oneself to identify themselves to technology stacks like football club memberships given at birth.
  - anthk 2y ago
    Neither I am a sole Unix user; I have Risc OS open (Apache 2.0?) on an RPI to experiment something else beyond Unix/C. But Windows it's too heavyweight, from 8 it has been a disaster. And the NT kernel+explorer can be really slim (look at ReactOS, or XP, or a debloated W7). The problem it's that Apple and MS (and RedHat) are just selling shiny turds wasting tons of cycles to do trivial tasks. Worse, you can't slim down your install so it behaves like a sane system for 1GB of RAM. I can watch 720p@30FPS videos under a n270 netbook with MPV. Something even native players for WXP can't do with low level direct draw calls well enough. The Windows > XP philosophy among RedHat and Apple it's: let bloat and crap out our OSes with unnecesary services and XML crap (and interpreted languages such as JS and C#) for the desktop until hardware vendors idolize US so the average user has to buy new crap to do the same task ever and ever. Security? Why the fuck does Gnome 3 need JS at first? Where's Vala, where it could shine here and Mutter could get a big boost and memory leaks could be a thing of the past?

eesmith 2y ago

I realized the hype for the Unix Philosophy was overblown around 1993 when I learned Perl and almost immediately stopped using a dozen different command-line tools.

anthk 2y ago
Ken Thompson and Unix folks agree with you. The point is... Perl was a solution to the former Unix (BSD/GNU) bloatings. When you have a look at Plan 9 (now 9fron) with rc as a shell, awk and the power of rio/acme scripting and namespaces among aux/listen... Perl feels bloated and with the same terse syntax as SH derived shells.
- eesmith 2y ago
  I've been using Python almost full time since 1998 so, to misquote Dijkstra, I am mentally mutilated beyond regeneration.
- bmacho 2y ago
  Is plan9 awk different?
  - anthk 2y ago
    Not much; what makes AWK shine it's the I/O in plan9; it's trivial to spawn sockets (literally from the command line), either plain text or encrypted. Also, rc it's much simpler than Bash.
whatnow37373 2y ago
I realized the hype for composing $thing$s was overblown around 1993 when I learned I could just have "A Grand Unified $thing$" and almost immediately stopped using a dozen different $thing$s. Then, a decade or two later, I realized the Grand Unified $thing$ was itself composed, but not by me so I had no control over it. Then I thought to myself, how great would it be if we decompose this Grand Unified $thing$ into many reusable $thing$s? That way we can be optimally productive by not being dependent on the idiosyncrasies of Grand Unified $thing$. And so it was written and so it was done. We built many a $thing$ and the world was good, excellent even. But then one of the Ancients realized we could increase our productivity dramatically if we would compose our many $thing$s into one Grand Unified $thing$ so we wouldn't have to learn to use all these different $thing$s. And so it was written and so it was done. Thus goes the story of the Ancients and their initiation of the most holy of cycles.

a-french-anon 2y ago

I don't see what crusty implementation details have to do with a philosophy. In fact, UNIX itself is a poor implementation of the "UNIX" philosophy, which is why Plan 9 exists. The idea of small composable tools doing one thing and doing it well may have been mostly an ideal (and now pretty niche), but I don't think it was purely invented after the fact. Just crippled by the "worse is better".