7 ms·

Worse Is Better (2001)

88 points by karimf 5y ago

IceDane 5y ago
If worse is better then this website is friggin' great.
- AlexandrB 5y ago
  The website is great though. Loads fast, mostly text, not too contrasty. I'd take this over the Reddit or Twitter mobile interfaces any day.
  - knowingathing 5y ago
    100%. new reddit UI is soooo slow.
  - Hammershaft 5y ago
    New reddit is a blight on the already scarred name of software development that seems to exist as a parody of modern web development.
- hamandcheese 5y ago
  You might like this: https://motherfuckingwebsite.com/ https://motherfuckingwebsite.com/
- Zababa 5y ago
  One thing I really like about websites like that (and HN for example) is that zooming just works. If you zoom, you're left with what looks like a modern blog. I have HN on 125% zoom all the time and I often forget about it. The website also perfectly supports bookmarklets to change the CSS. This is empowering the user to make the website how they want. I'd prefer that over what a designer thought would be the best for me.
drewcoo 5y ago
So we're presented with one design philosophy and one design Gabriel admits is a strawman. This was written before steelmanning was common and he was open about it, so the strawman is forgivable. Then again, maybe they're both stickmen of those design approaches. All of the important context is stripped from both. What is the goal of the designed thing? How will it be used? What are the costs? The "better" "MIT/Stanford style" was designing things to be as perfect as possible when considered in a vacuum. The "worse" "NJ style" was intended for use in industry. I still see That jarring difference between the academic and industry approaches today. And I'd rather make a difference in the world with running software, but I can see value in academics, too.
- majkinetor 5y ago
  Yeah, the difference is about acedemia vs reality - real life is not a happy case - happy case is side case.
  - ChrisMarshallNY 5y ago
    I was just referring to a paper I wrote, some years ago[0], about a [quite successful] system that I designed. It has become widely adopted, and has been taken over by a new, energetic, and highly-talented team. It is something that many in today's industry would sneer at. It's a primitive, mostly-procedural PHP framework that fails to achieve Buzzword Bingo. I deliberately designed it to be primitive. It is meant to be taken up by fairly unskilled users, and implemented in spartan, low-tech environments. It's really quite successful. The important parts are that the code quality is extremely high, as is the robustness of the system. I don't know if I've ever gotten a question about the code. In fact, I'm really just teats on a boar hog, as far as the current team is concerned. I don't think there's one blessed technical thing that I can offer them. It only took them a month or so to grok the system. They did sneer at it a lot, but they have yet to rewrite it in node.js (but they have written some excellent adapters for it in Node). I'm a big believer in functionality and utility over purity. It needs to work, and work well. Pretty is nice, but Quality and Applicability are the Principal goals. [0] https://littlegreenviper.com/miscellany/bmlt/ https://littlegreenviper.com/miscellany/bmlt/
majkinetor 5y ago
Worse is better is definitely better. I have no doubts about it. Natural organisms seem to follow that pattern - Pauling showed the cells produce sub-optimum concentrations of substances by genetic machinery probably because keeping it at optimum takes up more resources to maintain cellular machinery. Sounds totally like worse is better to me. Life is full of examples .
pipthepixie 5y ago
> The concept known as "worse is better" holds that in software making (and perhaps in other arenas as well) it is better to start with a minimal creation and grow it as needed. Or in other words, try to avoid Feature Creep[0] or Overengineering[1] [0] https://en.wikipedia.org/wiki/Feature_creep https://en.wikipedia.org/wiki/Feature_creep [1] https://en.wikipedia.org/wiki/Overengineering https://en.wikipedia.org/wiki/Overengineering
- mjw1007 5y ago
  I think it's more than avoiding feature creep. I think the most interesting parts are « It is more important for the implementation to be simple than the interface. » and « completeness must be sacrificed whenever implementation simplicity is jeopardized ». I think of this every time I'm annoyed that I can't add an empty directory to a git repository.
jchw 5y ago
Many newer programming languages have focused on reducing hidden control flow and ugly text macros in favor of more transparent metaprogramming, which may help to illustrate one of the bigger issues with Lisp. Lisp itself is simple and elegant, but that doesn't mean it's easy to write simple and elegant Lisp code. Imperative programming is maybe less elegant and beautiful than functional programming, but imperative programming is easy to understand by humans. Sure, C code may not literally execute line by line, but this is how C programmers mentally model execution, to the point where sometimes people are befuddled to learn it’s not the case. It's such an effective approach that CPUs also provide an as-if illusion of in-order execution. And sure, Lisp macros are powerful, but it feels like nobody ever stopped to consider if maybe there's an upper limit to how powerful you really want a programming language to be. Well, I have. I want languages more like Go and Zig. People will always hate at least Go, but it didn't hit TIOBE top 10 out of sheer baseless hype and corporate sponsorship. Simple, easy to understand, perhaps even "stupid" code works. I could be wrong—perhaps the Lisp renaissance is just around the bend. But realistically, I'm not running into any problems where I wish to deal with more clever and elegant code. In fact, I'm running into problems where I wish to deal with dumber and more obvious code. That these ideals often conflict is probably a great source of debate and strife.
- BoiledCabbage 5y ago
  Programming languages don't win because they are inherently better. Programming languages win because they fill a need better, or are more familiar. There are better languages than other, that help people to write better code, have bugs be easier to find, push better paradigms. But thats not what decides a programming language winner. A winner helps someone do X faster or with less effort. If better languages want to win they need to both be better, and be first to tackle niche X before a worse / familiar language does. And do it sufficiently significantly better to overcome the "familiarity benefit" a worse language will get that enters the same space. A not perfect example - typescript is almost the exact same language as JS and it took almost a decade for people to realize that unless you're writing small solo projects TS is better in just about every way. That is a best case scenario for comparison. Identical syntax, fully backwards compatible. On "language" a complete subset of the other (so no wars about losing a to gain be so is the trade off worth it), almost no new paradigm to learn and it still took our industry almost a decade to agree that it's universally better. If it takes that long to evaluate a clear cut case, its strong evidence that language benefit is not what primarilt drives language adoption. I've been around since the arguments about how Python would never be adopted because "white space was significant and that's a terrible syntax choice." That its distracting and takes mental focus. I've seen all the arguments. When a syntax is different it slows adoption drastically. Not because its worse but people we're humans. People don't like change. Then Python solved a need bettet then everything else and it took off. And once you use Python regularly you see how absurd those whitespace arguments were. JS and its approach took over because that's what the web was written in. If the language of the web had been chosen to be Lisp (as almost happened), everyone would be using Lisp right now without giving it a second thought.
chartpath 5y ago
I think it's possible to take the cult of simplicity too far. As is the case with over engineering. There is always the risk of over-simplifying and dumbing down the inherent complexity of problems. Instead of representing the problem space with a good data model, programmers who love to brag about their love of "simplicity" sometimes end up with many extra "simple" layers than are necessary. It's not a binary because there are a lot of factors that go into simplicity and some matter more than others in different contexts. One person's simplicity is another's tedious verbosity. And another's use of specialized programming techniques is someone else's scary learning curve. Much easier to just label My Preferred Solution as The Most Simple and Parsimonious because clearly I am the smartest and most scientific thinker in the group. Other approaches are Too Complex, therefore I don't need to understand them. It's just projection of insecurity about knowledge gaps by hiding under the appearance of being an iconoclast. That said, there are definitely some castle-in-the-sky and nonsense-on-stilts implementations out there :) Some would say ORMs, others would point to the actor model, and others would even say anything higher level than pointers and for-loops. For what purpose though?
- Hypx_ 5y ago
  The entire concept of "worse is better" can be more accurately be described as "don't let the perfect be the enemy of the good." Simple, functional solutions are good ideas, and attempt to replace them with perfect ones are likely to fail. In software, that just means writing code using practical languages that are proven to work. It does not need to be written in the ideal language, especially if using the ideal language requires very specialized skills. Furthermore, you do not need software that solves every single corner case. Once you have solve the main problems and most of the minor ones, there's no reason to waste years solving the last few annoying issues.
