[pavelkaroukin]

Both OPs examples would be spotted by unit tests and finding actual bug after that is quite trivial.

So I agree, you can trigger some features unpredictably, but this just shows power behind tool and remind you to be well self-organized =)

[mst]

Frankly, the first one is a clear explanation of why you should have a config object not a hash.

Don't use a freeform data structure for data that isn't actually freeform if you want the perl5 VM to be able to catch errors for you.

Shutterstock are legendary round the perl community for being a hive of badly written ancient code that never gets significant refactoring effort though; combine this with a significant tendency not to use libraries due to NIH syndrome and their experience of gotchas becomes more an inevitability than bad luck.

Or: You might love your programming language, but if your relationship with it tends towards the abusive, the problems end up cutting both ways.

(though it's only in the past half decade that the perl community as a whole has seriously moved to trying to make the sensible techniques standard - and any project started during the dot-com era is almost certainly a hive of badly written now-ancient code; there's similarly timed spikes of awful PHP and then rails code due to their popularity spikes since)

[douglashunter]

> Shutterstock are legendary round the perl community for being a hive of badly written ancient code that never gets significant refactoring effort though

I like to think that we're legendary for choosing a sane upgrade path to a services based approach built on Modern Perl. For our help debugging Dancer's (https://github.com/sukria/Dancer/issues/642) and Feersum's (https://github.com/stash/Feersum/issues/12) header parsing troubles. For our continuous sponsorship of YAPC (http://yapcna.org/sponsorship/our-sponsors).

Heh, we're legends in my own mind! [grin]