You could:
Try to help them understand why you would rather use strict and warnings. (Of course, this means you'll need to know that.)
I doubt "Because the Perlmonks say so" will be entirely sufficient. If you can demonstrate a business case, one outlining the benefits for detecting common mistakes early and so forth, you should be able to make headway. Most bean-counter types understand better return on the investment.
Perhaps you could propose a test scenario, one comparing your current practices against the results of using strict & warnings. If it works, then you'll have something concrete to work with.
Also, it may help to propose a transition plan, one that updates your legacy code over time. That can be an effective way to rewrite stuff without slowing down the entire process.
Use strict and warnings to develop your contributions to the project and then deactivate those before turning it in. I'm not too fond of that idea myself, but at least your work gets some benefit.
Failing the above, put up with it until you find a position with a more enlightened organization. (I'm not sure it's productive to be in a place where you're marginalized for wanting to use better coding practices.)
As far as programming Perl if you're conforming to the (sub)standards they demand, I don't see why not. It's still Perl and you're still learning something about it. Just keep learning the best practices on your own and be ready to move if there's an opportunity.
--f
In reply to Re: to perl or not to perl
by footpad
in thread to perl or not to perl
by utopian
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |