in reply to to perl or not to perl
My editors rarely expect me to write English such that a person who speaks only Mandarin could understand the point of my book or article. (I find the argument that "Perl is hard to read" similarly toothless.)
tilly and Abigail and many other posters are correct. You should establish what the coding standards are and work within those. I hope your company encourages good communication between programmers such that you can learn from each other.
I would rather have one new programmer willing and able to learn than ten seasoned programmers unwilling even to ask me what my latest idiom means. Any organization that treats its programmers like stagnant morons will soon retain only people who refuse to learn.
You can write staggeringly useful programs in a small subset of Perl, but rare is the program over 50 lines that can't be improved with hash slices, for example.
If you have to, be subversive. Show your fellow programmers another way to do it, and say, "Here is what it does, here is why it is better, maybe we should consider it." It's subversive because you're teaching them and appealing to a hopefully-just-dormant sense of curiosity.
Best of luck.
|
|---|