Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.
Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.
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.
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.
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
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.
> 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
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.... 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.