3 ms·

What is there to be sad about retrying ideas? Maybe the reason they failed the first time is no longer true.

spc476 3y ago
It's not the retrying that's bad, but the hype, that this time, it'll be better! It's almost never better.
Arnt 3y ago
Indeed. Maybe. When people turn up at the IETF and want to repeat a bad idea, that's the kind of thing they say. They say "the reasons why foo was bad don't necessarily apply to bar" while waving their hands. They try try to make it sound as if the reasons actually don't apply, usually without having much idea about what the reasons were.
phantomathkg 3y ago
I think the parent comments indicate s/he experience something bad twice.
kstenerud 3y ago
Because often they DIDN'T fail the first time. It's just that when the next batch of devs decided they needed something, they didn't bother learning from the previous generation, and instead re-did every mistake of the past 30 years, to finally "invent" the already-working approach that had been there for decades. One example that springs to mind is GUI code. We've gone through 3 cycles of that so far (including the original). Another is programming languages.
- adql 3y ago
  And biggest one is cloud. We went from sending our code to run at mainframe owned by big corporation and leased monthy for a price to sending our code to big corporation to run at not-mainframe for a monthly price
cryptonector 3y ago
There's a lot of wheel reinvention going on in our industry. Take Protocol Buffers. It exists because "ASN.1 sucks", but it's got all the problems that DER had, so it's really just a bad reinvention of ASN.1. In just the context of serialization formats you'll find a mind boggling amount of wheel reinvention. From S-expressions to all the 1980s RPCs (Apollo Domain, ONC, DCE, ...) to COM to all the ASN.1 encoding rules, to XML and FastInfoSet, to JSON and all the binary JSONs out there, to Protocol Buffers and Flat Buffers and... It's nuts. It goes on an on. And there's one or several RPCs for every one of these.

It's not the retrying that's bad, but the hype, that this time, it'll be better! It's almost never better.

Arnt 3y ago

Indeed. Maybe. When people turn up at the IETF and want to repeat a bad idea, that's the kind of thing they say. They say "the reasons why foo was bad don't necessarily apply to bar" while waving their hands. They try try to make it sound as if the reasons actually don't apply, usually without having much idea about what the reasons were.

phantomathkg 3y ago

I think the parent comments indicate s/he experience something bad twice.

kstenerud 3y ago

Because often they DIDN'T fail the first time. It's just that when the next batch of devs decided they needed something, they didn't bother learning from the previous generation, and instead re-did every mistake of the past 30 years, to finally "invent" the already-working approach that had been there for decades. One example that springs to mind is GUI code. We've gone through 3 cycles of that so far (including the original). Another is programming languages.

adql 3y ago
And biggest one is cloud. We went from sending our code to run at mainframe owned by big corporation and leased monthy for a price to sending our code to big corporation to run at not-mainframe for a monthly price

cryptonector 3y ago

There's a lot of wheel reinvention going on in our industry. Take Protocol Buffers. It exists because "ASN.1 sucks", but it's got all the problems that DER had, so it's really just a bad reinvention of ASN.1. In just the context of serialization formats you'll find a mind boggling amount of wheel reinvention. From S-expressions to all the 1980s RPCs (Apollo Domain, ONC, DCE, ...) to COM to all the ASN.1 encoding rules, to XML and FastInfoSet, to JSON and all the binary JSONs out there, to Protocol Buffers and Flat Buffers and... It's nuts. It goes on an on. And there's one or several RPCs for every one of these.