Front page | perl.perl5.porters |
Postings from August 2021
Philip R Brenan writes: > If the proposed new hash function is "better" than the existing function > then the existing hash function is not "the best" which raises the > possibility that there might be other "better" hash functions to choose > from. One such possibility might use multi way trees: It might. But then again, Nicholas has a proof-of-concept of his specific proposal, which is different to the possibility of other algorithms. > May I therefore propose that if hash functions are in fact in play: I don't think it works that certain categories of changes are “in play” or not: more that any proposal is considered on its merits. > there should be a competition to find the best hash functions > currently available today and that the best of the best should be made > available to all Perl programmers via a "use' clause that gives each > Perl programmer the opportunity to choose the best function for their > specific needs? You're suggesting that even if the proposed new hashing algorithm (with a working proof-of-concept, a list of the fall-out from switching to it and what needs patching, and an experienced Perl 5 developer seemingly offering to do the work involved) is agreed to be an improvement on the current one, that we should decline this proposal for the aspiration of a competition and switchable algorithms? A competition that would take effort to run and oversee (and to come up with entries for), and then further effort implementing each of the chosen algorithms, and their switching method? I'm not saying there wouldn't be any advantages in that happening. But even if volunteers were found to do all that (and those were additional volunteers, not taking time away from doing other things on Perl) and it ran very smoothly, it would clearly take longer to do than making the proposed hash algorithm switch. And there's the chance that it wouldn't go well, or efforts would fizzle away without reaching completion. At which point it'd be several years later and we'd still be on the current hashing algorithm. Let's debate a specific proposal on its own merits, and not discard it, or derail the discussion, in the hope of something bigger and vaguer that possibly could happen in the future. > This would provide a powerful argument for using Perl - the only > language that puts the needs of its application programmers first and > unambiguously ahead of the needs of the programmers supporting the > language. I can think of dozens of ways in which languages' designs prioritize their users over their own developers. I'm not sure that switchable hashing algorithms is one that would occur to most users, nor that it's such a key feature that it would bring hoards running to Perl. One could even argue the opposite: that users are best served by being freed of such low-level considerations, trusting the implementation to do something sensible without their having to even think about it. But that's largely irrelevant anyway: even if I'm wrong and user- switchable hashing algorithms is just what Perl needs, that still isn't a reason to drop the specific proposal being made in this thread. SmylersThread Previous | Thread Next