3 ms·

> That's how you get better stuff though, with cycles. This is an assumption that is not necessarily true. In the short term, there are plenty of examples of p

> That's how you get better stuff though, with cycles. This is an assumption that is not necessarily true. In the short term, there are plenty of examples of places where it is not true. As for this being true "asymptotically", that is a hard to verify assumption. What is true is that cycles result in something new. New does not necessarily mean better. The examples you give below are examples where the cycles have worked; there are examples where it has not.

coldtea 10y ago
>This is an assumption that is not necessarily true. In the short term, there are plenty of examples of places where it is not true. Any example? Because cycles (and I could have said "iteration") is what got us from bone tools to spaceships... >The examples you give below are examples where the cycles have worked; there are examples where it has not. That doesn't mean much. Even if a process (e.g. iteration) doesn't always achieve the desire result, it can still be the only way to achieve those results. E.g. asking a person out. It might not always work, but it's still the only way to go on a date with them.
- gajjanag 10y ago
  > Any example? Really depends on what means by better and what one values. Still, here are some relatively unambiguous ones: global warming/climate change, the fragile nature of the current equilibrium wrt nuclear weapons. Maybe long term we will solve them, but in the short term we are worse off. > That doesn't mean much. Even if a process (e.g. iteration) doesn't always achieve the desire result, it can still be the only way to achieve those results. > E.g. asking a person out. It might not always work, but it's still the only way to go on a date with them. There are costs associated with each iteration, and in the context of dating, there is a threshold to the number of rejections. Obviously, at some level any work is an iteration on the existing body of work, in which case your point also does not mean much. My point is that in certain cases it can be best to leave things as they are. "Fixing" rm is one such thing for me: there are trivial workarounds via aliases (can be shipped by a distribution) for those who really care. I am sure your thoughts are not unique on this: people must have tried "fixing" rm in the past, and judged it not worth it. One is completely free to work on "improving" something. However, there should be no expectations that others find it an improvement.

coldtea 10y ago

>This is an assumption that is not necessarily true. In the short term, there are plenty of examples of places where it is not true. Any example? Because cycles (and I could have said "iteration") is what got us from bone tools to spaceships... >The examples you give below are examples where the cycles have worked; there are examples where it has not. That doesn't mean much. Even if a process (e.g. iteration) doesn't always achieve the desire result, it can still be the only way to achieve those results. E.g. asking a person out. It might not always work, but it's still the only way to go on a date with them.

gajjanag 10y ago
> Any example? Really depends on what means by better and what one values. Still, here are some relatively unambiguous ones: global warming/climate change, the fragile nature of the current equilibrium wrt nuclear weapons. Maybe long term we will solve them, but in the short term we are worse off. > That doesn't mean much. Even if a process (e.g. iteration) doesn't always achieve the desire result, it can still be the only way to achieve those results. > E.g. asking a person out. It might not always work, but it's still the only way to go on a date with them. There are costs associated with each iteration, and in the context of dating, there is a threshold to the number of rejections. Obviously, at some level any work is an iteration on the existing body of work, in which case your point also does not mean much. My point is that in certain cases it can be best to leave things as they are. "Fixing" rm is one such thing for me: there are trivial workarounds via aliases (can be shipped by a distribution) for those who really care. I am sure your thoughts are not unique on this: people must have tried "fixing" rm in the past, and judged it not worth it. One is completely free to work on "improving" something. However, there should be no expectations that others find it an improvement.