4 ms·

Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works. I'm old enough to have lived through

Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works. I'm old enough to have lived through this multiple times now :-(

diogenes4 3y ago
Not really relevant to networking, but I firmly believe hash tables (and hashing) had a concrete starting point within recorded history, which appears to be January 1953.
- pncnmnp 3y ago
  Fascinating! I delved into Knuth's "TAOCP Volume 3", specifically the Hashing section, and indeed: > The idea of hashing appears to have been originated by H. P. Luhn, who wrote an internal IBM memorandum in January 1953 that suggested the use of chaining; in fact, his suggestion was one of the first applications of linked linear lists. Unfortunately, I couldn't locate the memo. It seems they never made it public. However, I stumbled upon a nice paper from 1953 in which he discusses enhancing search engines by refining sets - http://jonathanstray.com/papers/Luhn-SearchEngine-1953.pdf http://jonathanstray.com/papers/Luhn-SearchEngine-1953.pdf Knuth also references Arnold I. Dumey, who appears to be the first to describe hash tables in open literature. I was able to retrieve his paper: https://archive.org/details/sim_computers-and-people_1956-12_5_12/page/n5/mode/2up https://archive.org/details/sim_computers-and-people_1956-12.... Dumey initiates with an O(log n) solution using the "twenty questions" game, subsequently explaining how we'd be better off if we could do computation before we access the memory. I found his introduction to the hash function rather intriguing: > A certain manufacturing company had a parts and assemblies list of many thousands of items. A mixed digital and alphabetic system of numbering items was used, of six positions in all. Eight complex machines or assemblies were sold to the public. These had item numbers taken from the general system. In setting up a punch card control system on these eight items it was first proposed to record the entire six digit number for each item. However, examination of the eight assembly numbers disclosed that no two were alike on the fourth digit. It was therefore sufficient, for sorting purposes, merely to record the fourth digit, thereby releasing five badly needed information spaces for other purposes. > This rather extreme case indicates that an examination of the item description may disclose a built-in redunancy which can be used to cut the field down to practical size. He further discusses handling duplicates and introduces chaining: > Adjust the addressing scheme, according to a method which will be described later, to reduce the number of direct addresses, and use the excess locations to store overflows. Put the overflow address at the tail end of stored item information. What the best reduction is varies from case to case. Note that the expectation of the number of accesses to be made goes up when these methods are used. At each access we check by using the complete item description, usually. And discusses how a somewhat efficient hash address can be constructed by diving a prime number and using the remainder: > Consider the item description as though it were a number in the scale of 37 or whatever. Or write it as a binary number by using the appropriate punched tape coding. Divide this number by a number slightly less than the number of addressable locations (the writer prefers the nearest prime). Throw away the quotient. Use the remainder as the address, adjusting to base 10, as the case may be.
blowski 3y ago
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
deleted 3y ago
[deleted]
readthenotes1 3y ago
Said every old person since the beginning of sentience

Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works. I'm old enough to have lived through this multiple times now :-(

diogenes4 3y ago

Not really relevant to networking, but I firmly believe hash tables (and hashing) had a concrete starting point within recorded history, which appears to be January 1953.

pncnmnp 3y ago
Fascinating! I delved into Knuth's "TAOCP Volume 3", specifically the Hashing section, and indeed: > The idea of hashing appears to have been originated by H. P. Luhn, who wrote an internal IBM memorandum in January 1953 that suggested the use of chaining; in fact, his suggestion was one of the first applications of linked linear lists. Unfortunately, I couldn't locate the memo. It seems they never made it public. However, I stumbled upon a nice paper from 1953 in which he discusses enhancing search engines by refining sets - http://jonathanstray.com/papers/Luhn-SearchEngine-1953.pdf http://jonathanstray.com/papers/Luhn-SearchEngine-1953.pdf Knuth also references Arnold I. Dumey, who appears to be the first to describe hash tables in open literature. I was able to retrieve his paper: https://archive.org/details/sim_computers-and-people_1956-12_5_12/page/n5/mode/2up https://archive.org/details/sim_computers-and-people_1956-12.... Dumey initiates with an O(log n) solution using the "twenty questions" game, subsequently explaining how we'd be better off if we could do computation before we access the memory. I found his introduction to the hash function rather intriguing: > A certain manufacturing company had a parts and assemblies list of many thousands of items. A mixed digital and alphabetic system of numbering items was used, of six positions in all. Eight complex machines or assemblies were sold to the public. These had item numbers taken from the general system. In setting up a punch card control system on these eight items it was first proposed to record the entire six digit number for each item. However, examination of the eight assembly numbers disclosed that no two were alike on the fourth digit. It was therefore sufficient, for sorting purposes, merely to record the fourth digit, thereby releasing five badly needed information spaces for other purposes. > This rather extreme case indicates that an examination of the item description may disclose a built-in redunancy which can be used to cut the field down to practical size. He further discusses handling duplicates and introduces chaining: > Adjust the addressing scheme, according to a method which will be described later, to reduce the number of direct addresses, and use the excess locations to store overflows. Put the overflow address at the tail end of stored item information. What the best reduction is varies from case to case. Note that the expectation of the number of accesses to be made goes up when these methods are used. At each access we check by using the complete item description, usually. And discusses how a somewhat efficient hash address can be constructed by diving a prime number and using the remainder: > Consider the item description as though it were a number in the scale of 37 or whatever. Or write it as a binary number by using the appropriate punched tape coding. Divide this number by a number slightly less than the number of addressable locations (the writer prefers the nearest prime). Throw away the quotient. Use the remainder as the address, adjusting to base 10, as the case may be.

blowski 3y ago

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

deleted 3y ago

[deleted]

readthenotes1 3y ago

Said every old person since the beginning of sentience