gambler 5y ago
>The concept known as "worse is better" holds that in software making (and perhaps in other arenas as well) it is better to start with a minimal creation and grow it as needed. It's a horrible moniker for the concept and most people who use it don't really mean piecemeal growth at all. What they do talk about is usually design where some shortcut allows you to quickly accomplish a short-term goal while completely ignoring long-term consequences. This is the mentality that I see everywhere in the software industry today. Go is mentioned here in comments as an example of "worse is better". It fits nicely. The main "feature" of the language is that it doesn't have any constructs that would require an average college grad or a disgruntled Java shitcoder out there to apply effort in order to understand the feature. Thus, people grab the language and mindlessly run with it. By the time the codebase grows where you need more advanced features, it's too late to switch. My prediction is that in a few years when an average Go codebase switches ownership at least once, it will become widely hated, and language developers will start cramming in features that they originally said aren't needed there at all. You've already seen a preview of thing when they replaced cutesey (and obviously broken) dependency management with modules.
- grumblenum 5y ago
  I don’t think much will change until the incentives change. Right now there is basically no consequence for doing the wrong thing. Software is unique in that defects are generally tolerated. Minimizing time to market can be everything where often winners take all. Thus an incomplete solution today is worth more than a flawless solution in the future. I’m not saying it’s good, but it is a predictable consequence of the market incentives.
- michaelfeathers 5y ago
  > It's a horrible moniker for the concept and most people who use it don't really mean piecemeal growth at all. What they do talk about is usually design where some shortcut allows you to quickly accomplish a short-term goal while completely ignoring long-term consequences. This is the mentality that I see everywhere in the software industry today. I think the moniker is perfect because that is exactly what piecemeal growth is in nature. That's why code seems to have a biological feel. The rough bit, for we humans, is that code tends toward piecemeal growth because of the economics of change. It is easier to add to something that exists than to make something new, so entities (functions, classes, services) tend to grow in size. We have to step in, as gardeners in a way, to guide structure. I don't know that it was intended by the original people behind micro-services (Fred George comes to mind), but micro-services are a good example of aligning with natural tendency rather than attempting to impose a design and continually falling short. Part of the intent was that you just rewrite a micro-service when it becomes unmaintainable. That's a direct structural correspondence to apoptosis in biology. Cells live for a while, then they are replaced.
draw_down 5y ago
In discussing the example of the loser-ing problem: > The right thing is to back out and restore the user program PC to the instruction that invoked the system routine The concept of “backing out” is left unspecified in the first place which is suspicious, but also there’s no guarantee that it will always succeed. In the-right-thing, what if backing out fails? Or some effect has taken place which can’t be simply “backed out”? You’re left with the same problem anyway. Maybe those dumb old Unix guys were on to something after all.
manmal 5y ago
The notion that a minimal first version is the ideal starting point is mirrored in this quote from John Gall: > A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.
wrycoder 5y ago
Read the original [0] Lisp: the good news, the bad news, and how to win big. (Spoiler: they didn’t.) [0] https://www.dreamsongs.com/WIB.html https://www.dreamsongs.com/WIB.html
jchanimal 5y ago
Worse is better and excellence are not at odds. Worse is better applies at one side of a shearing layer, and excellence on the other. In software, a worse is better API imposes designing for modularity upon the applications that depend on you. An excellent implementation means your internals are clean and efficient.
jstimpfle 5y ago
Why is there never much discussion about the actual technical issue presented in the text, which is how to design a syscall API with respect to interrupt handling? I never thought of the EINTR errno as a hack. It strikes me as very pragmatic and actually the right choice. Am I missing something? Why would one want to save the state of the system call routine when an interrupt occurs and the interrupt handler is executed in user code? The point of interrupts is precisely that they can interrupt a call that otherwise could potentially block forever. When an interrupt occurs, the user code has the chance to completely cancel any attempts to complete the original call. Otherwise, just re-try. The complexity added to the syscall API is small, the practical benefit is very real. So why would I want a general mechanism in the kernel that automatically continues the blocking call after running the interrupt handler? To me the lesson from "Worse is Better" has always been "Don't design before you actually know what you need. You'll probably end up with something that does not do what you want and that you can't fix".

