←back to thread

1371 points yett | 2 comments | | HN request time: 0.889s | source
Show context
amenghra ◴[] No.43774928[source]
IMHO, if something isn’t part of the contract, it should be randomized. Eg if iteration order of maps isn’t guaranteed in your language, then your language should go out of its way to randomize it. Otherwise, you end up with brittle code: code that works fine until it doesn’t.
replies(11): >>43774993 #>>43775199 #>>43775210 #>>43775344 #>>43775361 #>>43775510 #>>43775759 #>>43776084 #>>43776311 #>>43776598 #>>43778608 #
codebje ◴[] No.43778608[source]
I once updated a little shy of 1mloc of Perl 5.8 code to run on Perl 5.32 (ish). There were, overall, remarkably few issues that cropped up. One of these issues (that showed itself a few times) was more or less exactly this: the iteration order through a hash is not defined. It has never been defined, but in Perl 5.8 it was consistent: for the same insertion order of the same set of keys, a hash would always iterate in the same way. In a later Perl it was deliberately randomised, not just once, but on every iteration through the hash.

It turned out there a few places that had assumed a predictable - not just stable, but deterministic - hash key iteration order. Mostly this showed up as tests that failed 50% of the time, which suggested to me a rough measure of how annoying an error is to track down is inversely correlated with how often the error appears in tests.

(Other issues were mostly due to the fact that Perl 5 is all but abandoned by its former community: a few CPAN modules are just gone, some are so far out of date that they can't be coerced to still work with other modules that have been updated over time. )

replies(1): >>43781009 #
1. zerr ◴[] No.43781009[source]
At booking.com? :)
replies(1): >>43799122 #
2. codebje ◴[] No.43799122[source]
No, but they do (did?) have a vast ocean of Perl, and I did know a hacker or two who got hired to work there on it.