Your point is a good one; and if I were in charge of the department, that's what I'd do. On the other hand, I'm not.

1) I'm not a manager; I don't get to decide how to spend my time. Projects get given to me and I do the best I can with them. Training is not really part of my job description; so I'd have to do training for free after hours. I don't mind teaching, but doing it for free after a long day's work, knowing it will benefit my employer more than it will me, doesn't seem all that fair to me.

2) Many of my co-workers don't speak English as a first language; discussing technical concepts is more difficult because of a language barrier. Essentially, at times I end up teaching two languages at once (English+Perl); so progress is frustratingly slow, and, like I said, it's not something I'm supposed to spend much time on.

3) I just don't find it that hard to write simpler code; part of what I was railing at was an ex-coworker using an incredibly obfuscated micro-language solution (with ties, coderefs, objects, evals -- the whole kitchen sink) where a simple SQL query would have sufficed. I find that if I write in a simple, consistant style, I don't have to worry about the alternative ways of "phrasing" something; there's the simple, straightforward encoding, and then there's "something else". If I have to think about something else, odds are I need to think about how to encapsulate the problem better. Nothing I work with is very hard.

Perhaps if I were an engineer working with differential equations, or a statistician analysing stock market trends, or an AI researcher, I'd need some of those exotic features in Perl. But I just don't need that much complexity to automate FTP downloads, or convert file formats, or do simple financial calculations, or to implement other simple business logic. I get no benefit from @INC codrefs, or other wacky perl features. I just have to make sure they're not being used against me. :-(

-
Ytrew