88 points by karimf 5y ago

IceDane 5y ago

If worse is better then this website is friggin' great.

AlexandrB 5y ago
The website is great though. Loads fast, mostly text, not too contrasty. I'd take this over the Reddit or Twitter mobile interfaces any day.
- knowingathing 5y ago
  100%. new reddit UI is soooo slow.
- Hammershaft 5y ago
  New reddit is a blight on the already scarred name of software development that seems to exist as a parody of modern web development.
hamandcheese 5y ago
You might like this: https://motherfuckingwebsite.com/ https://motherfuckingwebsite.com/
Zababa 5y ago
One thing I really like about websites like that (and HN for example) is that zooming just works. If you zoom, you're left with what looks like a modern blog. I have HN on 125% zoom all the time and I often forget about it. The website also perfectly supports bookmarklets to change the CSS. This is empowering the user to make the website how they want. I'd prefer that over what a designer thought would be the best for me.

drewcoo 5y ago

So we're presented with one design philosophy and one design Gabriel admits is a strawman. This was written before steelmanning was common and he was open about it, so the strawman is forgivable. Then again, maybe they're both stickmen of those design approaches. All of the important context is stripped from both. What is the goal of the designed thing? How will it be used? What are the costs? The "better" "MIT/Stanford style" was designing things to be as perfect as possible when considered in a vacuum. The "worse" "NJ style" was intended for use in industry. I still see That jarring difference between the academic and industry approaches today. And I'd rather make a difference in the world with running software, but I can see value in academics, too.

majkinetor 5y ago
Yeah, the difference is about acedemia vs reality - real life is not a happy case - happy case is side case.
- ChrisMarshallNY 5y ago
  I was just referring to a paper I wrote, some years ago[0], about a [quite successful] system that I designed. It has become widely adopted, and has been taken over by a new, energetic, and highly-talented team. It is something that many in today's industry would sneer at. It's a primitive, mostly-procedural PHP framework that fails to achieve Buzzword Bingo. I deliberately designed it to be primitive. It is meant to be taken up by fairly unskilled users, and implemented in spartan, low-tech environments. It's really quite successful. The important parts are that the code quality is extremely high, as is the robustness of the system. I don't know if I've ever gotten a question about the code. In fact, I'm really just teats on a boar hog, as far as the current team is concerned. I don't think there's one blessed technical thing that I can offer them. It only took them a month or so to grok the system. They did sneer at it a lot, but they have yet to rewrite it in node.js (but they have written some excellent adapters for it in Node). I'm a big believer in functionality and utility over purity. It needs to work, and work well. Pretty is nice, but Quality and Applicability are the Principal goals. [0] https://littlegreenviper.com/miscellany/bmlt/ https://littlegreenviper.com/miscellany/bmlt/

majkinetor 5y ago

Worse is better is definitely better. I have no doubts about it. Natural organisms seem to follow that pattern - Pauling showed the cells produce sub-optimum concentrations of substances by genetic machinery probably because keeping it at optimum takes up more resources to maintain cellular machinery. Sounds totally like worse is better to me. Life is full of examples .

pipthepixie 5y ago

> The concept known as "worse is better" holds that in software making (and perhaps in other arenas as well) it is better to start with a minimal creation and grow it as needed. Or in other words, try to avoid Feature Creep[0] or Overengineering[1] [0] https://en.wikipedia.org/wiki/Feature_creep https://en.wikipedia.org/wiki/Feature_creep [1] https://en.wikipedia.org/wiki/Overengineering https://en.wikipedia.org/wiki/Overengineering

mjw1007 5y ago
I think it's more than avoiding feature creep. I think the most interesting parts are « It is more important for the implementation to be simple than the interface. » and « completeness must be sacrificed whenever implementation simplicity is jeopardized ». I think of this every time I'm annoyed that I can't add an empty directory to a git repository.

jchw 5y ago

