7 ms·

"worse is better" seems to be born out again and again and again. In fact it's fairly hard to find cases where "do the right thing" won. Here's some examples wh

by emtel 7y ago

"worse is better" seems to be born out again and again and again. In fact it's fairly hard to find cases where "do the right thing" won. Here's some examples where a clearly flawed technology became totally dominant. * Unix * The C language * DOS and Windows * Javascript * The x86 instruction set. And here are some cases where dominance was achieved in a more narrow market, or in which one might argue about which technology was "worse", or where its not totally clear which was the winner. * Linux/SysV vs any of the BSDs * Ethernet vs ATM, SONET, etc. * Android vs iOS * MySQL vs Postgres (Postgres is having a renaissance, but for a long time mysql was very dominant) What is also especially striking is how often "The Right Thing" in programming languages seems to lose, whereby "lose" I mean "have a very small fraction of market share despite almost everyone agreeing that the language is better in almost every way to more widely-used languages like C/C++, Java, etc." * LISP and Scheme * The whole ML family * Haskell * Rust (although its soon to tell on this one) Meanwhile, languages that aren't obviously terrible, but have major flaws, like Java and Python, are ubiquitous, and the dumpster-fire languages Perl and PHP have enjoyed massive success.

TickleSteve 7y ago
That's likely because the criteria to be judged as "better" is likely from an academic basis. Academia generally does not produce products. Products are generally produced by pragmatic engineers & developers. Academically 'better' does not equate to 'better' for "getting shit done". This just emphasises how different academia is from real product development.
jstimpfle 7y ago
My impression is that there are various, even contradicting understandings and opinions in the wild what "worse is better" actually means. Rarely do people who interpret it in a cynical way demonstrate a good understanding of the total set of qualities that matter for the success of a technology. If you think LISP or Haskell are without flaws (despite all the years of hype), then... you're wrong.
- lisper 7y ago
  It's not that they are without flaws, it's that it is a lot easier to fix/ignore/work-around the flaws than in other languages, where the flaws are unchangeable (except by the standards committee) and constantly in your face.
  - jstimpfle 7y ago
    hear, hear.
  - ncmncm 7y ago
    No. You are just used to your flaws, and not used to theirs; and have learned not to complain about yours, but complaints about theirs are welcomed in your circle. In other words: other systems really are crap, but so is yours, really, but we all get our stuff done, despite it all. Sometimes things get better (Moore's law has forgiven all manner of evil) and sometimes they get worse (Java).
    - lisper 7y ago
      > You are just used to your flaws, and not used to theirs This is a testable theory: name me a flaw in Common Lisp that cannot easily be worked around. I'll bet that for any flaw you name, I'll be able to show you an easy way to work around it.
      - jstimpfle 7y ago
        Of course you will be able to give a brittle, half-assed work around for any issue that someone throws at you. But you know, not all people are obsessed with LISP, not all people are ok with half-assed workarounds. I think you are being very dishonest to yourself if you think that LISP is universally the best just because you can theoretically turn it into anything. You can't, really. Good tooling matters. Error messages matter. Standardization matters. Syntax matters (to some extent). Mindshare matters (a lot). There's a lot of subtle qualities that you can't just fake. When I write performance sensitive code I'll personally just pick C. I'm sure there's a Common Lisp solution available to specify machine types and compile efficient code. (Probably there's many, which is another problem). But what's the point in putting lipstick on a pig when I can just use the real deal that works perfectly for what I'm doing?
msla 7y ago
> Ethernet vs ATM, SONET, etc. I'm not convinced Ethernet and ATM are going for entirely the same markets. I've never heard of SOHO ATM, at any rate. Really, Ethernet faced off with Token Ring, which has good features (guaranteed bandwidth, for one) compared to unswitched Ethernet, which is pretty much a dead technology at this point. > Linux/SysV Linux isn't System V, it's POSIX. That sounds like a cop-out, but Linux, one, has no code from any System V systems, and, two, doesn't feel like System V. If anything, it feels like GNU, which is a lot more featureful than System V ever was. (Compare Solaris to most Linux distros, for example.) And if we're going to say System V... well, the BSDs still exist, and Solaris was the last of the classic System V OSes in anything like widespread use. And even Solaris/SunOS wasn't pure System V, was it? > The x86 instruction set. Making good use of cache turned out to be much more important than ease of decoding, and having a Huffman-coded machine code is a good way to do that. Plus, the x86 ISA isn't weird in some ways the RISC ISAs which tried to displace it were: It has no branch delay slots, it has multiplication and division opcodes which work like normal opcodes, it can load immediates into a register without a lot of contortion, it's reasonably friendly to unaligned memory accesses... Really, x86 is only bad in a rather narrow analysis.
basementcat 7y ago
* The English language
userbinator 7y ago
LISP and Scheme Look at how much the first Lisp machines cost, and how utterly slow they were for that price relative to other hardware of the time. In turns out that in the real world, abstract notions of academic purity are nearly worthless, and efficiency/performance matters a lot.
- lispm 7y ago
  > how utterly slow they were for that price relative to other hardware of the time examples?
lizmat 7y ago
Perhaps because there's more money to be made with "worse" languages? You can make more money in language A if something takes a day in language A, and only an hour in language B, at similar cognitive load.
- ncmncm 7y ago
  Well, yes. That was really the core of the complaint, but nobody would read complaints about The Almighty Dollar then, any more than now, so it had to be wrapped up in techno-morality.

by emtel 7y ago

TickleSteve 7y ago

That's likely because the criteria to be judged as "better" is likely from an academic basis. Academia generally does not produce products. Products are generally produced by pragmatic engineers & developers. Academically 'better' does not equate to 'better' for "getting shit done". This just emphasises how different academia is from real product development.

jstimpfle 7y ago

My impression is that there are various, even contradicting understandings and opinions in the wild what "worse is better" actually means. Rarely do people who interpret it in a cynical way demonstrate a good understanding of the total set of qualities that matter for the success of a technology. If you think LISP or Haskell are without flaws (despite all the years of hype), then... you're wrong.

lisper 7y ago
It's not that they are without flaws, it's that it is a lot easier to fix/ignore/work-around the flaws than in other languages, where the flaws are unchangeable (except by the standards committee) and constantly in your face.
- jstimpfle 7y ago
  hear, hear.
- ncmncm 7y ago
  No. You are just used to your flaws, and not used to theirs; and have learned not to complain about yours, but complaints about theirs are welcomed in your circle. In other words: other systems really are crap, but so is yours, really, but we all get our stuff done, despite it all. Sometimes things get better (Moore's law has forgiven all manner of evil) and sometimes they get worse (Java).
  - lisper 7y ago
    > You are just used to your flaws, and not used to theirs This is a testable theory: name me a flaw in Common Lisp that cannot easily be worked around. I'll bet that for any flaw you name, I'll be able to show you an easy way to work around it.
    - jstimpfle 7y ago
      Of course you will be able to give a brittle, half-assed work around for any issue that someone throws at you. But you know, not all people are obsessed with LISP, not all people are ok with half-assed workarounds. I think you are being very dishonest to yourself if you think that LISP is universally the best just because you can theoretically turn it into anything. You can't, really. Good tooling matters. Error messages matter. Standardization matters. Syntax matters (to some extent). Mindshare matters (a lot). There's a lot of subtle qualities that you can't just fake. When I write performance sensitive code I'll personally just pick C. I'm sure there's a Common Lisp solution available to specify machine types and compile efficient code. (Probably there's many, which is another problem). But what's the point in putting lipstick on a pig when I can just use the real deal that works perfectly for what I'm doing?

msla 7y ago

> Ethernet vs ATM, SONET, etc. I'm not convinced Ethernet and ATM are going for entirely the same markets. I've never heard of SOHO ATM, at any rate. Really, Ethernet faced off with Token Ring, which has good features (guaranteed bandwidth, for one) compared to unswitched Ethernet, which is pretty much a dead technology at this point. > Linux/SysV Linux isn't System V, it's POSIX. That sounds like a cop-out, but Linux, one, has no code from any System V systems, and, two, doesn't feel like System V. If anything, it feels like GNU, which is a lot more featureful than System V ever was. (Compare Solaris to most Linux distros, for example.) And if we're going to say System V... well, the BSDs still exist, and Solaris was the last of the classic System V OSes in anything like widespread use. And even Solaris/SunOS wasn't pure System V, was it? > The x86 instruction set. Making good use of cache turned out to be much more important than ease of decoding, and having a Huffman-coded machine code is a good way to do that. Plus, the x86 ISA isn't weird in some ways the RISC ISAs which tried to displace it were: It has no branch delay slots, it has multiplication and division opcodes which work like normal opcodes, it can load immediates into a register without a lot of contortion, it's reasonably friendly to unaligned memory accesses... Really, x86 is only bad in a rather narrow analysis.

basementcat 7y ago

* The English language

userbinator 7y ago

LISP and Scheme Look at how much the first Lisp machines cost, and how utterly slow they were for that price relative to other hardware of the time. In turns out that in the real world, abstract notions of academic purity are nearly worthless, and efficiency/performance matters a lot.

lispm 7y ago
> how utterly slow they were for that price relative to other hardware of the time examples?

lizmat 7y ago

Perhaps because there's more money to be made with "worse" languages? You can make more money in language A if something takes a day in language A, and only an hour in language B, at similar cognitive load.

ncmncm 7y ago
Well, yes. That was really the core of the complaint, but nobody would read complaints about The Almighty Dollar then, any more than now, so it had to be wrapped up in techno-morality.