26 ms·

I spent a while in Perl and tend to agree, I was the only one in my group who went out of his way to write readable/maintainable code. Everyone else believed in

I spent a while in Perl and tend to agree, I was the only one in my group who went out of his way to write readable/maintainable code. Everyone else believed in extreme code ownership and enjoyed playing "golf". I've never coded in Python, but spent a little time in Ruby and liked how they knew you could do things many different ways, so the community and leadership focused on identifying and promoting idioms. I think that's a key factor in adoption. Perl had some of that (and the excellent "Effective Perl" had a chapter on it), but you need to make it part of your culture.

draegtun 15y ago
> so the community and leadership focused on identifying and promoting idioms. I think that's a key factor in adoption. Perl had some of that (and the excellent "Effective Perl" had a chapter on it), but you need to make it part of your culture. Yes it does need to be part of your culture. And there is no reason for a Perl team/shop not to because best practise idioms are heavily preached [1] and baked into [2] Perl and its community. [1] Modern Perl movement & Perl Best Practises (http://en.wikipedia.org/wiki/Perl_Best_Practices http://en.wikipedia.org/wiki/Perl_Best_Practices) [2] Perl::Critic (https://metacpan.org/module/Perl::Critic https://metacpan.org/module/Perl::Critic), Moose (http://moose.perl.org http://moose.perl.org), EPO extended core (http://www.enlightenedperl.org/extendedcore.html http://www.enlightenedperl.org/extendedcore.html), etc