Many newer programming languages have focused on reducing hidden control flow and ugly text macros in favor of more transparent metaprogramming, which may help to illustrate one of the bigger issues with Lisp. Lisp itself is simple and elegant, but that doesn't mean it's easy to write simple and elegant Lisp code. Imperative programming is maybe less elegant and beautiful than functional programming, but imperative programming is easy to understand by humans. Sure, C code may not literally execute line by line, but this is how C programmers mentally model execution, to the point where sometimes people are befuddled to learn it’s not the case. It's such an effective approach that CPUs also provide an as-if illusion of in-order execution. And sure, Lisp macros are powerful, but it feels like nobody ever stopped to consider if maybe there's an upper limit to how powerful you really want a programming language to be. Well, I have. I want languages more like Go and Zig. People will always hate at least Go, but it didn't hit TIOBE top 10 out of sheer baseless hype and corporate sponsorship. Simple, easy to understand, perhaps even "stupid" code works. I could be wrong—perhaps the Lisp renaissance is just around the bend. But realistically, I'm not running into any problems where I wish to deal with more clever and elegant code. In fact, I'm running into problems where I wish to deal with dumber and more obvious code. That these ideals often conflict is probably a great source of debate and strife.

BoiledCabbage 5y ago
Programming languages don't win because they are inherently better. Programming languages win because they fill a need better, or are more familiar. There are better languages than other, that help people to write better code, have bugs be easier to find, push better paradigms. But thats not what decides a programming language winner. A winner helps someone do X faster or with less effort. If better languages want to win they need to both be better, and be first to tackle niche X before a worse / familiar language does. And do it sufficiently significantly better to overcome the "familiarity benefit" a worse language will get that enters the same space. A not perfect example - typescript is almost the exact same language as JS and it took almost a decade for people to realize that unless you're writing small solo projects TS is better in just about every way. That is a best case scenario for comparison. Identical syntax, fully backwards compatible. On "language" a complete subset of the other (so no wars about losing a to gain be so is the trade off worth it), almost no new paradigm to learn and it still took our industry almost a decade to agree that it's universally better. If it takes that long to evaluate a clear cut case, its strong evidence that language benefit is not what primarilt drives language adoption. I've been around since the arguments about how Python would never be adopted because "white space was significant and that's a terrible syntax choice." That its distracting and takes mental focus. I've seen all the arguments. When a syntax is different it slows adoption drastically. Not because its worse but people we're humans. People don't like change. Then Python solved a need bettet then everything else and it took off. And once you use Python regularly you see how absurd those whitespace arguments were. JS and its approach took over because that's what the web was written in. If the language of the web had been chosen to be Lisp (as almost happened), everyone would be using Lisp right now without giving it a second thought.

chartpath 5y ago

I think it's possible to take the cult of simplicity too far. As is the case with over engineering. There is always the risk of over-simplifying and dumbing down the inherent complexity of problems. Instead of representing the problem space with a good data model, programmers who love to brag about their love of "simplicity" sometimes end up with many extra "simple" layers than are necessary. It's not a binary because there are a lot of factors that go into simplicity and some matter more than others in different contexts. One person's simplicity is another's tedious verbosity. And another's use of specialized programming techniques is someone else's scary learning curve. Much easier to just label My Preferred Solution as The Most Simple and Parsimonious because clearly I am the smartest and most scientific thinker in the group. Other approaches are Too Complex, therefore I don't need to understand them. It's just projection of insecurity about knowledge gaps by hiding under the appearance of being an iconoclast. That said, there are definitely some castle-in-the-sky and nonsense-on-stilts implementations out there :) Some would say ORMs, others would point to the actor model, and others would even say anything higher level than pointers and for-loops. For what purpose though?

Hypx_ 5y ago
The entire concept of "worse is better" can be more accurately be described as "don't let the perfect be the enemy of the good." Simple, functional solutions are good ideas, and attempt to replace them with perfect ones are likely to fail. In software, that just means writing code using practical languages that are proven to work. It does not need to be written in the ideal language, especially if using the ideal language requires very specialized skills. Furthermore, you do not need software that solves every single corner case. Once you have solve the main problems and most of the minor ones, there's no reason to waste years solving the last few annoying issues.

gambler 5y ago

>The concept known as "worse is better" holds that in software making (and perhaps in other arenas as well) it is better to start with a minimal creation and grow it as needed. It's a horrible moniker for the concept and most people who use it don't really mean piecemeal growth at all. What they do talk about is usually design where some shortcut allows you to quickly accomplish a short-term goal while completely ignoring long-term consequences. This is the mentality that I see everywhere in the software industry today. Go is mentioned here in comments as an example of "worse is better". It fits nicely. The main "feature" of the language is that it doesn't have any constructs that would require an average college grad or a disgruntled Java shitcoder out there to apply effort in order to understand the feature. Thus, people grab the language and mindlessly run with it. By the time the codebase grows where you need more advanced features, it's too late to switch. My prediction is that in a few years when an average Go codebase switches ownership at least once, it will become widely hated, and language developers will start cramming in features that they originally said aren't needed there at all. You've already seen a preview of thing when they replaced cutesey (and obviously broken) dependency management with modules.

grumblenum 5y ago
I don’t think much will change until the incentives change. Right now there is basically no consequence for doing the wrong thing. Software is unique in that defects are generally tolerated. Minimizing time to market can be everything where often winners take all. Thus an incomplete solution today is worth more than a flawless solution in the future. I’m not saying it’s good, but it is a predictable consequence of the market incentives.
michaelfeathers 5y ago
> It's a horrible moniker for the concept and most people who use it don't really mean piecemeal growth at all. What they do talk about is usually design where some shortcut allows you to quickly accomplish a short-term goal while completely ignoring long-term consequences. This is the mentality that I see everywhere in the software industry today. I think the moniker is perfect because that is exactly what piecemeal growth is in nature. That's why code seems to have a biological feel. The rough bit, for we humans, is that code tends toward piecemeal growth because of the economics of change. It is easier to add to something that exists than to make something new, so entities (functions, classes, services) tend to grow in size. We have to step in, as gardeners in a way, to guide structure. I don't know that it was intended by the original people behind micro-services (Fred George comes to mind), but micro-services are a good example of aligning with natural tendency rather than attempting to impose a design and continually falling short. Part of the intent was that you just rewrite a micro-service when it becomes unmaintainable. That's a direct structural correspondence to apoptosis in biology. Cells live for a while, then they are replaced.

draw_down 5y ago

In discussing the example of the loser-ing problem: > The right thing is to back out and restore the user program PC to the instruction that invoked the system routine The concept of “backing out” is left unspecified in the first place which is suspicious, but also there’s no guarantee that it will always succeed. In the-right-thing, what if backing out fails? Or some effect has taken place which can’t be simply “backed out”? You’re left with the same problem anyway. Maybe those dumb old Unix guys were on to something after all.

manmal 5y ago

The notion that a minimal first version is the ideal starting point is mirrored in this quote from John Gall: > A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.

wrycoder 5y ago

Read the original [0] Lisp: the good news, the bad news, and how to win big. (Spoiler: they didn’t.) [0] https://www.dreamsongs.com/WIB.html https://www.dreamsongs.com/WIB.html

jchanimal 5y ago

Worse is better and excellence are not at odds. Worse is better applies at one side of a shearing layer, and excellence on the other. In software, a worse is better API imposes designing for modularity upon the applications that depend on you. An excellent implementation means your internals are clean and efficient.

jstimpfle 5y ago

Why is there never much discussion about the actual technical issue presented in the text, which is how to design a syscall API with respect to interrupt handling? I never thought of the EINTR errno as a hack. It strikes me as very pragmatic and actually the right choice. Am I missing something? Why would one want to save the state of the system call routine when an interrupt occurs and the interrupt handler is executed in user code? The point of interrupts is precisely that they can interrupt a call that otherwise could potentially block forever. When an interrupt occurs, the user code has the chance to completely cancel any attempts to complete the original call. Otherwise, just re-try. The complexity added to the syscall API is small, the practical benefit is very real. So why would I want a general mechanism in the kernel that automatically continues the blocking call after running the interrupt handler? To me the lesson from "Worse is Better" has always been "Don't design before you actually know what you need. You'll probably end up with something that does not do what you want and that you can't fix".